summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1706.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1706.txt')
-rw-r--r--doc/rfc/rfc1706.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1706.txt b/doc/rfc/rfc1706.txt
new file mode 100644
index 0000000..5b5d821
--- /dev/null
+++ b/doc/rfc/rfc1706.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group B. Manning
+Request for Comments: 1706 ISI
+Obsoletes: 1637, 1348 R. Colella
+Category: Informational NIST
+ October 1994
+
+
+ DNS NSAP Resource Records
+
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ OSI lower layer protocols, comprising the connectionless network
+ protocol (CLNP) and supporting routing protocols, are deployed in
+ some parts of the global Internet. Maintenance and debugging of CLNP
+ connectivity is greatly aided by 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.
+
+ 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.
+
+ This document obsoletes RFC 1348 and RFC 1637.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella [Page 1]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+1. Introduction
+
+ OSI lower layer protocols, comprising the connectionless network
+ protocol (CLNP) [5] and supporting routing protocols, are deployed in
+ some parts of the global Internet. Maintenance and debugging of CLNP
+ connectivity is greatly aided by support in the Domain Name System
+ (DNS) [7] [8] for mapping between names and NSAP (network service
+ access point) addresses [6] [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 [1] or Annex A of [6] for
+ additional information.
+
+2. Background
+
+ The reason for defining DNS mappings for NSAPs is to support the
+ existing CLNP deployment in the Internet. Debugging with CLNP ping
+ and traceroute has become more difficult with only numeric NSAPs as
+ the scale of deployment has increased. 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 describes the most serious short-term
+ problem. Scaling of a hosts.txt-like solution has well-known long-
+ term scaling difficiencies.
+
+3. Scope
+
+ The methods defined in this paper are applicable to all NSAP formats.
+
+ As a point of reference, there is a distinction between registration
+ and publication of addresses. For IP addresses, the IANA is the root
+ registration authority and the DNS a publication method. For NSAPs,
+ Annex A of the network service definition, ISO8348 [6], describes the
+ root registration authority and this memo defines how the DNS is used
+ as a publication method.
+
+
+
+
+
+
+Manning & Colella [Page 2]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+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 [6], 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 [2].
+ 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 [3]). NIST defined the subsequent
+ fields in [2], 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.
+
+ 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 [4] in addition to TCP/UDP must select NSels
+ for use by OSI Transport that do not conflict with the IP PROTO
+ values.
+
+
+
+Manning & Colella [Page 3]
+
+RFC 1706 DNS NSAP RRs October 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.
+
+
+ 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 (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
+
+ 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 [1].
+
+
+
+
+
+Manning & Colella [Page 4]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+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).
+
+ * 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.
+
+
+
+Manning & Colella [Page 5]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+ * 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
+
+ NSAP RRs cause no additional section processing.
+
+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.
+
+
+
+
+Manning & Colella [Page 6]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+ 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).
+
+
+ ;;;;;;
+ ;;;;;; 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
+ ;
+ bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+ IN A 129.6.224.162
+ IN HINFO PC_486 BSDi1.1
+ ;
+ 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
+
+
+
+Manning & Colella [Page 7]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+ 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
+
+
+
+
+ ;;;;;;
+ ;;;;;; 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 8]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+9. Authors' Addresses
+
+ Bill Manning
+ USC/Information Sciences Institute
+ 4676 Admiralty Way
+ Marina del Rey, CA. 90292
+ USA
+
+ Phone: +1.310.822.1511
+ EMail: bmanning@isi.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] 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.
+
+ [2] 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.
+
+ [3] ISO/IEC. Data interchange - structures for the identification of
+ organization. International Standard 6523, ISO/IEC JTC 1,
+ Switzerland, 1984.
+
+ [4] ISO/IEC. Connection oriented transport protocol specification.
+ International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
+
+ [5] ISO/IEC. Protocol for Providing the Connectionless-mode Network
+ Service. International Standard 8473, ISO/IEC JTC 1,
+ Switzerland, 1986.
+
+
+
+
+
+
+Manning & Colella [Page 9]
+
+RFC 1706 DNS NSAP RRs October 1994
+
+
+ [6] ISO/IEC. Information Processing Systems -- Data Communications --
+ Network Service Definition. International Standard 8348, ISO/IEC
+ JTC 1, Switzerland, 1993.
+
+ [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [8] Mockapetris, P., "Domain Names -- Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella [Page 10]
+