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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 ([ISO8348]). [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 solution. 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 NSAPAs: <http://www.iana.org/assignments/osi-nsapa-numbers>. 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 [RFC1888]. 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 <David.Wilson@isode.com> Steve Kille <Steve.Kille@isode.com> Alexey Melnikov <Alexey.Melnikov@isode.com> 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 "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. Acknowledgement 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 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. Wilson et al Expires: July 2006 [Page 6]