summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1637.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1637.txt')
-rw-r--r--doc/rfc/rfc1637.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1637.txt b/doc/rfc/rfc1637.txt
new file mode 100644
index 0000000..24f18b7
--- /dev/null
+++ b/doc/rfc/rfc1637.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group B. Manning
+Request for Comments: 1637 Rice University
+Obsoletes: 1348 R. Colella
+Category: Experimental NIST
+ June 1994
+
+
+ DNS NSAP Resource Records
+
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. This memo does not specify an Internet standard of any
+ kind. Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ The Internet is moving towards the deployment of an OSI lower layers
+ infrastructure. This infrastructure comprises the connectionless
+ network protocol (CLNP) and supporting routing protocols. Also
+ required as part of this infrastructure is support in the Domain Name
+ System (DNS) for mapping between names and NSAP addresses.
+
+ This document defines the format of one new Resource Record (RR) for
+ the DNS for domain name-to-NSAP mapping. The RR may be used with any
+ NSAP address format. This document supercedes RFC 1348.
+
+ NSAP-to-name translation is accomplished through use of the PTR RR
+ (see STD 13, RFC 1035 for a description of the PTR RR). This paper
+ describes how PTR RRs are used to support this translation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella [Page 1]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+1. Introduction
+
+ The Internet is moving towards the deployment of an OSI lower layers
+ infrastructure. This infrastructure comprises the connectionless
+ network protocol (CLNP) [6] and supporting routing protocols. Also
+ required as part of this infrastructure is support in the Domain Name
+ System (DNS) [8] [9] for mapping between domain names and OSI Network
+ Service Access Point (NSAP) addresses [7] [Note: NSAP and NSAP
+ address are used interchangeably throughout this memo].
+
+ This document defines the format of one new Resource Record (RR) for
+ the DNS for domain name-to-NSAP mapping. The RR may be used with any
+ NSAP address format.
+
+ NSAP-to-name translation is accomplished through use of the PTR RR
+ (see RFC 1035 for a description of the PTR RR). This paper describes
+ how PTR RRs are used to support this translation.
+
+ This memo assumes that the reader is familiar with the DNS. Some
+ familiarity with NSAPs is useful; see [2] or [7] for additional
+ information.
+
+2. Background
+
+ The reason for defining DNS mappings for NSAPs is to support CLNP in
+ the Internet. Debugging with CLNP ping and traceroute is becoming
+ more difficult with only numeric NSAPs as the scale of deployment
+ increases. Current debugging is supported by maintaining and
+ exchanging a configuration file with name/NSAP mappings similar in
+ function to hosts.txt. This suffers from the lack of a central
+ coordinator for this file and also from the perspective of scaling.
+ The former is the most serious short-term problem. Scaling of a
+ hosts.txt-like solution has well-known long-term scaling
+ difficiencies.
+
+ A second reason for this work is the proposal to use CLNP as an
+ alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A
+ Simple Proposal for Internet Addressing and Routing" [1]. For this to
+ be practical, the DNS must be capable of supporting CLNP addresses.
+
+3. Scope
+
+ The methods defined in this paper are applicable to all NSAP formats.
+ This includes support for the notion of a custom-defined NSAP format
+ based on an AFI obtained by the IAB for use in the Internet.
+
+ As a point of reference, there is a distinction between registration
+ and publication of addresses. For IP addresses, the IANA is the root
+
+
+
+Manning & Colella [Page 2]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+ registration authority and the DNS a publication method. For NSAPs,
+ addendum two of the network service definition, ISO8348/Ad2 [7] is
+ the root registration authority and this memo defines how the DNS is
+ used as a publication method.
+
+4. Structure of NSAPs
+
+ NSAPs are hierarchically structured to allow distributed
+ administration and efficient routing. Distributed administration
+ permits subdelegated addressing authorities to, as allowed by the
+ delegator, further structure the portion of the NSAP space under
+ their delegated control. Accomodating this distributed authority
+ requires that there be little or no a priori knowledge of the
+ structure of NSAPs built into DNS resolvers and servers.
+
+ For the purposes of this memo, NSAPs can be thought of as a tree of
+ identifiers. The root of the tree is ISO8348/Ad2 [7], and has as its
+ immediately registered subordinates the one-octet Authority and
+ Format Identifiers (AFIs) defined there. The size of subsequently-
+ defined fields depends on which branch of the tree is taken. The
+ depth of the tree varies according to the authority responsible for
+ defining subsequent fields.
+
+ An example is the authority under which U.S. GOSIP defines NSAPs [3].
+ Under the AFI of 47, NIST (National Institute of Standards and
+ Technology) obtained a value of 0005 (the AFI of 47 defines the next
+ field as being two octets consisting of four BCD digits from the
+ International Code Designator space [4]). NIST defined the subsequent
+ fields in [3], as shown in Figure 1. The field immediately following
+ 0005 is a format identifier for the rest of the U.S. GOSIP NSAP
+ structure, with a hex value of 80. Following this is the three-octet
+ field, values for which are allocated to network operators; the
+ registration authority for this field is delegated to GSA (General
+ Services Administration).
+
+ The last octet of the NSAP is the NSelector (NSel). In practice, the
+ NSAP minus the NSel identifies the CLNP protocol machine on a given
+ system, and the NSel identifies the CLNP user. Since there can be
+ more than one CLNP user (meaning multiple NSel values for a given
+ "base" NSAP), the representation of the NSAP should be CLNP-user
+ independent. To achieve this, an NSel value of zero shall be used
+ with all NSAP values stored in the DNS. An NSAP with NSel=0
+ identifies the network layer itself. It is left to the application
+ retrieving the NSAP to determine the appropriate value to use in that
+ instance of communication.
+
+
+
+
+
+
+Manning & Colella [Page 3]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+ |--------------|
+ | <-- IDP --> |
+ |--------------|-------------------------------------|
+ | AFI | IDI | <-- DSP --> |
+ |-----|--------|-------------------------------------|
+ | 47 | 0005 | DFI | AA |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
+ AA Administrative Authority
+ Rsvd Reserved
+ RD Routing Domain Identifier
+ Area Area Identifier
+ ID System Identifier
+ SEL NSAP Selector
+
+ Figure 1: GOSIP Version 2 NSAP structure.
+
+
+ When CLNP is used to support TCP and UDP services, the NSel value
+ used is the appropriate IP PROTO value as registered with the IANA.
+ For "standard" OSI, the selection of NSel values is left as a matter
+ of local administration. Administrators of systems that support the
+ OSI transport protocol [5] in addition to TCP/UDP must select NSels
+ for use by OSI Transport that do not conflict with the IP PROTO
+ values.
+
+ In the NSAP RRs in Master Files and in the printed text in this memo,
+ NSAPs are often represented as a string of "."-separated hex values.
+ The values correspond to convenient divisions of the NSAP to make it
+ more readable. For example, the "."-separated fields might correspond
+ to the NSAP fields as defined by the appropriate authority (ISOC,
+ RARE, U.S. GOSIP, ANSI, etc.). The use of this notation is strictly
+ for readability. The "."s do not appear in DNS packets and DNS
+ servers can ignore them when reading Master Files. For example, a
+ printable representation of the first four fields of a U.S. GOSIP
+ NSAP might look like
+
+ 47.0005.80.005a00
+
+
+
+
+
+
+Manning & Colella [Page 4]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+ and a full U.S. GOSIP NSAP might appear as
+
+ 47.0005.80.005a00.0000.1000.0020.00800a123456.00.
+
+ Other NSAP formats have different lengths and different
+ administratively defined field widths to accomodate different
+ requirements. For more information on NSAP formats in use see RFC
+ 1629 [2].
+
+5. The NSAP RR
+
+ The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
+ (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
+ mapping in the DNS using the NSAP RR operates analogously to IP
+ address lookup. A query is generated by the resolver requesting an
+ NSAP RR for a provided domain name.
+
+ NSAP RRs conform to the top level RR format and semantics as defined
+ in Section 3.2.1 of RFC 1035.
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | |
+ / /
+ / NAME /
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TYPE = NSAP |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | CLASS = IN |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TTL |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | RDLENGTH |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / RDATA /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ where:
+
+ * NAME: an owner name, i.e., the name of the node to which this
+ resource record pertains.
+
+ * TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
+
+
+
+
+Manning & Colella [Page 5]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+ * CLASS: two octets containing the RR IN CLASS code of 1.
+
+ * TTL: a 32 bit signed integer that specifies the time interval in
+ seconds that the resource record may be cached before the source
+ of the information should again be consulted. Zero values are
+ interpreted to mean that the RR can only be used for the
+ transaction in progress, and should not be cached. For example,
+ SOA records are always distributed with a zero TTL to prohibit
+ caching. Zero values can also be used for extremely volatile data.
+
+ * RDLENGTH: an unsigned 16 bit integer that specifies the length in
+ octets of the RDATA field.
+
+ * RDATA: a variable length string of octets containing the NSAP.
+ The value is the binary encoding of the NSAP as it would appear in
+ the CLNP source or destination address field. A typical example of
+ such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
+ 20 (decimal); "."s have been omitted to emphasize that they don't
+ appear in the DNS packets.
+
+ 39840f80005a0000000001e13708002010726e00
+
+5.1 Additional Section Processing
+
+ [The specification in this section is necessary for completeness in
+ describing name server support for TUBA. For the time being, name
+ servers participating in TUBA demonstrations MAY ELECT to implement
+ this behavior; it SHOULD NOT be the default behavior of name servers
+ because the IPng sweepstakes are still outstanding and further
+ consideration is required for truncation and other issues.]
+
+ RFC 1035 describes the additional section processing (ASP) required
+ when servers encounter NS records during query processing. From
+ Section 3.3.11, "NS RDATA format":
+
+ NS records cause both the usual additional section processing to
+ locate a type A record, and, when used in a referral, a special
+ search of the zone in which they reside for glue information.
+
+ For TUBA, identical ASP is required on type NSAP records to support
+ servers and resolvers that use CLNP, either because of preference or
+ because it is the only internetworking protocol available (i.e., in
+ the absense of IPv4). Thus, NS records cause ASP which locates a type
+ NSAP record in addition to a type A record. Both type A and NSAP
+ records should be returned, if available.
+
+
+
+
+
+
+Manning & Colella [Page 6]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+6. NSAP-to-name Mapping Using the PTR RR
+
+ The PTR RR is defined in RFC 1035. This RR is typically used under
+ the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
+
+ Similarly, the PTR RR is used to map from NSAPs to domain names under
+ the "NSAP.INT" domain. A domain name is generated from the NSAP
+ according to the rules described below. A query is sent by the
+ resolver requesting a PTR RR for the provided domain name.
+
+ A domain name is generated from an NSAP by reversing the hex nibbles
+ of the NSAP, treating each nibble as a separate subdomain, and
+ appending the top-level subdomain name "NSAP.INT" to it. For example,
+ the domain name used in the reverse lookup for the NSAP
+
+ 47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+
+ would appear as
+
+ 0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
+ 0.8.5.0.0.0.7.4.NSAP.INT.
+
+ [Implementation note: For sanity's sake user interfaces should be
+ designed to allow users to enter NSAPs using their natural order,
+ i.e., as they are typically written on paper. Also, arbitrary "."s
+ should be allowed (and ignored) on input.]
+
+7. Master File Format
+
+ The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
+ conforms to Section 5, "Master Files," of RFC 1035. Below are
+ examples of the use of these RRs in Master Files to support name-to-
+ NSAP and NSAP-to-name mapping.
+
+ The NSAP RR introduces a new hex string format for the RDATA field.
+ The format is "0x" (i.e., a zero followed by an 'x' character)
+ followed by a variable length string of hex characters (0 to 9, a to
+ f). The hex string is case-insensitive. "."s (i.e., periods) may be
+ inserted in the hex string anywhere after the "0x" for readability.
+ The "."s have no significance other than for readability and are not
+ propagated in the protocol (e.g., queries or zone transfers).
+
+
+
+
+
+
+
+
+
+
+Manning & Colella [Page 7]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+ ;;;;;;
+ ;;;;;; Master File for domain nsap.nist.gov.
+ ;;;;;;
+
+
+ @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
+ 1994041800 ; Serial - date
+ 1800 ; Refresh - 30 minutes
+ 300 ; Retry - 5 minutes
+ 604800 ; Expire - 7 days
+ 3600 ) ; Minimum - 1 hour
+ IN NS emu.ncsl.nist.gov.
+ IN NS tuba.nsap.lanl.gov.
+ ;
+ ;
+ $ORIGIN nsap.nist.gov.
+ ;
+ ; hosts
+ ;
+ bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
+ IN A 129.6.224.161
+ IN HINFO PC_486 BSDi1.1(TUBA)
+ ;
+ bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+ IN A 129.6.224.162
+ IN HINFO PC_486 BSDi1.1(TUBA)
+ ;
+ cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
+ IN A 129.6.224.171
+ IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA)
+ ;
+ infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
+ IN A 129.6.55.164
+ IN HINFO PC/486 BSDi1.0(TUBA)
+ ;
+ ; routers
+ ;
+ cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
+ IN A 129.6.224.151
+ IN A 129.6.225.151
+ IN A 129.6.229.151
+ ;
+ 3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
+ IN A 129.6.224.111
+ IN A 129.6.225.111
+ IN A 129.6.228.111
+
+
+
+
+
+Manning & Colella [Page 8]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+ ;;;;;;
+ ;;;;;; Master File for reverse mapping of NSAPs under the
+ ;;;;;; NSAP prefix:
+ ;;;;;;
+ ;;;;;; 47.0005.80.005a00.0000.0001.e133
+ ;;;;;;
+
+
+ @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
+ 1994041800 ; Serial - date
+ 1800 ; Refresh - 30 minutes
+ 300 ; Retry - 5 minutes
+ 604800 ; Expire - 7 days
+ 3600 ) ; Minimum - 1 hour
+ IN NS emu.ncsl.nist.gov.
+ IN NS tuba.nsap.lanl.gov.
+ ;
+ ;
+ $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
+ ;
+ 0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov.
+ ;
+ 0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov.
+ ;
+ 0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov.
+ ;
+ 0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov.
+ ;
+ 0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov.
+ ;
+ 0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov.
+
+8. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella [Page 9]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+9. Authors' Addresses
+
+ Bill Manning
+ Rice University -- ONCS
+ P.O. Box 1892
+ 6100 South Main
+ Houston, Texas 77251-1892
+ USA
+
+ Phone: +1.713.285.5415
+ EMail: bmanning@rice.edu
+
+
+ Richard Colella
+ National Institute of Standards and Technology
+ Technology/B217
+ Gaithersburg, MD 20899
+ USA
+
+ Phone: +1 301-975-3627
+ Fax: +1 301 590-0932
+ EMail: colella@nist.gov
+
+10. References
+
+ [1] Callon R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
+ Proposal for Internet Addressing and Routing", RFC 1347, DEC,
+ June 1992.
+
+ [2] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
+ for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
+ Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
+ 1994.
+
+ [3] GOSIP Advanced Requirements Group. Government Open Systems
+ Interconnection Profile (GOSIP) Version 2. Federal Information
+ Processing Standard 146-1, U.S. Department of Commerce, National
+ Institute of Standards and Technology, Gaithersburg, MD, April
+ 1991.
+
+ [4] ISO/IEC. Data interchange - structures for the identification of
+ organization. International Standard 6523, ISO/IEC JTC 1,
+ Switzerland, 1984.
+
+ [5] ISO/IEC. Connection oriented transport protocol specification.
+ International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
+
+
+
+
+
+Manning & Colella [Page 10]
+
+RFC 1637 DNS NSAP RRs June 1994
+
+
+ [6] ISO/IEC. Protocol for Providing the Connectionless-mode Network
+ Service. International Standard 8473, ISO/IEC JTC 1,
+ Switzerland, 1986.
+
+ [7] ISO/IEC. Information Processing Systems -- Data Communications --
+ Network Service Definition Addendum 2: Network Layer Addressing.
+ International Standard 8348/Addendum 2, ISO/IEC JTC 1,
+ Switzerland, 1988.
+
+ [8] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [9] Mockapetris, P., "Domain Names -- Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella [Page 11]
+