Network Working Group B. Manning (Rice University) INTERNET DRAFT R. Colella (NIST) May 7, 1993 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 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document 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 two new Resource Records (RRs) for the DNS, building upon earlier work in RFC 1348. This format may be used with any NSAP address format. Expiration Date November 7, 1993 [Page 1] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 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 DNS 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 two new Resource Records (RRs) for the DNS, building upon earlier work in RFC 1348. This format may be used with any NSAP address format. This memo assumes that the reader is familiar with the DNS. Some familiarity with NSAPs is useful; see [CGC91] or [ISO88] 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 a re- placement for IP: "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" [Cal92]. Should this pro- posal be selected, the DNS must be capable of supporting CLNP addresses. 3 Scope The RRs defined in this paper support all known 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. B. Manning/R. Colella [Page 2] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 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, 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. Accommodation of this distributed authority requires flexibility in the DNS inverse mapping of NSAPs to names, allowing sub-authorities to represent the substructure they define, if any, in the DNS as well as the NSAP values themselves. While all NSAP structures currently known to be in use in the Internet have fixed field sizes (e.g., [CGC91, Bry92]), some NSAP formats defined in ISO8348/Ad2 define one of the fields as variable-sized. These formats are still parsable, since the total NSAP length is known and there is, at most, one variable-sized field. These formats are accommodated in this document, even though there is no current requirement. For the purposes of this memo, NSAPs can be thought of as a tree of identifiers. The root of the tree is defined in 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 US GOSIP defines NSAPs [GOSIP]. Under the AFI of 47, NIST (National Institute of Standards and Technol- ogy) 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 [GOSIP], as shown in Figure 1. The field immediately following 0005 is a format identifier for the rest of the US GOSIP NSAP structure, with a hex value of 80. Following this is the three-octet field, values for B. Manning/R. Colella [Page 3] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 which are allocated to network operators; the registration authority for this field is delegated to GSA (General Services Administration). _______________ |_<--_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. 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 will 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. In the event that CLNP is used to support TCP and UDP services, the NSel value used will be 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 [ISO86a] in addition to TCP/UDP will select NSels for use by OSI Transport that do not conflict with the IP PROTO values. In Master Files and in the printed text in this memo, NSAPs are 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, GOSIP, ANSI, etc.). The use of this notation is strictly for readability. The "."s do B. Manning/R. Colella [Page 4] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 not appear in DNS packets. For example, a printable representation of the first four fields of a US GOSIP NSAP might look like 47.0005.80.005a00 and a full US GOSIP NSAP might appear as 47.0005.80.005a00.0000.1000.0020.00800a123456.00. For more information on US GOSIP NSAPs, see RFC1237 [CGC91]. Other NSAP formats have different fields and field widths (see [Bry92]). 5 The NSAP RR The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 (decimal). 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 DNS 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 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ B. Manning/R. Colella [Page 5] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 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 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 NSAP RRs cause no additional section processing. 6 The NSAP-PTR RR [Editors' note: the inverse mapping function is for further study. The current thinking is that NSAP structure information is stored with NSAP prefixes in Master Files and returned with queries on NSAP prefixes. Exactly how this works needs to be given more thought.] B. Manning/R. Colella [Page 6] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 7 Master File Format The format of NSAP RRs in Master Files conforms to Section 5, "Master Files," of RFC 1035. Below is an example of the use of NSAP RR in a Master File. [Note: the format of NSAP-PTR RRs in Master Files is for further study.] ;;;;;; ;;;;;; Master File for domain tuba.ncsl.nist.gov. ;;;;;; @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( 900831 ; Serial - date 1800 ; Refresh - 30 minutes 300 ; Retry - 5 minutes 604800 ; Expire - 7 days 3600 ) ; Minimum - 1 hour IN NS emu.ncsl.nist.gov. ; ; $ORIGIN tuba.ncsl.nist.gov. ; emu IN NSAP 47.0005.80.005a00.0000.0001.e137.08002010726e.00 IN A 129.6.55.32 IN HINFO Sun_Sparc SunOS_4.1.3 ; osi IN NSAP 47.0005.80.005a00.0000.0001.e137.080020079efc.00 IN A 129.6.55.1 ; cursive IN NSAP 47.0005.80.005a00.0000.0001.e137.eeeeee000085.00 IN A 129.6.224.85 IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA) ; cisco1 IN NSAP 47.0005.80.005a00.0000.0001.e137.888888000181.00 IN A 129.6.224.181 ; 3com1 IN NSAP 47.0005.80.005a00.0000.0001.e137.111111000111.00 IN A 129.6.225.111 B. Manning/R. Colella [Page 7] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 8 Resolving NSAP-PTR Queries [Editors' note: this section is still very drafty. It's predicated on the idea of embedding the NSAP structure information in the Master Files with the RRs for NSAP prefixes.] The NSAP-PTR RR is defined with mnemonic "NSAP-PTR" and TYPE code 23 (decimal). It's function is analogous to the PTR record used for IP addresses [Moc87b], although the details of how it operates are different. NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse lookup for IP addresses due to the structure of NSAPs and the require- ments this places on the lookup process. The NSAP-to-name scheme operates with minimal a priori knowledge of how NSAPs are structured and operates according to a simple algorithm. Given an NSAP to be resolved, the only a priori information needed is that the first field of all NSAPs is one octet. The basic algorithm operates as follows: 1. build an initial query to read the record associated with the first octet. 2. knowledge of the NSAP structure is not complete, so set (COMPL-KNOW = FALSE). 3. send the query. 4. when the response is returned, if (COMPL-KNOW == TRUE), done. 5. construct a more detailed query with the additional structure information from the response. 6. if the structure information returned in step 4 ends with a ".", then set (COMPL-KNOW = TRUE). 7. go to step 3. The a priori knowledge required is that all NSAPs begin with an initial one-octet field, the AFI (Authority and Format Identifier, see [ISO88]); this is captured in step 1. Steps 3 through 7 represent a simple learning algorithm in which the resolver issues queries that are increasingly detailed until the result is obtained. B. Manning/R. Colella [Page 8] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 Successful termination, step 4, occurs if the last query sent was based on complete NSAP structure information, as determined by the trailing ".". 9 Security Security issues are not addressed in this memo. 10 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 (voice); +1 301 590-0932 (fax) EMail: colella@nist.gov A. Issues A number of issues remain to be addressed. A.1 Relationship to X.500 It may be useful to associate an X.500 distinguished name with an NSAP. Some thought should be given to whether this is useful and how it could be done. B. Manning/R. Colella [Page 9] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 A.2 NSAP prefixes Should NSAP prefixes be encoded in the DNS? This may have some useful features. References [Bry92] P. Bryant. NSAPs. IPTAG/92/23 PB660, Science and Engineering Research Council, Rutherford Appleton Laboratory, May 1992. [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, IETF OSI NSAP Administration Working Group, July 1991. [GOSIP] GOSIP Advanced Requirements Group. Government Open Systems Interconnection Profile (GOSIP) Version 2 [final text]. Fed- eral Information Processing Standard, U.S. Department of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, (Pending Publication). [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. [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. B. Manning/R. Colella [Page 10] INTERNET-DRAFT DNS NSAP Resource Records May 7, 1993 [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. Expiration Date November 7, 1993 [Page 11]