One document matched: draft-ietf-pppext-pppoe-mtu-1500-00.txt

Internet Draft                                           John Fitzgibbon
draft-ietf-pppext-pppoe-mtu-1500-00.txt
January 2005
Expires: July 2005


                 Accommodating an MTU of 1500 in PPPoE


IPR Statement

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2005). All Rights Reserved.

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.
   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.

1.  Description

   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.

   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.

   The reduction in MTU was deemed necessary because a PPPoE header
   requires 8 octets, and the maximum payload size of an Ethernet frame
   is 1500 octets.

   However, many devices support variable length Ethernet headers,
   without compromising the 1500 octet MTU of the Ethernet Frame's
   payload. For example, any device that supports double-tagged VLANs,
   (802.1Q-in-Q), will already allow for at least 8 octets of additional
   data in the Ethernet header to accommodate the two VLAN tags.

   Therefore, it is suggested to replace Section 7, Paragraph 2 of RFC
   2516, which reads as follows:

   "The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
   larger size than 1492.  Since Ethernet has a maximum payload size of
   1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
   2 octets, the PPP MTU MUST NOT be greater than 1492."

   with the following:

   "The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
   larger size than 1500.

   Since Ethernet has a maximum payload size of 1500 octets, and the
   PPPoE Header plus Protocol ID is 8 octets, an MRU greater than 1492
   can only be accommodated if the negotiating devices, and any
   intermediate devices, are capable of treating the PPPoE Header plus
   Protocol ID as if they were part of the Ethernet Header. In other
   words, they must have sufficient overhead in their Ethernet Header
   representations to accommodate the extra 8 octets.

   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
   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
   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.

   If the LCP includes any 802.1Q VLAN tags, a device SHOULD negotiate
   an MRU no larger than 1492."

2.  Security Considerations

   Older devices which assume that the maximum size for an Ethernet
   header plus its payload is less than 1522 octets might suffer buffer
   overflow conditions if they encounter larger frames. These devices
   should be retired, as most modern network devices are capable of
   generating larger Ethernet frames, which leaves the older devices
   vulnerable to attack regardless of whether PPPoE is used as the
   attack vector.

3.  References

   [1]  Mamakos L., Lidl K., Evarts J., Carrel D., Simone D., Wheeler
        R., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC
        2516, February 1999

4.  Author's Address

   John Fitzgibbon
   468 Duboce Ave,
   San Francisco  CA  94117

   Phone: 415-558-9851
   EMail: fitz@jfitz.com

5.  Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights."

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.