Internet Code Point (ICP) Assignments for NSAP Addresses
RFC 4548
Document | Type |
RFC - Proposed Standard
(May 2006; No errata)
Was draft-gray-rfc1888bis (individual in gen area)
|
|
---|---|---|---|
Authors | John Rutemiller , Eric Gray , George Swallow | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4548 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | ewgray@lucent.com |
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 TerminologyShow full document text