Re: I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt

> 	Title		: Accommodating an MTU of 1500 in PPPoE
> 	Author(s)	: J. Fitzgibbon

So, now that this is (finally) out, I have some comments.

> Abstract
> 
>    Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC
>    2516, mandates a maximum negotiated MRU of 1492. This memo proposes
>    relaxing that restriction to allow a maximum negotiated MRU of 1500.

Many implementations (including the one on Solaris) assume that if the
MRU is not negotiated on a PPPoE link (or is rejected), then the
default MRU is 1492.  Is that still true?

Suppose one of these new implementations is negotiating with an old
one.  The new one suggests an MRU of 1500.  The old peer looks at that
and says, "well, I can't ever send a packet that big, but I'm glad he
could accept it if I could, so I'll send Configure-Ack."  The old peer
doesn't include the MRU option in its Configure-Request (as none is
really needed).

What MTU does the new peer end up with?  The answer can't be 1500, or
interoperability is broken.

>    This can be achieved by treating the PPPoE Header and Protocol ID as
>    part of the Ethernet Header, taking advantage of the fact that most
>    network devices have buffers for the Ethernet Header and Payload that
>    are at least 1522 octets in size. To aid backward compatability, the

This part seems like the wrong venue to me.  In order to get the PPPoE
Session Stage Ethertype recognized as being in the same class of types
as the VLAN tag, I think that the IEEE specifications have to be
updated.  I don't think that extending Ethernet standards is something
the IETF should undertake.

>    As PPPoE [1] is increasingly becoming the protocol of choice for
>    provisioning residential and small business Internet service, this is
>    having the undesirable effect of reducing the effective MTU for large
>    segments of Internet users from 1500 octets to 1492 octets.

Protocol of choice or not, PPPoE has a number of serious problems,
perhaps chief among them that it hasn't gone through any of the IETF
review processes.  (Ignoring the obvious design flaws, such as the
one-way assignment of session IDs.)

I'm not sure that we should try too hard to publish extensions to
something that is effectively a dead end.  If someone's interested, I
suppose publishing it as yet another "Informational" RFC doesn't
completely break the rules, but it does seem at least a bit
misleading.

>    The reduced MTU can cause problems for any equipment or software that
>    is configured with a static MTU, in particular if the expected or
>    default value is 1500. In addition, widespread adoption of a lower
>    MTU reduces the overall efficiency of the Internet.

I don't think "efficiency" of 1492 versus 1500 is noticable at all.
The real issue is that Path MTU Discovery just doesn't work.  It
doesn't work because there are huge numbers of horribly broken packet
filters (firewalls) and NATs out there, and there's just nothing
anyone can do about the problem.

And it's yet another good reason why PPPoE is probably not a good
idea.

>    Devices that are not capable of handling the extra 8 octets in their
>    Ethernet Header SHOULD negotiate an MRU no larger than 1492. If no
>    MRU has been specified by the receiving side, the sending side MAY
>    assume that the receiving side is capable of handling the PPP default
>    MRU of 1500. To ensure compatability with older equipment, if the

As above, I believe that breaks compatibility.  The default has to be
1492.

>    sending side is assigning an MRU greater than 1492 to the receiving
>    side, (either by default, or through negotiation), it is RECOMMENDED
>    that the sending side send one or more MRU-sized Echo-Request packets
>    once the session is opened, to test that the receiving side and any
>    intermediate equipment can handle the MRU. If no Echo-Replies are

I think that a procedure like that is a *requirement*, not just a
recommendation.  The problem is that there simply is no way for any
PPPoE implementation to know whether the intermediate devices (which
may include switches that add and remove VLAN tags) support an actual
MTU of 1508.  There's just no way to know that what's being negotiated
is at all reasonable.

>    received, the sending side MAY choose to repeat the test with
>    Echo-Request packets of size 1492. If these packets receive replies,
>    the sending side MAY choose to treat the receiver as if it had
>    explicitly specified an MRU of 1492.

I think that's ambiguous.  It should probably restart LCP instead.

-- 
James Carlson, IP Systems Group?               <[email protected]>
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

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext