    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]