Network Working Group J. Arkko Internet-Draft Ericsson Updates: 2125 (if approved) J. Carlson Intended status: BCP Workingcode Expires: March 11, 2010 A. Baber ICANN September 7, 2009 IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol (BAP) draft-arkko-pppext-bap-ianafix-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 11, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Arkko, et al. Expires March 11, 2010 [Page 1] Internet-Draft BAP IANA Rules September 2009 Abstract This document specifies the IANA guidelines for allocating new values in the PPP Bandwidth Allocation and Bandwidth Allocation Control Protocols. 1. Introduction This document specifies the IANA guidelines [RFC5226] for allocating new values for various fields in the PPP Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP) [RFC2125]. BACP is the control protocol for BAP, and is used to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [RFC1990]. The IANA guidelines are given in Section 2. Previously, no IANA guidance existed for such allocations either in [RFC2125] or [RFC3818]. The purpose of this document is to allow IANA to manage number assignments based on these guidelines in a consistent manner. This document also points to [RFC2153] which allows the construction of vendor-specific packets and options. These mechanisms may also be used for temporary experimental extensions, alleviating the need to allocate specific experimental values in this document. 2. IANA Considerations The IANA is instructed to create the following registries. For all the registries, new values can be allocated through RFC Required [RFC5226]. IANA is instructed to create a registry for the BACP option values. The initial contents of the registry should be as follows: Registry Name: PPP BACP Configuration Option Types Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Type Configuration Option Reference ---- -------------------- --------- 0 Vendor-Specific [RFC2153] 1 Favored-Peer [RFC2125] 2-255 Unassigned IANA is also instructed to create a registry for the BAP Type field. The initial contents of the registry should be as follows: Arkko, et al. Expires March 11, 2010 [Page 2] Internet-Draft BAP IANA Rules September 2009 Registry Name: PPP BAP Type Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Type Datagram Reference ---- -------------------- --------- 0 Vendor-Specific [RFC 2153] 1 Call-Request [RFC 2125] 2 Call-Response [RFC 2125] 3 Callback-Request [RFC 2125] 4 Callback-Response [RFC 2125] 5 Link-Drop-Query-Request [RFC 2125] 6 Link-Drop-Query-Response [RFC 2125] 7 Call-Status-Indication [RFC 2125] 8 Call-Status-Response [RFC 2125] 9-255 Unassigned IANA is also instructed to create a registry for the BAP Response Code field. The initial contents of the registry should be as follows: Registry Name: PPP BAP Response Code Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Value Response Code Reference ---- -------------------- --------- 0 Request-Ack [RFC 2125] 1 Request-Nak [RFC 2125] 2 Request-Rej [RFC 2125] 3 Request-Full-Nak [RFC 2125] 4-255 Unassigned IANA is also instructed to create a registry for the BAP Datagram Option Type field. The initial contents of the registry should be as follows: Arkko, et al. Expires March 11, 2010 [Page 3] Internet-Draft BAP IANA Rules September 2009 Registry Name: PPP BAP Datagram Option Type Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Type Datagram Option Reference ---- -------------------- --------- 0 Vendor-Specific [RFC 2153] 1 Link-Type [RFC 2125] 2 Phone-Delta [RFC 2125] 3 No-Phone-Number-Needed [RFC 2125] 4 Reason [RFC 2125] 5 Link-Discriminator [RFC 2125] 6 Call-Status [RFC 2125] 7-255 Unassigned IANA is also instructed to create a registry for the BAP Link Type field. The initial contents of the registry should be as follows: Registry Name: PPP BAP Link Type Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Bit Link Type Reference ---- -------------------- --------- 0 ISDN [RFC 2125] 1 X.25 [RFC 2125] 2 analog [RFC 2125] 3 switched digital (non-ISDN) [RFC 2125] 4 ISDN data over voice [RFC 2125] 5-7 Unassigned Note the order of bits in this field as specified in Section 6.1 of [RFC2125]: bit 0 of the Link Type field corresponds to bit 39 of the Link-Type BAP Option. Also note that bits 5-7 were originally marked reserved [RFC2125], but this RFC makes them in principle available for allocation. New allocations are discouraged, however, as it would be difficult to assess the impacts new bits might have on interoperability with existing implementations. IANA is also instructed to create a registry for the BAP Phone-Delta Sub-Option Type field. The initial contents of the registry should be as follows: Arkko, et al. Expires March 11, 2010 [Page 4] Internet-Draft BAP IANA Rules September 2009 Registry Name: PPP BAP Phone-Delta Sub-Option Type Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Type Sub-Option Reference ---- -------------------- --------- 0 Vendor-Specific [RFC 2153] 1 Unique-Digits [RFC 2125] 2 Subscriber-Number [RFC 2125] 3 Phone-Number-Sub-Address [RFC 2125] 4-255 Unassigned IANA is also instructed to create a registry for the BAP Call Status field. The initial contents of the registry should be as follows: Registry Name: PPP BAP Call Status Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Value Call Status Reference ----- -------------------- --------- 0 Success [RFC 2125] 1-254 Q.931 values [RFC 2125] [ITU.Q931.1993] 255 Non-specific failure [RFC 2125] IANA is also instructed to create a registry for the BAP Call Action field. The initial contents of the registry should be as follows: Registry Name: PPP BAP Call Action Reference: [RFC2125 and XXX THIS RFC] Registration Procedures: RFC Required Value Action Reference ----- -------------------- --------- 0 No retry [RFC 2125] 1 Retry [RFC 2125] 2-255 Unassigned 3. Security Considerations This specification does not change the security properties of BAP or BACP. However, a few words are necessary about the use of vendor-specific extensions. Obviously, the use of vendor-specific extensions affects interoperability. General purpose extensions would be better defined as standard extensions. Similarly, if vendor-specific extensions are Arkko, et al. Expires March 11, 2010 [Page 5] Internet-Draft BAP IANA Rules September 2009 used to test temporary experimental designs, guidance given in [RFC3692] should be followed to avoid potentially harmful side- effects. 4. Acknowledgments The lack of any registration procedures has come up in IANA's review of existing registries and RFCs. 5. References 5.1. Normative References [RFC2125] Richards, C. and K. Smith, "The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)", RFC 2125, March 1997. [RFC2153] Simpson, W. and K. Fox, "PPP Vendor Extensions", RFC 2153, May 1997. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 5.2. Informative References [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004. [ITU.Q931.1993] International Telecommunications Union, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1993. Appendix A. Changes from the Original RFCs This document specifies only the IANA rules associated with various fields in BAP and BACP, and does not change the operation of the Arkko, et al. Expires March 11, 2010 [Page 6] Internet-Draft BAP IANA Rules September 2009 protocols themselves. Appendix B. Acknowledgments The authors would like to thank Carlos Pignataro, Eswaran Srinivasan, Ignacio Goyret, and Bill Simpson for feedback. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net James D. Carlson Workingcode Email: carlsonj@workingcode.com Amanda Baber ICANN Email: amanda.baber@icann.org Arkko, et al. Expires March 11, 2010 [Page 7]