1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc4048.txt b/doc/rfc/rfc4048.txt
new file mode 100644
index 0000000..778f68b
--- /dev/null
+++ b/doc/rfc/rfc4048.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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
+
+
+
+Carpenter                    Informational                      [Page 1]
+
+RFC 4048                  RFC 1888 Is Obsolete                April 2005
+
+
+   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.
+
+
+
+
+Carpenter                    Informational                      [Page 2]
+
+RFC 4048                  RFC 1888 Is Obsolete                April 2005
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter                    Informational                      [Page 3]
+
+RFC 4048                  RFC 1888 Is Obsolete                April 2005
+
+
+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.
+
+
+
+
+
+
+
+Carpenter                    Informational                      [Page 4]
+