Article View: comp.protocols.ppp
Article #349Re: James - any new thots on pppoE?
From: James Carlson
Date: Mon, 12 Feb 2001 14:57
Date: Mon, 12 Feb 2001 14:57
52 lines
3195 bytes
3195 bytes
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
Technical Details
Message-ID:
<xoav8znc3q4u.fsf@sun.com>Path:
arc1-ca.pugleaf.net!supernews.google.com!sn-xit-03!supernews.com!hermes.visi.com!news-out.visi.com!newsfeed.direct.ca!look.ca!btnet-peer0!btnet-feed5!btnet!carbon.eu.sun.com!new-usenet.uk.sun.com!eastnews1.east.sun.com!not-for-mailReferences:
<3A87F5AB.7592D38E@snt.bst.bls.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1122a6,8bcec72c5c695208 X-Google-Attributes: gid1122a6,public X-Google-Thread: 103eaf,8bcec72c5c695208 X-Google-Attributes: gid103eaf,public X-Google-ArrivalTime: 2001-02-12 07:16:05 PST Path: arc1-ca.pugleaf.net!supernews.google.com!sn-xit-03!supernews.com!hermes.visi.com!news-out.visi.com!newsfeed.direct.ca!look.ca!btnet-peer0!btnet-feed5!btnet!carbon.eu.sun.com!new-usenet.uk.sun.com!eastnews1.east.sun.com!not-for-mail From: James Carlson <james.d.carlson@sun.com> Newsgroups: comp.protocols.ppp,bellsouth.net.support.adsl Subject: Re: James - any new thots on pppoE? Date: 12 Feb 2001 09:57:53 -0500 Organization: Sun Microsystems Inc. - BDC Lines: 52 Message-ID: <xoav8znc3q4u.fsf@sun.com> References: <3A87F5AB.7592D38E@snt.bst.bls.com> NNTP-Posting-Host: phorcys.east.sun.com X-Home-Page: http://people.ne.mediaone.net/carlson/ X-Newsreader: Gnus v5.7/Emacs 20.7