Mailing List Archive: NANOG: users

PPPoE vs. Bridged ADSL

Index | Next | Previous | View Threaded

jdupuy-list at socket

Oct 28, 2009, 2:20 PM

Post #1 of 19 (1245 views)
Permalink

PPPoE vs. Bridged ADSL

There is a debate among our engineering staff as to the best means of
provisioning broadband service over copper facilities. Due to our
history, we have a mix out in the field. Some customers are on DSLAMS
set up for bridged connections with DHCP; isolated by a variety of means
including VLANS. Some customers are on PPPoE over ATM. Some customers
are on PPPoE over ethernet (PPPoEoE ?? :) ).

There seem to be pros and cons to both directions. Certainly true
bridging has less overhead. But modern CPEs can minimize the impact of
PPPoE. PPPoE allows for more flexible provisioning; including via
RADIUS. Useful for the call center turning customers on/off without NOC
help. But VLAN tricks can sometimes do many of the same things.

Opinions on this? I'd be interested in hearing the latest real world
experience for both and the direction most folks are going in.

BTW, I doubt it is relevant to the discussion, but most of our DSLAMS
are Adtran TA5000s (or are being migrated to that platform.) We are
mostly a cisco shop for the upstream routers.

Thanks,

John

jbates at brightok

Oct 28, 2009, 2:32 PM

Post #2 of 19 (1215 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

JD wrote:
> There seem to be pros and cons to both directions. Certainly true
> bridging has less overhead. But modern CPEs can minimize the impact of
> PPPoE. PPPoE allows for more flexible provisioning; including via
> RADIUS. Useful for the call center turning customers on/off without NOC
> help. But VLAN tricks can sometimes do many of the same things.

Call your vendor and demand better radius backend support for dhcp. :)

The largest fallback to PPPoE is the CPE needing to terminate the PPPoE
or the customer's router/computer/etc needing to do so. This can be a
pain especially in business environments. I have one section of my
network (maintained by counterpart, not me) that is 90% PPPoE/A. The
other 10% is bridge due to customer needs and CPE limitations.

I personally run all my stuff as bridge, including all the CPEs.

> BTW, I doubt it is relevant to the discussion, but most of our DSLAMS
> are Adtran TA5000s (or are being migrated to that platform.) We are
> mostly a cisco shop for the upstream routers.

I have been extremely happy with unnumbered vlans in the cisco work for
terminating mass vlans from dslams that support 802.1ad. The fact that
it works right next to RBE works great for me. The current IPv6 layouts
aren't as pretty for this setup, though.

Jack

saxon.jones at gmail

Oct 28, 2009, 2:44 PM

Post #3 of 19 (1209 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

On Cisco hardware PPPoE was cleaner if you have other ISPs' customers on
your network and you want to put them in their own VRF's. I've been out of
that world for a while now, so maybe it's changed.

-saxon

2009/10/28 JD <jdupuy-list [at] socket>

> There is a debate among our engineering staff as to the best means of
> provisioning broadband service over copper facilities. Due to our history,
> we have a mix out in the field. Some customers are on DSLAMS set up for
> bridged connections with DHCP; isolated by a variety of means including
> VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE
> over ethernet (PPPoEoE ?? :) ).
>
> There seem to be pros and cons to both directions. Certainly true bridging
> has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE
> allows for more flexible provisioning; including via RADIUS. Useful for the
> call center turning customers on/off without NOC help. But VLAN tricks can
> sometimes do many of the same things.
>
> Opinions on this? I'd be interested in hearing the latest real world
> experience for both and the direction most folks are going in.
>
> BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are
> Adtran TA5000s (or are being migrated to that platform.) We are mostly a
> cisco shop for the upstream routers.
>
> Thanks,
>
> John
>
>

dave at mvn

Oct 28, 2009, 3:10 PM

Post #4 of 19 (1208 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

>
> Opinions on this? I'd be interested in hearing the latest real world
> experience for both and the direction most folks are going in.
>
> I can't speak to which would be better on copper specifically, but in
general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff
will be similar (you'll need a way to authenticate users, turn them off and
on, et cetera); the differences won't be all that big. Either you're storing
their MACs in a database, or their port assignments and VLAN tags, or their
usernames and passwords.

With PPPoE, however, the end-user can't just plug in and go - they'll have
to configure their PC, or a DSL modem, or something. That means a phone call
to your tech support, most likely. In many cases, DHCP can lead to
plug-and-play simplicity, which means they don't have to call you, and you
don't have to answer their calls. Everyone wins. :)

David Smith
MVN.net

walter.keen at rainierconnect

Oct 28, 2009, 3:33 PM

Post #5 of 19 (1207 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

Most aDSL modems if set to PPPoE (I think Actiontec's come this way by
default) will send the mac as the pppoe un/pw.
David E. Smith wrote:

Opinions on this? I'd be interested in hearing the latest real world
experience for both and the direction most folks are going in.

I can't speak to which would be better on copper specifically, but in

general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff
will be similar (you'll need a way to authenticate users, turn them off and
on, et cetera); the differences won't be all that big. Either you're storing
their MACs in a database, or their port assignments and VLAN tags, or their
usernames and passwords.

With PPPoE, however, the end-user can't just plug in and go - they'll have
to configure their PC, or a DSL modem, or something. That means a phone call
to your tech support, most likely. In many cases, DHCP can lead to
plug-and-play simplicity, which means they don't have to call you, and you
don't have to answer their calls. Everyone wins. :)

David Smith
MVN.net

--

Walter Keen
Network Technician
Rainier Connect
(o) 360-832-4024
(c) 253-302-0194

george at montco

Oct 28, 2009, 4:30 PM

Post #6 of 19 (1203 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

We like PPPoE on the edge because we can use RADIUS to apply policy to
the subscribers for bandwidth management, class-of-service, SNPs, etc.
You probably have some of these features via your DSLAM, but we found
it easier to do via RADIUS with a web based GUI for our provisioning
folks. So if we need to snip someone's Internet and leave voice or VPN
packets alone due to an abuse issue for example, we can apply the
policy that references the appropriate ACL.

George

Attachments:

smime.p7s (2.36 KB)

nanog at 85d5b20a518b8f6864949bd940457dc124746ddc

Oct 28, 2009, 4:32 PM

Post #7 of 19 (1203 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

On Wed, 28 Oct 2009 15:33:58 -0700
Walter Keen <walter.keen [at] rainierconnect> wrote:

> Most aDSL modems if set to PPPoE (I think Actiontec's come this way by
> default) will send the mac as the pppoe un/pw.
> David E. Smith wrote:
>
> Opinions on this? I'd be interested in hearing the latest real world
> experience for both and the direction most folks are going in.
>

DOCSIS cable networks use DHCP and have for a long time. If you have
Ethernet based DSLAMs, they can usually do the a number of tricks (e.g.
Option 82 insertion into the DHCP request) that would make a DHCP ADSL
deployment no harder (or easier) than a DOCSIS cable network.

It seems to me that the fundamental purpose of PPPoE is to be able to
uniquely identify the customer for billing/provisioning purposes. Even
though you only need to be able to do that at the start of their
session, with PPPoE you pay an 8 byte per packet overhead, on _every_
packet sent and received by the customer. Other methods of
distinguishing the customer, e.g. Option 82, static DHCP mapped to a
customer MAC address, or possibly 802.1x if it were available, have
much, much lower overhead.

I think PPPoE really only exists to make ADSL look like high speed
dial-up, so that ISPs dial up backend systems didn't need to be changed
when ADSL was introduced. That was a valid concern in the past, but
with existing solutions or models such as the DOCSIS Cable methods, and
Ethernet based DSLAMS, I'd suggest avoiding PPPoE if you can.

> I can't speak to which would be better on copper specifically, but in
>
>
> general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff
> will be similar (you'll need a way to authenticate users, turn them off and
> on, et cetera); the differences won't be all that big. Either you're storing
> their MACs in a database, or their port assignments and VLAN tags, or their
> usernames and passwords.
>
> With PPPoE, however, the end-user can't just plug in and go - they'll have
> to configure their PC, or a DSL modem, or something. That means a phone call
> to your tech support, most likely. In many cases, DHCP can lead to
> plug-and-play simplicity, which means they don't have to call you, and you
> don't have to answer their calls. Everyone wins. :)
>
> David Smith
> MVN.net
>
>
> --
>
>
> Walter Keen
> Network Technician
> Rainier Connect
> (o) 360-832-4024
> (c) 253-302-0194

nanog at daork

Oct 28, 2009, 4:52 PM

Post #8 of 19 (1202 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

Apologies if this message is brief, it is sent from my cellphone.

On 29/10/2009, at 11:33, Walter Keen <walter.keen [at] rainierconnect>
wrote:

> Most aDSL modems if set to PPPoE (I think Actiontec's come this
> way by
> default) will send the mac as the pppoe un/pw.
> David E. Smith wrote:
>
> Opinions on this? I'd be interested in hearing the latest real world
> experience for both and the direction most folks are going in.
>
> I can't speak to which would be better on copper specifically, but in
>
>
> general I'd favor DHCP over PPPoE. Either way, most of the back-end
> stuff
> will be similar (you'll need a way to authenticate users, turn them
> off and
> on, et cetera); the differences won't be all that big. Either you're
> storing
> their MACs in a database, or their port assignments and VLAN tags,
> or their
> usernames and passwords.
>
> With PPPoE, however, the end-user can't just plug in and go -
> they'll have
> to configure their PC, or a DSL modem, or something. That means a
> phone call
> to your tech support, most likely. In many cases, DHCP can lead to
> plug-and-play simplicity, which means they don't have to call you,
> and you
> don't have to answer their calls. Everyone wins. :)
>
> David Smith
> MVN.net
>
>
> --
>
>
> Walter Keen
> Network Technician
> Rainier Connect
> (o) 360-832-4024
> (c) 253-302-0194
>
> !DSPAM:22,4ae8c6fe233691194411224!
>
>

swmike at swm

Oct 29, 2009, 1:23 AM

Post #9 of 19 (1191 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

On Wed, 28 Oct 2009, JD wrote:

I think the important thing is to have a separate L2 isolation per
customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX
will both solve this problem, but deploying multicast TV offering might be
harder in this deployment model.

There is really no devices out there to securely do IPv6 to the end user
natively when you have a shared L2 domain (in v4 this implies the L2
device will do DHCP snooping and do filtering based on that).

I don't really like tunneling, so I'd advocate the q-in-q model with
separate vlan per customer (or having the L3 routing very close to the
customer so you don't need to do q-in-q but still can do separate vlan per
customer).

--
Mikael Abrahamsson email: swmike [at] swm

sean at donelan

Oct 29, 2009, 2:07 AM

Post #10 of 19 (1193 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

On Wed, 28 Oct 2009, David E. Smith wrote:
> With PPPoE, however, the end-user can't just plug in and go - they'll have
> to configure their PC, or a DSL modem, or something. That means a phone call
> to your tech support, most likely. In many cases, DHCP can lead to
> plug-and-play simplicity, which means they don't have to call you, and you
> don't have to answer their calls. Everyone wins. :)

One of the reasons for UUNET's PPPOE design was to reduce phone calls and
configuration hassles. But in a different way. In the "old" days, people
thought there would be separation between the ISP and the wholesale
network. The idea that the provider could control/manage the CPE, like a
cable set-top box, was probably more radical at the time than a dumb
modem and PPPOE client on the PC.

PPPOE can allow changing ISPs just by changing the username [at] domai,
without needing to call wholesale provider's tech support and
reconfiguring the circuit. You could even have multiple PC's sharing the
same circuit, each connecting to different ISPs at the same time. Or use
PPPOE to "call" a business' DSLAM pool for work access, and then call
AOL's DSLAM pool for personal use. The concept of multiple "dialers" was
well supported on most operating systems, and more familar to the public
at the time than trying to set hostnames or read MAC addresses in DHCP
configurations.

In those days, VPN/IPSEC tunnel support wasn't very common. Businesses
still had dial-up modem pools, X.25 PADs, and private
PPP/PPPOE/PPPOA/PPPOx connections. Compared to the overhead for other
point-to-point and tunneling protocols at the time, PPPOE's overhead
didn't look that bad. And since it was based on PPP, PPPOE made route
addressing (and other routing stuff) easy. Addressing a single host is
the simple case of the more general router PPP information.

As Milo used to say, with enough thrust you could get DHCP to do many of
those same things too. There were a lot of experiments, and not all of
them worked well.

As they say, the world changed.

Ethernet won, vertically integrated ISPs won, VPN won, and yes DHCP
(with lots of options) won too. We can have a betamax/vhs-style argument
of technical superiority; but the market made a choice.

vince at cisco

Oct 29, 2009, 6:11 AM

Post #11 of 19 (1182 views)
Permalink

RE: PPPoE vs. Bridged ADSL [In reply to]

This current draft

DHCP Authentication

http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt

Adds the username/password that PPP has to DHCP and I believe support IPv6.

Vince

-----Original Message-----
From: Sean Donelan [mailto:sean [at] donelan]
Sent: Thursday, October 29, 2009 5:07 AM
To: nanog [at] nanog
Subject: Re: PPPoE vs. Bridged ADSL

On Wed, 28 Oct 2009, David E. Smith wrote:
> With PPPoE, however, the end-user can't just plug in and go - they'll
> have to configure their PC, or a DSL modem, or something. That means a
> phone call to your tech support, most likely. In many cases, DHCP can
> lead to plug-and-play simplicity, which means they don't have to call
> you, and you don't have to answer their calls. Everyone wins. :)

One of the reasons for UUNET's PPPOE design was to reduce phone calls and
configuration hassles. But in a different way. In the "old" days, people
thought there would be separation between the ISP and the wholesale network.
The idea that the provider could control/manage the CPE, like a cable
set-top box, was probably more radical at the time than a dumb modem and
PPPOE client on the PC.

PPPOE can allow changing ISPs just by changing the username [at] domai, without
needing to call wholesale provider's tech support and reconfiguring the
circuit. You could even have multiple PC's sharing the same circuit, each
connecting to different ISPs at the same time. Or use PPPOE to "call" a
business' DSLAM pool for work access, and then call AOL's DSLAM pool for
personal use. The concept of multiple "dialers" was well supported on most
operating systems, and more familar to the public at the time than trying to
set hostnames or read MAC addresses in DHCP configurations.

In those days, VPN/IPSEC tunnel support wasn't very common. Businesses still
had dial-up modem pools, X.25 PADs, and private PPP/PPPOE/PPPOA/PPPOx
connections. Compared to the overhead for other point-to-point and
tunneling protocols at the time, PPPOE's overhead didn't look that bad. And
since it was based on PPP, PPPOE made route addressing (and other routing
stuff) easy. Addressing a single host is the simple case of the more
general router PPP information.

As Milo used to say, with enough thrust you could get DHCP to do many of
those same things too. There were a lot of experiments, and not all of them
worked well.

As they say, the world changed.

Ethernet won, vertically integrated ISPs won, VPN won, and yes DHCP (with
lots of options) won too. We can have a betamax/vhs-style argument of
technical superiority; but the market made a choice.

jbates at brightok

Oct 29, 2009, 8:02 AM

Post #12 of 19 (1177 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

Mikael Abrahamsson wrote:
> I think the important thing is to have a separate L2 isolation per
> customer so you can more easily deploy IPv6 in the future. q-in-q or
> PPPoX will both solve this problem, but deploying multicast TV offering
> might be harder in this deployment model.

In general, it shouldn't be. Local multicast TV offerings should be
transmitted out of band from the standard internet connection, either
different vlan or outside of the PPPoE. The nature of it usually
indicates a specialized CPE maintained by the provider to support the
necessary QOS, and division of Internet and Video traffic.

For public multicast, splitting in the local pop just doesn't matter much.

> There is really no devices out there to securely do IPv6 to the end user
> natively when you have a shared L2 domain (in v4 this implies the L2
> device will do DHCP snooping and do filtering based on that).

Several vendors claim to have v6 support for this in the next year.
Currently, many of them completely break v6 due to the v4 security.

Jack

jbates at brightok

Oct 29, 2009, 8:10 AM

Post #13 of 19 (1179 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

Vince Mammoliti wrote:
> This current draft
>
> DHCP Authentication
>
> http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt
>
>
> Adds the username/password that PPP has to DHCP and I believe support IPv6.
>

Now if we could just tweak things perfectly so customers can hook up,
log in to the ISP, and use tickets to access everything and it's dog,
that would rock. :)

A nice extension to allow corporate networks to interface with that
system would be even cooler.

*dreams of a secure authenticate once world*

Jack

frnkblk at iname

Oct 29, 2009, 1:12 PM

Post #14 of 19 (1167 views)
Permalink

RE: PPPoE vs. Bridged ADSL [In reply to]

Others commented on things I already had in mind only the username/password
thing of PPPoE. We use the same username/pw on the modem as the customer
users for their e-mail, so a password change necessitates a truck roll (I
know, I know, TR-069). We started with PPPoE for our FTTH, because we were
familiar with it, but we moved over to a "VLAN per service" model which ends
up something like RBE in function. We can track customers based on the
Option 82 info, so we're good to go in terms of tracking them.

Frank

-----Original Message-----
From: JD [mailto:jdupuy-list [at] socket]
Sent: Wednesday, October 28, 2009 4:21 PM
To: NANOG list
Subject: PPPoE vs. Bridged ADSL

There is a debate among our engineering staff as to the best means of
provisioning broadband service over copper facilities. Due to our
history, we have a mix out in the field. Some customers are on DSLAMS
set up for bridged connections with DHCP; isolated by a variety of means
including VLANS. Some customers are on PPPoE over ATM. Some customers
are on PPPoE over ethernet (PPPoEoE ?? :) ).

There seem to be pros and cons to both directions. Certainly true
bridging has less overhead. But modern CPEs can minimize the impact of
PPPoE. PPPoE allows for more flexible provisioning; including via
RADIUS. Useful for the call center turning customers on/off without NOC
help. But VLAN tricks can sometimes do many of the same things.

Opinions on this? I'd be interested in hearing the latest real world
experience for both and the direction most folks are going in.

BTW, I doubt it is relevant to the discussion, but most of our DSLAMS
are Adtran TA5000s (or are being migrated to that platform.) We are
mostly a cisco shop for the upstream routers.

Thanks,

John

mailvortex at gmail

Oct 29, 2009, 4:10 PM

Post #15 of 19 (1157 views)
Permalink

Re: PPPoE vs. Bridged ADSL [In reply to]

On Thu, Oct 29, 2009 at 11:10 AM, Jack Bates <jbates [at] brightok> wrote:
> *dreams of a secure authenticate once world*

It may be worth noting here that there are times were one wants
barriers between automation to keep malfunction or malice from
spreading too far without human involvement.

Of course, most of the current barriers we have are accidental,
random, and ill-defined, so there's clearly room for improvement
either way. :)

-- Ben

frnkblk at iname

Oct 30, 2009, 2:51 AM

Post #16 of 19 (1150 views)
Permalink

RE: PPPoE vs. Bridged ADSL [In reply to]

For telco-delivered IPTV, the multicast channel, bi-directional control
channel, and video are transmitted on different VP/VC. For VDSL2, I'm
guessing it would be a different VLAN.

Frank

-----Original Message-----
From: Jack Bates [mailto:jbates [at] brightok]
Sent: Thursday, October 29, 2009 10:03 AM
To: nanog [at] nanog
Subject: Re: PPPoE vs. Bridged ADSL

Mikael Abrahamsson wrote:
> I think the important thing is to have a separate L2 isolation per
> customer so you can more easily deploy IPv6 in the future. q-in-q or
> PPPoX will both solve this problem, but deploying multicast TV offering
> might be harder in this deployment model.

In general, it shouldn't be. Local multicast TV offerings should be
transmitted out of band from the standard internet connection, either
different vlan or outside of the PPPoE. The nature of it usually
indicates a specialized CPE maintained by the provider to support the
necessary QOS, and division of Internet and Video traffic.

For public multicast, splitting in the local pop just doesn't matter much.

> There is really no devices out there to securely do IPv6 to the end user
> natively when you have a shared L2 domain (in v4 this implies the L2
> device will do DHCP snooping and do filtering based on that).

Several vendors claim to have v6 support for this in the next year.
Currently, many of them completely break v6 due to the v4 security.

Jack

sean at donelan

Oct 30, 2009, 5:18 AM

Post #17 of 19 (1157 views)
Permalink

RE: PPPoE vs. Bridged ADSL [In reply to]

On Thu, 29 Oct 2009, Vince Mammoliti wrote:
> This current draft
>
> DHCP Authentication
>
> http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt

That's what makes protocol wars so much fun. With enough options, almost
any protocol can do almost anything.

As you know, I did my best to kill PPPOx at an ISP and in the IPTV
architecture several vendors were selling at the time. I still
think that sometimes DHCP is the answer, and other times PPPOx is the
answer, but you can usually make either work if necessary. And even
though I chose DHCP, the vendor needed to fix several things. I haven't
kept track if all of them were really fixed.

sean at donelan

Oct 31, 2009, 1:13 PM

Post #18 of 19 (1128 views)
Permalink

RE: PPPoE vs. Bridged ADSL [In reply to]

On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote:
> Others commented on things I already had in mind only the username/password
> thing of PPPoE. We use the same username/pw on the modem as the customer
> users for their e-mail, so a password change necessitates a truck roll (I
> know, I know, TR-069). We started with PPPoE for our FTTH, because we were
> familiar with it, but we moved over to a "VLAN per service" model which ends
> up something like RBE in function. We can track customers based on the
> Option 82 info, so we're good to go in terms of tracking them.

You can have a "network username/password" for the customer different
from the mail and other application-layer username/password. Some ISPs
did that in the dial-up days, and also with PPPOx. The network account
information is configured in the dialer or router/modem; and most users
never need to know the network-layer stuff. The user can change their
mail/application password (and use it for off-network access) without
affecting their network-layer pasword.

The same network account may have multiple mail/application accounts
associated with it. It also helps in the debate whether you store
unreversable passwords or cleartext passwords for things like CHAP/PAP;
need to split accounts because people change households; network
re-architecture moves circuits around or users move and re-associating
the connections with the correct accounts. Yep, I sometimes found two
households with swapped VPI/VCI, VLAN or PORT identifiers because
someone/something made a data entry or circuit termination mistake.

I like a combination of 802.1x and Option 82 as way of cross-checking,
and layer 2/3 anti-spoof protection. I also like handling network things
mostly at the network/hardware level, separate from the application layer
identity so the user changes aren't affected.

But there are almost always multiple ways to solve a problem.

frnkblk at iname

Oct 31, 2009, 3:55 PM

Post #19 of 19 (1121 views)
Permalink

RE: PPPoE vs. Bridged ADSL [In reply to]

Hindsight being what it is, we would have likely had a separate
account/password for the PPP account.

I guess we could theoretically have two layers of RADIUS checking, the first
layer being the application-layer username/password, and failing that, the
original username/password that we assigned to the PPP device.

Frank

-----Original Message-----
From: Sean Donelan [mailto:sean [at] donelan]
Sent: Saturday, October 31, 2009 3:14 PM
To: NANOG list
Subject: RE: PPPoE vs. Bridged ADSL

On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote:
> Others commented on things I already had in mind only the
username/password
> thing of PPPoE. We use the same username/pw on the modem as the customer
> users for their e-mail, so a password change necessitates a truck roll (I
> know, I know, TR-069). We started with PPPoE for our FTTH, because we
were
> familiar with it, but we moved over to a "VLAN per service" model which
ends
> up something like RBE in function. We can track customers based on the
> Option 82 info, so we're good to go in terms of tracking them.

You can have a "network username/password" for the customer different
from the mail and other application-layer username/password. Some ISPs
did that in the dial-up days, and also with PPPOx. The network account
information is configured in the dialer or router/modem; and most users
never need to know the network-layer stuff. The user can change their
mail/application password (and use it for off-network access) without
affecting their network-layer pasword.

The same network account may have multiple mail/application accounts
associated with it. It also helps in the debate whether you store
unreversable passwords or cleartext passwords for things like CHAP/PAP;
need to split accounts because people change households; network
re-architecture moves circuits around or users move and re-associating
the connections with the correct accounts. Yep, I sometimes found two
households with swapped VPI/VCI, VLAN or PORT identifiers because
someone/something made a data entry or circuit termination mistake.

I like a combination of 802.1x and Option 82 as way of cross-checking,
and layer 2/3 anti-spoof protection. I also like handling network things
mostly at the network/hardware level, separate from the application layer
identity so the user changes aren't affected.

But there are almost always multiple ways to solve a problem.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads