diff options
Diffstat (limited to 'doc/rfc/rfc4548.txt')
| -rw-r--r-- | doc/rfc/rfc4548.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc4548.txt b/doc/rfc/rfc4548.txt new file mode 100644 index 0000000..cadeed3 --- /dev/null +++ b/doc/rfc/rfc4548.txt @@ -0,0 +1,507 @@ + + + + + + +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 ....................................................2 + 1.1. Conventions ................................................2 + 1.2. Acronyms and Terminology ...................................3 + 2. IANA Considerations .............................................3 + 3. Initial Allocations and Uses ....................................4 + 3.1. IPv4 Address Encoding in an NSAPA ..........................4 + 3.2. IPv6 Address Encoding in an NSAPA ..........................5 + 4. Security Considerations .........................................6 + 5. References ......................................................7 + 5.1. Normative References .......................................7 + 5.2. Informative References .....................................7 + + + +Gray, et al. Standards Track [Page 1] + +RFC 4548 Internet Code Point (ICP) Assignments May 2006 + + +1. Introduction + + Section 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 section + 6 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 2006 + + +1.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 2006 + + +5. References + +5.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] + |