summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4937.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4937.txt')
-rw-r--r--doc/rfc/rfc4937.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4937.txt b/doc/rfc/rfc4937.txt
new file mode 100644
index 0000000..89c4f90
--- /dev/null
+++ b/doc/rfc/rfc4937.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group P. Arberg
+Request for Comments: 4937 Redback Networks
+Category: Informational V. Mammoliti
+ Cisco Systems
+ June 2007
+
+
+ IANA Considerations for PPP over Ethernet (PPPoE)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document describes the IANA considerations for the PPP over
+ Ethernet (PPPoE) protocol.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Terminology ................................................2
+ 1.2. Specification of Requirements ..............................2
+ 2. IANA Considerations .............................................2
+ 2.1. Registration Policies for PPPoE TAG Values .................2
+ 2.2. Reserved PPPoE TAG Values ..................................3
+ 2.3. Registration Policies for PPPoE Code Fields ................3
+ 2.4. Reserved PPPoE Code fields .................................4
+ 3. Security Considerations .........................................4
+ 4. References ......................................................4
+ 4.1. Normative References .......................................4
+ 4.2. Informative References .....................................4
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arberg & Mammoliti Informational [Page 1]
+
+RFC 4937 IANA Considerations for PPPoE June 2007
+
+
+1. Introduction
+
+ This document provides guidance to the Internet Assigned Numbers
+ Authority (IANA) regarding the registration of values related to the
+ PPP over Ethernet Protocol (PPPoE), defined in [RFC2516], in
+ accordance with BCP 26, [RFC2434]. It also reserves PPPoE TAG values
+ as well as PPPoE packet Code fields, which are or have been in use on
+ the Internet.
+
+1.1. Terminology
+
+ The following terms are used here with the meanings defined in BCP
+ 26: "name space", "registration".
+
+ The following policies are used here with the meanings defined in BCP
+ 26: "First Come First Served".
+
+1.2. Specification of Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. These words are often capitalized. The key
+ words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+ "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
+ are to be interpreted as described in [RFC2119].
+
+2. IANA Considerations
+
+ The PPPoE protocol, as defined in [RFC2516], defines two name spaces
+ that require registration, the PPPoE TAG and the PPPoE Code field.
+
+2.1. Registration Policies for PPPoE TAG Values
+
+ IANA has set up a registry of "PPPoE TAG Values". These are 16-bit
+ values. PPPoE TAG values already in use are specified as reserved in
+ this document. All other TAG values between 0 and 65535 are to be
+ assigned by IANA, using the "First Come First Served" policy defined
+ in [RFC2434].
+
+ A TAG-Name and a description for the usage, as well as a point of
+ contact, MUST be provided for any assignment from this registry. A
+ document reference SHOULD also be provided.
+
+
+
+
+
+
+
+
+
+
+Arberg & Mammoliti Informational [Page 2]
+
+RFC 4937 IANA Considerations for PPPoE June 2007
+
+
+2.2. Reserved PPPoE TAG Values
+
+ TAG Value TAG Name Tag Description Reference
+ ----------- ------------------- --------------------- ---------
+ 0 0x0000 End-Of-List See the reference [RFC2516]
+
+ 257 0x0101 Service-Name See the reference [RFC2516]
+ 258 0x0102 AC-Name See the reference [RFC2516]
+ 259 0x0103 Host-Uniq See the reference [RFC2516]
+ 260 0x0104 AC-Cookie See the reference [RFC2516]
+ 261 0x0105 Vendor-Specific See the reference [RFC2516]
+ 262 0x0106 Credits See the reference [RFC4938]
+ 263 0x0107 Metrics See the reference [RFC4938]
+ 264 0x0108 Sequence Number See the reference [RFC4938]
+
+ 272 0x0110 Relay-Session-Id See the reference [RFC2516]
+ 273 0x0111 HURL See the reference [CARREL]
+ 274 0x0112 MOTM See the reference [CARREL]
+
+ 288 0x0120 PPP-Max-Payload See the reference [RFC4638]
+ 289 0x0121 IP_Route_Add See the reference [CARREL]
+
+ 513 0x0201 Service-Name-Error See the reference [RFC2516]
+ 514 0x0202 AC-System-Error See the reference [RFC2516]
+ 515 0x0203 Generic-Error See the reference [RFC2516]
+
+2.3. Registration Policies for PPPoE Code Fields
+
+ IANA has set up a registry of PPPoE Active Discovery Code fields.
+ These are 8-bit values. PPPoE Code fields already in use are
+ specified as reserved in this document. All other Code values
+ between 0 and 255 are to be assigned by IANA, using the "First Come
+ First Served" policy defined in [RFC2434].
+
+ A PPPoE Active Discovery packet name and a description for the usage,
+ as well as a point of contact, MUST be provided for any assignment
+ from this registry.
+
+ A document reference SHOULD also be provided.
+
+
+
+
+
+
+
+
+
+
+
+
+Arberg & Mammoliti Informational [Page 3]
+
+RFC 4937 IANA Considerations for PPPoE June 2007
+
+
+2.4. Reserved PPPoE Code fields
+
+ Code PPPoE Packet Name Description Reference
+ -------- ----------------------------- ----------------- ---------
+ 0 0x00 PPP Session Stage See the reference [RFC2516]
+
+ 7 0x07 PADO, Offer See the reference [RFC2516]
+ 9 0x09 PADI, Initiation See the reference [RFC2516]
+
+ 10 0x0a PADG, Session-Grant See the reference [RFC4938]
+ 11 0x0b PADC, Session-Credit Response See the reference [RFC4938]
+ 12 0x0c PADQ, Quality See the reference [RFC4938]
+
+ 25 0x19 PADR, Request See the reference [RFC2516]
+ 101 0x65 PADS, Session-confirmation See the reference [RFC2516]
+
+ 167 0xa7 PADT, Terminate See the reference [RFC2516]
+
+ 211 0xd3 PADM, Message See the reference [CARREL]
+ 212 0xd4 PADN, Network See the reference [CARREL]
+
+3. Security Considerations
+
+ This document focuses on IANA considerations for the PPPoE protocol,
+ and as such, should help remove the possibility of the same PPPoE
+ code field and PPPoE TAG value being used for different
+ functionalities.
+
+4. References
+
+4.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
+ and R. Wheeler, "A Method for Transmitting PPP Over
+ Ethernet (PPPoE)", RFC 2516, February 1999.
+
+4.2. Informative References
+
+ [CARREL] Carrel D., Simone D., Ho C. and T. Stoner, "Extensions to a
+ Method for Transmitting PPP Over Ethernet (PPPoE)", Work in
+ Progress.
+
+
+
+Arberg & Mammoliti Informational [Page 4]
+
+RFC 4937 IANA Considerations for PPPoE June 2007
+
+
+ [RFC4938] Berry, B. and H. Holgate, "PPP Over Ethernet (PPPoE)
+ Extensions for Credit Flow and Link Metrics", RFC 4938,
+ June 2007.
+
+ [RFC4638] Arberg, P., Kourkouzelis, D., Duckett, M., Anschutz, T.,
+ and J. Moisand, "Accommodating a Maximum Transit
+ Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in
+ the Point-to-Point Protocol over Ethernet (PPPoE)", RFC
+ 4638, September 2006.
+
+Authors' Addresses
+
+ Peter Arberg
+ Redback Networks, Inc.
+ 300 Holger Way
+ San Jose, CA 95134
+ USA
+ EMail: parberg@redback.com
+
+
+ Vince Mammoliti
+ Cisco Systems, Inc.
+ 181 Bay Street, Suite 3400
+ Toronto, Ontario, M5J 2T3
+ Canada
+ EMail: vince@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arberg & Mammoliti Informational [Page 5]
+
+RFC 4937 IANA Considerations for PPPoE June 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Arberg & Mammoliti Informational [Page 6]
+