INTERNET DRAFT M. A. Patton Expiration Date: October 1995 BBN June 1995 DNS Resource Records for Nimrod Routing Architecture 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires December 1995. Abstract This document describes two additional RR types for the Domain Name System[7,8] required to implement the Nimrod Routing Architecture[1]. These RRs record the Nimrod Locator and an Endpoint Identifier (EID) associated with a given Domain Name. Introduction Nimrod is a scalable internetwork routing architecture. The Nimrod architecture is designed to accommodate an internetwork of arbitrary size and with heterogeneous service requirements and restrictions and to admit incremental deployment throughout an internetwork. The key to Nimrod's scalability is its ability to represent and manipulate routing-related information at multiple levels of abstraction. To do this efficiently, Nimrod separates the identification of communicating entities (Endpoints) from any topological information. Endpoint Identifiers (EIDs) are used to specify and uniquely identify entities connected to the network. Information about the topological location of an endpoint in the network is given by a Locator, which may change as the network topology changes. During the initial deployment of the Nimrod system the mapping will be stored in the existing DNS system as two additional RRs on the Domain Name of the Endpoint. This document describes the two new RR types required to record this information. Nimrod uses a hierarchy of abstract maps of (parts of) the network. A Locator is a topologically significant "name" for a Nimrod node, indicating where in the map hierarchy it can be found. Because it reflects location in the network, a node's Locator will change when the network topology changes. An EID is a short identifier for the endpoint of a communication (e.g. a host system) and has no structure or significance other than global uniqueness. An endpoint can retain the same EID forever, no matter where in the network it is located. Any given system has exactly one EID to identify it, but may have more than one Locator if it appears in multiple maps. Updates of the EID and the Locator information will almost always be done through a Dynamic Update[2] protocol, triggered by normal Nimrod protocol operations. Except during testing, these will not be done by manual editing of a master file, which means that human readability is not a major concern. 1. definition of the RR types Both of the RR types described in this document encode numbers whose structure (if any) is not meaningfully interpreted by the DNS system. Thus each is encoded as an uninterpreted string of octets. The interpretation of the values is described in the Nimrod protocol spec [[[TBD]]]. 1.1. The EID (Endpoint Identifier) RR The EID (Endpoint IDentifier) RR is defined with mnemonic "EID" and TYPE code 31 (decimal) and is used to map from domain names to EIDs. The EIDs declared in this RR may be used by any system that uses Endpoint Identifiers, but the initial use is intended for the Nimrod Routing system. EIDs are short, fixed length strings of octets whose content is meaningful to the Nimrod routing system. Since the top level RR format and semantics as defined in Section 3.2.1 of RFC 1035 include a length indicator, the Domain Name System is not required to understand any internal structure. An Endpoint can only have one unique identifier, so multiple different EID RRs at the same DNS name is an error. There are three ways to interpret such a condition when returned. If the conflict occurs when a reply is received from the authoritative server, that should be used and the existing (cached) RR should be discarded. The simplest, but less sure, way to deal with non-authoritative conflict is to ignore the RRs with the smaller TTL and use the one with the longest remaining Time To Live. Secondly, the query can be retried at the authoritative server, with the result replacing the erroneous info as per the first item. Any caching server which is cognizant of EIDs should retain at most one EID RR as determined above, but legacy servers may not handle this requirement, so any system that needs to make use of EIDs must handle the conflict resolution described. The format of an Endpoint IDentifier (EID) RR is: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE = EID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS = IN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: * NAME: an owner name, i.e., the name of the DNS node to which this resource record pertains. * TYPE: two octets containing the EID RR TYPE code of 31 (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. * RDLENGTH: an unsigned 16 bit integer that specifies the length in octets of the RDATA field. * RDATA: a string of octets containing the Endpoint Identifier. The value is the binary encoding of the Identifier, meaningful only to the system utilizing it. 1.2. The NIMLOC (Nimrod Locator) RR The NIMLOC (Nimrod Locator) RR is defined with mnemonic "NIMLOC" and TYPE code 32 (decimal) and is used to map from domain names to Nimrod Locators. Nimrod Locators are possibly variable length strings of octets whose content is only meaningful to the Nimrod routing system. Since the top level RR format and semantics as defined in Section 3.2.1 of RFC 1035 include a length indicator, the Domain Name System is not required to understand any internal structure. A Nimrod system may have any number of Locators associated with it. They are in this sense like A and AAAA RRs for IPv4 and IPv6 addresses. Multiple NIMLOC RRs with the same NAME, CLASS and RDATA are the same and can be merged in a cache, retaining only the highest TTL. The format of a Nimrod Locator (NIMLOC) RR is: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE = NIMLOC | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS = IN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: * NAME: an owner name, i.e., the name of the DNS node to which this resource record pertains. * TYPE: two octets containing the NIMLOC RR TYPE code of 32 (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. * 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 Nimrod Locator. The value is the binary encoding of the Locator specified in the Nimrod protocol[[[ref to be supplied]]]. 2. Additional Section Processing DNS servers cognizant of EID and NIMLOC type RRs should return these records in the Additional Section of any response including an A or AAAA type RR. These could be in response to either A or AAAA type queries, or some other query (e.g. NS) that specifies A and/or AAAA records in the Additional Section. This is not required for operation of the Nimrod system, as additional queries can always be made, but, in general, any time an A or AAAA RR will be used by a Nimrod agent, it will also need the EID and Locator info. 3. Master File Format The format of NIMLOC and EID RRs follows all the rules of RFC 1035, Section 5, "Master Files." The RDATA portion of both the NIMLOC and EID records contains uninterpreted binary data. The representation in the text master file is an even number of hex characters (0 to 9, a to f), case is not significant. Example master file with NIMLOC and EID RRs (based on the example in RFC1035): @ IN SOA VENERA Action\.domains ( 20 ; SERIAL 7200 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS A.ISI.EDU. NS VENERA NS VAXA MX 10 VENERA MX 20 VAXA A A 26.3.0.103 EID E32C6F78163A9348 NIMLOC 32251A030067 VENERA A 10.1.0.52 A 128.9.0.32 EID 813F4B7CDAB34217 NIMLOC 3227450A010034 NIMLOC 75234159EAC457800920 VAXA A 10.2.0.27 A 128.9.0.33 EID 3141592653589793 NIMLOC 75234159EAC457800921 4. Acknowledgements I'd like to thank the members of the DNS and Nimrod mailing lists for their comments and suggestions, and to the Nimrod Architects for the documents on which this is based. I'd also like to thank Arnt Gulbrandsen for his collected list of DNS RFCs and permission to use it as the basis for the References section and Bill Manning, the author of RFC1348, for unwittingly supplying the boilerplate and diagrams I used as a basis for this document. Specific thanks to Robert Elz, Masataka Ohta, and Martha Steenstrup for their helpful comments on early drafts. [[[ more? ]]]. 5. Security Considerations Security issues are not discussed in this memo. 6. References [1] draft-ietf-nimrod-routing-arch-00.txt: I. Castineyra, J. N. Chiappa, M. Steenstrup, "The Nimrod Routing Architecture", March 1995 [2] draft-ietf-dnsind-dynDNS-01.txt: S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain Name System", March 1995 [3] RFC 1536: A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller, "Common DNS Implementation Errors and Suggested Fixes.", 10/06/1993. [4] RFC 1348: B. Manning, "DNS NSAP RRs", 07/01/1992. [5] RFC 1183: R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart, "New DNS RR Definitions", 10/08/1990. [6] RFC 1101: P. Mockapetris, "DNS encoding of network names and other types", 04/01/1989. [7] RFC 1035: P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. [8] RFC 1034: P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. [9] RFC 1033: M. Lottor, "Domain administrators operations guide", 11/01/1987. [10] RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987. [11] RFC 974: C. Partridge, "Mail routing and the domain system", 01/01/1986. 7. Authors' Address: Michael A. Patton Bolt Beranek and Newman 10 Moulton Street Cambridge, MA, 02138 Phone: (617) 873 2737 FAX: (617) 873 3457 Email: map@bbn.com This Internet Draft expires December 1995