RFC 1637

DNS NSAP Resource Records 🎀

Okay bestie, this one's from June 1994 and it's by B. Manning (Rice University) and R. Colella (NIST) 🧚 It's an Experimental doc, not a standard, and it obsoletes RFC 1348 💅 It's all about getting NSAP addresses into the DNS so CLNP can be debugged without a sad little hosts.txt file 🦋

Status of this Memo ✨

This memo defines an Experimental Protocol for the Internet community. It 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 toward OSI lower-layer infrastructure, which means the connectionless network protocol (CLNP) and its routing protocols. The DNS also needs to map names to NSAP addresses for this to work, so this doc defines one new Resource Record (RR) for domain name-to-NSAP mapping 💖 The RR can be used with any NSAP address format. This document supercedes RFC 1348.

NSAP-to-name translation uses the PTR RR (see STD 13, RFC 1035 for the PTR RR). This paper explains how PTR RRs get used for that 🔥

1. Introduction 🌈

The Internet is moving toward OSI lower-layer infrastructure: CLNP [6] plus supporting routing protocols. The DNS [8] [9] also needs to map domain names to OSI Network Service Access Point (NSAP) addresses [7]. [Note: NSAP and NSAP address are used interchangeably throughout this memo].

This doc defines one new Resource Record (RR) for the DNS, for domain name-to-NSAP mapping. It works with any NSAP address format 🧚

NSAP-to-name translation uses the PTR RR (see RFC 1035 for the PTR RR), and this paper shows how PTR RRs help with it ✨

This memo assumes you already know the DNS. Some NSAP knowledge helps too; see [2] or [7] for more info 🫶

2. Background 🍓

So why do we want DNS mappings for NSAPs? To support CLNP on the Internet 💅 Debugging CLNP with ping and traceroute gets harder when you only have numeric NSAPs and the deployment keeps growing 😭 Right now people keep a configuration file of name/NSAP mappings, kind of like hosts.txt. The problem is there's no central coordinator for it, and it doesn't scale. The lack of a coordinator is the bigger short-term problem. A hosts.txt-style solution has well-known long-term scaling difficulties.

There's a second reason too. The proposal "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" [1] wants to use CLNP as an alternative to IP 👑 For that to be practical, the DNS has to be able to support CLNP addresses. 🦋

3. Scope 🎀

The methods here apply to all NSAP formats. That includes custom-defined NSAP formats based on an AFI obtained by the IAB for use in the Internet 💖

Quick reference: there's a difference between registering addresses and publishing them. For IP addresses, the IANA is the root registration authority and the DNS is the 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 hierarchical so administration can be distributed and routing stays efficient 💅 Distributed administration lets delegated addressing authorities further structure their part of the NSAP space, as the delegator allows. Because of that, DNS resolvers and servers shouldn't need much (or any) built-in knowledge of NSAP structure ahh, that's the vibe 🙈

For this memo, you can think of NSAPs as a tree of identifiers. The root is ISO8348/Ad2 [7], and its immediately registered subordinates are the one-octet Authority and Format Identifiers (AFIs) defined there. The size of later fields depends on which branch you take, and the depth of the tree depends on whichever authority defines the later fields 🌈

Here's an example: the authority under which U.S. GOSIP defines NSAPs [3]. Under AFI 47, NIST (National Institute of Standards and Technology) got the value 0005. The AFI 47 defines the next field as two octets made of four BCD digits from the International Code Designator space [4]. NIST defined the later fields in [3], shown in Figure 1 ✨ The field right after 0005 is a format identifier for the rest of the U.S. GOSIP NSAP structure, with hex value 80. After that is a three-octet field whose values get allocated to network operators. Registration authority for that 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 system, and the NSel identifies the CLNP user. There can be more than one CLNP user, which means multiple NSel values for one "base" NSAP. So the NSAP representation should be CLNP-user independent 🫶 To do that, 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. The application retrieving the NSAP figures out which value to use for that particular communication 💖

          |--------------|
          | <-- 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 supports TCP and UDP services, the NSel value is the appropriate IP PROTO value registered with the IANA 🦋 For "standard" OSI, picking NSel values is left to local administration. Admins of systems that run the OSI transport protocol [5] alongside TCP/UDP must pick OSI Transport NSels that don't conflict with the IP PROTO values 🚨

In NSAP RRs in Master Files and in the printed text here, NSAPs often show up as a string of "."-separated hex values 🍓 Those values match convenient divisions of the NSAP, so the fields might line up with what the authority defines (ISOC, RARE, U.S. GOSIP, ANSI, etc.). The dots are purely for readability. They don't show up in DNS packets, and DNS servers can ignore them when reading Master Files. For example, 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 look like:

47.0005.80.005a00.0000.1000.0020.00800a123456.00.

Other NSAP formats have different lengths and different admin-defined field widths for their own needs. For more on NSAP formats in use, see RFC 1629 [2] 🌸

5. The NSAP RR 💜

The NSAP RR has the mnemonic "NSAP" and TYPE code 22 (decimal). It maps domain names to NSAPs. Name-to-NSAP mapping in the DNS with the NSAP RR works the same way as IP address lookup. The resolver generates a query asking for an NSAP RR for a given domain name 🧚

NSAP RRs follow the top-level RR format and semantics 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 this resource record is about. 🫶
• TYPE: two octets holding the NSAP RR TYPE code, 22 (decimal). 💅
• CLASS: two octets holding the RR IN CLASS code, 1. 🎀
• TTL: a 32-bit signed integer for how many seconds the resource record may be cached before the source of the information should be consulted again ⏰ A zero value means the RR can only be used for the transaction in progress and should not be cached. For example, SOA records always get distributed with a zero TTL so they can't be cached. Zero can also be used for extremely volatile data 🙈
• RDLENGTH: an unsigned 16-bit integer for the length in octets of the RDATA field. 📏
• RDATA: a variable-length string of octets holding the NSAP. The value is the binary encoding of the NSAP as it would appear in the CLNP source or destination address field. Here's a typical example (in hex). For this NSAP, RDLENGTH is 20 (decimal). The dots are left out to show they don't appear in DNS packets 🦋

39840f80005a0000000001e13708002010726e00

(part 2 coming bestie, don't go anywhere 💖)

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

okay so this bit is needed to make the whole TUBA picture complete 🎀 but for now, name servers joining TUBA demos MAY ELECT to do this. It SHOULD NOT be the default, because the IPng sweepstakes are still up in the air and truncation (and some other stuff) needs more thought 💅

RFC 1035 explains the additional section processing (ASP) that servers have to do when they run into NS records during query processing. Here's what Section 3.3.11, "NS RDATA format", says:

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, the same ASP is needed on type NSAP records, so that servers and resolvers using CLNP can find what they need. They might prefer CLNP, or it might be the only internetworking protocol they've got (aka no IPv4) 🫶 So NS records trigger ASP that looks up a type NSAP record in addition to a type A record. Both type A and NSAP records should be returned, if available ✨

6. NSAP-to-name Mapping Using the PTR RR 🧚

The PTR RR is defined in RFC 1035. You usually see it under the IN-ADDR.ARPA domain, where it maps IPv4 addresses to domain names.

Same energy here: the PTR RR also maps NSAPs to domain names, but under the NSAP.INT domain. The domain name gets generated from the NSAP using the rules below, and then the resolver sends a query asking for a PTR RR for that domain name 💜

A domain name is generated from an NSAP by reversing the hex nibbles of the NSAP, treating each nibble as its own subdomain, and then tacking the top-level subdomain name NSAP.INT onto the end. For example, the reverse lookup domain name for this NSAP:

47.0005.80.005a00.0000.0001.e133.ffffff000162.00

would look like this:

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 follows Section 5, "Master Files," of RFC 1035. Below are some examples of using these RRs in Master Files to support name-to-NSAP and NSAP-to-name mapping, and they're honestly so pretty 🌸

The NSAP RR brings in a new hex string format for the RDATA field. It starts with "0x" (a zero followed by an 'x' character), then a variable length string of hex characters (0 to 9, a to f). The hex string is case-insensitive. You can drop "."s (periods) anywhere after the "0x" for readability. Those dots don't mean anything beyond readability, and they don't get sent over the protocol (so not in queries or zone transfers either) 🦋

Here's the master file for the nsap.nist.gov domain:

;;;;;;
;;;;;; 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

;;;;;;
;;;;;; 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. 🙈

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.

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