GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1637

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

 [The specification in this section is necessary for completeness in
 describing name server support for TUBA. For the time being, name
 servers participating in TUBA demonstrations MAY ELECT to implement
 this behavior; it SHOULD NOT be the default behavior of name servers
 because the IPng sweepstakes are still outstanding and further
 consideration is required for truncation and other issues.]
 RFC 1035 describes the additional section processing (ASP) required
 when servers encounter NS records during query processing. From
 Section 3.3.11, "NS RDATA format":
    NS records cause both the usual additional section processing to
    locate a type A record, and, when used in a referral, a special
    search of the zone in which they reside for glue information.
 For TUBA, identical ASP is required on type NSAP records to support
 servers and resolvers that use CLNP, either because of preference or
 because it is the only internetworking protocol available (i.e., in
 the absense of IPv4). Thus, NS records cause ASP which locates a type
 NSAP record in addition to a type A record. Both type A and NSAP
 records should be returned, if available.

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

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

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

 ;;;;;;
 ;;;;;; 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(TUBA)
 ;
 bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
          IN  A      129.6.224.162
          IN  HINFO PC_486    BSDi1.1(TUBA)
 ;
 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
          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

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

 ;;;;;;
 ;;;;;; 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 9] RFC 1637 DNS NSAP RRs June 1994

9. Authors' Addresses

 Bill Manning
 Rice University -- ONCS
 P.O. Box 1892
 6100 South Main
 Houston, Texas 77251-1892
 USA
 Phone: +1.713.285.5415
 EMail: bmanning@rice.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] Callon R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
     Proposal for Internet Addressing and Routing", RFC 1347, DEC,
     June 1992.
 [2] 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.
 [3] 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.
 [4] ISO/IEC.  Data interchange - structures for the identification of
     organization.  International Standard 6523, ISO/IEC JTC 1,
     Switzerland, 1984.
 [5] ISO/IEC. Connection oriented transport protocol specification.
     International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.

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

 [6] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
     Service.  International Standard 8473, ISO/IEC JTC 1,
     Switzerland, 1986.
 [7] ISO/IEC. Information Processing Systems -- Data Communications --
     Network Service Definition Addendum 2: Network Layer Addressing.
     International Standard 8348/Addendum 2, ISO/IEC JTC 1,
     Switzerland, 1988.
 [8] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
     13, RFC 1034, USC/Information Sciences Institute, November 1987.
 [9] Mockapetris, P., "Domain Names -- Implementation and
     Specification", STD 13, RFC 1035, USC/Information Sciences
     Institute, November 1987.

Manning & Colella [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1637.txt · Last modified: 1994/06/08 20:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki