One document matched: draft-carpenter-ipv6-osi-00.txt
Internet Draft B. Carpenter
February 26, 1995 (editor)
Mechanisms for OSI NSAPs, CLNP and TP over IPv6
Abstract
draft-carpenter-ipv6-osi-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, CLNP, and Transport Protocols over 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 ISSUES:
1. Use of restricted or truncated NSAPAs in source routing header?
2. Any advice for CLNP sites with more than one NSAP prefix in use?
3. Do discovery and stateless auto-config work with restricted NSAPs?
Do discovery and any kind of auto-config work with truncated NSAPs?
4. Do we need the Total Length field in the NSAPA extension header?
(If not make it a reserved field to preserve the alignment)
5. Is the NSAP extension header included in the security payload?
6. Re routing with truncated NSAP addresses (section 4, just below:
the diagram) Should we expand the "any suitable way" clause in this
paragraph? It seems to imply a high degree of correlation between the
[presumedly existing] CLNP network topology and the IPV6 subnet
structure. Or is this an unjustified assumption?
7. Should CLNP encapsulation & TP over IPv6 be separate documents?
8. Which IETF working groups should adopt the document(s) after
Danvers?
Expires August 31, 1995 [Page 1]
Table of Contents:
Status of this Memo.............................................3
1. General recommendation on NSAP addressing plans..............4
2. Summary of defined mechanisms................................5
3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC...6
4. Truncated NSAPA used as an IPv6 address......................8
5. Carriage of full NSAPAs in IPv6 extension headers............9
6. CLNP encapsulated in IPv6...................................10
7. ISO Transport Protocols over IPv6...........................11
8. IPv6 addresses inside an NSAPA..............................13
9. Security condiderations.....................................14
Acknowledgements...............................................14
References.....................................................15
Annex A: Summary of NSAP Allocations...........................16
Authors' Addresses.............................................18
Expires August 31, 1995 [Page 2]
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 August 31, 1995 [Page 3]
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]. 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 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 considered only as a well known
example.
Expires August 31, 1995 [Page 4]
2. Summary of defined mechanisms
The remainder of this document defines six 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 extension header
3. Normal IPv6 address, full NSAPA in IPv6 extension header
4. CLNP encapsulated in IPv6
5. OSI Transport Protocol carried over IPv6
6. IPv6 address carried as OSI address
Note in addition that an Internet Standard STD-35 "ISO Transport
Service on top of the TCP" exists already [RFC1006]. There is a also
a Proposed Standard for "OSI Connectionless Transport Service over
UDP" [RFC1240].
To clarify the relationship between the first four 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 Section 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 Section 4 below. EITHER an
extension header containing the complete NSAPA, as in Section 5
below, OR an encapsulated CLNP packet, SHALL be present.
With any other format of IPv6 address, an extension header
containing a complete NSAPA, as defined in Section 5 below,
MAY be present. Alternatively, an encapsulated CLNP packet
MAY be present.
Expires August 31, 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.
Certain other uses of this algorithmic mapping could be envisaged.
It could be used as an intermediate addressing plan for a network
making a transition from CLNP to IPv6. It could be used in a header
translation scheme for dynamic translation between IPv6 and CLNP. It
could be used to allow CLNP and IPv6 traffic to share the same
routing architecture within an organization (Ships in the Day).
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 section 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.
Expires August 31, 1995 [Page 6]
A network using such addresses could route using Internet routing
protocols (or suitably adapted implementations of ES-IS [3], IS-IS
[4] and IDRP [5]). It is expected that hosts using such addresses
could be configured using IPv6 stateful auto-configuration
[addrconf].
Expires August 31, 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 and truncated |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| zero pads if necessary | pack ID if applicable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case, the high order octets which make up the Area Address
portion of the NSAP address are used in any suitable way for routing
to an IPv6 node which can interpret a full NSAP address. Depending
upon the length of the NSAP, it may be possible to use the same
system ID value in the IPv6 address as in the NSAP. If appropriate,
the address can be interpreted as an IPv6 pack address, with the pack
ID in the two low order bytes of the address.
A pack ID may be used to identify either a host or router, or
potentially even an OSI Endsystem or Intermediate System. For
example, a pack ID might be configured to identify the endpoints of a
CLNP tunnel, or it might identify a particular OSI capable system in
a particular subnet. If such an address is used as either the source
or destination IPv6 address, an NSAPA extension header or CLNP packet
MUST be present. It is the responsibility of the system identified
by the pack ID 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 a pack ID is used to identify a router in a particular subnet, and
the NSAPA extension header follows the IPV6 routing header, 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 header. 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. 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].
Expires August 31, 1995 [Page 8]
5. Carriage of full NSAPAs in IPv6 extension headers
The codings described in the previous sections are inadequate if the
ICD or DCC binary format in use is too large to fit into 16 bytes, or
if any other format defined in [IS8348] must be carried. In this
case, an IPv6 extension header of type NSAPA is used. Protocol code
57 has been assigned by IANA for this and will appear in the next
edition of [assigned]. This header follows the IPv6 routing header if
present, and its format is:
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 | Total Length |Source NSAP Len| Dest. NSAP Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| |
+ Source NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination NSAP +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad with zeros to next 64-bit boundary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length fields are each one octet long and are expressed in
octets. The boundary between the source NSAP and the destination
NSAP length is simply aligned on an octet boundary. With standard 20
octet NSAPs the total header length is 48 bytes.
The NSAP encodings follow [IS8348] exactly. If only one of the end
systems uses NSAP addresses, the NSAP Length field of the other SHALL
be set to zero in the NSAP extension header.
This extension header is used in two cases. Firstly, an IPv6 source
node using normal IPv6 addresses (unicast address or pack address)
MAY supply an NSAP extension 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.
Expires August 31, 1995 [Page 9]
6. CLNP encapsulated in IPv6
If it is required to tunnel CLNP [IS8473] through an IPv6 network,
then the transport header SHALL be a CLNP PDU, and the final IPv6
Next Header field SHALL have the value 80 decimal (as defined for
ISO-IP in [assigned]).
Mechanisms for the creation of CLNP tunnels and their management are
outside the scope of this document. As for the cases described in the
previous section, the IPv6 end nodes might be conveniently reached by
pack addresses.
Note that the tunnelling of CLNP over the Internet is discussed in
detail in [RFC1070], but that document has no standards status and
makes different assumptions about address mapping. In contrast to
[RFC1070], CLNP tunnels through an IPv6 network are simply a virtual
point-to-point encapsulation technology, using statically configured
tunnel endpoints. There is no support for simulating a multipoint
subnetwork, nor for dynamic mapping between NSAP addresses and IP
addresses. Instead, IP addresses are simply viewed as Subnetwork
Point of Attachment (SNPA) addresses that must be statically
configured to create the tunnel.
Once a tunnel is established, data is transmitted using CLNP
[IS8473]. The ES-IS [3], IS-IS [4], and IDRP [5] protocols may be
used to dynamically establish neighbor adjacencies and routing. Any
NSAP addresses may be assigned to the systems at either end of the
tunnel. There is no need to constrain the NSAP address format as
documented in [RFC1070], since there is no need to perform dynamic
address mapping. The "EON" header of [RFC1070] is not present.
No attempt is required to implement feedback of error indications
from ICMP in the IP subnetwork into CLNP error PDUs. The tunnel is
ignorant of problems in the IP subnetwork, and depends upon
mechanisms in the OSI routing protocols to detect connectivity
failures.
Expires August 31, 1995 [Page 10]
7. ISO Transport Protocols over IPv6
If it is required to carry ISO Transport Protocols [ISO8072, ISO8073]
over an IPv6 network, then the IPv6 transport header SHALL be a TP
PDU, and the final IPv6 Next Header field SHALL have the value 29
decimal (as defined for ISO-TP in [assigned]).
+---------------+------------------------
| IPv6 header | TP PDU
| |
| Next Header = |
| ISO-TP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TP PDU
| | |
| Next Header = | Next Header = |
| Routing | ISO-TP |
+---------------+----------------+------------------------
7.1 Protocol Classes
The ISO connection-oriented transport protocol [ISO8073] supports
five different classes of service. Only one such class, class 4
(TP4), is suitable for use on a connectionless network service such
as provided by IPv6. Transport classes 0 through 3 should not carried
over an IPv6 network in this manner.
Note that the connectionless transport protocol [ISO8072] has no such
restriction. Its PDUs should be carried exactly as described above.
There is no conflict inherent in using the same IPv6 Next Header
value for both connection-oriented and connectionless protocols. ISO
transport implementations can distinguish the two protocols by their
different PDU types.
7.2 Maximum TPDU Size
When negotiating a maximum TPDU size, TP4 implementations may
consider the services available from the network layer. Unlike IPv4
or CLNP, IPv6 only permits fragmentation by the originating system.
TP4 may use its knowledge of the capabilities of the local system to
maximize the efficiency of data transfer.
7.2.1 Path MTU Discovery and Fragmentation
If the TP4 implementation can accept Path MTU Discovery [RFC1191]
information, and if the TP4 implementation can efficiently invoke the
IPv6 fragmentation function, then the TP4 may propose the largest
TPDU size and/or preferred maximum TPDU size that the implementation
can support.
If, during the life of the connection, IPv6 reports PMTU information
to the TP4 implementation, TP4 should adjust its local TPDU size
accordingly. Note that the original TPDU (the one which solicited the
PMTU) cannot be repacketized; TP4 must instead rely on IPv6
fragmentation for that PDU's retransmission.
Expires August 31, 1995 [Page 11]
7.2.2 No Path MTU Discovery or Fragmentation
If the TP4 implementation cannot accept Path MTU Discovery
information from IPv6, or if it cannot efficiently invoke the IPv6
fragmentation function, then TP4 may propose a TPDU size of
{512|1024} octets and a preferred maximum TPDU size of {512|1408}
octets. These sizes will ensure that TPDUs are no larger than the
IPv6 minimum MTU of {576|1500} bytes [IPv6].
7.3 PDU Lifetime
Unlike IPv4 and CLNP, IPv6 nodes are not required to enforce PDU
lifetimes. Any transport protocol that relies on the network
protocol to limit packet lifetime ought to be upgraded to provide its
own mechanisms for detecting and discarding obsolete packets.
7.4 Related work
The carriage of OSI Connectionless Transport Services over UDP is
described in [RFC1240], which is currently a Proposed Standard. The
present proposal is independent of that one.
Expires August 31, 1995 [Page 12]
8. 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 dummy selector. To
maintain compatibility with both NSAP format and IPv6 addressing,
this octet must be present but unused.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Recursive address embedding is not allowed. The embedded IPv6 address
MUST NOT have the prefixes 0x02 or 0x03, and an NSAP with the Isoc
ICD code MUST NOT be embedded in an IPv6 packet.
Expires August 31, 1995 [Page 13]
9. Security condiderations
Security issues are not specifically addressed in this document, but
it is compatible with the IPv6 security mechanisms [security]. Note,
however, that when CLNP is tunnelled through IPv6 the IPv6 security
mechanisms can at best protect the tunnel, but not the end-to-end
CLNP service.
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 August 31, 1995 [Page 14]
References
[ISO8072] Protocol for providing the connectionless-mode transport
service, ISO/IEC 8072, 1987.
[ISO8073] Protocol for providing the connection-mode transport
service, ISO/IEC 8073 (2nd ed.), 1992.
[RFC1191] Path MTU Discovery, Mogul and Deering, November 1990.
[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] ???
[3] 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.
[4] ISO, "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service (ISO
8473)," ISO/IEC 10589:1992.
[5] ISO, "Intermediate system to Intermediate system interdomain
routeing information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network Service
(ISO 8473)," ISO/IEC 10747:1993.
[IPv6] The IPv6 base documents
[RFC1006] STD-35, ISO Transport Service on top of the TCP...
[RFC1070] Use of the Internet as a Subnetwork for Experimentation
with the OSI Network Layer...
[RFC1240] OSI Connectionless Transport Services on top of UDP...
[RFC1629] The one that explains GOSIPv2 addressing
[Rekhter] Forthcoming IPv6 address allocation documents.
[addrconf] Forthcoming IPv6 autoconfig document.
[assigned] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700
[UNI] ATM Forum UNI 3.x
[security] IPv6 security spec
Expires August 31, 1995 [Page 15]
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 August 31, 1995 [Page 16]
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 August 31, 1995 [Page 17]
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
Dave Katz Phone: +1 (415) 688-8284
cisco Systems, Inc. EMail: dkatz@cisco.com
1525 O'Brien Dr.
Menlo Park, CA 94025
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
Stephen Thomas
Associate Principal Engineer Phone: (404) 514-3522
AT&T Tridom Fax: (404) 514-3491
840 Franklin Court Email: stephen.thomas@tridom.com
Marietta, GA 30067 USA
Expires August 31, 1995 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 07:09:43 |