Internet Draft: Network Address to support OSI over IPv6      D. Wilson
Document: draft-melnikov-nsap-ipv6-02                          S. Kille
Expires: July 2006                                          A. Melnikov
Intended category: Standard Track                            Isode Ltd.
Updates: RFC 1277                                          January 2006

                Network Address to support OSI over IPv6

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   A revised version of this draft document will be submitted to the RFC
   editor as a Proposed Standard for the Internet Community.  Discussion
   and suggestions for improvement are requested, and should be sent
   directly to the authors. Distribution of this draft is unlimited.


   This document defines a format for OSI NSAP Addresses for use where
   TCP or UDP is used to provide the OSI Network Service over IPv6, as
   in RFC 2126 (ISO Transport Service on top of TCP (ITOT)).  This
   requires encoding of an IPv6 address and a port number in the NSAP.
   RFC 1277 defines an NSAP format for use with IPv4 addresses, and this
   document updates RFC 1277 to allow for IPv6 addresses.

1.   Introduction

Wilson et al               Expires: July 2006                   [Page 1]

INTERNET DRAFT  Network Address to support OSI over IPv6    January 2006

1.1.   Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

   Editorial comments/questions or missing paragraphs are marked in the
   text with << and >>.

1.2.   Rationale

   [ITOT] defines a mechanism for the OSI upper layers to use Transport
   Classes 0 and 2 using TCP as the Network Service. In this case the
   Network Service Access Point (NSAP) address is effectively defined by
   the IP address and TCP port number.

   It would be possible to have a local mechanism to map from arbitrary
   network addresses to the required TCP/IP information. However, this
   is not practical for wide-area connections. Therefore, a mechanism
   which encodes the TCP/IP addressing information with the NSAP address
   is to be preferred. [RFC1277] provides such an embedding mechanism.
   However, it only supports IPv4 addresses.

   There are places where NSAP addresses are carried in protocol. The
   preferred concrete syntax for NSAP addresses uses 20 octets. IPv6
   addresses are 16 octets long, and TCP port numbers require 2 octets.
   Therefore there are only two octets free to define the address

   [RFC1888] defines a format for embedding IPv6 addresses into NSAP
   addresses. However, this format defines a IDI of two octets, leaving
   one octet for the network selector. So there is insufficient space in
   the network selector for the TCP port number. To use the domain
   identifier for part of the TCP port number does not seem an elegant

   However, this NSAP address format could be used if the default port
   for the service is implied. Implementations of ITOT SHOULD interpret
   NSAP addresses in this format as implying the use of IPv6 with the
   default port.

   The only other defined Authority and Format Indicator (AFI) which
   leaves suffient space for both an IPv6 address and TCP port number is
   the binary local AFI (49). However, using this format may conflict
   with other uses of this AFI on some systems, if they support multiple
   network services and the local AFI is use on one of these.

Wilson et al               Expires: July 2006                   [Page 2]

INTERNET DRAFT  Network Address to support OSI over IPv6    January 2006

   Therefore, in order to support OSI transport over IPv6 to non-default
   ports we need a new NSAP address format.

2.   NSAPA for IPv6 address and port

   The Initial Domain Part (IDP) consists of one octet AFI (<<to be
   allocated by ITU-T>>) and a one octet IDI. The IDI is used to
   distinguish different uses of the address and port contained in the
   Domain Specific Part. For ITOT, the IDI value of 0 is used. Further
   values for this field are to be assigned by the IANA on an IETF
   consensus basis [RFC2434].

   The Domain Specific Part (DSP) consists of two fields: 16 octet IPv6
   address in network byte order, followed by 2 octet port number in
   network byte order. The TCP port number takes over the function of
   the network selector. If the port number field is 0, the port number
   defaults to the value defined in [ITOT].

   An NSAPA with the <<TBD>> AFI code is converted to an IPv6 address by
   stripping off the first and the twentieth octets.

          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 = <<TBD>> |    IDI        |       IPv6  (byte 0-1)        |
    4-7  |             IPv6  (bytes 2-5)                                 |
    8-11 |             IPv6  (bytes 6-9)                                 |
    12-15|             IPv6  (bytes 10-13)                               |
    16-19|     IPv6 (bytes 14-15)        |      Port (2 bytes)           |

3.   Security Considerations

   <<Security issues are not specifically addressed in this document,
   but it is compatible with the IPv6 security mechanisms [RFC2401].>>

4.   IANA Considerations

   IANA is requested to add AFI <<TBD>> to the registry of the OSI

Wilson et al               Expires: July 2006                   [Page 3]

INTERNET DRAFT  Network Address to support OSI over IPv6    January 2006

   The following IDI should be registered under this AFI:

       IDI Value   Address Encoding   Format Definition
       ----------  -----------------  ----------------------------
          '0'           IPv6          <this document>, section 2

   <<This needs some communication with ITU-T to allocate a new AFI and
   delegate it to IANA.>>

   Remaining decimal values '1' through '99'<<?>> MUST be assigned on an
   IETF consensus basis [RFC2434].

5.   Acknowledgments

   This document borrows some text from RFC 1277 [RFC1277] and RFC 1888

6.   References

6.1.   Normative references

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

   [RFC1277] Kille, S., "Encoding Network Addresses to support operation
   over non-OSI lower layers", RFC 1277, November 1991.

   [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 2460, December 1998.

   Hinden,, R., and S. Deeing, "IP Version 6 Addressing Architecture",
   RFC 2373, April 2003.

   [ITOT] Pouffary, Y. and A. Young, "ISO Transport Service on top of
   TCP (ITOT)", RFC 2126, March 1997.

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998.

   [RFC2434] RFC 2434, "Guidelines for Writing an IANA Considerations
   Section in RFCs", Thomas Narten and Harald Alvestrand, October 1998.

6.2.   Informative references

   [RFC1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
   and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.

Wilson et al               Expires: July 2006                   [Page 4]

INTERNET DRAFT  Network Address to support OSI over IPv6    January 2006

   [ISO8348]  ISO. "International Standard 8348.  Information Processing
   Systems - Open Systems Interconnection: Network Service Definition."
   [ITU Recommendation X.213]

7.   Author's Addresses

   David Wilson    <>
   Steve Kille     <>
   Alexey Melnikov <>

   Isode Ltd.
   5 Castle Business Village,
   36 Station Road,
   Hampton, Middlesex,
   TW12 2BX, United Kingdom

8.   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

9.   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

Wilson et al               Expires: July 2006                   [Page 5]

INTERNET DRAFT  Network Address to support OSI over IPv6    January 2006

   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

   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-

Wilson et al               Expires: July 2006                   [Page 6]