isabel dias isabeldias1 at yahoo.com
Wed Jan 26 08:39:36 CST 2011



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


From: Paul Stewart <paul at paulstewart.org>
To: Miquel van Smoorenburg <mikevs at xs4all.net>
Cc: nanog at nanog.org
Sent: Wed, January 26, 2011 1:40:49 PM
Subject: RE: PPPOE vs DHCP

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



-----Original Message-----
From: Miquel van Smoorenburg [mailto:mikevs at xs4all.net] 
Sent: Wednesday, January 26, 2011 4:16 AM
To: paul at paulstewart.org
Cc: nanog at nanog.org
Subject: Re: PPPOE vs DHCP

In article <[email protected]> you write:
>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

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)



More information about the NANOG mailing list