PPPOE vs DHCP
jbates at brightok.net
Wed Jan 26 00:44:46 CST 2011
On 1/25/2011 6:34 PM, Paul Stewart wrote:
> 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
> Allows control over customer connections (suspend accounts, create accounts
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
> 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
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 ->
> No usage tracking builtin to DHCP (GB transfer)
> 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.
More information about the NANOG