Internet Code Point (ICP) Assignments for NSAP Addresses
RFC 4548

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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