next rev of "DNS NSAP Resource Records" for review and comment Tue, 19 April 1994 16:33 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa05713; 19 Apr 94 12:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05709; 19 Apr 94 12:33 EDT
Received: from by CNRI.Reston.VA.US id aa09297; 19 Apr 94 12:33 EDT
Received: from by IETF.CNRI.Reston.VA.US id aa05659; 19 Apr 94 12:30 EDT
Received: from by ( id KAA16653; Tue, 19 Apr 1994 10:29:02 -0600
Received: by ( id KAA20413; Tue, 19 Apr 1994 10:28:18 -0600
Received: from by ( id KAA20410; Tue, 19 Apr 1994 10:28:16 -0600
Received: from ENH.NIST.GOV by ( id KAA16329; Tue, 19 Apr 1994 10:28:02 -0600
Received: from by ENH.NIST.GOV (PMDF V4.2-13 #4653) id <01HBCXXCJZBK0043J6@ENH.NIST.GOV>; Tue, 19 Apr 1994 12:26:41 EDT
Received: from by (4.1/SMI-4.0-MHS-7.0) id AA00649; Tue, 19 Apr 94 12:28:46 EDT
Date: Tue, 19 Apr 1994 12:28:46 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Subject: next rev of "DNS NSAP Resource Records" for review and comment
Cc:,, IESG@CNRI.Reston.VA.US
Message-id: <>
Content-transfer-encoding: 7BIT


Here is the next version of the DNS NSAP RR document (pardon the
formatting nits -- I'll fix those in the "official" version).  I've
addressed all comments received as a result of the "last call" to the
satisfaction of the commentors, Bill, and me.  As a result of some of
these comments, Bill and I have concluded that the doc should go to
Experimental RFC under IPng rather than as a Proposed Standard (see the
discussion of additional section processing in the Comments List).
Speak now (within the next week or so) if you have any further comments
before we go the next step.


Comments List (not including editorial fixes):

1. need TTL units (Sec 5): added seconds as the TTL units in the bulleted

2. need additional section processing (Sec 5.1):  It was pointed out
	that, for TUBA, there are times when ASP is desirable,
	e.g., when querying for NS records for a server that
	is CLNP-only.  Since this ties the document to the
	IPng deliberations, it should be tracked as Experimental
	as are all the IPng-related RFCs.

3. change reverse mapping tree root (Sec 6):  Was .NSAP, now NSAP.INT.

4. reverse mapping suggested to be on byte boundaries (Sec 6):  It is
	forseeable that NSAP delegations will take place on nibble
	boundaries, since 1) they routinely take place on byte
	boundaries now, and 2) I've already seen addressing plans
	that divide NSAPs on nibble boundaries for internal
	routing purposes.  I convinced the commentor that this
	was reasonable, so nibble boundaries remain.

5. change NSAP RR Master File format (Sec 7):  the format for the
	RDATA field of an NSAP RR was a string of hex digits with
	interspersed "."s for readability.  A more generalized
	hex string format has now been introduced which is
	identical to what was there except that the hex string
	is preceded by "0x".


Network Working Group                           B. Manning (Rice University)
INTERNET DRAFT                                             R. Colella (NIST)
                                                             April xxx, 1994

                           DNS NSAP Resource Records
Status of This Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."

To learn the status of any Internet-Draft, please check the 1id-
abstract.txt listing contained in the Internet-Drafts Shadow Directories
on,,,, or

It is intended that this document will be submitted to the IESG for
consideration as a standards document. Distribution of this document is


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
RFC 1035 for a description of the PTR RR). This paper describes how PTR
RRs are used to support this translation.
INTERNET-DRAFT                                              April xxx, 1994

1   Introduction

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

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" [Cal92 ]. 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

Expires October xxx, 1994                                            [Page 2]
INTERNET-DRAFT                                                April xxx, 1994

registration authority and the DNS a publication method. For NSAPs,
addendum two of the network service definition, ISO8348/Ad2 [ISO88 ] 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 [ISO88 ], 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
[Gro91 ]. 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 [ISO84 ]). NIST defined
the subsequent fields in [Gro91 ], 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

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

Expires October xxx, 1994                                            [Page 3]
INTERNET-DRAFT                                                April xxx, 1994

           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.

transport protocol [ISO86a ] 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


and a full U.S. GOSIP NSAP might appear as


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 1237 [CGC91 ].

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.

Expires October xxx, 1994                                            [Page 4]
INTERNET-DRAFT                                                April xxx, 1994

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


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

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


Expires October xxx, 1994                                            [Page 5]
INTERNET-DRAFT                                                April xxx, 1994

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

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

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


would appear as*

[Implementation note: For sanity's sake user interfaces should be
designed to allow users to enter NSAPs using their natural order, i.e.,

Expires October xxx, 1994                                            [Page 6]
INTERNET-DRAFT                                                April xxx, 1994

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

;;;;;; Master File for domain

@      IN     SOA (
                                    1994041800  ; Serial  - date
                                    1800         ; Refresh - 30 minutes
                                    300          ; Retry    - 5 minutes
                                    604800       ; Expire  - 7 days
                                    3600 )       ; Minimum - 1 hour
       IN     NS
       IN     NS
;     hosts
bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
         IN  A
         IN  HINFO PC`486    BSDi1.1(TUBA)
bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
         IN  A
         IN  HINFO PC`486    BSDi1.1(TUBA)
cursive IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
         IN  A
         IN  HINFO PC`386    DOS`5.0/NCSA`Telnet(TUBA)
infidel IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
         IN  A
         IN  HINFO PC/486    BSDi1.0(TUBA)

Expires October xxx, 1994                                            [Page 7]
INTERNET-DRAFT                                                April xxx, 1994

;     routers
cisco1  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
         IN  A
         IN  A
         IN  A
3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
         IN  A
         IN  A
         IN  A
;;;;;; Master File for reverse mapping of NSAPs under the
;;;;;;     NSAP prefix:
;;;;;;          47.0005.80.005a00.0000.0001.e133

@      IN     SOA (
                                    1994041800  ; Serial  - date
                                    1800         ; Refresh - 30 minutes
                                    300          ; Retry    - 5 minutes
                                    604800       ; Expire  - 7 days
                                    3600 )       ; Minimum - 1 hour
       IN     NS
       IN     NS
$ORIGIN    3.3.1.e.
;  IN    PTR
;  IN    PTR
;  IN    PTR
;  IN    PTR
;  IN    PTR
;  IN    PTR

8   Security

Security issues are not addressed in this memo.

Expires October xxx, 1994                                            [Page 8]
INTERNET-DRAFT                                                April xxx, 1994

9   Authors' Addresses

Bill Manning
Rice University -- ONCS
P.O. Box 1892
6100 South Main
Houston, Texas 77251-1892

Phone: +1.713.285.5415
Richard Colella
National Institute of Standards and Technology
Gaithersburg, MD 20899

Phone: +1 301-975-3627 (voice); +1 301 590-0932 (fax)

[Cal92]   R. Callon.  TCP and UDP with Bigger Addresses (TUBA), A Simple
          Proposal for Internet Addressing and Routing.  RFC 1347, Network
          Working Group, June 1992.

[CGC91]   R. Colella, E. Gardner, and R. Callon.  Guidelines for OSI NSAP
          Allocation In The Internet.  RFC 1237, Network Working Group,
          July 1991.

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

[ISO84]   ISO/IEC.  Data interchange - structures for the identification
          of organization.  International Standard 6523, ISO/IEC JTC 1,
          Switzerland, 1984.

[ISO86a]  ISO/IEC.  Connection oriented transport protocol specification.
          International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.

[ISO86b]  ISO/IEC.  Protocol for Providing the Connectionless-mode
          Network Service.  International Standard 8473, ISO/IEC JTC 1,
          Switzerland, 1986.

Expires October xxx, 1994                                            [Page 9]
INTERNET-DRAFT                                                April xxx, 1994

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

[Moc87a]  P. Mockapetris.  Domain name -- concepts and facilities.  RFC
          1034, Network Working Group, November 1987.

[Moc87b]  P. Mockapetris.  Domain name -- implementation and specifica-
          tion.  RFC 1035, Network Working Group, November 1987.

Expires October xxx, 1994                                           [Page 10]