RFC 1888
OSI NSAPs and IPv6
RFC 1888: OSI NSAPs and IPv6 🦋
Network Working Group 💖 This one is RFC 1888, and it was published in August 1996 by the IETF.
It's marked as Experimental, so the vibe is "try it and tell us how it goes," not "this is the rule." 🧪
The authors are J. Bound (Digital Equipment Corporation), B. Carpenter (CERN), D. Harrington (Digital Equipment Corporation), J. Houldsworth (ICL Network Systems), and A. Lloyd (Datacraft Technologies). 🫶 The title block doesn't list anything it obsoletes or updates.
Status of This Memo ✨
okay so first things first, this memo defines an Experimental Protocol for the Internet community. It is NOT an Internet standard of any kind 🙈 Discussion and suggestions for improvement are literally requested, so bring your ideas. Distribution of this memo is unlimited. 📣
Abstract 🌸
okay so the big takeaway is that if you're a network implementor who already planned or deployed an OSI NSAP addressing plan and you want to move to IPv6, you should redesign a native IPv6 addressing plan that fits your needs. 💅
BUT, and this is a big but, the doc also defines a set of mechanisms for supporting OSI NSAP addressing inside an IPv6 network. Those mechanisms are the ones that MUST be used if that support is needed 🔥 It also defines a mapping of IPv6 addresses within the OSI address format, in case you need that too.
Table of Contents 🧚
1. General recommendation on NSAP addressing plans..............2
2. Summary of defined mechanisms................................4
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC...4
3.1 Routing restricted NSAPAs...................................5
4. Truncated NSAPA used as an IPv6 address......................6
4.1 Routing truncated NSAPAs....................................8
5. Carriage of full NSAPAs in IPv6 destination option...........9
6. IPv6 addresses inside an NSAPA..............................10
7. Security Considerations.....................................11
Acknowledgements...............................................11
References.....................................................12
Annex A: Summary of NSAP Allocations...........................13
Annex B: Additional Rationale..................................14
Authors' Addresses.............................................161. General recommendation on NSAP addressing plans 💖
this one's for network implementors who already planned or deployed an OSI NSAP addressing plan for OSI CLNP [IS8473], following the OSI network layer addressing plan [IS8348] and using ES-IS and IS-IS routing [IS9542, IS10589]. It explains how to adapt that plan for IPv6 [RFC1883] 🦋
Most known CLNP addressing plans use either the Digital Country Code (DCC) or the International Code Designator (ICD) formats from [IS8348]. A famous example is the US Government OSI Profile Version 2 (GOSIP) addressing plan [RFC1629]. The basic NSAP addressing scheme and the current implementations are summarised in Annex A ✨
[IS8348] sets a maximum NSAPA (NSAP address) size of 20 bytes, and some implementors built their address allocation schemes to use that whole 20-byte space 🍓
Other NSAP addressing plans come from the ITU-T for public data services like X.25 and ISDN. Those can also go up to 20 bytes long 🌈
The general recommendation is that implementors SHOULD design native IPv6 addressing plans according to [RFC1884], but do it as a natural re-mapping of their CLNP plans. There's no general recipe for this, but CLNP addresses in DCC or ICD format can usually be split into two parts: the high order part, which belongs to the network service provider, and the low order part, which covers the user's network topology and host computers 👑
For example, in some US GOSIP applications the high order part is the AFI, ICD, DFI, AA and RD fields, which together take up 9 bytes. The low order part is the Area and ID fields, which together take up 8 bytes. The selector byte and the two reserved bytes are not part of the addressing plan. So in that case, the high-order part could be swapped out for the provider part of an IPv6 provider-based addressing plan. An 8-byte prefix is recommended here, and [RFC1884] MUST be followed when planning that replacement. The low order part then gets mapped straight into the low-order half of the IPv6 address space, and user site address plans stay the same 🫶 A 6-byte ID field, exactly as used in US GOSIP and other CLNP plans, is fine to use as the token for IPv6 autoconfiguration [RFC1971] ✨
Similar rules would apply to other CLNP plans like US GOSIP. US GOSIP is just used here as a well-known example 💅
Three warnings need careful thought in every case ⚠️
- The ES-IS/IS-IS model has a routing hierarchy that goes down to the Area level, but not every end system in an Area has to be on the same physical subnet (the same "wire" or "link"). IS routers on different links within one Area swap info about the end systems each of them can reach directly. IPv6 routing, on the other hand, goes all the way down to the subnet level, and all hosts on the same subnet are assumed to be on the same link. So when you map a CLNP addressing plan into IPv6 format without changing the physical topology, you may need to add an extra level of hierarchy to deal with that mismatch. In other words, the Area number cannot blindly be mapped as a subnet number, unless the physical network topology matches that mapping.
- It's highly desirable that subnet addresses can be aggregated for wide area routing, so routing tables stay small. So implementors should make sure the address prefix used for all their subnets is the same, whether a particular subnet uses a pure IPv6 addressing scheme or one derived from a CLNP scheme like the ones above 🌸
- Some hosts have more than one physical network interface. In the ES-IS model, an end system can have more than one NSAP address, and each one identifies the host as a whole. That kind of end system can be referenced by any one of its NSAPs and reached through any one of its physical connections. In the IPv6 model, a host can have multiple IPv6 addresses per interface, but each of its physical interfaces must have its own unique addresses. This restriction must be applied when you map an NSAP addressing plan into an IPv6 addressing plan for such hosts 🧚
This document doesn't deal with migrating the routing protocols used with CLNP (ES-IS or IS-IS) or with moving their network infrastructure over. 🙈
2. Summary of defined mechanisms 🎀
this doc defines four separate mechanisms. None of them are mandatory parts of an IPv6 implementation, since they're ELECTIVE. BUT if you do need one of them, it MUST be implemented exactly as defined here 💜
- Restricted NSAPA mapping into 16-byte IPv6 address
- Truncated NSAPA for routing, full NSAPA in IPv6 option
- Normal IPv6 address, full NSAPA in IPv6 option
- IPv6 address carried as OSI address
To see how the first three mechanisms fit together, here's the deal 🦋
If the first byte of an IPv6 address is hexadecimal 0x02 (binary 00000010), then the remaining 15 bytes SHALL contain a restricted NSAPA, mapped the way Chapter 3 below describes. The word "restricted" is there because this format is currently limited to a subset of the ICD and DCC formats.
If the first byte of an IPv6 address is hexadecimal 0x03 (binary 00000011), then the remaining 15 bytes SHALL contain a truncated NSAPA, as described in Chapter 4 below. EITHER a destination option holding the complete NSAPA in any format (Chapter 5 below), OR an encapsulated CLNP packet, SHALL be present.
For any other IPv6 address format, a destination option containing a complete NSAPA (defined in Chapter 5 below) MAY be present. ✨
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC 🌈
some organizations might decide, for various reasons, not to follow the general recommendation and redesign their addressing plan 🙃 They might want to keep their existing OSI NSAP addressing plan unchanged for IPv6. This is a big deal for routing, though. It means routing between those organizations and the rest of the Internet is unlikely to be optimised. An organization using both native IPv6 addresses and NSAP addresses for IPv6 would probably end up with inefficient internal routing 😭 Even so, to cover this case, this document defines a way to map a subset of the NSAP address space into the IPv6 address space. The mapping is algorithmic and reversible within that subset 🔥
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 |0 0 0 0 0 0 1 0| AFcode| IDI (last 3 digits) |Prefix(octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | Prefix (octets 1 through 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | Area (octets 0 and 1) | ID (octets 0 and 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| ID (octets 2 through 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The AFcode nibble is overloaded, and it's encoded like this 🧩
0000-1001 Implied AFI value is 47 (ICD)
(0-9 decimal) AFcode is first BCD digit of the ICD
IDI is last three BCD digits of the ICD
1010 Implied AFI value is 39 (DCC)
(hex. A) IDI is the three BCD digits of the DCC
1011-1111 Reserved, not to be used.
(hex. B-F)The NSEL octet isn't included, because it's no use for TCP and UDP traffic. If you do need it, use the mechanism described in the next chapter 💅
The longest CLNP routing prefixes known to be in active use today are 5 octets (split into the AA and RD fields in US GOSIP version 2). So the semantics of existing 20-octet NSAPAs can be fully mapped. DECnet/OSI (Registered Trade Mark) address semantics are fully mapped too 👑
Hosts using restricted NSAPAs could be configured with IPv6 auto-configuration [RFC1971], and they could use normal IPv6 neighbour discovery mechanisms [RFC1970] 🌸
Restricted NSAPAs, as long as they can be fully routed using IPv6 routing protocols, may be used in IPv6 routing headers. 💖
3.1 Routing restricted NSAPAs ✨
okay so bestie, remember from Chapter 1 how OSI/GOSIP routing and IPv6 routing don't line up? 😭 Restricted NSAPAs can be routed hierarchically down to the Area level, but inside an Area they have to be flat-routed. Normal IPv6 addresses can be routed hierarchically all the way down to the physical subnet (link) level, and they only need to be flat-routed on the physical subnet itself 🦋
So a packet addressed to a restricted NSAPA can use any normal IPv6 routing protocol only as far as the Area. If the Area has more than one physical subnet reached by more than one router, no IPv6 routing protocol can get the packet to the correct final router. There's no fix for this in the existing IPv6 mechanisms, ngl 💀 Presumably a flooding algorithm, or a suitably adapted ES-IS implementation, could solve it.
Without a routing protocol like that, you've got two options: either the Area number has to be hierarchically structured to match the physical subnets, or each Area has to be limited to one physical subnet ✨
IPv6 networks also need routes to aggregate so the routing tables stay small 🌸 If a subscriber uses both normal IPv6 addresses [RFC1884] and restricted NSAPAs, those two types of address will absolutely not aggregate with each other, since they differ from the second most significant bit onwards. So using both types could come with a real operational penalty with the routing tech we currently have 😬
4. Truncated NSAPA used as an IPv6 address 🎀
An NSAP address carries routing information (like the Routing Domain and area/subnet identifiers) in the form of the Area Address (as defined in [IS10589]). This routing info is usually a good fit for a 16 byte IPv6 address, and it can be represented that way using the following format:
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 |0 0 0 0 0 0 1 1| High order octets of full NSAP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | NSAP address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | NSAP address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| NSAP address truncated ... zero pads if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If it's appropriate, a truncated NSAPA used as a destination IPv6 address may be interpreted as an IPv6 anycast address 💅 An anycast address can identify an IPv6 node, or potentially even an OSI End System or Intermediate System. For example, it might be set up to identify the endpoints of a CLNP tunnel, or a particular OSI capable system on a particular subnet 🧚
If a truncated NSAPA is used as a source address, it must be interpreted as a unicast address, so it has to be uniquely assigned within the IPv6 address space 🔒
Whenever a truncated NSAPA is used as the source or destination IPv6 address (or both), EITHER an NSAPA destination option OR an encapsulated CLNP packet MUST be present. The destination system is on the hook for picking the right move for each IPv6 packet it receives (forward, decapsulate, or discard, for example) and, where needed, sending an appropriate ICMP error message back to the originating host 💀
If the truncated NSAPA identifies a router and an NSAPA destination option is present, then that router is responsible for forwarding the complete IPv6 packet to the right host, based on the Destination NSAP field in the NSAPA option 🫶
That forwarding process may be based on static routing information (a manual mapping of NSAPs to IPv6 unicast addresses), or it may be gathered automatically in a way that's analogous to the ES-IS mechanism, perhaps using extensions to the Neighbor Discovery protocol [RFC1970] 🌈 The details of such a mechanism are beyond the scope of this document.
This document doesn't restrict which NSAP address formats can be used in truncated NSAPAs. That said, it's pretty obvious that binary ICD or DCC formats will be way easier to fit into an IPv6 routing infrastructure than the other formats defined in [IS8348] 🍓
It's not expected that IPv6 autoconfiguration [RFC1971] and discovery [RFC1970] will work unchanged for truncated NSAPAs 🙈
Truncated NSAPAs aren't meaningful within IPv6 routing headers, and there's no way to include full NSAPAs in routing headers either 🌸
If a packet whose source address is a truncated NSAPA causes an ICMP message to be returned for whatever reason, that ICMP message may be discarded rather than being returned to the true source of the packet 🦋
4.1 Routing truncated NSAPAs
This is a grey area 🌫️ If the truncated NSAPA keeps a hierarchical structure, it can be routed like a restricted NSAPA, with the same problem around the mismatch between Areas and subnets. If possible, in the case of a GOSIP-like NSAPA, it should be truncated right after the Area number. In that case the routing considerations will be similar to those for restricted NSAPAs, except that final delivery of the packet depends on the last IPv6 router being able to interpret the NSAPA destination option (or an encapsulated CLNP packet) ✨
In the general case, nothing can be said, since the NSAPA could have almost any format and might have very little hierarchical content after truncation. There may be lots of cases where truncated NSAPAs can't be routed across large regions of the IPv6 network 😭
The situation for route aggregation is similar to what's described in Section 3.1 as long as the truncated NSAPAs have ICD or DCC format. However, if arbitrary NSAPAs are used, nothing can be predicted about route aggregation, and we have to assume it will be poor 💀
5. Carriage of full NSAPAs in IPv6 destination option 👑
When a truncated NSAPA is used as an IPv6 address for something other than a CLNP tunnel, the full NSAPA must be carried in a destination option. Any format defined in [IS8348] is allowed 🧚
The NSAPA destination option is illustrated below. It has no alignment requirement 🎀
The option type code is 11-0-00011 = 195 decimal 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 1 1| Opt Data Len |Source NSAP Len| Dest. NSAP Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The length fields are each one octet long and are expressed in octets 📏 The destination node should check that the length fields are consistent (Option Data Length = Source NSAP Length + Dest. NSAP Length +2). If they're inconsistent, the destination node shall discard the packet and send an ICMP Parameter Problem, Code 2, message to the packet's source address, pointing to the Option Data Length field 😤
The boundary between the source NSAP and the destination NSAP is simply aligned on an octet boundary. With standard 20 octet NSAPs, the total option length is 44 bytes and the Option Data Length is 42 🍓
The NSAP encodings follow [IS8348] exactly 💜
If this option is used, both end systems concerned SHOULD use NSAP addresses. In the exceptional case that only one of the end systems uses NSAP addresses, the NSAP Length field of the other SHALL be set to zero in the NSAP destination option 🫶
This destination option is used in two cases. Firstly, an IPv6 source node using normal IPv6 addresses (unicast or anycast) MAY supply an NSAP destination option header for interpretation by the IPv6 destination node ✨ Secondly, an IPv6 node MAY use a truncated NSAP address in place of a normal IPv6 address 🦋
IPv6 nodes are not required to implement this option, except for nodes using truncated NSAPAs other than for CLNP tunnels 🌈
6. IPv6 addresses inside an NSAPA ✨
okay so, if you ever need to stuff an IPv6 address inside a 20-octet NSAP address, for whatever reason 💅, then the following format MUST be used. no other format for this, bestie 🫶
one specific reason you'd do this is to show an IP address inside the ATM Forum address format 🦋. another is letting CLNP packets that are carrying IPv6 packets get routed across a CLNP network using the IPv6 address architecture. the way it works is that a few of the leading bytes of the IPv6 address could act as a CLNP routing prefix 🌸
The first three octets are an IDP in binary format 🎀. They use an AFI code that is still being allocated to the IANA. The AFI value that's been provisionally allocated is 35, but getting that official needs a formal change to [IS8348]. The encoding is the same as for AFI value 47 [IS8348]. The third octet of the IDP is called the ICP (Internet Code Point), and its value must be zero. Every other value is reserved for the IANA to allocate 🧚
So an AFI value of 35 with an ICP value of zero means "this NSAPA embeds a 16 byte IPv6 address" ✨
The last octet is a selector. To stay compatible with both NSAP format and IPv6 addressing, this octet must be present, but it means nothing for IPv6 🙈 Its default value is zero.
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 = 35 | ICP = 0000 | IPv6 (byte 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv6 (bytes 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | IPv6 (bytes 5-8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| IPv6 (bytes 9-12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| IPv6 (bytes 13-15) |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+In theory this format would let you do recursive address embedding 🌀
BUT, and this is a big but 😭, it's considered dangerous because it could cause routing table anomalies or loops (see [RFC1326]). So an embedded IPv6 address MUST NOT have the prefixes 0x02 or 0x03, and an NSAPA with the IANA AFI code MUST NOT be embedded in an IPv6 header 🚫
To turn an NSAPA with the IANA AFI code and ICP set to zero into an IPv6 address, you strip off the first three octets and the twentieth octet 💜 Every other NSAPA format gets handled according to the earlier chapters of this document.
7. Security Considerations 🔐
Security isn't specifically covered in this document, but it's compatible with the IPv6 security mechanisms in [RFC1825] 🛡️ fr fr, go read that one if you're worried.
Acknowledgements
The authors want to give a huge thank you to Ross Callon, Richard Collella, Steve Deering, Dirk Fieldhouse, Joel Halpern, Denise Heagerty, Cyndi Jung, Yakov Rekhter, and the members of the former TUBA and current IPNG working groups of the IETF 🌈 for their suggestions and comments. The support of Scott Bradner and Allison Mankin of the IESG was essential 👑
Herb Bertine, Alan Chambers, Dave Marlow, and Jack Wheeler were all super active in getting the AFI allocation sorted with ISO/IEC JTC1/SC6 🙌
References
[IS8473] Data communications protocol for providing the connectionless-mode network service, ISO/IEC 8473, 1988.
[IS8348] Annex A, Network Layer Addressing, and Annex B, Rationale for the material in Annex A, of ISO/IEC 8348, 1993 (identical to CCITT Recommendation X.213, 1992).
[IS10589] Intermediate system to intermediate system intra-domain-routeing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473), ISO 10589, 1992.
[IS9542] End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473), ISO 9542, 1988.
[RFC1629] Colella, R., Callon, R., Gardner, E., and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994.
[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC 1326, May 1992.
[RFC1883] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1884] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
[RFC1971] Thompson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC1971, August 1996.
[RFC1970] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC1970, August 1996.
[RFC1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
Annex A: Summary of NSAP Allocations 🗂️
-----IDP------
-----------------------------------------------------
| AFI | IDI | DOMAIN SPECIFIC PART |
-----------------------------------------------------
--------------------20 bytes max---------------------The Initial Domain Part (IDP) is split into the Authority and Format Identifier (AFI), followed by the Initial Domain Identifier (IDI) 💖 That whole combo is then followed by the Domain Specific Part, and what goes in that part is up to each domain.
Here's a summary of the current allocations:
ISO DCC Scheme
AFI = decimal 38 or binary 39 = ISO Data Country Code Scheme. IDI = 3 decimal or binary digits specifying the country. ISO allocates the country codes. The DSP is administered by the standards authority for each country. In the UK, the British Standards Institution has delegated administration to the Federation of Electronics Industries - FEI 🇬🇧
The UK DSP is split into a single digit UK Format Indicator (UKFI), which says whether it's a large, medium or small organisation (kinda like IP addressing 👀), and a UK Domain Identifier (UKDI). Using binary coded decimal examples only (there are binary equivalents):
UKFI = 0 is reserved UKFI = 1, UKDI = nnn, UK Domain Specific Part = 31 digits. UKFI = 2, UKDI = nnnnn, UKDSP = 29 digits max. UKFI = 3, UKDI = nnnnnnnn, UKDSP = 26 digits max. UKFI = 4 to 9 reserved
The UK Government has been allocated a UKDI in the UKFI = 1 (large organisation) format, and it has specified the breakdown of the Government Domain Specific Part: sub domain addresses, followed by a station ID (which could be a MAC address) and a selector (which could be a TSAP selection) 🏛️
ITU-T X.121
AFI = decimal 36 or 52, binary 37 or 53 indicates that the IDI is a 14 digit max X.121 International Numbering Plan address (prefix, 3 digit Data Country Code, dial up data network number). The full X.121 address shows who controls the formatting of the DSP 📞
ITU-T F.69
AFI = 40,54 or binary 41,55 indicates that the IDI is a telex number up to 8 digits long 📠
ITU-T E.163
AFI = 42,56 or binary 43,57 indicates that the IDI is a normal telephone number up to 12 digits long ☎️
ITU-T E.164
AFI = 44,58 or binary 45,59 indicates that the IDI is an ISDN number up to 15 digits long 📱
ISO 6523-ICD
AFI = 46 or binary 47 indicates that the IDI is an International Code Designator allocated according to ISO 6523. You have to be a global organisation to get one of these 🌍 The organisation the ISO 6523 designator is issued to specifies the DSP allocation.
Annex B: Additional Rationale 🧠
This annex is here to give extra rationale, motivation and justification for supporting NSAPAs in an IPv6 network 🦋
There are several models for OSI-IPv6 convergence, and address mapping is only one of them. The other models are:
- Dual stack coexistence, in which a CLNP network and an IPv6 network exist side by side indefinitely using multiprotocol routers.
- CLNP tunnels over IPv6.
- OSI transport over IPv6.
- OSI transport over UDP.
- OSI transport over TCP (compare RFC 1006).
The present model is more fundamental, because it tries to unify and reconcile the OSI and IPv6 addressing and routing schemes, and to replace CLNP with IPv6 at the network level 🔥 The reason for this choice is to preserve the investment in NSAPA allocation schemes, and to open the door for peer-to-peer routing models between IPv6 and bearer services (such as ATM) that use NSAPA addressing. It should be noted that such peer-to-peer models are contentious at the time of writing, but either way, a consistent address mapping is preferable to multiple mappings 🙃
Besides keeping an existing addressing plan, certain other uses of restricted NSAPAs could be imagined. They could be used as an intermediate addressing plan for a network moving from CLNP to IPv6. They could be used in a header translation scheme for dynamic translation between IPv6 and CLNP. They could also let CLNP and IPv6 traffic share the same routing architecture inside an organization ("Ships in the Day") 🚢
It should be noted that using full NSAPA addresses in end systems impacts a lot of things. The most obvious are the API and DNS 😵💫 If applications are going to work normally, everything that has to be modified to cope with IPv6 addresses has to be modified further for full NSAPAs. The mechanisms defined in this document are only a small part of the whole picture.
A destination option was chosen to carry full NSAPAs, instead of a dedicated extension header 💭 With an extension header, every IPv6 node would have needed to understand its syntax just to ignore it. With a destination option, intermediate nodes can ignore it without knowing anything about its syntax. So only the nodes that care about NSAPAs need to know anything about them.
So we end up with two classes of IPv6 nodes:
- Nodes knowing only about 16 byte addresses (including restricted NSAPAs, which behave largely like any other IPv6 addresses).
- Nodes also knowing about 20 byte NSAPAs, either as an extension of the IPv6 address space or as the CLNP address space. In either case, regions of the network containing such nodes are connected to each other by unicast or anycast tunnels through the 16 byte address space. Routing, system configuration, and neighbour discovery in the NSAPA regions are outside the scope of the normal IPv6 mechanisms 🌈
Authors' Addresses ✨
okay so this is where the authors tell you how to reach them 💌 bestie, these are the real people who wrote this RFC, so here are their contact deets, the whole thing, no cuts 🫶
Jim Bound
Member Technical Staff Phone: (603) 881-0400
Network Operating Systems Fax: (603) 881-0120
Digital Equipment Corporation Email: bound@zk3.dec.com
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Brian E. Carpenter
Group Leader, Communications Systems Phone: +41 22 767-4967
Computing and Networks Division Fax: +41 22 767-7155
CERN Telex: 419000 cer ch
European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch
1211 Geneva 23, Switzerland
Dan Harrington Phone: (508) 486-7643
Digital Equipment Corp.
550 King Street (LKG2-2/Q9) Email: dan@netrix.lkg.dec.com
Littleton, MA 01460
Jack Houldsworth Phone- ICL: +44 438 786112
ICL Network Systems Home: +44 438 352997
Cavendish Road Fax: +44 438 786150
Stevenage Email: j.houldsworth@ste0906.wins.icl.co.uk
Herts
UK SG1 4BQ
Alan Lloyd Phone: +61 3 727 9222
Datacraft Technologies Fax: +61 3 727 1557
252 Maroondah Highway Email: alan.lloyd@datacraft.com.au
Mooroolbark 3138
Victoria Australia
X.400- G=alan;S=lloyd;O=dcthq;P=datacraft;A=telememo;C=auheads up bestie: the text I was given for this part only had the author addresses in it. The Security Considerations, Acknowledgements, References and Annexes weren't in there, so I haven't written them. Send those over and I'll slay them too 💅🎀
📦 where this page comes from
- ietf: rfc1888 1996-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms