DNS NSAP Resource Records
RFC 1706
Document | Type |
RFC - Informational
(October 1994; No errata)
Obsoletes RFC 1637
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1706 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 nextShow full document text