doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

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