1 Malazshura

Point Code Assignments

[Docs] [txt|pdf] [draft-gray-rfc1...] [Tracker] [Diff1] [Diff2]

PROPOSED STANDARD

Network Working Group E. Gray Request for Comments: 4548 J. Rutemiller Updates: 1888, 4048 Ericsson Category: Standards Track G. Swallow Cisco Systems, Inc. May 2006 Internet Code Point (ICP) Assignments for NSAP Addresses Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. Table of Contents 1. Introduction ....................................................21.1. Conventions ................................................21.2. Acronyms and Terminology ...................................32. IANA Considerations .............................................33. Initial Allocations and Uses ....................................43.1. IPv4 Address Encoding in an NSAPA ..........................43.2. IPv6 Address Encoding in an NSAPA ..........................54. Security Considerations .........................................65. References ......................................................75.1. Normative References .......................................75.2. Informative References .....................................7Gray, et al. Standards Track [Page 1]
RFC 4548 Internet Code Point (ICP) Assignments May 20061. IntroductionSection 6 of RFC 1888 [1888] previously provided for assignment of the initial Internet Code Point (ICP) value '0' for encoding an IPv6 address in a Network Service Access (or Attachment) Point [NSAP] address. RFC 1888 also defined multiple means for restricted encoding of an NSAP address in an IPv6 address. The means RFC 1888 defined for encoding NSAP addresses in IPv6 address format was heavily annotated with warnings and limitations that apply should this encoding be used. Possibly as a result, these encodings are not used and appear never to have been used in any IPv6 deployment. In addition, section 6 contains minor errors. As a result of these various considerations, RFC 1888 [1888] has been obsoleted and declared Historic by RFC 4048 [4048]. It is the belief of the authors of this document that the errors in section 6 of RFC 1888 resulted -- at least in part -- because the ITU-T specification [X.213] that originally assigned Authority and Format Identifier (AFI) '35' to IANA was not freely publicized, nor was it incorporated or explained using the mechanism commonly used in the IETF, i.e., an RFC. It is therefore part of the purpose of this document to provide that explanation. In addition, because there are other documents that refer to the IPv6 ICP assignment in RFC 1888, it is necessary for the errors in section6 of RFC 1888 to be corrected, irrespective of the RFC's ultimate status. Finally, no previous RFC (including RFC 1888) has ever formalized an assignment of an IPv4 ICP. This may have been in part because of a lack of formal definition of an IANA assignment policy for ICP values under the IANA-allocated AFI ('35'). This document replaces section 6 of RFC 1888 in defining the ICP for IPv6 address encoding in an NSAP address, and it formalizes the ICP assignment for IPv4 address encoding in an NSAP address. 1.1. Conventions 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 RFC 2119 [2119]. Gray, et al. Standards Track [Page 2]
RFC 4548 Internet Code Point (ICP) Assignments May 20061.2. Acronyms and Terminology AFI - Authority and Format Identifier BCD - Binary Coded Decimal DSP - Domain Specific Part IANA - Internet Assigned Numbers Authority ICP - Internet Code Point IDI - Initial Domain Identifier IDP - Initial Domain Part IETF - Internet Engineering Task Force ISO - International Organization for Standardization NSAP - Network Service Access (or Attachment) Point (often NSAPA) NSAPA - NSAP Address; 20-Octet Address Format OSI - Open Systems Interconnection RFC - Request For Comments WIP - Work In Progress 2. IANA Considerations An ITU-T Recommendation [X.213] has allocated two AFIs designating IANA as the assignment authority. One of these two AFIs ('34') is allocated for assignment of NSAPA in Decimal Numeric Format. This document does not address allocation for this AFI as it is not clear what use (if any) can be made of this encoding format at this time. The other AFI ('35') is to be used for binary encoding except as noted below. The NSAPA format consists of an Initial Domain Part (IDP) and Domain Specific Part (DSP). The IDP, in turn, consists of an Authority and Format Identifier (AFI) and an Initial Domain Identifier (IDI). The AFI is defined to be a binary octet, and the IDI is defined to be a four decimal digit number encoded in two octets using Binary Coded Decimal format. Each nibble of the IDI is used to represent a decimal digit, using binary value '0000' through '1001'. In assigning allocation authority for AFI '35' to IANA, the ITU-T Recommendation [X.213] specifies that the two-octet IDI will be used to hold an Internet Code Point (ICP) that, because of the decimal encoding, MUST be in the decimal range from '0' to '9999'. The ITU-T recommendation assumes the assignment of ICP '0' (zero) for IPv6 address encoding in a Network Service Access Point Address (NSAPA, or often NSAP). In addition, ITU-T assumed that IANA would assign an ICP for IPv4 address encoding in an NSAPA and X.213 assumed that the ICP value for this purpose would be '1'. Gray, et al. Standards Track [Page 3]
RFC 4548 Internet Code Point (ICP) Assignments May 2006 In an NSAPA, the DSP is the remaining octets after the IDP. For AFI '35', this is 17 octets having a format as defined by IANA or as defined by another party and published with IANA consent. IANA, as the authority responsible for AFI '35', SHOULD NOT assign an ICP unless there is a corresponding defined, and published, format at the time of the code point assignment. The IANA has assigned the following ICP values: ICP Value Address Encoding Format Definition ---------- ----------------- ---------------------------- '0' IPv6 RFC 4548, section 3.2 '1' IPv4 RFC 4548, section 3.1 Remaining decimal values '2' through '9999' MUST be assigned on an IETF consensus basis [2434]. 3. Initial Allocations and Uses This document continues the ICP assignment and format definition as previously defined in RFC 1888, and it formalizes the allocation of ICP value '1' for IPv4 encoding and the format to be used. The sections below describe the specific IPv4 and IPv6 address encoding formats. 3.1. IPv4 Address Encoding in an NSAPA If it is required, for whatever reason, to embed an IPv4 address inside a 20-octet NSAP address, then the following format MUST be used. Note: alignment is an artifact of existing NSAPA usage. A specific possible use of this embedding is to express an IP address within the ATM Forum address format. Another possible use would be to allow Connectionless Network Protocol (CLNP) packets that encapsulate IPv4 packets to be routed in a CLNP network using the IPv4 address architecture. Several leading octets of the IPv4 address could be used as a CLNP routing prefix. An NSAPA with an AFI value of '35' and an ICP value of '1' (one) encodes a 4-octet IPv4 address in the first 4 octets of the DSP. The last 13 octets of the DSP are unspecified in this document. To maintain compatibility with both NSAP format and IPv4 addressing, these octets MUST be present, but have no intrinsic significance for IPv4. The default values for the unspecified octets is zero. Gray, et al. Standards Track [Page 4]
RFC 4548 Internet Code Point (ICP) Assignments May 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 | AFI = 0x35 | ICP = 0001 | IPv4 (octet 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IPv4 (octets 1-3) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An NSAPA with the IANA AFI code and ICP set to '1' (one) is converted to an IPv4 address by stripping off the first 3 and the last 13 octets. If the NSAP-addressed contents are passed to a higher layer, the last 13 octets SHOULD be presented to the higher layer as well. If an NSAP address using this encoding is used for routing in an IPv4 routing architecture, only the 4-octet IPv4 address MAY be considered. 3.2. IPv6 Address Encoding in an NSAPA If it is required, for whatever reason, to embed an IPv6 address inside a 20-octet NSAP address, then the following format MUST be used. Note: alignment is an artifact of existing NSAPA usage. A specific possible use of this embedding is to express an IP address within the ATM Forum address format. Another possible use would be to allow CLNP packets that encapsulate IPv6 packets to be routed in a CLNP network using the IPv6 address architecture. Several leading octets of the IPv6 address could be used as a CLNP routing prefix. An NSAPA with an AFI value of '35' and an ICP value of '0' (zero) encodes a 16-octet IPv6 address in the first 16 octets of the DSP. The last octet of the DSP is a selector. To maintain compatibility with both NSAP format and IPv6 addressing, this octet MUST be present, but it has no intrinsic significance for IPv6. Its default value is zero, but other values may be used as specified for any specific application. For example, this octet may be used to specify one of 255 possible port numbers. Gray, et al. Standards Track [Page 5]
RFC 4548 Internet Code Point (ICP) Assignments May 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 | AFI = 0x35 | ICP = 0000 | IPv6 (octet 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IPv6 (octets 1-4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | IPv6 (octets 5-8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| IPv6 (octets 9-12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| IPv6 (octets 13-15) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An NSAPA with the IANA AFI code and ICP set to '0' (zero) is converted to an IPv6 address by stripping off the first 3 octets and the 20th octet. If the NSAP-addressed contents are passed to a higher layer, the last octet SHOULD be presented to the higher layer as well. If an NSAP address using this encoding is used for routing in an IPv6 routing architecture, only the 16-octet IPv6 address MAY be considered. 4. Security Considerations The NSAP encoding of IPv4 and IPv6 addresses is compatible with the corresponding security mechanisms of RFC 4301 [4301], hence this document introduces no new security exposure in the Internet. Gray, et al. Standards Track [Page 6]
RFC 4548 Internet Code Point (ICP) Assignments May 20065. References5.1. Normative References [4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [NSAP] International Organization for Standardization, "Information technology - Open Systems Interconnection - Network service Definition", ISO/IEC 8348:2002, 2002. [X.213] ITU-T Recommendation X.213, X-Series Recommendations, Data Networks and Open Systems Communications, October, 2001. [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 5.2. Informative References [1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J., and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. [4048] Carpenter, B., "RFC 1888 Is Obsolete", RFC 4048, April 2005. Gray, et al. Standards Track [Page 7]
RFC 4548 Internet Code Point (ICP) Assignments May 2006 Authors' Addresses Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851 EMail: Eric.Gray@Marconi.com John Rutemiller Ericsson 3000 Marconi Drive Warrendale, PA, 15086-7502 EMail: John.Rutemiller@Marconi.com George Swallow Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: swallow@cisco.com Gray, et al. Standards Track [Page 8]
RFC 4548 Internet Code Point (ICP) Assignments May 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 provided by the IETF Administrative Support Activity (IASA). Gray, et al. Standards Track [Page 9]
Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/

Point-to-Point (PPP) Protocol Field Assignments

Last Updated
2016-03-11
Available Formats

XML
HTML
Plain text

Registries included below

PPP DLL Protocol Numbers

Reference
[RFC1661][RFC3818]
Note
The Point-to-Point Protocol (PPP) Data Link Layer [RFC1331][RFC1332][RFC1353] contains a 16 bit Protocol field to identify the the encapsulated protocol. The Protocol field is consistent with the ISO 3309 (HDLC) extension mechanism for Address fields. All Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0", and the least significant bit of the least significant octet equals "1". It is recommended that values in the "02xx" to "1exx" and "xx01" to "xx1f" ranges not be assigned, as they are compression inefficient.
Available Formats

CSV
RangeRegistration ProceduresNote
0xxx-3xxxIETF ReviewNetwork Layer Protocols
4xxx-7xxxIETF ReviewLow volume traffic without NCP
8xxx-bxxxIETF ReviewNetwork Control Protocols
cxxx-fxxxIETF ReviewLink-layer Control Protocols
Value (in hex)Protocol NameReference
0001Padding Protocol[RFC1661]
0003ROHC small-CID[RFC3095]
0005ROHC large-CID[RFC3095]
0007-001fReserved (transparency inefficient)[RFC1661]
0021Internet Protocol version 4[RFC1332]
0023OSI Network Layer[RFC1377]
0025Xerox NS IDP[RFC1764]
0027DECnet Phase IV[RFC1762]
0029Appletalk[RFC1378]
002bNovell IPX[RFC1552]
002dVan Jacobson Compressed TCP/IP[RFC1332]
002fVan Jacobson Uncompressed TCP/IP[RFC1332]
0031Bridging PDU[RFC3518]
0033Stream Protocol (ST-II)
0035Banyan Vines[RFC1763]
0037Unassigned
0039AppleTalk EDDP
003bAppleTalk SmartBuffered
003dMulti-Link[RFC1990]
003fNETBIOS Framing[RFC2097]
0041Cisco Systems
0043Ascom Timeplex
0045Fujitsu Link Backup and Load Balancing (LBLB)
0047DCA Remote Lan
0049Serial Data Transport Protocol (PPP-SDTP)[RFC1963]
004bSNA over 802.2[RFC2043]
004dSNA[RFC2043]
004fIPv6 Header Compression
0051KNX Bridging Data[ianp_knxunix_knx_co]
0053Encryption[RFC1968]
0055Individual Link Encryption[RFC1968]
0057Internet Protocol version 6[RFC5072]
0059PPP Muxing[RFC3153]
005bVendor-Specific Network Protocol (VSNP)[RFC3772]
005dTRILL Network Protocol (TNP)[RFC6361]
0061RTP IPHC Full Header[RFC3544]
0063RTP IPHC Compressed TCP[RFC3544]
0065RTP IPHC Compressed Non TCP[RFC3544]
0067RTP IPHC Compressed UDP 8[RFC3544]
0069RTP IPHC Compressed RTP 8[RFC3544]
006fStampede Bridging
0071Reserved[Karl_Fox]
0073MP+ Protocol[RFC1934]
007dReserved (Control Escape)[RFC1661]
007fReserved (compression inefficient)[RFC1662]
0081Unassigned
0083Unassigned
00c1NTCITS IPI[Alan_Ungar]
00cfReserved (PPP NLPID)[RFC1661]
00fbSingle link compression in multilink[RFC1962]
00fdCompressed datagram[RFC1962]
00ffReserved (compression inefficient)[RFC1661]
0201802.1d Hello Packets[RFC3518]
0203IBM Source Routing BPDU[RFC3518]
0205DEC LANBridge100 Spanning Tree[RFC3518]
0207Cisco Discovery Protocol[Arun_Sastry]
0209Netcs Twin Routing[Oliver_Korfmacher]
020bSTP - Scheduled Transfer Protocol[Ben_Segal]
020dEDP - Extreme Discovery Protocol[Don_Grosser]
0211Optical Supervisory Channel Protocol (OSCP)[Sharat_C_Prasad]
0213Optical Supervisory Channel Protocol (OSCP)[Sharat_C_Prasad]
0231Luxcom
0233Sigma Network Systems
0235Apple Client Server Protocol[Howard_Ridenour]
0281MPLS Unicast[RFC3032]
0283MPLS Multicast[RFC3032]
0285IEEE p1284.4 standard - data packets[Brian_Batchelder]
0287ETSI TETRA Network Protocol Type 1[Seppo_Nieminen]
0289Multichannel Flow Treatment Protocol[Pete_McCann]
028b-1exxReserved for compression inefficient
2063RTP IPHC Compressed TCP No Delta[RFC3544]
2065RTP IPHC Context State[RFC3544]
2067RTP IPHC Compressed UDP 16[RFC3544]
2069RTP IPHC Compressed RTP 16[RFC3544]
4001Cray Communications Control Protocol[Erling_B_Stage]
4003CDPD Mobile Network Registration Protocol[Frank_Quick]
4005Expand accelerator protocol[Ilan_Rachmani]
4007ODSICP NCP[K_Arvind]
4009DOCSIS DLL[Jason_Gaedtke]
400BCetacean Network Detection Protocol[Curtis_A_Siller_Jr]
4021Stacker LZS[RFC1974]
4023RefTek Protocol[Robert_Banfill]
4025Fibre Channel[Murali_Rajagopal]
4027OpenDOF[Bryant_Eastham]
405bVendor-Specific Protocol (VSP)[RFC3772]
405dTRILL Link State Protocol (TLSP)[RFC6361]
8001-801fNot Used - reserved[RFC1661]
8021Internet Protocol Control Protocol[RFC1332]
8023OSI Network Layer Control Protocol[RFC1377]
8025Xerox NS IDP Control Protocol[RFC1764]
8027DECnet Phase IV Control Protocol[RFC1762]
8029Appletalk Control Protocol[RFC1378]
802bNovell IPX Control Protocol[RFC1552]
802dReserved
802fReserved
8031Bridging NCP[RFC3518]
8033Stream Protocol Control Protocol
8035Banyan Vines Control Protocol[RFC1763]
8037Unassigned
8039Reserved
803bReserved
803dMulti-Link Control Protocol[RFC1990]
803fNETBIOS Framing Control Protocol[RFC2097]
8041Cisco Systems Control Protocol
8043Ascom Timeplex
8045Fujitsu LBLB Control Protocol
8047DCA Remote Lan Network Control Protocol (RLNCP)
8049Serial Data Control Protocol (PPP-SDCP)[RFC1963]
804bSNA over 802.2 Control Protocol[RFC2043]
804dSNA Control Protocol[RFC2043]
804fIP6 Header Compression Control Protocol
8051KNX Bridging Control Protocol[ianp_knxunix_knx_co]
8053Encryption Control Protocol[RFC1968]
8055Individual Link Encryption Control Protocol[RFC1968]
8057IPv6 Control Protocol[RFC5072]
8059PPP Muxing Control Protocol[RFC3153]
805bVendor-Specific Network Control Protocol (VSNCP)[RFC3772]
805dTRILL Network Control Protocol (TNCP)[RFC6361]
806fStampede Bridging Control Protocol
8073MP+ Control Protocol[RFC1934]
8071Reserved[Karl_Fox]
807dNot Used - reserved[RFC1661]
8081Unassigned
8083Unassigned
80c1NTCITS IPI Control Protocol[Alan_Ungar]
80cfNot Used - reserved[RFC1661]
80fbsingle link compression in multilink control[RFC1962]
80fdCompression Control Protocol[RFC1962]
80ffNot Used - reserved[RFC1661]
8207Cisco Discovery Protocol Control[Arun_Sastry]
8209Netcs Twin Routing[Oliver_Korfmacher]
820bSTP - Control Protocol[Ben_Segal]
820dEDPCP - Extreme Discovery Protocol Ctrl Prtcl[Don_Grosser]
8235Apple Client Server Protocol Control[Howard_Ridenour]
8281MPLSCP[RFC3032]
8285IEEE p1284.4 standard - Protocol Control[Brian_Batchelder]
8287ETSI TETRA TNP1 Control Protocol[Seppo_Nieminen]
8289Multichannel Flow Treatment Protocol[Pete_McCann]
c021Link Control Protocol[RFC1661]
c023Password Authentication Protocol[RFC1661]
c025Link Quality Report[RFC1661]
c027Shiva Password Authentication Protocol
c029CallBack Control Protocol (CBCP)
c02bBACP Bandwidth Allocation Control Protocol[RFC2125]
c02dBAP[RFC2125]
c05bVendor-Specific Authentication Protocol (VSAP)[RFC3772]
c081Container Control Protocol[Ken_funk_com]
c223Challenge Handshake Authentication Protocol[RFC1661]
c225RSA Authentication Protocol[Badari_Narayana]
c227Extensible Authentication Protocol[RFC3748]
c229Mitsubishi Security Info Exch Ptcl (SIEP)[Shoichiro_Seno]
c26fStampede Bridging Authorization Protocol
c281Proprietary Authentication Protocol[Ken_funk_com]
c283Proprietary Authentication Protocol[Wayne_Tackabury]
c481Proprietary Node ID Authentication Protocol[Ken_funk_com]

PPP Link Control Protocol (LCP) and Internet Protocol Control Protocol (IPCP) Codes

Registration Procedure(s)
IETF Review
Reference
[RFC1661][RFC3818]
Note
The Point-to-Point Protocol (PPP) Link Control Protocol (LCP), the Compression Control Protocol (CCP), Internet Protocol Control Protocol (IPCP), and other control protocols, contain an 8 bit Code field which identifies the type of packet.
Available Formats

CSV

PPP LCP Configuration Option Types

Registration Procedure(s)
IETF Review
Reference
[RFC1661][RFC3818]
Note
The Point-to-Point Protocol (PPP) Link Control Protocol (LCP) specifies a number of Configuration Options which are distinguished by an 8 bit Type field.
Available Formats

CSV
TypeConfiguration OptionReference
0Vendor Specific[RFC2153]
1Maximum-Receive-Unit[RFC1661]
2Async-Control-Character-Map
3Authentication-Protocol[RFC1661]
4Quality-Protocol[RFC1661]
5Magic-Number[RFC1661]
6DEPRECATED (Quality-Protocol)
7Protocol-Field-Compression[RFC1661]
8Address-and-Control-Field-Compression[RFC1661]
9FCS-Alternatives[RFC1570]
10Self-Describing-Pad[RFC1570]
11Numbered-Mode[RFC1663]
12DEPRECATED (Multi-Link-Procedure)
13Callback[RFC1570]
14DEPRECATED (Connect-Time)
15DEPRECATED (Compound-Frames)
16DEPRECATED (Nominal-Data-Encapsulation)
17Multilink-MRRU[RFC1990]
18Multilink-Short-Sequence-Number-Header[RFC1990]
19Multilink-Endpoint-Discriminator[RFC1990]
20Proprietary[Ken_funk_com]
21DCE-Identifier [Warning: option type in the RFC is incorrect.][RFC1976]
22Multi-Link-Plus-Procedure[RFC1934]
23Link Discriminator for BACP[RFC2125]
24LCP-Authentication-Option[Ken_Culbert]
25Consistent Overhead Byte Stuffing (COBS)[James_Carlson]
26Prefix elision[RFC2686][RFC2687]
27Multilink header format[RFC2686][RFC2687]
28Internationalization[RFC2484]
29Simple Data Link on SONET/SDH[RFC2823]
30Unassigned

PPP TNCP Configuration Option Types

Registration Procedure(s)
IETF Review
Reference
[RFC6361]
Available Formats

CSV
TypeConfiguration OptionReference
0Vendor Specific[RFC2153]

PPP ECP Configuration Option Types

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1968]
Note
A one octet field is used in the Encryption Control Protocol (ECP) to indicate the configuration option type [RFC1968].
Available Formats

CSV

PPP CCP Configuration Option Types

Registration Procedure(s)
IETF Review
Reference
[RFC1962][RFC3818]
Note
A one octet field is used in the Compression Control Protocol (CCP) to indicate the configuration option type [RFC1962]. The unassigned values 4-15 are intended to be assigned to other freely available compression algorithms that have no license fees.
Available Formats

CSV

PPP SDCP Configuration Options

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1963]
Note
A one octet field is used in the PPP Serial Data Transport Protocol (SDTP) to indicate the option type [RFC1963]. Note that Option Types 5-8 are specific to a single port and require port numbers in their format. Option Types 6-8 are specific to the HDLC-Synchronous Transport-Mode.
Available Formats

CSV

PPP Authentication Algorithms

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1994]
Note
A one octet field is used in the Challenge-Handshake Authentication Protocol (CHAP) to indicate which algorithm is in use [RFC1994].
Available Formats

CSV

PPP LCP FCS-Alternatives

Registration Procedure(s)
IETF Review
Reference
[RFC1570][RFC3818]
Note
The Point-to-Point Protocol (PPP) Link Control Protocol (LCP) FCS-Alternatives Configuration Option contains an 8-bit Options field which identifies the FCS used. These are assigned as follows.
Available Formats

CSV
BitFCSReference
1Null FCS[RFC1570]
2CCITT 16-Bit FCS[RFC1570]
3Unassigned
4CCITT 32-bit FCS[RFC1570]

PPP Multilink Endpoint Discriminator Class

Registration Procedure(s)
IETF REview
Reference
[RFC1990][RFC3818]
Note
The Point-to-Point Protocol (PPP) Link Control Protocol (LCP) Multilink Endpoint Discriminator Option includes a Class field which identifies the address class.
Available Formats

CSV
ClassDescriptionReference
0Null Class[RFC1990]
1Locally Assigned[RFC1990]
2Internet Protocol (IPv4)[RFC1990]
3IEEE 802.1 global MAC address[RFC1990]
4PPP Magic Number Block[RFC1990]
5Public Switched Network Director Number[RFC1990]
6Internet Protocol (Ipv6) Address[RFC3790]

PPP LCP Callback Operation Fields

Registration Procedure(s)
IETF Review
Reference
[RFC1570][RFC3818]
Note
The Point-to-Point Protocol (PPP) Link Control Protocol (LCP) Callback Configuration Option contains an 8-bit Operations field which identifies the format of the Message.
Available Formats

CSV
OperationDescriptionReference
0Location determined by user authentication[RFC1570]
1Dialing string[RFC1570]
2Location identifier[RFC1570]
3E.164 number[RFC1570]
4X.500 distinguished name[RFC1570]
5Unassigned
6Location is determined during CBCP negotiation

PPP ATCP Configuration Option Types

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1378]
Note
The Point-to-Point Protocol (PPP) Apple Talk Control Protocol (ATCP) specifies a number of Configuration Options [RFC1378] which are distinguished by an 8 bit Type field.
Available Formats

CSV

PPP OSINLCP Configuration Option Types

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1377]
Note
The Point-to-Point Protocol (PPP) OSI Network Layer Control Protocol (OSINLCP) specifies a number of Configuration Options [RFC1377] which are distinguished by an 8 bit Type field.
Available Formats

CSV
TypeConfiguration OptionReference
1Align-NPDU[RFC1377]

PPP Banyan Vines Configuration Option Types

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1763]
Note
The Point-to-Point Protocol (PPP) Banyan Vines Control Protocol (BVCP) specifies a number of Configuration Options [RFC1763] which are distinguished by an 8 bit Type field.
Available Formats

CSV

PPP Bridging Configuration Option Types

Registration Procedure(s)
IETF Review
Reference
[RFC3518][RFC3818]
Note
The Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) specifies a number of Configuration Options which are distinguished by an 8 bit Type field.
Available Formats

CSV
TypeConfiguration OptionReference
1Bridge-Identification[RFC3518]
2Line-Identification[RFC3518]
3MAC-Support[RFC3518]
4Tinygram-Compression[RFC3518]
5LAN-Identification (obsoleted)[RFC3518]
6MAC-Address[RFC3518]
7Spanning-Tree-Protocol (old formatted)[RFC3518]
8IEEE-802-Tagged-Frame[RFC3518]
9Management-Inline[RFC3518]
10Bridge-Control-Packet-Indicator[RFC3518]

PPP Bridging MAC Types

Registration Procedure(s)
IETF Review
Reference
[RFC3518][RFC3818]
Note
The Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) contains an 8 bit MAC Type field which identifies the MAC encapsulated.
Available Formats

CSV
TypeMACAddress FormatReference
0Reserved[RFC3518]
1IEEE 802.3/EthernetCanonical addresses[RFC3518]
2IEEE 802.4Canonical addresses[RFC3518]
3IEEE 802.5Non-canonical addresses[RFC3518]
4FDDINon-canonical addresses[RFC3518]
5-10Reserved
11IEEE 802.5Canonical addresses[RFC3518]
12FDDICanonical addresses[RFC3518]

PPP Bridging Spanning Tree

Registration Procedure(s)
IETF Review
Reference
[RFC3518][RFC3818]
Note
The Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) Spanning Tree Configuration Option contains an 8-bit Protocol field which identifies the spanning tree used. These are assigned as follows:
Available Formats

CSV
ProtocolSpanning TreeReference
0Null - no spanning tree protocol supported[RFC3518]
1IEEE 802.1D spanning tree protocol[RFC3518]
2IEEE 802.1G extended spanning tree protocol[RFC3518]
3IBM source route spanning tree protocol[RFC3518]
4DEC LANbridge 100 spanning tree protocol[RFC3518]

PPP (IPXCP) Configuration Options

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1552]
Available Formats

CSV
OptionDescriptionReference
1IPX-Network-Number[RFC1552]
2IPX-Node-Number[RFC1552]
3IPX-Compression-Protocol[RFC1552]
4IPX-Routing-Protocol[RFC1552]
5IPX-Router-Name[RFC1552]
6IPX-Configuration-Complete[RFC1552]

IPX Compression Protocol Values (Value 3)

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1552]
Available Formats

CSV
Value (in hex)ProtocolReference
0000-0001Unassigned
0002Telebit Compressed IPX[RFC1552]
0002-0234Unassigned
0235Shiva Compressed NCP/IPX[RFC1552]

IPX Routing Protocol Options (Value 4)

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC1552]
Available Formats

CSV

NetBIOS Frames Control Protocol (NBFCP) Configuration Options

Registration Procedure(s)
Expert Review
Expert(s)
James Carlson
Reference
[RFC2097]
Note
NBFCP Configuration Options [RFC2097] allow modifications to the standard characteristics of the network-layer protocol to be negotiated. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed. NBFCP uses the same Configuration Option format defined for LCP, with a separate set of Options.
Available Formats

CSV
ValueOptionReference
0Reserved[RFC2153]
1Name-Projection[RFC2097]
2Peer-Information[RFC2097]
3Multicast-Filtering[RFC2097]
4IEEE-MAC-Address-Required[RFC2097]
5-255Unassigned

NBFCP Configuration Options - Name-Projection 'Added' field (value 1)

Registration Procedure(s)
IANA does not allocate
Reference
[RFC2097]
Note
The Name-Projection 'Added' field is not defined by IETF or allocated through IANA and thus no new values should be allocated.
Available Formats

CSV
Value (Hex)Result Codes for Added fieldReference
00Name successfully added.[RFC2097]
0DDuplicate name in local name table.[RFC2097]
0EName table full.[RFC2097]
15Name not found or cannot specify "*" or null.[RFC2097]
16Name in use on remote NetBIOS.[RFC2097]
19Name conflict detected.[RFC2097]
30Name defined by another environment.[RFC2097]
35Required system resources exhausted.[RFC2097]
36-FFUndefined

NBFCP Configuration Options - Peer-Information (value 2)

Registration Procedure(s)
Expert Review
Reference
[RFC2097]
Available Formats

CSV
ValuePeer-ClassReference
1Reserved for legacy implementations.[RFC2097]
2PPP NetBIOS Gateway Server.[RFC2097]
3Reserved for legacy implementations.[RFC2097]
4PPP Local Access Only Server.[RFC2097]
5Reserved for legacy implementations.[RFC2097]
6PPP NBF Bridge.[RFC2097]
7Reserved for legacy implementations.[RFC2097]
8PPP End-System.[RFC2097]
9-255Unassigned

PPP EAP Request/Response Types

Registration Procedure(s)
Expert Review
Reference
[RFC3748]
Note
A one octet field is used in the Extensible Authentication Protocol (EAP) to indicate the function and structure of EAP Request and Response packets [RFC3748]. This registry has been replaced. See the "Method Types" registry at [IANA registry eap-numbers] for a current list of the assigned types.
No registrations at this time.

PPP Vendor Specific OUI Options

Registration Procedure(s)
Registry closed by [RFC5342]
Reference
[RFC5342]
Note
PPP Vendor Extensions [RFC2153] uses IEEE standard OUIs (Organizationally Unique Identifiers) to indicate vendor-specific features. See [RFC1700] for details on contacting the IEEE. Vendors that desire to use their IEEE 802 OUI for PPP Vendor Extensions should register their OUI with IANA. Vendors that do not otherwise need an IEEE assigned OUI can request a PPP specific OUI from IANA out of the 'CF0000' range, which has both the "locally-assigned" and "broadcast/multicast" bits set to one. See [RFC2153] for details.
Available Formats

CSV
OUI (in hex)OrganizationReference
CF0001NTT Mobile Communications Network
CF0001Data Comm for Business [1][John_McCain]
CF00023GPP2 Vendor specific packet ID[Trevor_Plestid]
CF0003Trafficmaster, Plc[David_Fernandez]
CF0004-CFFFFFReserved: Registry closed

PPP IPCP Configuration Option Types

Registration Procedure(s)
IETF Review
Reference
[RFC1332][RFC3818]
Note
The Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) specifies a number of Configuration Options which are distinguished by an 8 bit Type field.
Available Formats

CSV
TypeConfiguration OptionReference
1IP-Addresses (deprecated)[RFC1332]
2IP-Compression-Protocol[RFC1332]
3IP-Address[RFC1332]
4Mobile-IPv4[RFC2290]
5-128Unassigned
129Primary DNS Server Address[RFC1877]
130Primary NBNS Server Address[RFC1877]
131Secondary DNS Server Address[RFC1877]
132Secondary NBNS Server Address[RFC1877]

PPP IPv6CP Configuration Options

Registration Procedure(s)
IETF Review
Reference
[RFC5072][RFC3818]
Note
IPV6CP Configuration Options allow negotiation of desirable IPv6 parameters. IPV6CP uses the same Configuration Option format defined for LCP, with a separate set of Options. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
Available Formats

CSV
TypeConfiguration OptionReference
1Interface-Identifier[RFC5072]
2IPv6-Compression-Protocol[RFC5172]

IP-Compression-Protocol Types

Registration Procedure(s)
IETF Review
Reference
[RFC1332]
Available Formats

CSV
Value (hex)DescriptionReference
002dVan Jacobson Compressed TCP/IP[RFC1144][RFC1332]
0003Robust Header Compression (ROHC)[RFC3241]
0061IP Header Compression[RFC2507][RFC3544]

IPv6-Compression-Protocol Types

Registration Procedure(s)
IETF Review
Reference
[RFC5172]
Available Formats

CSV
Value (hex)DescriptionReference
0003Robust Header Compression (ROHC)[RFC3241]
004fHistorical; do not use -- see RFC2023
0061IP Header Compression[RFC2507][RFC3544]

IP Header Compression Configuration Option Suboption Types

Registration Procedure(s)
Standards Action
Reference
[RFC3544]
Available Formats

CSV
ValueDescriptionReference
1RTP Header Compression[RFC2508][RFC3544]
2Enhanced RTP-Compression[RFC3544]
3TCP or non-TCP Compression Disable[RFC3544]

ROHC Configuration Option Suboption Identifier Values

Reference
[RFC3241]
Note
Please see [IANA registry rohc-sub-ids]
No registrations at this time.

People

Leave a Comment

(0 Comments)

Your email address will not be published. Required fields are marked *