rfc1637.txt

RFC 的详细文档！

Network Working Group                                         B. Manning
Request for Comments: 1637                               Rice University
Obsoletes: 1348                                               R. Colella
Category: Experimental                                              NIST
                                                               June 1994


                       DNS NSAP Resource Records


Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   The Internet is moving towards the deployment of an OSI lower layers
   infrastructure. This infrastructure comprises the connectionless
   network protocol (CLNP) and supporting routing protocols. Also
   required as part of this infrastructure is 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. This document supercedes RFC 1348.

   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.



















Manning & Colella                                               [Page 1]

RFC 1637                      DNS NSAP RRs                     June 1994


1.  Introduction

   The Internet is moving towards the deployment of an OSI lower layers
   infrastructure. This infrastructure comprises the connectionless
   network protocol (CLNP) [6] and supporting routing protocols. Also
   required as part of this infrastructure is support in the Domain Name
   System (DNS) [8] [9] for mapping between domain names and OSI Network
   Service Access Point (NSAP) addresses [7] [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 [2] or [7] for additional
   information.

2.  Background

   The reason for defining DNS mappings for NSAPs is to support CLNP in
   the Internet. Debugging with CLNP ping and traceroute is becoming
   more difficult with only numeric NSAPs as the scale of deployment
   increases. 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 is the most serious short-term problem. Scaling of a
   hosts.txt-like solution has well-known long-term scaling
   difficiencies.

   A second reason for this work is the proposal to use CLNP as an
   alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A
   Simple Proposal for Internet Addressing and Routing" [1]. For this to
   be practical, the DNS must be capable of supporting CLNP addresses.

3.  Scope

   The methods defined in this paper are applicable to all NSAP formats.
   This includes support for the notion of a custom-defined NSAP format
   based on an AFI obtained by the IAB for use in the Internet.

   As a point of reference, there is a distinction between registration
   and publication of addresses. For IP addresses, the IANA is the root



Manning & Colella                                               [Page 2]

RFC 1637                      DNS NSAP RRs                     June 1994


   registration authority and the DNS a publication method. For NSAPs,
   addendum two of the network service definition, ISO8348/Ad2 [7] is
   the root registration authority and this memo defines how the DNS is
   used as a publication method.

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/Ad2 [7], 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 [3].
   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 [4]). NIST defined the subsequent
   fields in [3], 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.






Manning & Colella                                               [Page 3]

RFC 1637                      DNS NSAP RRs                     June 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.


   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 [5] in addition to TCP/UDP must select NSels
   for use by OSI Transport that do not conflict with the IP PROTO
   values.

   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 (ISOC,
   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






Manning & Colella                                               [Page 4]

RFC 1637                      DNS NSAP RRs                     June 1994


   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 [2].

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).




Manning & Colella                                               [Page 5]

RFC 1637                      DNS NSAP RRs                     June 1994


   *  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.

   *  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

5.1  Additional Section Processing