SIPP Working Group S. Thomson (Bellcore) INTERNET-DRAFT C. Huitema (INRIA) March 1994 DNS Extensions to support Simple Internet Protocol Plus (SIPP) 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." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document defines the changes that need to be made to the Domain Name System to support hosts running Simple Internet Protocol Plus (SIPP). A new resource record type is defined to store a SIPP address sequence and a new inverse lookup domain is used to store the inverse mapping. The definitions of existing query types that return Internet addresses as part of additional section processing are also updated. The extensions are intended to be compatible with existing applications and name server/resolver implementations. SIPP WG, Expires September 30, 1994 [Page 1] INTERNET-DRAFT SIPP DNS March 1994 1. INTRODUCTION Unlike an IPv4 host, a SIPP host[SIPP-SPEC] has a sequence of addresses, each 64 bits long[SIPP-ROAD]. Current support for the storage of Internet addresses in the Domain Name System (DNS)[RFC1034, RFC1035] is IPv4-specific, and existing name server/resolver implementations and applications assume type A queries return 32-bit IPv4 addresses. To ensure compatibility with existing software, we retain the current resource record for storing an IPv4 address, and define a new resource record type to map a domain name to a SIPP address sequence. We also define a new domain to store the inverse mapping. In addition, to ensure continued effi- cient operation, existing queries that return IPv4 addresses as part of additional section processing are updated to return SIPP address sequences as well. 2. NEW RESOURCE RECORD DEFINITION AND INVERSE DOMAIN A new record type is defined to store a host's SIPP address sequence. A host that has more than one SIPP address sequence must have more than one such record. 2.1. ASEQ record type The ASEQ resource record type is a new record specific to the Inter- net class that stores a single SIPP address sequence. Pending assignment by IANA, the provisional value of the type is 64. 2.2. ASEQ data format A SIPP address sequence is encoded in the data portion of an ASEQ resource record as a sequence of 64-bit words. The low-order address in the sequence is represented first, as follows: SIPP WG, Expires September 30, 1994 [Page 2] INTERNET-DRAFT SIPP DNS March 1994 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADDRESS 0 | | | ----------------------------------------------------------------- | ADDRESS 1 | | | ----------------------------------------------------------------- | ADDRESS 2 | | | ----------------------------------------------------------------- / ... / / / ----------------------------------------------------------------- | ADDRESS n | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: ADDRESS i is the ith address in the address sequence. An address is encoded in network byte order (high-order byte first). 2.3. ASEQ query An ASEQ query for a specified domain name in the Internet class returns all ASEQ resource records mapped by the domain name in the answer section of a response. A type ASEQ query does not perform additional section processing. That is, no records are returned in the additional section of a response to an ASEQ query. SIPP WG, Expires September 30, 1994 [Page 3] INTERNET-DRAFT SIPP DNS March 1994 2.4. Textual format of ASEQ records The textual representation of the data portion of the ASEQ resource record used in a master database file is the textual representation of a SIPP address sequence as defined in [SIPP-ROAD]. The preferred form of a single 64-bit address is the hexadecimal representation, which is a sequence of four 16-bit hexadecimal values, separated by a colon. Leading zeroes may be omitted, except in the case of a null 16-bit value which is represented by a single zero, e.g. bcd:0:1234:5678. Addresses in an address sequence are separated by a double colon, e.g. a:b:c:d::e:f:0:1. An alternative textual format for the low-order address in an address sequence is to encode the low-order 32 bits in a similar way to an IPv4 address, that is, as four 8-bit decimal values separated by dots, and to encode the high- order 32 bits with the hexadecimal representation just described, e.g. a:b:128.96.41.1. 2.5. Inverse Domain A special domain is needed to map a SIPP address sequence to a host name. Pending assignment by IANA, the domain is provisionally rooted at SIPP-ADDR.ARPA. A SIPP address sequence is represented as a name in the SIPP- ADDR.ARPA domain by a sequence of 8-bit values separated by dots with the suffix ".SIPP-ADDR.ARPA". The sequence of 8-bit values is encoded in reverse order, i.e. the low-order byte is encoded first, followed by the next low-order byte and so on. Each 8-bit value is represented by a hexadecimal character string with leading zeroes omitted except in the case of a null value which is represented by a single zero. For example, the inverse lookup domain name correspond- ing to the address sequence bcd:0:8060:2105 would be SIPP WG, Expires September 30, 1994 [Page 4] INTERNET-DRAFT SIPP DNS March 1994 5.21.60.80.0.0.cd.b.SIPP-ADDR.ARPA. and aaaa:bbbb:cccc:dddd::ee:ff:0:1 would be 1.0.0.0.ff.0.ee.0.dd.dd.cc.cc.bb.bb.aa.aa.SIPP-ADDR.ARPA. 3. MODIFICATIONS TO OTHER RESOURCE RECORD DEFINITIONS All existing query types that perform type A additional section pro- cessing, i.e. name server (NS), mail exchange (MX) and mailbox (MB) query types, must be redefined to perform both type A and type ASEQ additional section processing. These new definitions mean that when any one of these queries is made, both IPv4 addresses (type A record) and SIPP address sequences (type ASEQ record) may be returned in the additional section of a response. This modification enables additional section processing to be useful whether a host named in one of these records has an IPv4 address, a SIPP address sequence or both. Note that additional section process- ing is not guaranteed to return complete information, e.g. records of one of the types may be returned, but not both (even if both exist). The addresses returned in the additional section by such queries must therefore be regarded as hint information. SIPP WG, Expires September 30, 1994 [Page 5] INTERNET-DRAFT SIPP DNS March 1994 4. TRANSITIONAL ISSUES The above modifications make some assumptions about existing name server and resolver implementations to ensure correct operation. In this section, we list the assumptions made, and also indicate when a name server should be upgraded to store SIPP address sequences. DNS, like other applications, must also be upgraded to use SIPP itself in communications with other hosts[SIPP-API], although this need not be done at the same time modifications are made to store SIPP address sequences. This section describes the algorithm SIPP- capable applications, such as a recursive resolver, should follow when looking up the Internet address of a destination using DNS. 4.1. Assumptions Made about Existing Implementations The proposed modifications to DNS are compatible with existing name server and resolver implementations under the following assumptions: 1. an existing name server has been implemented to accept requests for a record type that it does not recognize, e.g. ASEQ queries, and 2. an unmodified resolver ignores all record types received it does not understand, e.g. ASEQ records received in the additional section of a response. 4.2. Upgrading DNS to support SIPP Address Sequences In practice, all name servers in DNS cannot be upgraded at the same time; individual name servers will be upgraded to support SIPP address sequences as needed. A name server managing a particular domain should be upgraded to support SIPP address sequences by the time 1. the first host or name server in the domain becomes SIPP- capable. SIPP WG, Expires September 30, 1994 [Page 6] INTERNET-DRAFT SIPP DNS March 1994 2. the first name server in a delegated subdomain becomes SIPP- capable. Note that when a name server acquires a SIPP address sequence, both the name server itself should support the storage of SIPP address sequences as well as the parent name server, since both are responsi- ble for answering queries for the name server's address. 4.3. SIPP Application Interface To DNS During transition, hosts may have IPv4 addresses, SIPP address sequences or both[SIPP-IPAE]. Since a SIPP-capable application does not in general know, in advance of a DNS query, whether a destination is SIPP-capable or not, a host must be prepared to query for both types of address. If a destination has both a SIPP address sequence and an IPv4 address, the SIPP address sequence should be used in preference to the IPv4 address in communications. When using name server implementations that do not allow several queries to be made in a single message, a SIPP host should use the following algorithm to determine a destination address: 1. First, the host should make an ASEQ type query. If the ASEQ query returns an ASEQ record, the host should use address sequences in communications. 2. If no ASEQ records are found and the response is otherwise error-free, the host should make a type A query. If the A query returns an A record, the host should use IPv4 addresses in com- munications. 3. If no ASEQ or A records are found for the destination host, then communication setup fails. Note that, in particular, SIPP-capable name server/resolver implemen- tations should follow these rules when determining the addresses of other name servers during recursive query processing. SIPP WG, Expires September 30, 1994 [Page 7] INTERNET-DRAFT SIPP DNS March 1994 5. REFERENCES [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, USC/Information Sciences Institute, November 1987. [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specifica- tion", RFC 1035, USC/Information Sciences Institute, November 1987. [SIPP-SPEC] S.Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft, February 1994, . [SIPP-ROAD] S.Deering, P. Francis and R. Govindan, "Simple Internet Protocol Plus (SIPP): Routing and Addressing", Internet Draft, February 1994, . [SIPP-IPAE] Robert E. Gilligan, E. Nordmark, B. Hinden, "IPAE: The SIPP Interoperability and Transition Mechanism", Internet Draft, November 1993, [SIPP-API] Robert E. Gilligan, "SIPP Program Interface for BSD Systems", Internet Draft, December 1993, SIPP WG, Expires September 30, 1994 [Page 8]