diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc1706.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc1706.txt | 563 |
1 files changed, 0 insertions, 563 deletions
diff --git a/contrib/bind9/doc/rfc/rfc1706.txt b/contrib/bind9/doc/rfc/rfc1706.txt deleted file mode 100644 index 5b5d821..0000000 --- a/contrib/bind9/doc/rfc/rfc1706.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -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] - |
