Re: PPPOE vs DHCP

[Jack Bates <jbates () brightok net>]

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 
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