DNS NSAP Resource Records
RFC 1706

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• rfc1706

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