Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol
How an ISO network address is laid out so that ISO datagrams can be routed in the Internet.
Callon, R. and H.W. Braun, "Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol", RFC 1069, DOI 10.17487/RFC1069, February 1989, <https://www.rfc-editor.org/info/rfc1069>.
@misc{rfc1069,
series = {Request for Comments},
number = 1069,
howpublished = {RFC 1069},
publisher = {RFC Editor},
doi = {10.17487/RFC1069},
url = {https://www.rfc-editor.org/info/rfc1069},
author = {R. Callon and H.W. Braun},
title = {{Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol}},
pagetotal = 10,
year = 1989,
month = feb,
} RFC text
Contents
Network Working Group R. Callon Request for Comments: 1069 DEC Obsoletes: RFC 986 H.W. Braun UMich February 1989 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol Status of This Memo This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet. This is a solution to one of the problems inherent in the use of "ISO-grams" in the Internet. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This memo is a revision of RFC 986. Changes were made in order to allow the addressing used in the CLNP in the Internet to be potentially useful for routing in the context of new inter- and intra-domain routing protocols, and in the context of large numbers of networks and routing domains. The addressing scheme proposed in this RFC allows individual routing domains to make use of internal routing algorithms utilizing a variety of addressing formats, while still providing for a common addressing approach for use by inter- domain routing. These features are important due to the rapid growth currently being experienced in the Internet. 1. Objectives The data communications protocols currently emerging out of the international standardization efforts warrant an early integration into the existing extensive Internet network infrastructure. The two possible approaches are a top-down one, where ISO applications like FTAM, X.400 and VTP are integrated on top of the transport function of the IP protocol suite, or a bottom-up approach where the whole ISO tower gets integrated without merging the two suites. The bottom-up approach may make use of the fact that the ISO-CLNP and the IP are very similar in function. This implies that it is reasonable to implement a multiprotocol function in some or all of the Internet gateways (potentially including part or all of the Internet environment). The result would be that at least large portions of the Internet, in particular the backbones, can become usable for full implementations of the ISO protocol stack. A major problem with this approach is that there are open issues with regard to the ISO addressing within the CLNP. In particular, the ISO network layer addressing standard allows a great deal of flexibility in the assignment of addresses, and a particular address format must be chosen. A further problem is the need for implementation and integration of routing facilities for the ISO-compatible subset of the Internet environment. This paper proposed to use addresses which are considerably more flexible than the addresses used in the current IP Internet environment. This flexibility is necessary in order to allow some routing domains to base their internal routing protocol on addresses derived from the current IP addresses, to allow other routing domains to base routing on addresses in accordance to the intra-domain routing protocol being developed by ANSI and ISO [6], and to allow generality for a future inter-domain routing protocol. The addressing scheme proposed here makes use of the concept of "routing domains" as used in ANSI and ISO. This concept is similar to, but not identical with, the concept of "Autonomous System" used in the Internet. Routing domains include a combination of gateways, networks, and end systems (not just gateways), and routing domain boundaries may be used to define associated access control and policy routing constraints. Like autonomous systems, routing domains may be assumed to be topologically contiguous. There is no a priori reason why routing domains assigned for use with the ISO IP need to have any particular relation with existing autonomous systems which have been assigned for use with the IP. The assignment of specific routing domain identifiers is an "assigned numbers" function which is necessary for use of the ISO IP in the Internet, but is beyond the scope of this document. It is expected that this addressing scheme will be appropriate for long term use with the ISO IP in the Internet. However, it is also expected that in the long term, the Internet will be interconnected with other routing domains making use of other schemes, such as addresses assigned to commercial internets through ANSI, and addresses assigned by national standards organizations in other countries. This implies that, in the long term, gateways in the Internet will need to be able to route datagrams to destinations in other routing domains not conforming to the addressing format proposed here. This is discussed in greater detail in section 6. 2. Introduction The CLNP is documented in [1], but for matters of completeness the following illustration of the CLNP header is included here as Figure 1. The addressing part of the header is the subject of this RFC, i.e., the source and the destination address, respectively. These addresses are generally discussed in [2] and [3], with this document presenting a specific method for addressing in the Internet environment, consistent with the international standardized NSAP addresses. Octet +--------------------------------------+ +-------- | Network Layer Protocol Identifier | 1 : |--------------------------------------| : | Length Indicator | 2 : |--------------------------------------| : | Version/Protocol Id Extension | 3 : Fixed |--------------------------------------| : | Lifetime | 4 : Part |--------------------------------------| : |SP|MS|E/R| Type | 5 : |--------------------------------------| : | Segment Length | 6,7 : |--------------------------------------| : | Checksum | 8,9 : |--------------------------------------| +-------- | Destination Address Length Indicator | 10 : |--------------------------------------| : | Destination Address | 11 through m-1 : Address |--------------------------------------| : | Source Address Length Indicator | m : Part |--------------------------------------| : | Source Address | m+1 through n-1 : |--------------------------------------| +-------- | Data Unit Identifier | n,n+1 : |--------------------------------------| : Segment | Segment Offset | n+2,n+3 : ation |--------------------------------------| : | Total Length | n+4,n+5 : Part |--------------------------------------| +-------- | Options | n+6 through p : Options Part |--------------------------------------| +-------- | Data | p+1 through z : Data +--------------------------------------+ +-------- Figure 1: PDU Header Format 3. Addresses for Use in the Internet This section describes the addresses used to address NSAPs in the Internet. The appropriate Authority and Format Identifier (AFI) is one octet in length. It specifies an ISO-6523-ICD assignment, and also that the Domain Specific Part (DSP) of the address is based on binary. The AFI octet uses the value "47". The ISO-6523-ICD format is used to emphasize that this is an administrative assignment. The usage of an ISO DCC (Data Country Code) would be possible, but could be misleading due to the fairly far spread geographical extent of the Internet. As required by the ISO addressing standard, the next two octets of the address, in this case, specify the Initial Domain Identifier. This two octet value is the International Code Designator (ICD) assigned to the Internet, "0006". The remainder of the NSAP address is the Domain Specific Part (DSP). This is assigned by the Internet administration, which is considered to be an addressing domain. Note that there is no particular relationship required between addressing domains and routing domains. In this case, although the Internet is considered to be a single addressing domain, it is expected that it will consist of multiple routing domains. The DSP of the address specifies a one octet version number, a two octet global area number, a two octet routing domain number, a variable length padding field, a variable length IGP specific part, and a one octet selector field. The version number is provided to allow for future extensions, and must contain the value "02". The global area number and routing domain number are provided to allow for inter-domain routing. Initially, the global area number is reserved and must be set to zero. The routing domain number may be set to the routing domain number of any gateway by which the associated host address is directly reachable. The IGP specific part of the address may contain whatever addressing format is used in the routing domain. Two particular formats are expected to be used initially, and are presented in section 4. Padding is used so that the entire address will always be 20 octets in length. The selector field performs the same function as the user protocol field in the IP header. This is necessary because the ISO protocol considers identification of the user protocol to be an addressing issue, and therefore does not allow for the user protocol to be specified in the protocol header independently from the address. The assignment of specific routing domain identifiers to defined routing domains, and the assignment of values for use in the selector field, are functions for the Assigned Numbers authority for the Internet [4]. The specific values to be used are outside of the scope of this document. In summary, a source or destination address within the ISO Connectionless Protocol, when used in the Internet, looks as follows: Octet +------------------------+ | AFI | 1 +------------------------+ | IDI / ICD | 2 +-- --+ |(specifies DoD Internet)| 3 +------------------------+ | Version Number | 4 +------------------------+ | Global Area | 5 +--- ---+ | Number | 6 +------------------------+ | Routing | 7 +--- ---+ | Domain | 8 +------------------------+ | | 9 : Padding : : : : : | | n +------------------------+ | IGP | n+1 : : : : : : | Specific | 19 +------------------------+ | Selector | 20 +------------------------+ Figure 2: ISO IP address structure The Authority and Format Identifier (AFI) is "47" (BCD). The Initial Domain Identifier (IDI) consists of the International Code Designator (ICD) assigned to the Internet, and must contain the value "0006". The Version Number must contain the value "02". The Global Area Number must contains the value "00". The Padding field is of variable length, but must contain the value zero. 4. Specific Values for use with the IGP specific field In general, a particular routing domain may specify any addressing scheme for use with the IGP specific part of the address, up to 11 octets in length (consistent with the maximum address length of 20 octets). However, it is expected that initially addresses used in this field will consist of either the current IP addresses, or addresses conformant with those specified in the draft ANSI proposal for intra-domain routing. For end systems which are members of routing domains using the IP addresses for internal routing, the addresses will look as follows: Octet +------------------------+ | AFI | 1 +------------------------+ | IDI / ICD | 2 +-- --+ |(specifies DoD Internet)| 3 +------------------------+ | Version Number | 4 +------------------------+ | Global Area | 5 +--- ---+ | Number | 6 +------------------------+ | Routing | 7 +--- ---+ | Domain | 8 +------------------------+ | | 9 : Padding : : : : : | | 15 +------------------------+ | Four Octet | 16 +--- ---+ | Internet | 17 +--- ---+ | DoD | 18 +--- ---+ | Address | 19 +------------------------+ | Selector | 20 +------------------------+ Figure 3: ISO IP Address with Encoded DoD IP Address For end systems which are members of routing domains using the address format specified in the draft ANSI proposal for intra-domain routing [6], the addresses will look as follows: Octet +------------------------+ | AFI | 1 +------------------------+ | IDI / ICD | 2 +-- --+ |(specifies DOD Internet)| 3 +------------------------+ | Version Number | 4 +------------------------+ | Global Area | 5 +--- ---+ | Number | 6 +------------------------+ | Routing | 7 +--- ---+ | Domain | 8 +------------------------+ | | 9 +--- ---+ | Padding | 10 +--- ---+ | | 11 +------------------------+ | | 12 +--- LOC-AREA ---+ | | 13 +------------------------+ | | 14 : ID : : : : : | | 19 +------------------------+ | Selector | 20 +------------------------+ Figure 4: ISO IP Address with Encoded ANSI-format Address 5. Devices Attached to PDNs Otherwise isolated end systems, which are attached to the Internet only indirectly via public data networks, and simple LANs which are similarly attached only via Public Data Networks, may make use of a separate address format based on their X.121 address. Such addresses may, for example, use the ISO-X.121 address format discussed in [3]. These addresses will need to be handled for routing purposes in much the same way as addresses in routing domains which have been interconnected to the Internet, but which use other address formats, such as those specified by national standards bodies. 6. Migration to Future Routing Protocols Initially, routing of ISO datagrams in the Internet may make use of the first 8 octets of the address (AFI, ICD, version, global area number, and routing domain number) as a flat field identifying the routing domain. This implies that if EGP is initially used for routing between routing domains, a new version of EGP may be required to carry 8 octet routing domain numbers instead of 3 octet network numbers. There are currently several efforts underway to determine the requirements for inter-autonomous system routing, and to define a new protocol. One of the requirements of inter-autonomous system routing is the need to be able to deal with a very large Internet. It is anticipated that during the lifetime of the addressing scheme described in this RFC the number of networks in the Internet will grow to the point where it is no longer feasible for any gateway to maintain separate routes to every network in the Internet. Allowing inter-domain routing to be done by routing domain number instead of network number is therefore a necessary step in the long term. It is difficult to anticipate the rate at which the number of routing domains may grow. For example, during a period of time in which the number of networks grows by a factor of 100, it is not clear whether the number of routing domains may also be expected to grow by a factor of 100, or by some lesser amount. It is possible that the number of routing domains will also grow to a point where it is not feasible for a single gateway to maintain separate routes to each. In order to prepare for this eventuality, we have provided for a "global area" field. In the long term, it will be necessary for gateways to route to destinations which are in routing domains utilizing other addressing formats, specified by other organizations such as ANSI, ECMA, etc. In this case, it will not be possible to ensure that the first 8 octets of the address specifies the routing domain. In the long term, it will therefore be necessary to route based on variable length routing domain identifiers. It may be assumed that future inter-domain routing protocols will allow for specification of either (1) an address mask, specifying which part of an address is relevant for specifying those destinations which are reachable via a particular domain; or (2) a length field, specifying how many leading octets in a particular address are relevant. Specification of the details of such a routing protocol is beyond the scope of this document. References [1] ISO, "Protocol for Providing the Connectionless-Mode Network Services", RFC-926, ISO, December 1984. [2] ANSI, "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address", RFC-982, ANSI Working Document X3S3.3/85-258, April 1986. [3] ISO, Draft International Standard 8348/DAD2, "Information Processing Systems -- Data Communications -- Network Service Definition, Addendum 2 Covering Network Layer Addressing", RFC- 941, April 1985. [4] Reynolds, J. and J. Postel, "Assigned Numbers", RFC-1010, USC/Information Sciences Institute, May 1987. [5] Callon, R. and H. W. Braun, "Working Draft -- Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol," RFC-986, June 1986. [6] ISO TC97/SC6/WG2 working document, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol".
ISO Plain Language
On this page
§1Why ISO Addressing in the Internet Needed Rules
The data communications protocols emerging from the international standardization effort warranted early integration into the existing Internet infrastructure. There were two possible approaches. The top-down one integrated ISO applications such as FTAM, X.400 and VTP on top of the transport function of the IP protocol suite. The bottom-up one integrated the whole ISO tower without merging the two suites, which could make use of the fact that ISO-CLNP and IP are very similar in function. That implied a multiprotocol function in some or all of the Internet gateways, with the result that large portions of the Internet, in particular the backbones, could become usable for full implementations of the ISO protocol stack.
A major problem with the bottom-up approach was the open issue of ISO addressing within CLNP. The ISO network layer addressing standard allows a great deal of flexibility in the assignment of addresses, and a particular address format had to be chosen. A further problem was the need for implementation and integration of routing facilities for the ISO-compatible subset of the Internet environment.
The scheme proposed here uses more flexible addresses than those used in the current IP Internet environment. That flexibility lets some routing domains base their internal routing protocol on addresses derived from current IP addresses, lets others base routing on addresses following the intra-domain routing protocol being developed by ANSI and ISO, and leaves room for a future inter-domain routing protocol.
The scheme builds on the concept of routing domains as used by ANSI and ISO. This is similar to, but not identical with, the Internet's autonomous system. Routing domains include a combination of gateways, networks and end systems, not just gateways, and their boundaries may be used to define associated access control and policy routing constraints. Like autonomous systems, they may be assumed to be topologically contiguous. There is no reason in advance why routing domains for the ISO IP need any particular relation to the autonomous systems already assigned for IP. Assigning the specific routing domain identifiers is an assigned numbers function that is beyond the scope of this document.
The Internet and the ISO network layer could be joined up, because both do roughly the same job. The obstacle was addressing: ISO lets each network invent its own address format, and the Internet needs a common one to route between them.
§2Where the Addresses Sit in the CLNP Header
The CLNP is documented elsewhere, but the RFC reproduces an illustration of the CLNP header as Figure 1, because the addressing part of the header is the subject of the document: the source and destination address.
The header is divided into parts. The fixed part carries the network layer protocol identifier in octet 1, the length indicator in octet 2, the version and protocol identifier extension in octet 3, the lifetime in octet 4, the type field with its SP, MS and E/R bits in octet 5, the segment length in octets 6 and 7, and the checksum in octets 8 and 9. The address part follows: the destination address length indicator in octet 10, the destination address in octets 11 through m-1, the source address length indicator in octet m, and the source address in octets m+1 through n-1. The segmentation part carries the data unit identifier in octets n and n+1, the segment offset in octets n+2 and n+3 and the total length in octets n+4 and n+5. The options part runs from octet n+6 through p, and the data from octet p+1 through z.
The RFC presents a specific method for addressing in the Internet environment that is consistent with the international standardized NSAP addresses, which are otherwise discussed in the ISO documents it references.
The address is not a separate header but two fields inside the CLNP header: first the destination, then the source, each with a length octet in front of it.
§3The Structure of an ISO IP Address
The Authority and Format Identifier (AFI) is one octet and specifies an ISO-6523-ICD assignment, and that the Domain Specific Part of the address is based on binary. The AFI octet uses the value 47. The ISO-6523-ICD format is used to emphasize that this is an administrative assignment; an ISO Data Country Code would be possible, but could be misleading given the far-flung geographical extent of the Internet.
As the ISO addressing standard requires, the next two octets specify the Initial Domain Identifier. This two-octet value is the International Code Designator assigned to the Internet, 0006. The remainder of the address is the Domain Specific Part, which is assigned by the Internet administration, considered to be an addressing domain. There is no particular relationship required between addressing domains and routing domains: although the Internet is a single addressing domain, it is expected to consist of multiple routing domains.
The Domain Specific Part specifies a one-octet version number, a two-octet global area number, a two-octet routing domain number, a variable-length padding field, a variable-length IGP specific part, and a one-octet selector field. The version number allows for future extensions and must contain the value 02. The global area number and routing domain number allow inter-domain routing: the global area number is initially reserved and must be set to zero, and the routing domain number may be set to the routing domain number of any gateway by which the associated host address is directly reachable.
The IGP specific part may contain whatever addressing format the routing domain uses. Padding is used so that the entire address is always 20 octets long. The selector field performs the same function as the user protocol field in the IP header, because the ISO protocol treats identification of the user protocol as an addressing issue and does not allow the user protocol to be specified in the protocol header independently of the address. Assigning the specific routing domain identifiers and the values for the selector field are assigned numbers functions that are outside the scope of the document.
The address has a fixed shape. It starts with 47, then 0006, then a version number, then a global area number and a routing domain number. The rest is padding, the part the routing domain fills in for itself, and a final byte naming which user protocol is meant.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
AFI | AFI | 1 byte | 47 | Octet 1; the value 47, an ISO-6523-ICD assignment. |
IDI-ICD | IDI / ICD | 2 bytes | 0006 | Octets 2 and 3; the International Code Designator assigned to the Internet. |
VERSION | Version Number | 1 byte | 02 | Octet 4; the value 02, reserved for future extensions. |
GLOBAL-AREA | Global Area Number | 2 bytes | 00 | Octets 5 and 6; initially reserved and set to zero. |
ROUTING-DOMAIN | Routing Domain Number | 2 bytes | Octets 7 and 8; the routing domain of a gateway by which the host is directly reachable. | |
PADDING | Padding | 7 bytes | Octets 9 to 15; variable in length but always zero, so that the address is 20 octets. | |
IGP-SPECIFIC | IGP Specific Part | 4 bytes | Octets 16 to 19; here the four-octet DoD Internet address. | |
SELECTOR | Selector | 1 byte | Octet 20; names the user protocol, as the IP header's protocol field does. |
- AFIOne octet with the value 47, an ISO-6523-ICD assignment saying the domain specific part is binary.
- IDI / ICDTwo octets with the value 0006, the International Code Designator assigned to the Internet.
- Version numberOne octet with the value 02, present so the format can be extended later.
- Global area numberTwo octets, initially reserved and set to zero, for grouping routing domains later.
- Routing domain numberTwo octets naming the routing domain, which is what inter-domain routing works from.
- PaddingVariable length and always zero, so that the whole address is 20 octets.
- IGP specific partUp to 11 octets, in whatever format the routing domain uses internally.
- SelectorOne octet naming the user protocol, because ISO treats that as part of the address.
§4Two Expected Forms for the IGP-Specific Part
A particular routing domain may specify any addressing scheme for the IGP specific part of the address, up to 11 octets long, which is consistent with the maximum address length of 20 octets. It is expected that initially the addresses used in this field will consist of either the current IP addresses or addresses conformant with those in the draft ANSI proposal for intra-domain routing.
For end systems in routing domains that use IP addresses for internal routing, the address takes the form of Figure 3: the AFI, IDI/ICD, version number, global area number and routing domain number as before, then padding from octet 9 through octet 15, then the four-octet DoD Internet address in octets 16 through 19, then the selector in octet 20.
For end systems in routing domains using the address format from the draft ANSI proposal for intra-domain routing, the address takes the form of Figure 4: padding runs from octet 9 through octet 11, and the IGP specific part runs from octet 12 through octet 19, holding a LOC-AREA field and an ID field, with the selector again in octet 20.
The part of the address that the routing domain fills in can be up to 11 bytes. Two forms are expected: an ordinary four-byte Internet address, or the LOC-AREA and ID fields from the ANSI intra-domain routing proposal.
| Part of the address | DoD IP address form | ANSI form |
|---|---|---|
| Padding | Octets 9 to 15 | Octets 9 to 11 |
| IGP specific part | Octets 16 to 19: the four-octet DoD Internet address | Octets 12 to 19: a LOC-AREA field and an ID field |
| Selector | Octet 20 | Octet 20 |
| Total address length | 20 octets | 20 octets |
§5Devices Attached to Public Data Networks
Otherwise isolated end systems, attached to the Internet only indirectly via public data networks, and simple LANs similarly attached only via public data networks, may make use of a separate address format based on their X.121 address, for example the ISO-X.121 address format discussed in the ISO documents the RFC references.
These addresses have to be handled for routing purposes in much the same way as addresses in routing domains that are interconnected to the Internet but use other address formats, such as those specified by national standards bodies.
A host that reaches the Internet only through a public data network can be addressed by its X.121 number instead, and the Internet has to route for that form the same way it routes for other foreign address formats.
§6Migration to Future Routing Protocols
Initially, routing of ISO datagrams in the Internet may use the first eight octets of the address, the AFI, ICD, version, global area number and routing domain number, as a flat field identifying the routing domain. That implies that if EGP is initially used for routing between routing domains, a new version of EGP may be required to carry eight-octet routing domain numbers instead of three-octet network numbers.
Several efforts were underway to determine the requirements for inter-autonomous system routing and to define a new protocol. One requirement is the need to deal with a very large Internet. It is anticipated that during the lifetime of the addressing scheme described here the number of networks in the Internet will grow to the point where it is no longer feasible for any gateway to maintain separate routes to every network. Allowing inter-domain routing to be done by routing domain number instead of network number is therefore a necessary step in the long term.
It is difficult to anticipate how fast the number of routing domains may grow. If the number of networks grows by a factor of 100, it is not clear whether the number of routing domains grows by a factor of 100 or by some lesser amount. It is possible that the number of routing domains will also grow to a point where it is not feasible for a single gateway to maintain separate routes to each, and the global area field has been provided for that eventuality.
In the long term it will be necessary for gateways to route to destinations in routing domains that use other addressing formats, specified by organizations such as ANSI and ECMA. In that case it will not be possible to ensure that the first eight octets of the address specify the routing domain, and it will therefore be necessary to route based on variable-length routing domain identifiers. It may be assumed that future inter-domain routing protocols will allow either an address mask, specifying which part of an address is relevant for the destinations reachable via a particular domain, or a length field, specifying how many leading octets are relevant. The details of such a protocol are beyond the scope of this document.
The first eight bytes are enough to say which routing domain a destination belongs to, so routing between domains can work from those bytes alone. Later, when gateways cannot keep a route to every network, and when other address formats have to be routed for too, the scheme has room for longer identifiers and for a second grouping level.