Network Working Group B. Carpenter
Request for Comments: 4048 IBM
Category: Informational April 2005
RFC 1888 Is Obsolete
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document recommends that RFC 1888, on Open Systems
Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6,
be reclassified as Historic, as most of it has no further value,
apart from one section, which is faulty.
Table of Contents
1. IntrodUCtion .................................................. 1
2. Recommendation to Reclassify RFC 1888 ......................... 2
3. Security Considerations ....................................... 2
4. IANA Considerations ........................................... 2
5. Acknowledgements .............................................. 2
6. Normative References .......................................... 3
Author's Address .................................................. 3
Full Copyright Statement .......................................... 4
1. Introduction
[RFC1888] was published as an EXPerimental RFC in 1996, at an early
stage in the development of IPv6, when it appeared important to
consider usage of Open Systems Interconnection (OSI) addressing for
IPv6. In Sections 3 through 5, it defines mappings of certain OSI
Network Service Access Point (NSAP) addresses inside IPv6 addresses,
and how to carry arbitrary NSAP addresses as IPv6 destination
options. However, it also contains significant "health warnings"
about the difficulty of routing packets in the global Internet using
such addresses. As far as is known to the IETF, these address
mappings have never been seriously used and are not supported by IPv6
implementations. Furthermore, the deployment of OSI solutions is not
sufficiently widespread that any change in this situation can be
expected.
Additionally, Section 6 of [RFC1888] specifies a mapping of IPv6
addresses inside OSI NSAP addresses. This mapping has recently
aroused some interest: for example, to allow IP addresses to be
expressed in an Asynchronous Transfer Mode (ATM) context.
Unfortunately, Section 6 of [RFC1888] contains two errors in its
usage of OSI Initial Domain Part (IDP) format:
* first, the text refers to the Internet Code Point (ICP) as a single
octet, whereas it is correctly a 16-bit field;
* second, the text states that "[t]he first three octets are an IDP
in binary format", but [NSAP] states in section A.5.2.1 that "[t]he
abstract syntax for the IDI is decimal digits" and specifies a
preferred binary encoding in section A.5.3 "using a semi-octet to
represent the value of each decimal digit ... , yielding a value in
the range 0000-1001".
2. Recommendation to Reclassify RFC 1888
Due to the lack of use of one of the mappings, and to the errors in
the documentation of the other, this document recommends that the
IESG reclassify [RFC1888] as Historic.
It is assumed that parties who wish to use a mapping of IPv6
addresses inside OSI NSAP addresses will correct, augment, and
resubmit Section 6 of [RFC1888] as a separate document.
3. Security Considerations
This recommendation has no known impact on the security of the
Internet.
4. IANA Considerations
IANA has marked the IPv6 address prefix 0000 001, reserved for NSAP
Allocation in [RFC3513], simply as Reserved.
IANA is holding the registry for "OSI NSAPA Internet Code Point"
implied by Section 6 of [RFC1888] in abeyance until a replacement for
that Section is approved for publication.
5. Acknowledgements
Scott Brim and Arun Pandey made useful comments on this document.
6. Normative References
[RFC1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[NSAP] International Organization for Standardization,
"Information technology -- Open Systems Interconnection --
Network service definition", ISO/IEC 8348:2002, 2002.
Author's Address
Brian E. Carpenter
IBM Zurich Research Laboratory
Saeumerstrasse 4 / Postfach
8803 Rueschlikon
Switzerland
EMail: brc@zurich.ibm.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
