|
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 9, 2010.
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.
This document specifies the IANA guidelines for allocating new values in the PPP Bandwidth Allocation and Bandwidth Allocation Control Protocols.
This document specifies the IANA guidelines [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) for allocating new values for various fields in the PPP Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP) [RFC2125] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.). BACP is the control protocol for BAP, and is used to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [RFC1990] (Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, “The PPP Multilink Protocol (MP),” August 1996.).
The IANA guidelines are given in Section 2 (IANA Considerations). Previously, no IANA guidance existed for such allocations either in [RFC2125] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.) or [RFC3818] (Schryver, V., “IANA Considerations for the Point-to-Point Protocol (PPP),” June 2004.). 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] (Simpson, W. and K. Fox, “PPP Vendor Extensions,” May 1997.) which allows the construction of vendor-specific packets and options.
The IANA is instructed to create the following registries. For all the registries, new values can be allocated through RFC Required [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.).
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:
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:
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] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.): 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] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.), 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:
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
This specification does not change the security properties of BAP or BACP.
The lack of any registration procedures has come up in IANA's review of existing registries and RFCs.
[RFC2125] | Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” RFC 2125, March 1997 (TXT, HTML, XML). |
[RFC2153] | Simpson, W. and K. Fox, “PPP Vendor Extensions,” RFC 2153, May 1997 (TXT). |
[RFC5226] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT). |
[RFC1990] | Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, “The PPP Multilink Protocol (MP),” RFC 1990, August 1996 (TXT). |
[RFC3818] | Schryver, V., “IANA Considerations for the Point-to-Point Protocol (PPP),” BCP 88, RFC 3818, June 2004 (TXT). |
[ITU.Q931.1993] | International Telecommunications Union, “ISDN user-network interface layer 3 specification for basic call control,” ITU-T Recommendation Q.931, May 1993. |
This document specifies only the IANA rules associated with various fields in BAP and BACP, and does not change the operation of the protocols themselves.
The authors would like to thank Carlos Pignataro, Eswaran Srinivasan, Ignacio Goyret, and Bill Simpson for feedback.
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 |