As per Relevance of the word truncated, we have this rfc below:
Network Working Group J.
Request for Comments: 1888 Digital Equipment
Category: Experimental B.
D.
Digital Equipment
J.
ICL Network
A.
Datacraft
August 1996
OSI NSAPs and IPv
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This document recommends that network implementors who have
or deployed an OSI NSAP addressing plan, and who wish to deploy
transition to IPv6, should redesign a native IPv6 addressing plan
meet their needs. However, it also defines a set of mechanisms
the support of OSI NSAP addressing in an IPv6 network.
mechanisms are the ones that MUST be used if such support
required. This document also defines a mapping of IPv6
within the OSI address format, should this be required
Table of
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.............................................16
Bound, et. al. Experimental [Page 1]
RFC 1888 OSI NSAPs and IPv6 August 1996
1. General recommendation on NSAP addressing
This recommendation is addressed to network implementors who
already planned or deployed an OSI NSAP addressing plan for the
of OSI CLNP [IS8473] according to the OSI network layer
plan [IS8348] using ES-IS and IS-IS routing [IS9542, IS10589].
recommends how they should adapt their addressing plan for use
IPv6 [RFC1883].
The majority of known CLNP addressing plans use either the
Country Code (DCC) or the International Code Designator (ICD)
defined in [IS8348]. A particular example of this is the
Government OSI Profile Version 2 (GOSIP) addressing plan [RFC1629].
The basic NSAP addressing scheme and current implementations
summarised in Annex A
[IS8348] specifies a maximum NSAPA (NSAP address) size of 20
and some network implementors have designed address
schemes which make use of this 20 byte address space
Other NSAP addressing plans have been specified by the ITU-T
public data services, such as X.25 and ISDN, and these can also
addresses up to 20 bytes in length
The general recommendation is that implementors SHOULD design
IPv6 addressing plans according to [RFC1884], but doing so as
natural re-mapping of their CLNP addressing plans. While it
impossible to give a general recipe for this, CLNP addresses in
or ICD format can normally be split into two parts: the high
part relating to the network service provider and the low order
relating to the user network topology and host computers
For example, in some applications of US GOSIP the high order part
the AFI, ICD, DFI, AA and RD fields, together occupying 9 bytes.
low order part is the Area and ID fields, together occupying 8 bytes
(The selector byte and the two reserved bytes are not part of
addressing plan.) Thus, in such a case, the high-order part could
replaced by the provider part of an IPv6 provider-based
plan. An 8-byte prefix is recommended for this case and [RFC1884]
MUST be followed in planning such a replacement. The low order
would then be mapped directly in the low-order half of the IPv
address space, and user site address plans are unchanged. A 6-
ID field, exactly as used in US GOSIP and other CLNP
plans, will be acceptable as the token for IPv6
[RFC1971].
Analogous rules would be applied for other CLNP addressing
similar to US GOSIP, which is used only as a well known example
Bound, et. al. Experimental [Page 2]
RFC 1888 OSI NSAPs and IPv6 August 1996
Three warnings must be carefully considered in every case
1. The ES-IS/IS-IS model employs a routing hierarchy down to the
level, but not all end systems in an Area need to be in the
physical subnet (on the same "wire" or "link"). IS routers
different links within a given Area exchange information about
end systems they can each reach directly. In contrast, the IPv
routing model extends down to the subnet level and all hosts in
same subnet are assumed to be on the same link. In mapping a
addressing plan into IPv6 format, without changing the
topology, it may be necessary to add an extra level of hierarchy
cope with this mismatch. In other words, the Area number
blindly be mapped as a subnet number, unless the physical
topology corresponds to this mapping
2. It is highly desirable that subnet addresses can be aggregated
wide area routing purposes, to minimise the size of routing tables
Thus network implementors should ensure that the address prefix
for all their subnets is the same, regardless of whether a
subnet is using a pure IPv6 addressing scheme or one derived from
CLNP scheme as above
3. Some hosts have more than one physical network interface. In
ES-IS model, an end system may have more than one NSAP address,
of which identifies the host as a whole. Such an end system
more than one physical interface may be referenced by any one of
NSAPs, and reached via any one of the physical connections. In
IPv6 model, a host may have multiple IPv6 addresses per interface
but each of its physical interfaces must have its own
addresses. This restriction must be applied when mapping an
addressing plan into an IPv6 addressing plan for such hosts
This document does not address the issues associated with
the routing protocols used with CLNP (ES-IS or IS-IS) and
of their network infrastructure
Bound, et. al. Experimental [Page 3]
RFC 1888 OSI NSAPs and IPv6 August 1996
2. Summary of defined
This document defines four distinct mechanisms. All of these
ELECTIVE mechanisms, i.e. they are not mandatory parts of an IPv
implementation, but if such mechanisms are needed they MUST
implemented as defined in this document
1. Restricted NSAPA mapping into 16-byte IPv6
2. Truncated NSAPA for routing, full NSAPA in IPv6
3. Normal IPv6 address, full NSAPA in IPv6
4. IPv6 address carried as OSI
To clarify the relationship between the first three mechanisms,
that
If the first byte of an IPv6 address is hexadecimal 0x02 (
00000010), then the remaining 15 bytes SHALL contain a
NSAPA mapped as in Chapter 3 below. The term "restricted" is
to indicate that this format is currently restricted to a
of the ICD and DCC formats
If the first byte of an IPv6 address is hexadecimal 0x03 (
00000011), then the remaining 15 bytes SHALL contain a
NSAPA as described in Chapter 4 below. EITHER a destination
containing the complete NSAPA of any format, as described
Chapter 5 below, OR an encapsulated CLNP packet, SHALL be present
With any other format of IPv6 address, a destination
containing a complete NSAPA, as defined in Chapter 5 below, MAY
present
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and
Some organizations may decide for various reasons not to follow
above general recommendation to redesign their addressing plan.
may wish to use their existing OSI NSAP addressing plan unchanged
IPv6. It should be noted that such a decision has
implications for routing, since it means that routing between
organizations and the rest of the Internet is unlikely to
optimised. An organization using both native IPv6 addresses and
addresses for IPv6 would be likely to have inefficient
routing. Nevertheless, to cover this eventuality, the
document defines a way to map a subset of the NSAP address space
the IPv6 address space. The mapping is algorithmic and
within this subset of the NSAP address space
Bound, et. al. Experimental [Page 4]
RFC 1888 OSI NSAPs and IPv6 August 1996
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 encoded as
0000-1001 Implied AFI value is 47 (ICD
(0-9 decimal) AFcode is first BCD digit of the
IDI is last three BCD digits of the
1010 Implied AFI value is 39 (DCC
(hex. A) IDI is the three BCD digits of the
1011-1111 Reserved, not to be used
(hex. B-F
The NSEL octet is not included. It is of no use for TCP and
traffic. In any case where it is needed, the mechanism described
the next chapter should be used
The longest CLNP routing prefixes known to be in active use today
5 octets (subdivided into AA and RD fields in US GOSIP version 2).
Thus the semantics of existing 20-octet NSAPAs can be fully mapped
DECnet/OSI (Registered Trade Mark) address semantics are also
mapped
It is expected that hosts using restricted NSAPAs could be
using IPv6 auto-configuration [RFC1971], and that they could
normal IPv6 neighbour discovery mechanisms [RFC1970].
Restricted NSAPAs, assuming that they can be fully routed using IPv
routing protocols, may be used in IPv6 routing headers
3.1 Routing restricted
As mentioned in Chapter 1, there is a mismatch between the OSI
GOSIP routing model and the IPv6 routing model. Restricted NSAPAs
be routed hierarchically down to the Area level but must be flat
routed within an Area. Normal IPv6 addresses can be
Bound, et. al. Experimental [Page 5]
RFC 1888 OSI NSAPs and IPv6 August 1996
hierarchically down to physical subnet (link) level and only have
be flat-routed on the physical subnet
Thus, packets whose destination address is a restricted NSAPA can
routed using any normal IPv6 routing protocol only as far as
Area. If the Area contains more than one physical subnet reached
more than one router, no IPv6 routing protocol can route the
to the correct final router. There is no solution to this
within the existing IPv6 mechanisms. Presumably a
algorithm, or a suitably adapted implementation of ES-IS, could
this problem
In the absence of such a routing protocol, either the Area
must be hierarchically structured to correspond to physical subnets
or each Area must be limited to one physical subnet
It is necessary in an IPv6 network that routes may be aggregated
minimise the size of routing tables. If a subscriber is using
normal IPv6 addresses [RFC1884] and restricted NSAPAs, these
types of address will certainly not aggregate with each other,
they differ from the second most significant bit onwards. This
that there may be a significant operational penalty for using
types of address with currently known routing technology
4. Truncated NSAPA used as an IPv6
An NSAP address contains routing information (e.g. Routing Domain
area/subnet identifiers) in the form of the Area Address (as
in [IS10589]). The format and length of this routing information
typically compatible with a 16 byte IPv6 address, and may
represented as such 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 appropriate, when used as a destination IPv6 address,
truncated NSAPA may be interpreted as an IPv6 anycast address.
anycast address may be used to identify either an IPv6 node,
potentially even an OSI End System or Intermediate System.
Bound, et. al. Experimental [Page 6]
RFC 1888 OSI NSAPs and IPv6 August 1996
example, it might be configured to identify the endpoints of a
tunnel, or it might identify a particular OSI capable system in
particular subnet
If a truncated NSAPA is used as a source address, it must
interpreted as a unicast address and must therefore be
assigned within the IPv6 address space
If a truncated NSAPA is used as either the source or destination IPv
address (or both), EITHER an NSAPA destination option OR
encapsulated CLNP packet MUST be present. It is the responsibility
the destination system to take the appropriate action for each IPv
packet received (e.g. forward, decapsulate, discard) and,
necessary, return to the originating host an appropriate ICMP
message
If the truncated NSAPA is used to identify a router, and an
destination option is present, then it is the responsibility of
router to forward the complete IPv6 packet to the appropriate
based upon the Destination NSAP field in the NSAPA option.
forwarding process may be based upon static routing information (i.e
a manual mapping of NSAPs to IPv6 unicast addresses), or it may
gathered in an automated fashion analogous to the ES-IS mechanism
perhaps using extensions to the Neighbor Discovery
[RFC1970]. The details of such a mechanism are beyond the scope
this document
This document does not restrict the formats of NSAP address that
be used in truncated NSAPAs, but it is apparent that binary ICD
DCC formats will be much easier to accomodate in an IPv6
infrastructure than the other formats defined in [IS8348].
It is not expected that IPv6 autoconfiguration [RFC1971]
discovery [RFC1970] will work unchanged for truncated NSAPAs
Truncated NSAPAs are not meaningful within IPv6 routing headers,
there is no way to include full NSAPAs in routing headers
If a packet whose source address is a truncated NSAPA causes an
message to be returned for whatever reason, this ICMP message may
discarded rather than being returned to the true source of
packet
Bound, et. al. Experimental [Page 7]
RFC 1888 OSI NSAPs and IPv6 August 1996
4.1 Routing truncated
This is a grey area. If the truncated NSAPA retains a
structure, it can be routed like a restricted NSAPA, subject to
same problem concerning the mismatch between Areas and subnets.
possible, in the case of a GOSIP-like NSAPA, it should be
immediately after the Area number. In this case the
considerations will be similar to those for restricted NSAPAs,
that final delivery of the packet will depend on the last IPv6
being able to interpret the NSAPA destination option (or
encapsulated CLNP packet).
In the general case, nothing can be said since the NSAPA could
almost any format and might have very little hierarchical
after truncation. There may be many cases in which truncated
cannot be routed across large regions of the IPv6 network
The situation for route aggregation is similar to that described
Section 3.1 as long as the truncated NSAPAs have ICD or DCC format
However, if arbitrary NSAPAs are used nothing can be predicted
route aggregation and we must assume that it will be poor
Bound, et. al. Experimental [Page 8]
RFC 1888 OSI NSAPs and IPv6 August 1996
5. Carriage of full NSAPAs in IPv6 destination
In the case of a truncated NSAPA used as an IPv6 address other
for a CLNP tunnel, the full NSAPA must be carried in a
option. Any format defined in [IS8348] is allowed
The NSAPA destination option is illustrated below. It has
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
octets. The destination node should check the consistency of
length fields (Option Data Length = Source NSAP Length + Dest.
Length +2). In case of inconsistency the destination node
discard the packet and send an ICMP Parameter Problem, Code 2,
message to the packet's source address, pointing to the Option
Length field
The boundary between the source NSAP and the destination NSAP
simply aligned on an octet boundary. With standard 20 octet NSAPs
total option length is 44 bytes and the Option Data Length is 42.
Bound, et. al. Experimental [Page 9]
RFC 1888 OSI NSAPs and IPv6 August 1996
The NSAP encodings follow [IS8348] exactly
If this option is used, both end systems concerned SHOULD use
addresses. In the exceptional case that only one of the end
uses NSAP addresses, the NSAP Length field of the other SHALL be
to zero in the NSAP destination option
This destination option is used in two cases. Firstly, an IPv6
node using normal IPv6 addresses (unicast address or anycast address
MAY supply an NSAP destination option header for interpretation
the IPv6 destination node. Secondly, an IPv6 node MAY use a
NSAP address in place of a normal IPv6 address
IPv6 nodes are not required to implement this option, except
nodes using truncated NSAPAs other than for CLNP tunnels
6. IPv6 addresses inside an
If it is required, for whatever reason, to embed an IPv6
inside a 20-octet NSAP address, then the following format MUST
used
A specific possible use of this embedding is to express an IP
within the ATM Forum address format. Another possible use would
to allow CLNP packets that encapsulate IPv6 packets to be routed in
CLNP network using the IPv6 address architecture. Several
bytes of the IPv6 address could be used as a CLNP routing prefix
The first three octets are an IDP in binary format, using the
code in the process of being allocated to the IANA. The AFI
provisionally allocated is 35, but this requires a
modification to [IS8348]. The encoding format is as for AFI value 47
[IS8348]. The third octet of the IDP is known as the ICP (
Code Point) and its value must be zero. All other values are
for allocation by the IANA
Thus an AFI value of 35 with an ICP value of zero means that "
NSAPA embeds a 16 byte IPv6 address".
The last octet is a selector. To maintain compatibility with
NSAP format and IPv6 addressing, this octet must be present, but
has no significance for IPv6. Its default value is zero
Bound, et. al. Experimental [Page 10]
RFC 1888 OSI NSAPs and IPv6 August 1996
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Theoretically this format would allow recursive address embedding
However, this is considered dangerous since it might lead to
table anomalies or to loops (compare [RFC1326]). Thus embedded IPv
address MUST NOT have the prefixes 0x02 or 0x03, and an NSAPA
the IANA AFI code MUST NOT be embedded in an IPv6 header
An NSAPA with the IANA AFI code and ICP set to zero is converted
an IPv6 address by stripping off the first three and the
octets. All other formats of NSAPA are handled according to
previous Chapters of this document
7. Security
Security issues are not specifically addressed in this document,
it is compatible with the IPv6 security mechanisms [RFC1825].
The authors are pleased to acknowledge the suggestions and
of Ross Callon, Richard Collella, Steve Deering, Dirk Fieldhouse
Joel Halpern, Denise Heagerty, Cyndi Jung, Yakov Rekhter, and
of the former TUBA and current IPNG working groups of the IETF.
support of Scott Bradner and Allison Mankin of the IESG
essential
Herb Bertine, Alan Chambers, Dave Marlow, and Jack Wheeler were
active in arranging the AFI allocation by ISO/IEC JTC1/SC6.
Bound, et. al. Experimental [Page 11]
RFC 1888 OSI NSAPs and IPv6 August 1996
[IS8473] Data communications protocol for providing
connectionless-mode network service, ISO/IEC 8473, 1988.
[IS8348] Annex A, Network Layer Addressing, and Annex B,
for the material in Annex A, of ISO/IEC 8348, 1993 (identical
CCITT Recommendation X.213, 1992).
[IS10589] Intermediate system to intermediate system intra-domain
routeing routine information exchange protocol for use
conjunction with the protocol for providing the connectionless-
Network Service (ISO 8473), ISO 10589, 1992.
[IS9542] End system to Intermediate system routeing
protocol for use in conjunction with the Protocol for providing
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,
1994.
[RFC1326] Tsuchiya, P., "Mutual Encapsulation
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
Architecture", RFC 1884, December 1995.
[RFC1971] Thompson, S., and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC1971, August 1996.
[RFC1970] Narten, T., Nordmark, E., and W. Simpson, "
Discovery for IP Version 6 (IPv6)", RFC1970, August 1996.
[RFC1825] Atkinson, R., "Security Architecture for the
Protocol", RFC 1825, August 1995.
Bound, et. al. Experimental [Page 12]
RFC 1888 OSI NSAPs and IPv6 August 1996
Annex A: Summary of NSAP
-----IDP------
-----------------------------------------------------
| AFI | IDI | DOMAIN SPECIFIC PART |
-----------------------------------------------------
--------------------20 bytes max---------------------
The Initial Domain Part (IDP) is split into Authority and
Identifier (AFI) followed by the Initial Domain Identifier (IDI).
This combination is followed by the Domain Specific Part
allocation within that part is domain specific
The following is a summary of current allocations
ISO DCC
AFI = decimal 38 or binary 39 = ISO Data Country Code Scheme. IDI =
3 decimal or binary digits specifying the country. ISO allocate
country codes. The DSP is administered by the standards
for each country. In the UK, the British Standards Institution
delegated administration to the Federation of Electronics
-
The UK DSP is split into a single digit UK Format Indicator (UKFI
which indicates large, medium or small organisation rather like
addressing and a UK Domain Identifier (UKDI). Using binary
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
The UK Government have been allocated a UKDI in the UKFI = 1 (
organisation) format and have specified the breakdown of
Government Domain Specific Part with sub domain addresses followed
a station ID (which could be a MAC address) and a selector (
could be a TSAP selection).
ITU-T X.121
AFI = decimal 36 or 52, binary 37 or 53 indicates that the IDI is
14 digit max X.121 International Numbering Plan address (prefix, 3
digit Data Country Code, dial up data network number). The
X.121 address indicates who controls the formatting of the DSP
Bound, et. al. Experimental [Page 13]
RFC 1888 OSI NSAPs and IPv6 August 1996
ITU-T F.69
AFI = 40,54 or binary 41,55 indicates that the IDI is a telex
up to 8 digits long
ITU-T E.163
AFI = 42,56 or binary 43,57 indicates that the IDI is a
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
up to 15 digits long
ISO 6523-
AFI = 46 or binary 47 indicates that the IDI is an International
Designator allocated according to ISO 6523. You have to be a
organisation to get one of these. The Organisation to which the
6523 designator is issued specifies the DSP allocation
Annex B: Additional
This annex is intended to give additional rationale, motivation
justification for the support of NSAPAs in an IPv6 network
There are several models for OSI-IPv6 convergence, of which
mapping is only one. The other models can be identified
1. Dual stack coexistence, in which a CLNP network and an IPv
network exist side by side indefinitely using
routers
2. CLNP tunnels over IPv6.
3. OSI transport over IPv6.
4. OSI transport over UDP
5. OSI transport over TCP (compare RFC 1006)
The present model is more fundamental, as it attempts to unify
reconcile the OSI and IPv6 addressing and routing schemes,
replace CLNP by IPv6 at the network level. The rationale for
choice is to preserve investment in NSAPA allocation schemes, and
open the door for peer-to-peer routing models between IPv6 and
services (such as ATM) using NSAPA addressing. It should be
Bound, et. al. Experimental [Page 14]
RFC 1888 OSI NSAPs and IPv6 August 1996
that such peer-to-peer models are contentious at the time of writing
but in any case a consistent address mapping is preferable
multiple mappings
In addition to their use to retain an existing addressing plan
certain other uses of restricted NSAPAs could be envisaged.
could be used as an intermediate addressing plan for a network
a transition from CLNP to IPv6. They could be used in a
translation scheme for dynamic translation between IPv6 and CLNP
They could be used to allow CLNP and IPv6 traffic to share the
routing architecture within an organization ("Ships in the Day").
It should be noted that the use of full NSAPA addresses in
systems impacts many things. The most obvious are the API and DNS.
applications are to work normally, everything that has to be
to cope with IPv6 addresses has to be further modified for
NSAPAs. The mechanisms defined in the present document are only
small part of the whole
A destination option was chosen to carry full NSAPAs, in
to a dedicated extension header. In the case of an extension header
all IPv6 nodes would have needed to understand its syntax merely
order to ignore it. In contrast, intermediate nodes can ignore
destination option without any knowledge of its syntax. Thus
nodes interested in NSAPAs need to know anything about them
Thus we end up with two classes of IPv6 nodes
1. Nodes knowing only about 16 byte addresses (including
NSAPAs, which behave largely like any other IPv6 addresses).
2. Nodes also knowing about 20 byte NSAPAs, either as an extension
the IPv6 address space or as the CLNP address space. In either case
regions of the network containing such nodes are connected to
other by unicast or anycast tunnels through the 16 byte
space. Routing, system configuration, and neighbour discovery in
NSAPA regions are outside the scope of the normal IPv6 mechanisms
Bound, et. al. Experimental [Page 15]
RFC 1888 OSI NSAPs and IPv6 August 1996
Authors'
Jim
Member Technical Staff Phone: (603) 881-0400
Network Operating Systems Fax: (603) 881-0120
Digital Equipment Corporation Email: bound@zk3.dec.
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Brian E.
Group Leader, Communications Systems Phone: +41 22 767-4967
Computing and Networks Division Fax: +41 22 767-7155
CERN Telex: 419000 cer
European Laboratory for Particle Physics Email: brian@dxcoms.cern.
1211 Geneva 23,
Dan Harrington Phone: (508) 486-7643
Digital Equipment Corp
550 King Street (LKG2-2/Q9) Email: dan@netrix.lkg.dec.
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 SG1 4
Alan Lloyd Phone: +61 3 727 9222
Datacraft Technologies Fax: +61 3 727 1557
252 Maroondah Highway Email: alan.lloyd@datacraft.com.
Mooroolbark 3138
Victoria
X.400- G=alan;S=lloyd;O=dcthq;P=datacraft;A=telememo;C=
Bound, et. al. Experimental [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
