Internet DRAFT - draft-melnikov-nsap-ipv6
draft-melnikov-nsap-ipv6
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]