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/rfc1526.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc1526.txt (limited to 'doc/rfc/rfc1526.txt') diff --git a/doc/rfc/rfc1526.txt b/doc/rfc/rfc1526.txt new file mode 100644 index 0000000..62e97d8 --- /dev/null +++ b/doc/rfc/rfc1526.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group D. Piscitello +Request for Comments: 1526 Bellcore +Category: Informational September 1993 + + + Assignment of System Identifiers for TUBA/CLNP Hosts + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + This document describes conventions whereby the system identifier + portion of an RFC 1237 style NSAP address may be guaranteed + uniqueness within a routing domain for the purpose of + autoconfiguration in TUBA/CLNP internets. The mechanism is extensible + and can provide a basis for assigning system identifiers in a + globally unique fashion. + +Introduction + + This memo specifies methods for assigning a 6 octet system identifier + portion of the OSI NSAP address formats described in "Guidelines for + OSI NSAP Allocation in the Internet" [1], in a fashion that ensures + that the ID is unique within a routing domain. It also recommends + methods for assigning system identifiers having lengths other than 6 + octets. The 6 octet system identifiers recommended in this RFC are + assigned from 2 globally administered spaces (IEEE 802 or "Ethernet", + and IP numbers, administered by the Internet Assigned Numbers + Authority, IANA). + + At this time, the primary purpose for assuring uniqueness of system + identifiers is to aid in autoconfiguration of NSAP addresses in + TUBA/CLNP internets [2]. The guidelines in this paper also establish + an initial framework within which globally unique system identifiers, + also called endpoint identifiers, may be assigned. + +Acknowledgments + + Many thanks to Radia Perlman, Allison Mankin, and Ross Callon of for + their insights and assistance. Thanks also to the Ethernet connector + to my MAC, which conveniently and quite inobtrusively fell out, + enabling me to get an entire day's worth of work done without email + interruptions. + + + + +Piscitello [Page 1] + +RFC 1526 System Identifiers for TUBA September 1993 + + +1. Background + + The general format of OSI network service access point (NSAP) + addresses is illustrated in Figure 1. + + _______________________________________________ + |____IDP_____|_______________DSP______________| + |__AFI_|_IDI_|_____HO-DSP______|___ID___|_SEL_| + + IDP Initial Domain Part + AFI Authority and Format Identifier + IDI Initial Domain Identifier + DSP Domain Specific Part + HO-DSP High-order DSP + ID System Identifier + SEL NSAP Selector + + Figure 1: OSI NSAP Address Structure. + + The recommended encoding and allocation of NSAP addresses in the + Internet is specified in RFC 1237. RFC 1237 makes the following + statements regarding the system identifier (ID) field of the NSAPA: + + 1. the ID field may be from one to eight octets in length + + 2. the ID must have a single known length in any particular + routing domain + + 3. the ID field must be unique within an area for ESs and + level 1 ISs, and unique within the routing domain for level + 2 ISs. + + 4. the ID field is assumed to be flat + + RFC 1237 further indicates that, within a routing domain that + conforms to the OSI intradomain routing protocol [3] the lower-order + octets of the NSAP should be structured as the ID and SEL fields + shown in Figure 1 to take full advantage of intradomain IS-IS + routing. (End systems with addresses which do not conform may require + additional manual configuration and be subject to inferior routing + performance.) + + Both GOSIP Version 2 (under DFI-80h, see Figure 2a) and ANSI DCC NSAP + addressing (Figure 2b) define a common DSP structure in which the + system identifier is assumed to be a fixed length of 6 octets. + + + + + + +Piscitello [Page 2] + +RFC 1526 System Identifiers for TUBA September 1993 + + + _______________ + |<--__IDP_-->_|___________________________________ + |AFI_|__IDI___|___________<--_DSP_-->____________| + |_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_| + octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__| + + Figure 2 (a): GOSIP Version 2 NSAP structure. + ______________ + |<--_IDP_-->_|_____________________________________ + |AFI_|__IDI__|____________<--_DSP_-->_____________| + |_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_| + octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__| + + IDP Initial Domain Part + AFI Authority and Format Identifier + IDI Initial Domain Identifier + DSP Domain Specific Part + DFI DSP Format Identifier + ORG Organization Name (numeric form) + Rsvd Reserved + RD Routing Domain Identifier + Area Area Identifier + ID System Identifier + SEL NSAP Selector + + + Figure 2(b): ANSI NSAP address format for DCC=840 + +2. Autoconfiguration + + There are provisions in OSI for the autoconfiguration of area + addresses. OSI end systems may learn their area addresses + automatically by observing area address identified in the IS-Hello + packets transmitted by routers using the ISO 9542 End System to + Intermediate System Routing Protocol, and may then insert their own + system identifier. (In particular, RFC 1237 explains that when the ID + portion of the address is assigned using IEEE style 48-bit + identifiers, an end system can reconfigure its entire NSAP address + automatically without the need for manual intervention.) End systems + that have not been pre-configured with an NSAPA may also request an + address from an intermediate system their area using [5]. + +2.1 Autoconfiguration and 48-bit addresses + + There is a general misassumption that the 6-octet system identifier + must be a 48-bit IEEE assigned (ethernet) address. Generally + speaking, autoconfiguration does not rely on the use of a 48-bit + ethernet style address; any system identifier that is globally + + + +Piscitello [Page 3] + +RFC 1526 System Identifiers for TUBA September 1993 + + + administered and is unique will do. The use of 48-bit/6 octet system + identifiers is "convenient...because it is the same length as an 802 + address", but more importantly, choice of a single, uniform ID length + allows for "efficient packet forwarding", since routers won't have to + make on the fly decisions about ID length (see [6], pages 156-157). + Still, it is not a requirement that system identifiers be 6 octets to + operate the the IS-IS protocol, and IS-IS allows for the use of IDs + with lengths from 1 to 8 octets. + +3. System Identifiers for TUBA/CLNP + + Autoconfiguration is a desirable feature for TUBA/CLNP, and is viewed + by some as "essential if a network is to scale to a truly large size" + [6]. + + For this purpose, and to accommodate communities who do not wish to + use ethernet style addresses, a generalized format that satisfies the + following criteria is desired: + + o the format is compatible with installed end systems + complying to RFC 1237 + + o the format accommodates 6 octet, globally unique system + identifiers that do not come from the ethernet address space + + o the format accommodates globally unique system identifiers + having lengths other than 6 octets + + The format and encoding of a globally unique system identifier that + meets these requirements is illustrated in Figure 3: + + Octet 1 Octet 2 Octet 3 ... Octet LLL-1 Octet LLLL + +-----------+-----------+-----------+- ...-+-----------+-----------+ + | xxxx TTGM | xxxx xxxx | xxxx xxxx | | xxxx xxxx | xxxx xxxx | + +-----------+-----------+-----------+- ...-+-----------+-----------+ + + Figure 3. General format of the system identifier + +3.1 IEEE 802 Form of System Identifier + + The format is compatible with globally assigned IEEE 802 addresses, + since it carefully preserves the semantics of the global/local and + group/individual bits. Octet 1 identifies 2 qualifier bits, G and M, + and a subtype (TT) field whose semantics are associated with the + qualifier bits. When a globally assigned IEEE 802 address is used as + a system identifier, the qualifier bit M, representing the + multicast/unicast bit, must always be set to zero to denote a unicast + address. The qualifier bit G may be either 0 or 1, depending on + + + +Piscitello [Page 4] + +RFC 1526 System Identifiers for TUBA September 1993 + + + whether the individual address is globally or locally assigned. In + these circumstances, the subtype bits are "don't care", and the + system identifier shall be interpreted as a 48-bit, globally unique + identifier assigned from the IEEE 802 committee (an ethernet + address). The remaining bits in octet 1, together with octets 2 and + 3 are the vendor code or OUI (organizationally unique identifier), as + illustrated in Figure 4. The ID is encoded in IEEE 802 canonical + form (low order bit of low order hex digit of leftmost octet is the + first bit transmitted). + + Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 ++-----------+-----------+-----------+-----------+-----------+-----------+ +| VVVV VV00 | VVVV VVVV | VVVV VVVV | SSSS SSSS | SSSS SSSS | SSSS SSSS | ++-----------+-----------+-----------+-----------+-----------+-----------+ + +|------------vendor code -----------|--------station code---------------| + + Figure 4. IEEE 802 form of system identifier + +4. Embedded IP Address as System Identifier + + To distinguish 48-bit IEEE 802 addresses used as system identifiers + from other forms of globally admininistered system identifiers, the + qualifer bit M shall be set to 1. The correct interpretation of the M + bit set to 1 should be, "this can't be an IEEE 802 multicast address, + since use of multicast addresses is by convention illegal, so it must + be some other form of system identifier". The subtype (TT) bits + illustrated in Figure 3 thus become relevant. + + When the subtype bits (TT) are set to a value of 0, the system + identifier contains an embedded IP address. The remainder of the 48- + bit system identifier is encoded as follows. The remaining nibble in + octet 1 shall be set to zero. Octet 2 is reserved and shall be set + to a pre-assigned value (see Figure 5). Octets 3 through 6 shall + contain a valid IP address, assigned by IANA. Each octet of the IP + address is encoded in binary, in internet canonical form, i.e., the + leftmost bit of the network number first. + + Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 ++-----------+-----------+-----------+-----------+-----------+-----------+ +| 0000 0001 | 1010 1010 | aaaa aaaa | bbbb bbbb | cccc cccc | dddd dddd | ++-----------+-----------+-----------+-----------+-----------+-----------+ + +|-len&Type--|--reserved-|---------IP address----------------------------| + + Figure 5. Embedded IP address as system identifier + + + + + +Piscitello [Page 5] + +RFC 1526 System Identifiers for TUBA September 1993 + + + As an example, the host "eve.bellcore.com = 128.96.90.55" could retain + its IP address as a system identifier in a TUBA/CLNP network. The + encoded ID is illustrated in Figure 6. + + + Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 ++-----------+-----------+-----------+-----------+-----------+-----------+ +| 0000 0001 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 | ++-----------+-----------+-----------+-----------+-----------+-----------+ + +|-len&Type--|--reserved-|---------IP address----------------------------| + + Figure 6. Example of IP address encoded as ID + +H 2 "Other forms of System Identifiers" + + To allow for the future definition of additional 6-octet system + identifiers, the remaining subtype values are reserved. + + It is also possible to identify system identifiers with lengths other + than 6 octets. Communities who wish to use 8 octet identifiers (for + example, embedded E.164 international numbers for the ISDN ERA) must + use a GOSIP/ANSI DSP format that allows for the specification of 2 + additional octets in the ID field, perhaps at the expense of the + "Rsvd" fields; this document recommends that a separate Domain Format + Indicator value be assigned for such purposes; i.e., a DFI value that + is interpreted as saying, among other things, "the system identifier + encoded in this DSP is 64-bits/8 octets. The resulting ANSI/GOSIP DSP + formats under such circumstances are illustrated in Figure 7: + + + + + + + + + + + + + + + + + + + + + + +Piscitello [Page 6] + +RFC 1526 System Identifiers for TUBA September 1993 + + + ______________ + |<--_IDP_-->_|______________________________ + |AFI_|__IDI__|____________<--_DSP_-->_______| + |_39_|__840__|DFI_|_ORG_|RD_|Area_|_ID_|Sel_| + octets |_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__| + + Figure 7a: ANSI NSAP address format for DCC=840, DFI=foo + + _______________ + |<--__IDP_-->_|___________________________________ + |AFI_|__IDI___|___________<--_DSP_-->____________| + |_47_|__0005__|DFI_|AA_|_RD_|Area_|ID_|Sel_| + octets |_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__| + + IDP Initial Domain Part + AFI Authority and Format Identifier + IDI Initial Domain Identifier + DSP Domain Specific Part + DFI DSP Format Identifier + AA Administrative Authority + RD Routing Domain Identifier + Area Area Identifier + ID System Identifier + SEL NSAP Selector + + Figure 7b: GOSIP Version 2 NSAP structure, DFI=bar + + Similar address engineering can be applied for those communities who + wish to have shorter system identifiers; have another DFI assigned, + and expand the reserved field. + +5. Conclusions + + This proposal should debunk the "if it's 48-bits, it's gotta be an + ethernet address" myth. It demonstrates how IP addresses may be + encoded within the 48-bit system identifier field in a compatible + fashion with IEEE 802 addresses, and offers guidelines for those who + wish to use system identifiers other than those enumerated here. + + + + + + + + + + + + + +Piscitello [Page 7] + +RFC 1526 System Identifiers for TUBA September 1993 + + +6. References + + [1] Callon, R., Gardner, E., and R. Colella, "Guidelines for OSI NSAP + Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, June + 1991. + + [2] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple + Proposal for Internet Addressing and Routing", RFC 1347, DEC, + June 1992. + + [3] ISO, "Intradomain routing protocol for use in conjunction with + ISO 8473, Protocol for providing the OSI connectionless network + service", ISO 10589. + + [4] ISO, End-system and intermediate-system routing protocol for use + in conjunction with ISO 8473, Protocol for providing the OSI + connectionless network service, ISO 9542. + + [5] ISO, "End-system and intermediate-system routing protocol for use + in conjunction with ISO 8473, Protocol for providing the OSI + connectionless network service. Amendment 1: Dynamic Discovery + of OSI NSAP Addresses End Systems", ISO 9542/DAM1. + + [6] Perlman, R., "Interconnections: Bridges and Routers", Addison- + Wesley Publishers, Reading, MA. 1992. + +7. Security Considerations + + Security issues are not discussed in this memo. + +8. Author's Address + + David M. Piscitello + Bell Communications Research + NVC 1C322 + 331 Newman Springs Road + Red Bank, NJ 07701 + + EMail: dave@mail.bellcore.com + + + + + + + + + + + + +Piscitello [Page 8] + \ No newline at end of file -- cgit v1.2.3