Hey folks...
I'm meeting with a customer tomorrow (service provider, rural telco) and
we're pitching they move to a PPPOE platform most likely. But to be fair,
I'm looking to draw up a comparison so they are "well informed" of the
pros/cons. Has anyone done this?
I came up with the following brief start:
PPPOE vs DHCP
PPPOE Pros
Of course. There are plenty of ISPs doing ETTH with DHCP based solutions. and L2 and L3 switches for switching/routing.
Only reason I would ever roll out PPP today is because of some regulatory demand to provide bitstream to others, and most likely not even then (there are better ways).
Basically all your "con:s" on DHCP isn't true, they can all be solved and has been for 10 years by others.
PPPOE Pros
----------
Allows full authentication of customers (requires username/password)
Authentication isn't necessary if you have other methods of turning off a port. Authentication can actually be a Con, as the username/password can be forgotten and a truck rolled to reprogram a CPE because the user uses gmail (email often being the only other time the username/password is used).
Allows control over customer connections (suspend accounts, create accounts
etc)
Depending on telco processes, this is easily handled in the DLC (often times combined with turning off their phone service).
Easily assign static IP to customer (no MAC address or CPE information
required)
Option-82!
Assign public subnet to customer with ease (no manual routing required)
I'll give you this one.
IPv4/IPv6 fully supported on Juniper platform as required
I'm pretty sure it's supported for bridging/DHCP environments too.
Usage tracking (GB transfer) from radius generated data
It works, but there are other accounting methods.
PPPOE Cons
----------
Requires PPPOE termination router (Juniper ERX for example)
You're putting Juniper ERXs at customer houses? Really? I'd expect to see DSL/Cable drops which will utilize cheap end CPE (most of which don't support IPv6 hardly at all).
Requires Radius server(s) to assign and track customer IP assignments/usage
Customers require username/password to connect
Customers require PPPOE client software or router to connect
8 bytes MTU overhead
The 8 bytes usually isn't too bad and is counteracted in bridging environments by vlan tags (often dual tagged for proper isolation). You can usually set the MTUs 8 bytes larger to compensate and still allow 1500 byte IP packets.
DHCP Pros
---------
Simplistic - plug and play 90% of the time
Not when it's done right.
No MTU overhead, full 1500 MTU frame size
Yes and no. When you run vlan tags, it's a bit more complex. If using ATM termination, it's less complex.
DHCP Cons
---------
No authentication occurs (anyone physically connected can use Internet
generally)
For consumer use, not a concern. Hijacking a phone line, for example, may get you connected, but you've also broken the customer's connection. If you are on site, plug in behind the CPE and you're golden either way.
No user tracking without tracking customer CPE MAC addresses
option-82, and when I do track, I track IP -> MAC -> Interface. The MAC is just because customers ask which MAC. I only really care about IP -> Interface.
No usage tracking builtin to DHCP (GB transfer)
Granted.
There are several factors involved here. The first major thing is that we
believe the customer wants to move towards caps on their customer usage (X
amount of GB per month). Today, they are doing static IP assignments but
the interesting thing is that the CPE they have control over today (Comtrend
routers with DSL modem builtin). I know there's not always a good vs bad
here but looking for opinions from folks who may have already done this
comparison for a "boardroom discussion"....
Over the last decade, I've been building out all DSL networks as ATM, 1 pvc per interface (cisco RBE ftw) and Double tagged vlans, 1 vlan per interface (cisco unnumbered subinterfaces ftw). Juniper has similar stuff. We utilize proxy arp for customer communications. This creates a fully isolated environment with the router handling all the security and provisioning. Massive configs as I have it currently, though templating and dynamic configurations with radius backends has been getting added into newer code (hear the ASR has some nice backend options). All DSL cpes provided by the telcos are in bridging mode only (even wireless model were bridged).
Why did I do this? IPv6.
Telcos who did not follow my advice currently have the following issues. 1) PPPoE, must now replace every customer CPE (given out for free, customer expects telco to pay for replacement). Every DSL modem vendor I've talked to has stated that IPv6 support will not be in the older CPEs. 2) DSLAMs without q-in-q support or extremely limited vlan support requiring the DSLAM to do DHCP snooping and it's own security. IPv6 does not work... Period. Code will have to be upgraded for each of these DSLAMs to support IPv6. Vendors currently don't support it, and word is vendors are changing to support more vlans quickly. 
Ideally? You are starting a brand new network with no broadband customers. You have an inexpensive CPE which already supports IPv6 beautifully. All network equipment supports baby giants, or even better, jumbo frames. You adjust the MTU, you run PPPoE w/ v4/v6 and 1500 byte IP packets. Have a nice day. If you don't have the benefit/capability, other options tend to be more cost effective.
Jack
In article <051001cbbcf0$c33e8b20$49bba160$@org> you write:
PPPOE vs DHCP
Allows full authentication of customers (requires username/password)
You probably want to authenticate on circuit id, not username/password.
ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added
by the DSLAM or FTTH access switch when using an ethernet transport layer.
It's just a different radius attribute to authenticate on, no magic.
We do that so a customer doesn't have to configure his/her router
to get online.
Easily assign static IP to customer (no MAC address or CPE information
required)
Don't need that with DHCP either, if you run a DHCP server that can
assign IP addresses based on option82. I run a patched ISC dhcp3 server,
but I understand that ISC dhcp4 makes this pretty easy
Assign public subnet to customer with ease (no manual routing required)
Don't need manual routing with DHCP either, if you use a real
bras such as a juniper, since you can have it authenticate off
radius first before doing DHCP, and in the radius reply you can
return a static route.
Usage tracking (GB transfer) from radius generated data
True, at least juniper e-series BRASes don't send radius accounting
for atm rfc1483/bridged connections for some reason.
DHCP Cons
---------
One more DHCP con is that if you have an ethernet transport network
from the DSLAM or FTTH access switch to your router that lumps together
multiple customers in one VLAN, something along the way is probably
doing DHCP sniffing to set up routing. And you can be just about sure
that won't work with IPv6. VLAN-per-customer will work (and is a
really a great model, for all types of encapsulation)
Mike.
I just wanted to say thank you for a TONNE of feedback I received on this
topic. This has been of great help in filling in some items I missed in my
quick list.
Will try to respond offlist to several of you that responded - got over 100
replies offline with some interesting ideas. I definitely learned I should
have made my original post a bit clearer though and specifically the usage
tracking component 
Normally I would post a summary on these kinds of topics but quite honestly
there is such a huge varience in opinions and options around this that I'll
probably just invite anyone to hit me offlist if they are interested in the
feedback received so far...
Thanks folks,
Paul
Thank you for the response...
I should have made this a bit clearer - option 82 is an option on their
DSLAM's today and is supposed to work "not bad". But this customer may also
be looking at other services such as wireless in the future which does not
support option 82 - they want a unified delivery of their product. I left
out this detail as you can see
Also, the comment " so a customer doesn't have to configure his/her router
to get online" is also interesting - we WANT our customers to configure
their routers and understand them to a basic degree... this coming from a
security perspective where we are seeing a magnitude to customer routers
getting hacked or their wireless left open etc.
Usage based billing is a very hot topic in this area (Ontario, Canada) and
we will confirm with the customer today that they do indeed want to track
all GB usage per customer...
Today, they have no interest nor can they get IPv6 which is a shame....
having said that, we want to provide a solution to them than can do IPv6 in
the future...
Thanks,
Paul
PPPOE Cons
----------
Requires PPPOE termination router (Juniper ERX for example)
You're putting Juniper ERXs at customer houses? Really? I'd expect to
see DSL/Cable drops which will utilize cheap end CPE (most of which
don't support IPv6 hardly at all).
No, we're not putting ERX's at people's homes ... not sure where you got
that from? What I was saying is that if you're running PPPOE then you have
have somewhere in the service provider network to "terminate" the
sessions....
Paul
Hey. It was the middle of the night. I completely misread which side of the termination you were referring to.
Terminating PPPoE generally isn't much different than terminating VLANs. In Juniper world, it requires the right equipment. Cisco world, it's not generally a big deal.
Jack
http://s-tools1.juniper.net/solutions/literature/white_papers/200187.pdf
3rd party vendors might want to have me onboard 
otherwise you can come up w/
your own piece of kit, rfc' it and a few white papers bla and boom, start your
own business like the others have done in the past ..........
Terminating PPPoE generally isn't much different than terminating
VLANs. In Juniper world, it requires the right equipment. Cisco
world, it's not generally a big deal.
Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and now want IPv6 on your PPPoE. Not that I'm becomming increasingly bitter about that platform or anything...
Regards,
Tim.
10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in utilizing the IOS SR line. I've played with PPPoE and bridging on the 7200s mostly. I need to kick up an ASR, as I hear it's specialized code line has much better IPv6 support than IOS SR. both XR/XE codes seem to be much more richly featured, especially for radius backending DHCP.
Jack
10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in
utilizing the IOS SR line. I've played with PPPoE and bridging on the
7200s mostly. I need to kick up an ASR, as I hear it's specialized
code line has much better IPv6 support than IOS SR. both XR/XE codes
seem to be much more richly featured, especially for radius backending
DHCP.
So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR".
Regards,
Tim.
This is same solution they've given for the 7206 and other traditional IOS platforms. I haven't checked, but all the RBE/unnumbered vlan support for IPv6 with proxy-ND, better radius backend for DHCPv6, and supposedly IA_TA support for DHCPv6 will be in the ASR only. The features in IOS SR train are somewhat functional but extremely limited.
If I find myself having to spend money on ASRs, I may just spend the money replacing them with Juniper. Only reason I haven't is that I haven't needed to spend the money at all.
Jack
If Cisco won't do a good job of RBE on the 7206VXR, I may just need to stick with PPPoEv6 on the SR train. I have that successfully working in a test bed.
Frank
By IA_TA support, do you mean the ability for the 7206VXR to act as the DHCPv6 server? If I understand you correctly, I have it working well with DHCPv6 relay.
Frank
We were a mostly PPPoA shop, and were doing PPPoE on our FTTH but moved to
DHCP because of our desire to move to v6 without waiting for the access
vendor and to get rid of supporting that username/password combo. And DSL
modems that we're replacing in the field we're moving from PPPoA to PPPoE
because of Ethernet transport because I'm not as sold on RBE in a 7206VXR,
even though I really could use the same Option 82 in the same way as we do
for FTTH.
VLAN-per-user seems like a lot of router config overhead, though I could be
proved wrong if I misunderstand.
Frank
Yeah, IA_TA is the temporary addresses (compared to prefix delegation). I haven't tested it with relay, as I've hoped to avoid that (hate depending on remote servers). I'm interested, though, if RBE and unnumbered vlans can be made to work with IPv6 even with the relay as they do in IPv4. Documentation leads me to believe they won't (given cisco docs state that they figured one prefix per subinterface and no proxynd as they did in IPv4). I guess you could possibly manually activate proxynd on each subinterface? I know the routing mechanisms themselves work, verified with prefix delegations.
Jack
What was your problem with RBE? I've loved it (except for the 3000 interface configs that take 3-5minutes to write).
Jack
Hi,
I have not seen this in the discussion yet.
http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011
CPE support does not seem to be very broad yet.
As far as I can see there is almost PPPoE only for IPv6 in Europe.
In Germany cable is a mess by regulation. So no cable/dhcp.
There used to be a DTAG monopoly with aDSL only and PPPoE only.
Most ISPs still rely on the DTAG infrastructure. That is why
very PPPoE biased.
There is a high concentration of AVM in the CPE with Infineon
chipsets in both DSLAM and DSL-Modem / Router
--- OT ---
Living in the outback with DSL-1000 max I made some tests with
CIS-modem, Broadcom Cipset (Hitachi) and Infineon/AVM.
The CIS-modem is no longer sold but far superior to the others.
I had trouble to get some of the Broadcoms working.
Replacing the power supply unit (wallwart, not regulated) with
a regulated and filtered 13.5 volts power supply unit for my hamradio
both the bradcoms and the AVW worked almost a good as the CIS-modem.
Some of you might remember tuneable hum noise in ancient am-radios.
That noise could be cured by shunting the rectifiers with 4.7 nano
farad capacitors. The spectrum of the modem shows a lattice that
goes away with a reulated and filtered power source.
Of coarse you cannot spend a week experimenting at any client site.
So excuse the noise.
--- /OT ---
Hi,
I have not seen this in the discussion yet.
IPv6 CPE Survey - Updated (January 2011) | RIPE Labs
CPE support does not seem to be very broad yet.
As far as I can see there is almost PPPoE only for IPv6 in Europe.
As long as there is an ADSL interface they usually support both, goes for major vendors as well as some smaller ones.
In Germany cable is a mess by regulation. So no cable/dhcp.
There used to be a DTAG monopoly with aDSL only and PPPoE only.
Most ISPs still rely on the DTAG infrastructure. That is why
very PPPoE biased.There is a high concentration of AVM in the CPE with Infineon
chipsets in both DSLAM and DSL-Modem / Router
Part of the DTAG modems seem to be 7570 based and for what I have been told by German friends these can be flashed to the standard production releases. Not of much use for native, but you will get tunnel support in the box.
Marco