RFC 4048

RFC 1888 Is Obsolete

πŸ“… published April 2005, from ietf

RFC 4048: RFC 1888 Is Obsolete πŸ’–

Okay bestie, here's the header stuff first πŸŽ€

Request for Comments: 4048 Category: Informational Author: Brian E. Carpenter (IBM) Date: April 2005 Network Working Group

The title says it all: RFC 1888 is obsolete 😭 This doc recommends reclassifying it as Historic, since almost all of it has no further value except one section, which is faulty. πŸ₯€

Status of This Memo

This memo gives information to the Internet community ✨ It does not specify an Internet standard of any kind. Distribution of this memo is unlimited πŸ¦‹

Copyright (C) The Internet Society (2005). 🌈

Abstract

This doc recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic πŸ•°οΈ 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 🌸

Okay so [RFC1888] came out as an Experimental RFC in 1996, back when IPv6 was super new 🧚 People really wanted to think about using OSI addressing with IPv6, so it was a big deal at the time. In Sections 3 through 5, it defines mappings of certain OSI Network Service Access Point (NSAP) addresses inside IPv6 addresses, plus how to carry arbitrary NSAP addresses as IPv6 destination options. But it also has some serious "health warnings" about how hard it is to route packets across the global Internet using those addresses 🚨 As far as the IETF knows, these address mappings have never been seriously used, and IPv6 implementations don't support them. Also, OSI deployment isn't widespread enough that anything is likely to change that situation πŸ˜”

Also, Section 6 of [RFC1888] specifies a mapping of IPv6 addresses inside OSI NSAP addresses πŸ‘€ This one got some buzz lately, for example to let IP addresses be expressed in an Asynchronous Transfer Mode (ATM) context. Unfortunately, Section 6 of [RFC1888] has two errors in how it uses the OSI Initial Domain Part (IDP) format πŸ™ˆ

  • First, the text calls the Internet Code Point (ICP) a single octet, when it's actually a 16-bit field.
  • Second, the text says "[t]he first three octets are an IDP in binary format". But [NSAP] says in section A.5.2.1 that "[t]he abstract syntax for the IDI is decimal digits", and it 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 πŸ¦‹

Because one of the mappings is basically unused, and the other one's documentation has errors, this doc recommends that the IESG reclassify [RFC1888] as Historic πŸ“š

It's assumed that anyone who wants 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. Zero drama here 🫢

4. IANA Considerations ✨

IANA has marked the IPv6 address prefix 0000 001, which is 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. Thank you, queens πŸ‘‘

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

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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents is in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights can be found in the IETF online 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 send that info to the IETF at ietf-ipr@ietf.org. πŸ“¬

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. πŸ’–

πŸ“¦ where this page comes from