IANA Allocation Guidelines for the PPP
Bandwidth Allocation Protocol (BAP)EricssonJorvas02420Finlandjari.arkko@piuha.netWorkingcodecarlsonj@workingcode.comICANNamanda.baber@icann.orgIANA rulesPPPBandwidth Allocation ProtocolBandwidth Allocation Control ProtocolBAPBACPThis 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
for allocating new values for various fields
in the PPP Bandwidth Allocation Protocol (BAP) and Bandwidth
Allocation Control Protocol (BACP) . BACP is
the control protocol for BAP, and is used to manage the dynamic
bandwidth allocation of implementations supporting the PPP multilink
protocol .
The IANA guidelines are given in
. Previously, no IANA guidance existed for
such allocations either in or
. 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
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.
The IANA is instructed to create the following registries. For all
the registries, new values can be allocated through RFC Required
.IANA is instructed to create a registry for the BACP option
values. The initial contents of the registry should be as follows:IANA is also instructed to create a registry for the BAP Type field. The
initial contents of the registry should be as follows:IANA is also instructed to create a registry for the BAP Response Code field. The
initial contents of the registry should be as follows: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:IANA is also instructed to create a registry for the BAP Link Type field. The
initial contents of the registry should be as follows:Note the order of bits in this field as specified in Section 6.1 of
: 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 , 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:IANA is also instructed to create a registry for the BAP Call Status field. The
initial contents of the registry should be as follows:IANA is also instructed to create a registry for the BAP Call Action field. The
initial contents of the registry should be as follows: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
used to test temporary experimental designs, guidance given in
should be followed to avoid potentially
harmful side-effects.The lack of any registration procedures has come up in IANA's
review of existing registries and RFCs.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.