Subject: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt

From: [email-masked]
Date: Fri, 28 Jan 2005 15:57:41 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: Accommodating an MTU of 1500 in PPPoE
	Author(s)	: J. Fitzgibbon
	Filename	: draft-ietf-pppext-pppoe-mtu-1500-00.txt
	Pages		: 0
	Date		: 2005-1-28
	
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.
   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
   proposal recommends testing the link with MRU-sized Echo-Request
   packets if an MRU greater than 1492 has been assumed or negotiated.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-pppoe-mtu-1500-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-pppoe-mtu-1500-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-pppoe-mtu-1500-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Fri, 28 Jan 2005 17:05:52 -0500

> 	Author(s)	: J. Fitzgibbon

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

> Abstract

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.

>    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-masked]>
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

---

From: Bo Berry <[email-masked]>
Date: Sat, 29 Jan 2005 22:48:38 -0500

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

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 29 Jan 2005 21:21:09 -0700 (MST)

> From: Bo Berry <[email-masked]>

> gain from 1492 to 1500 in the scheme of things is negligible.

except when the PPPoE link is not directly connected to the sending host
and you get the problems of IP fragmentation

or except when path MTU discovery is used and something doesn't
generate or filters ICMP messages, and you get intermittent blackholes

> method would be backward compatible. 

What is an "optional tag"?  I kind of understand various PPP
Configure-Request options, but they are not what I'd call tags.  As
James Carlson wrote, the IETF seems an unlikely forum for modifying
IEEE standards.

Is there no way to use the LCP MR option to negotiate an effective MTU
of 1500 on media that differs from classic IEE 802.3 by having a data
size of 1508 or larger?  Why can't an advanced PPPoE box offer an MRU
of 1508 or ask for an MTU of 1508 using a Configure-Nak?

The PPPoE 8 byte overhead hassle is far from unique in the PPP world.
MP (multilink) and CCP (compression) are two common examples.  For
that matter, why couldn't advanced PPPoE boxes use PPP MP fragmentation
much as other PPP boxes handle the CCP and MP headers?

>                                       Another suggestion

Whether the proposal RFC is Informational or on the standards track 
would not affect the interoperability problems.

Vernon Schryver    [email-masked]

---

From: Bo Berry <[email-masked]>
Date: Mon, 31 Jan 2005 09:56:29 -0500

Vernon

According to the submitted abstract

this is PPPoE related, not PPP.  PPPoE, RFC2516, includes a provision for
optional tags 

RFC 2516             Transmitting PPP Over Ethernet        February 1999

   The PPPoE payload contains zero or more TAGs.  A TAG is a TLV (type-
   length-value) construct and is defined as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          TAG_TYPE             |        TAG_LENGTH             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          TAG_VALUE ...                                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TAG_TYPE is a sixteen bit field in network byte order.  Appendix A
   contains a list of all TAG_TYPEs and their TAG_VALUEs.

   TAG_LENGTH is a sixteen bit field.  It is an unsigned number in
   network byte order, indicating the length in octets of the TAG_VALUE.

   If a discovery packet is received with a TAG of unknown TAG_TYPE, the
   TAG MUST be ignored unless otherwise specified in this document.
   This provides for backwards compatibility if/when new TAGs are added.
   If new mandatory TAGs are added, the version number will be
   incremented.

Agree, IETF is not the place to redefine IEEE stds.  

-Bo Berry   [email-masked]

-- 
Warning: This document contains technical data whose export 
is restricted by the Arms Export Control Act (Title 22, U.S.C., 
Sec 2751, et seq.) or the Export Administration Act of 1979, 
as amended (Title 50, U.S.C., App. 2401 et seq.). Violations 
of these export laws are subject to severe criminal penalties.