J. Fitzgibbon:
Agree with the interoperability concerns brought forth
by J. Carlson. This is a real problem. Also performance
gain from 1492 to 1500 in the scheme of things is negligible.
If you are really set on gaining 8-bytes, consider defining
optional tags to negotiate the extended/longer MTU. This
method would be backward compatible. Another suggestion
is to publish as an Informational RFC.
Good luck
B. Berry
James Carlson wrote:
>> 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.
>
>
>
_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
