idnits 2.17.1 draft-ietf-pppext-pppoe-mtu-1500-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 150. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 142), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 154 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 77: '...nit (MRU) option MUST NOT be negotiate...' RFC 2119 keyword, line 80: '...ets, the PPP MTU MUST NOT be greater t...' RFC 2119 keyword, line 84: '...nit (MRU) option MUST NOT be negotiate...' RFC 2119 keyword, line 96: '... Ethernet Header SHOULD negotiate an M...' RFC 2119 keyword, line 97: '...e receiving side, the sending side MAY...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2005) is 7042 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. '1') Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft John Fitzgibbon 2 draft-ietf-pppext-pppoe-mtu-1500-00.txt 3 January 2005 4 Expires: July 2005 6 Accommodating an MTU of 1500 in PPPoE 8 IPR Statement 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC 43 2516, mandates a maximum negotiated MRU of 1492. This memo proposes 44 relaxing that restriction to allow a maximum negotiated MRU of 1500. 45 This can be achieved by treating the PPPoE Header and Protocol ID as 46 part of the Ethernet Header, taking advantage of the fact that most 47 network devices have buffers for the Ethernet Header and Payload that 48 are at least 1522 octets in size. To aid backward compatability, the 49 proposal recommends testing the link with MRU-sized Echo-Request 50 packets if an MRU greater than 1492 has been assumed or negotiated. 52 1. Description 54 As PPPoE [1] is increasingly becoming the protocol of choice for 55 provisioning residential and small business Internet service, this is 56 having the undesirable effect of reducing the effective MTU for large 57 segments of Internet users from 1500 octets to 1492 octets. 59 The reduced MTU can cause problems for any equipment or software that 60 is configured with a static MTU, in particular if the expected or 61 default value is 1500. In addition, widespread adoption of a lower 62 MTU reduces the overall efficiency of the Internet. 64 The reduction in MTU was deemed necessary because a PPPoE header 65 requires 8 octets, and the maximum payload size of an Ethernet frame 66 is 1500 octets. 68 However, many devices support variable length Ethernet headers, 69 without compromising the 1500 octet MTU of the Ethernet Frame's 70 payload. For example, any device that supports double-tagged VLANs, 71 (802.1Q-in-Q), will already allow for at least 8 octets of additional 72 data in the Ethernet header to accommodate the two VLAN tags. 74 Therefore, it is suggested to replace Section 7, Paragraph 2 of RFC 75 2516, which reads as follows: 77 "The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a 78 larger size than 1492. Since Ethernet has a maximum payload size of 79 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 80 2 octets, the PPP MTU MUST NOT be greater than 1492." 82 with the following: 84 "The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a 85 larger size than 1500. 87 Since Ethernet has a maximum payload size of 1500 octets, and the 88 PPPoE Header plus Protocol ID is 8 octets, an MRU greater than 1492 89 can only be accommodated if the negotiating devices, and any 90 intermediate devices, are capable of treating the PPPoE Header plus 91 Protocol ID as if they were part of the Ethernet Header. In other 92 words, they must have sufficient overhead in their Ethernet Header 93 representations to accommodate the extra 8 octets. 95 Devices that are not capable of handling the extra 8 octets in their 96 Ethernet Header SHOULD negotiate an MRU no larger than 1492. If no 97 MRU has been specified by the receiving side, the sending side MAY 98 assume that the receiving side is capable of handling the PPP default 99 MRU of 1500. To ensure compatability with older equipment, if the 100 sending side is assigning an MRU greater than 1492 to the receiving 101 side, (either by default, or through negotiation), it is RECOMMENDED 102 that the sending side send one or more MRU-sized Echo-Request packets 103 once the session is opened, to test that the receiving side and any 104 intermediate equipment can handle the MRU. If no Echo-Replies are 105 received, the sending side MAY choose to repeat the test with 106 Echo-Request packets of size 1492. If these packets receive replies, 107 the sending side MAY choose to treat the receiver as if it had 108 explicitly specified an MRU of 1492. 110 If the LCP includes any 802.1Q VLAN tags, a device SHOULD negotiate 111 an MRU no larger than 1492." 113 2. Security Considerations 115 Older devices which assume that the maximum size for an Ethernet 116 header plus its payload is less than 1522 octets might suffer buffer 117 overflow conditions if they encounter larger frames. These devices 118 should be retired, as most modern network devices are capable of 119 generating larger Ethernet frames, which leaves the older devices 120 vulnerable to attack regardless of whether PPPoE is used as the 121 attack vector. 123 3. References 125 [1] Mamakos L., Lidl K., Evarts J., Carrel D., Simone D., Wheeler 126 R., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 127 2516, February 1999 129 4. Author's Address 131 John Fitzgibbon 132 468 Duboce Ave, 133 San Francisco CA 94117 135 Phone: 415-558-9851 136 EMail: fitz@jfitz.com 138 5. Full Copyright Statement 140 Copyright (C) The Internet Society (2005). This document is subject 141 to the rights, licenses and restrictions contained in BCP 78, and 142 except as set forth therein, the authors retain all their rights." 144 This document and the information contained herein are provided on an 145 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 146 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 147 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 148 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 149 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 150 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.