🚀 go-pugleaf

This is a multi-part message in MIME format.
--------------EA61CE4760BB99F7A08C5FF8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for your comments, James.
You would probably get an argument about DHCP and bridging in a WAN
environment.  I believe almost all the ADSL providers started off that way
(including BellSouth), but they got away from it as fast as they could.  DHCP
works well, as long as you are in a trusted environment.  Stolen IPs,
broadcast traffic, rogue DHCP servers, using MAC address as "authentication"
proved very troublesome.  The Redbacks (which BellSouth [and the rest of the
known universe] switched to) were added by the providers who would do almost
anything to go to a more familiar PPP implementation (!), where authentication
is via username/password, traffic isolated to the ppp connection, nobody can
steal IPs.  In short, it "looks" like dialup.
In fact BellSouth still has a small group of original bridged customers, who
"lord it over the rest of us" because they don't have the pppoX drivers and
that complexity to deal with [software on top of Windoze] which has lent a
"certain amount of instability" into the ADSL picture.  So there has been a
tradeoff so far.
They (Redback) had to invent a ppp-like implementation over ethernet to pull
this off for all the ethernet NICs and ethernet bridging modems out there.
They also added the internal modems running pppoA but people still need the
Ethernet interface, for varied valid reasons.  BellSouth doesn't control the
CPE, like some providers, but it does complicate the service.
I understand your concerns about pppoE, especially that it is a proprietary
non standards track implementation, but I think the ADSL providers had little
choice [other than to go away].  The Telcos have always been big proponents of
standards [they want all this equipment to interoperate..], but market forces
forced their hand.
Also, I believe since the pppoE runs on a customer-specific PVC, the potential
for the abuse is less.
John
Still trying to learn ppp, and now l2tp.  Grief. I thot I had it under control
when I learned IP!
...I don't think I want to know about HURL and MOTM....

James Carlson wrote:

> John D Loop <loop@snt.bst.bls.com> writes:
> > Reading your new book on ppp.  Great stuff!
>
> Thanks!
>
> >  I read with interest your 1
> > page "slam" on pppoE and wondered if you had any more recent thots on
> > it.  It seems like we are stuck with it out here in ADSL land as a
> > defacto standard, for better or worse.
>
> It doesn't have to be that way.  DHCP works just fine.
>
> > All SOHO routers pretty much do
> > it now, along with pppoA.
>
> PPP over AAL5 ("PPPoA") is a different thing.  That's a standards-
> track protocol.  PPPoE is "informational," which essentially means
> that it's unreviewed and proprietary.
>
> >  And the consumers have to add pppoE clients
> > to their PC if they don't have a SOHO routers - this can get dicey
> > sometimes.  I can understand why it was invented [existing ppp
> > infrastructures & existing ethernet LAN environments], and I can even
> > see some advantages  [multiple sessions and multiple service selection].
>
> I don't think I see the same advantages.
>
> > The biggest problem I see is the smaller MTU breaking some connections
> > when intervening routers don't allow MTU path discovery to work
> > [assuming it is turned on].
>
> Yes, that's at least one problem.  More subtly, PPPoE also breaks the
> RFC 1661 default MTU.
>
> What's worse, PPPoE's session ID assignment mechanism is badly
> designed.  It assigns a single ID from the 'server' side only.
> Properly designed tunneling protocols assign IDs from both sides; that
> is, the client issues an ID number to the server for data inbound to
> the client, and the server issues a separate ID number to the client
> for data outbound from the client.  Because PPPoE doesn't do this, an
> individual system that has multiple PPPoE client sessions running has
> no guarantee that the assigned ID numbers don't conflict, and thus
> must demultiplex on both the ID number and the MAC address of the
> server.
>
> And don't get me started on the HURL and MOTM extensions ...
>
> --
> James Carlson, Internet Engineering       <james.d.carlson@east.sun.com>
> SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
> Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

--
Question posed to Arthur C. Clarke:
How do you keep up with the new advances?
"I don't, of course - who can? And it makes me sorry.  I can't read fiction
anymore, I just don't have time for it.  The entire time is spent e-mailing!"


--------------EA61CE4760BB99F7A08C5FF8
Content-Type: text/x-vcard; charset=us-ascii;
 name="loop.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John D Loop
Content-Disposition: attachment;
 filename="loop.vcf"

begin:vcard 
n:Loop;John 
tel;pager:jloop@bellsouthips.com
tel;fax:404 872 5329
tel;work:404 332 2232
x-mozilla-html:FALSE
org:BellSouth Telecom;Science and Technology
version:2.1
email;internet:loop@snt.bellsouth.com
title:Member Tech Staff
adr;quoted-printable:;;Room 40U95=0D=0A675 West Peachtree St=0D=0AAtlanta, GA 30375;;;;
x-mozilla-cpt:;27024
end:vcard

--------------EA61CE4760BB99F7A08C5FF8--