Internet Draft B. Carpenter
June 1995 (editor)
OSI NSAPs and IPv6
Abstract
draft-carpenter-nsap-ipv6-00.txt
This document recommends that network implementors who have planned or
deployed an OSI NSAP addressing plan, and who wish to deploy or transition
to IPv6, should redesign a native IPv6 addressing plan to meet their
needs. However, it also defines a set of mechanisms for the support
of OSI NSAP addressing in an IPv6 network. These mechanisms are the
ones that MUST be used if such support is required. This document
also defines a mapping of IPv6 addresses within the OSI address
format, should this be required.
DISCUSSION LIST: send mail to majordomo@sunroof.eng.sun.com with
"subscribe nosi" as message body.
OPEN ISSUE(S):
1. There is a serious question whether restricted or truncated NSAPAs
can be routed properly in an IPv6 network using normal IPv6 routing
protocols. See Sections 3.1 and 4.1 for discussion of this point. If
the final answer is negative, the proposed mappings are not viable.
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Expires December 1995 [Page 1]
Table of Contents:
Status of this Memo.............................................1
1. General recommendation on NSAP addressing plans..............3
2. Summary of defined mechanisms................................5
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC...6
3.1 Routing restricted NSAPAs...................................7
4. Truncated NSAPA used as an IPv6 address......................8
4.1 Routing truncated NSAPAs....................................9
5. Carriage of full NSAPAs in IPv6 destination option..........10
6. IPv6 addresses inside an NSAPA..............................11
7. Security condiderations.....................................12
Acknowledgements...............................................12
References.....................................................13
Annex A: Summary of NSAP Allocations...........................14
Annex B: Additional Rationale..................................16
Authors' Addresses.............................................17
Expires December 1995 [Page 2]
1. General recommendation on NSAP addressing plans
This recommendation is addressed to network implementors who have
already planned or deployed an OSI NSAP addressing plan for the usage
of OSI CLNP [IS8473] according to the OSI network layer addressing
plan [IS8348] using ES-IS routing [IS9542]. It recommends how they
should adapt their addressing plan for use with IPv6 [IPv6].
The majority of known CLNP addressing plans use either the Digital
Country Code (DCC) or the International Code Designator (ICD) formats
defined in [IS8348]. A particular example of this is the US
Government OSI Profile Version 2 (GOSIP) addressing plan [RFC1629].
The basic NSAP addressing scheme and current implementations are
summarised in Annex A.
[IS8348] specifies a maximum NSAPA (NSAP address) size of 20 bytes
and some network implementors have designed address allocation
schemes which make use of this 20 byte address space.
Other NSAP addressing plans have been specified by the ITU-T for
public data services, such as X.25 and ISDN, and these can also have
addresses up to 20 bytes in length.
The general recommendation is that implementors SHOULD design native
IPv6 addressing plans according to [Rekhter], but doing so as a
natural re-mapping of their CLNP addressing plans. While it is
impossible to give a general recipe for this, CLNP addresses in DCC
or ICD format can normally be split into two parts: the high order
part relating to the network service provider and the low order part
relating to the user network topology and host computers.
For example, in some applications of US GOSIP the high order part is
the AFI, ICD, DFI, AA and RD fields, together occupying 9 bytes. The
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 the
addressing plan.) Thus, in such a case, the high-order part would be
replaced by the provider part of an IPv6 provider-based addressing
plan. An 8-byte provider prefix is recommended for this case and
[Rekhter] MUST be followed in planning such a replacement. The low
order part would then be mapped directly in the low-order half of the
IPv6 address space, and user site address plans are unchanged. A 6-
byte ID field, exactly as used in US GOSIP and other CLNP addressing
plans, will be acceptable as the token for IPv6 autoconfiguration
[addrconf].
Analogous rules would be applied for other CLNP addressing plans
similar to US GOSIP, which is used only as a well known example.
Three warnings must be carefully considered in every case:
1. The ES-IS model employs a routing hierarchy down to the Area
level, but not all end systems in an Area need to be in the same
physical subnet (on the same "wire" or "link"). ES-IS routers on
different links within a given Area exchange information about the
end systems they can each reach directly. In contrast, the IPv6
routing model extends down to the subnet level and all hosts in the
same subnet are assumed to be on the same link. In mapping a CLNP
addressing plan into IPv6 format, without changing the physical
Expires December 1995 [Page 3]
topology, it may be necessary to add an extra level of hierarchy to
cope with this mismatch. In other words, the Area number cannot
blindly be mapped as a subnet number, unless the physical network
topology corresponds to this mapping.
2. It is highly desirable that subnet addresses can be aggregated for
wide area routing purposes, to minimise the size of routing tables.
Thus network implementors should ensure that the provider prefix used
for all their subnets is the same, regardless of whether a particular
subnet is using a pure IPv6 addressing scheme or one derived from a
CLNP scheme as above.
3. Some hosts have more than one physical network interface. In the
ES-IS model, such an end system may have multiple NSAP addresses and
may be reached through any of its physical interfaces using any of
these addresses. In the IPv6 model, a host may have multiple IPv6
addresses per interface, but each of its physical interfaces must
have its own unique addresses. This restriction must be applied when
mapping an NSAP addressing plan into an IPv6 addressing plan for such
hosts.
Expires December 1995 [Page 4]
2. Summary of defined mechanisms
This document defines four distinct mechanisms. All of these are
ELECTIVE mechanisms, i.e. they are not mandatory parts of an IPv6
implementation, but if such mechanisms are needed they MUST be
implemented as defined in this document.
1. Restricted NSAPA mapping into 16-byte IPv6 address
2. Truncated NSAPA for routing, full NSAPA in IPv6 option
3. Normal IPv6 address, full NSAPA in IPv6 option
4. IPv6 address carried as OSI address
To clarify the relationship between the first three mechanisms, note
that:
If the first byte of an IPv6 address is hexadecimal 0x02
(binary 00000010), then the remaining 15 bytes SHALL contain
a restricted NSAPA mapped as in Chapter 3 below.
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 containing the complete NSAPA, as in Chapter 5
below, OR an encapsulated CLNP packet [tunnel], SHALL be present.
With any other format of IPv6 address, a destination option
containing a complete NSAPA, as defined in Chapter 5 below,
MAY be present.
Expires December 1995 [Page 5]
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC
Some organizations may decide for various reasons not to follow the
above general recommendation to redesign their addressing plan. They
may wish to use their existing OSI NSAP addressing plan unchanged for
IPv6. It should be noted that such a decision has serious
implications for routing, since it means that routing between such
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 be likely to have inefficient internal
routing. Nevertheless, to cover this eventuality, the present
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 this subset of the NSAP address space.
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 encoded as follows
0000-1001 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 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 is not included. It is of no use for TCP and UDP
traffic. In any case where it is needed, the mechanism described in
the next chapter should be used.
The longest CLNP routing prefixes known to be in active use today are
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 fully
mapped.
It is expected that hosts using restricted NSAPAs could be configured
using IPv6 auto-configuration [addrconf], and that they could use
normal IPv6 neighbour discovery mechanisms [discovery].
Restricted NSAPAs, assuming that they can be fully routed using IPv6
routing protocols, may be used in IPv6 source routes.
Expires December 1995 [Page 6]
3.1 Routing restricted NSAPAs
As mentioned in Chapter 1, there is a mismatch between the OSI or
GOSIP routing model and the IPv6 routing model. Restricted NSAPAs can
be routed hierarchically down to the Area level but must be flat-
routed within an Area. Normal IPv6 addresses can be routed
hierarchically down to physical subnet (link) level and only have to
be flat-routed on the physical subnet.
Thus, packets whose destination address is a restricted NSAPA can be
routed using any normal IPv6 routing protocol only as far as the
Area. If the Area contains more than one physical subnet reached by
more than one router, no IPv6 routing protocol can route the packet
to the correct final router. There is no solution to this problem
within the existing IPv6 mechanisms. Presumably a flooding
algorithm, or a suitably adapted implementation of ES-IS [IS9542],
could solve this problem.
In the absence of such a routing protocol, either the Area number
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 to
minimise the size of routing tables. If a subscriber is using both
provider-based IPv6 addresses [Rekhter] and restricted NSAPAs, these
two types of address will certainly not aggregate with each other,
since they differ from the second most significant bit onwards. This
means that there may be a significant operational penalty for using
both types of address with currently known routing technology.
Expires December 1995 [Page 7]
4. Truncated NSAPA used as an IPv6 address
An NSAP address contains routing information (e.g. Routing Domain and
area/subnet identifiers) in the form of the Area Address (as defined
in [IS10589]). The format and length of this routing information are
typically compatible with a 16 byte IPV6 address, and may be
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, the
truncated NSAPA may be interpreted as an IPv6 anycast address. An
anycast address may be used to identify either an IPv6 node, or
potentially even an OSI End System or Intermediate System. For
example, it might be configured to identify the endpoints of a CLNP
tunnel [tunnel], or it might identify a particular OSI capable system
in a particular subnet.
If a truncated NSAPA is used as a source address, it must be
interpreted as a unicast address and must therefore be uniquely
assigned within the IPv6 address space.
If a truncated NSAPA is used as either the source or destination IPv6
address (or both), EITHER an NSAPA destination option OR an
encapsulated CLNP packet [tunnel] MUST be present. It is the
responsibility of the destination system to take the appropriate
action for each IPV6 packet received (e.g. forward, decapsulate,
discard) and, if necessary, return to the originating host an
appropriate ICMP error message.
If the truncated NSAPA is used to identify a router, and an NSAPA
destination option is present, then it is the responsibility of that
router to forward the complete IPv6 packet to the appropriate host
based upon the Destination NSAP field in the NSAPA option. This
forwarding process may be based upon static routing information (i.e.
a manual mapping of NSAPs to IPv6 unicast addresses), or it may be
gathered in an automated fashion analogous to the ES-IS mechanism,
perhaps using extensions to the Neighbor Discovery protocol
[discovery]. The details of such a mechanism are beyond the scope of
this document.
This document does not restrict the formats of NSAP address that may
be used in truncated NSAPAs, but it is apparent that binary ICD or
DCC formats will be much easier to accomodate in an IPv6 routing
infrastructure than the other formats defined in [IS8348].
It is not expected that IPv6 autoconfiguration [addrconf] and
discovery [discovery] will work unchanged for truncated NSAPAs.
Expires December 1995 [Page 8]
Truncated NSAPAs are not meaningful within IPv6 source routes, and
there is no way to include full NSAPAs in source routes.
4.1 Routing truncated NSAPAs
This is a grey area. If the truncated NSAPA retains a hierarchical
structure, it can be routed like a restricted NSAPA, subject to the
same problem concerning the mismatch between Areas and subnets. If
possible, in the case of a GOSIP-like NSAPA, it should be truncated
immediately after the Area number. In this case the routing
considerations will be similar to those for restricted NSAPAs, except
that final delivery of the packet will depend 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 many cases in which truncated NSAPAs
cannot be routed across large regions of the IPv6 network.
The situation for route aggregation is similar to that 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 must assume that it will be poor.
Expires December 1995 [Page 9]
5. Carriage of full NSAPAs in IPv6 destination option
In the case of a truncated NSAPA used as an IPv6 address other than
for 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 for the case where
it is the first option in the destination option extension header,
although this is not a requirement. The illustration is for the case
of 20 octet NSAPAs, although this is not a requirement. The
alignment requirement is 2n (any 2-octet alignment).
The option type code abcde is TBD.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |1 0 0 a b c d e| 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 the consistency of the
length fields (Option Data Length = Source NSAP Length + Dest. NSAP
Length +2). In case of inconsistency 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
Expires December 1995 [Page 10]
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 address or anycast address)
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.
6. IPv6 addresses inside an NSAPA
If it is required, for whatever reason, to embed an IPv6 address
inside a 20-octet NSAP address, then the following format MUST be
used.
A specific possible use of this embedding is to express an IP address
within the ATM Forum address format [UNI]. Another possible use
would be to allow CLNP packets that encapsulate IPv6 packets to be
routed in a CLNP network using the IPv6 address architecture. Several
leading bytes of the IPv6 address could be used as a CLNP routing
prefix.
The first three octets are an IDP meaning "this NSAPA embeds a 16
byte IPv6 address" and the last octet is a selector. To maintain
compatibility with both NSAP format and IPv6 addressing, this octet
must be present, but it has no significance for IPv6.
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 = 47 | ICD = ISoc (TBD) | 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 routing
table anomalies or to loops (compare [RFC1326]). Thus embedded IPv6
address MUST NOT have the prefixes 0x02 or 0x03, and an NSAPA with
the ISoc ICD code MUST NOT be embedded in an IPv6 header.
An NSAPA with the ISoc ICD code is converted to an IPv6 address by
stripping off the first three and the twentieth octets. All other
formats of NSAPA are handled according to the previous Chapters of
this document.
Expires December 1995 [Page 11]
7. Security condiderations
Security issues are not specifically addressed in this document, but
it is compatible with the IPv6 security mechanisms [security].
Acknowledgements
All direct contributors of text are listed below as authors. The
editor is also pleased to acknowledge the suggestions and comments of
Richard Collella, Dirk Fieldhouse, Denise Heagerty, Cyndi Jung, Yakov
Rekhter, and many other members of the former TUBA and new IPv6
working groups of the IETF. The support of Scott Bradner and Allison
Mankin of the IESG was essential.
Expires December 1995 [Page 12]
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] ???
[IS9542] ISO, "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.
[IPv6] The IPv6 base documents
[RFC1629] R. Colella, R. Callon, E. Gardner, Y. Rekhter, "Guidelines
for OSI NSAP Allocation in the Internet", RFC 1629, 1994.
[RFC1326] P. Tsuchiya, "Mutual Encapsulation Considered Dangerous",
RFC 1326, 1992.
[Rekhter] Forthcoming IPv6 address allocation documents.
[addrconf] Forthcoming IPv6 autoconfig document.
[assigned] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700
[discovery] Forthcoming IPv6 discovery document.
[UNI] ATM Forum UNI 3.x
[security] IPv6 security spec
[tunnel] Forthcoming CLNP over IPv6 document
Expires December 1995 [Page 13]
Annex A: Summary of NSAP Allocations
-----IDP------
-----------------------------------------------------
| AFI | IDI | DOMAIN SPECIFIC PART |
-----------------------------------------------------
--------------------20 bytes max---------------------
The Initial Domain Part (IDP) is split into Authority and Format
Identifier (AFI) followed by the Initial Domain Identifier (IDI).
This combination is followed by the Domain Specific Part and
allocation within that part is domain specific.
The following is a summary of 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 allocate the
country codes. The DSP is administered by the standards authority
for each country. In the UK, the British Standards Institution have
delegated administration to the Federation of Electronics Industries
- FEI
The UK DSP is split into a single digit UK Format Indicator (UKFI)
which indicates large, medium or small organisation rather like IP
addressing and a UK Domain Identifier (UKDI). Using binary code
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 have been allocated a UKDI in the UKFI = 1 (large
organisation) format and have specified the breakdown of the
Government Domain Specific Part with 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 indicates 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.
Expires December 1995 [Page 14]
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 to which the ISO
6523 designator is issued specifies the DSP allocation.
Expires December 1995 [Page 15]
Annex B: Additional Rationale
This annex is intended to give additional rationale, motivation and
justification for the support of NSAPAs in an IPv6 network.
There are several models for OSI-IPv6 convergence, of which address
mapping is only one. The other models can be identified as
1. Dual stack coexistence, in which a CLNP network and an IPv6
network exist side by side indefinitely using multiprotocol
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 and
reconcile the OSI and IPv6 addressing and routing schemes, and
replace CLNP by IPv6 at the network level. The rationale for this
choice is to preserve investment in NSAPA allocation schemes, and to
open the door for peer-to-peer routing models between IPv6 and bearer
services (such as ATM) using NSAPA addressing.
In addition to their use to retain an existing addressing plan,
certain other uses of restricted NSAPAs could be envisaged. They
could be used as an intermediate addressing plan for a network making
a transition from CLNP to IPv6. They could be used in a header
translation scheme for dynamic translation between IPv6 and CLNP.
They could be used to allow CLNP and IPv6 traffic to share the same
routing architecture within an organization (Ships in the Day).
It should be noted that the use of full NSAPA addresses in end
systems impacts many things. The most obvious are the API and DNS. If
applications are to work normally, everything that has to be modified
to cope with IPv6 addresses has to be further modified for full
NSAPAs. The mechanisms defined in the present document are only a
small part of the whole.
A destination option was chosen to carry full NSAPAs, in preference
to a dedicated extension header. In the case of an extension header,
all IPv6 nodes would have needed to understand its syntax merely in
order to ignore it. In contrast, intermediate nodes can ignore the
destination option without any knowledge of its syntax. Thus only
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 restricted
NSAPAs, which behave largely like any other IPv6 addresses).
2. 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
Expires December 1995 [Page 16]
space. Routing, system configuration, and neighbour discovery in the
NSAPA regions are outside the scope of the normal IPv6 mechanisms.
Authors' Addresses
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=au
Expires December 1995 [Page 17]