From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1069.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1069.txt (limited to 'doc/rfc/rfc1069.txt') diff --git a/doc/rfc/rfc1069.txt b/doc/rfc/rfc1069.txt new file mode 100644 index 0000000..a63eb52 --- /dev/null +++ b/doc/rfc/rfc1069.txt @@ -0,0 +1,563 @@ + + + + + + +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 + + + +Callon & Braun [Page 1] + +RFC 1069 IP ISO Addressing February 1989 + + + 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. + + + + +Callon & Braun [Page 2] + +RFC 1069 IP ISO Addressing February 1989 + + + 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 + + + + + + + +Callon & Braun [Page 3] + +RFC 1069 IP ISO Addressing February 1989 + + +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 + + + +Callon & Braun [Page 4] + +RFC 1069 IP ISO Addressing February 1989 + + + 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 + + + + +Callon & Braun [Page 5] + +RFC 1069 IP ISO Addressing February 1989 + + + 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Callon & Braun [Page 6] + +RFC 1069 IP ISO Addressing February 1989 + + + 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: + + + + + + + + + + + +Callon & Braun [Page 7] + +RFC 1069 IP ISO Addressing February 1989 + + + 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 + + + +Callon & Braun [Page 8] + +RFC 1069 IP ISO Addressing February 1989 + + + 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. + + + +Callon & Braun [Page 9] + +RFC 1069 IP ISO Addressing February 1989 + + +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". + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Callon & Braun [Page 10] + \ No newline at end of file -- cgit v1.2.3