Network Working Group C. Huitema (INRIA) INTERNET-DRAFT S. Thomson (Bellcore) October 1993 Extensions to DNS to support 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 SIPP is an internet protocol intended as the replacement for IP version 4. SIPP addresses differ from IP addresses in that they are at least 64 bits long and may be extended in multiples of 64 bits. This specification describes the modifications that need to be made to DNS to store SIPP addresses and to support the transition from use of IP to use of SIPP. 1. INTRODUCTION SIPP is an internet protocol intended as the replacement for IP ver- sion 4. SIPP addresses differ from IP addresses in that they are at least 64 bits long and may be extended in multiples of 64 bits. This specification describes the modifications that need to be made to DNS to store SIPP addresses and support the transition from use of IP to SIPP WG, Expires April 30, 1994 [Page 1] INTERNET-DRAFT SIPP DNS October 1993 use of SIPP. In this specification, we introduce a new resource record (RR) type to store a SIPP address and a new domain to form inverse lookups on an address. We also describe modifications to existing RR definitions and resolvers/applications to support IP, SIPP and dual-stack hosts during transition. The transition of DNS itself from being an IP- only service to supporting both IP and SIPP is also discussed. 2. Storing SIPP Addresses 2.1. ASEQ type value The ASEQ RR is a new Internet-specific RR added to store a SIPP address. Pending assignment by IANA, the provisional type value used is 64. 2.2. ASEQ data format SIPP addresses are encoded as a sequence of 64-bit words in the RDATA section of a record: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / ASEQ / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ASEQ One or more 64-bit words containing a SIPP address Hosts that have multiple SIPP addresses will have multiple ASEQ RRs. Type ASEQ RRs cause no additional section processing. The RDATA sec- tion of an ASEQ line in a master file is a SIPP address expressed in its textual format, yet to be defined. In this draft, an address is SIPP WG, Expires April 30, 1994 [Page 2] INTERNET-DRAFT SIPP DNS October 1993 written as a sequence of hex digits, separated by colons after every 4 digits, e.g. 0bcd:0000:1234:5678. 2.3. Inverse Domain A special domain is needed to map a SIPP address to a hostname. Pending assignment by IANA, the domain is provisionally rooted at SIPP-ADDR.ARPA. Domain names in the SIPP-ADDR.ARPA domain have a variable number of labels with suffix "SIPP-ADDR.ARPA". The low-order 32-bits of a SIPP address are represented by four labels, one per octet. The labels are expressed as a character string for a decimal value in the range 0-FF with leading zeroes omitted except in the case of a null value which is represented by a single zero. The higher order parts of the address have labels that represent two octets each. Each label is expressed as a character string for a hex value in the range 0-FFFF with leading zeroes omitted except in the case of a null value which is represented by a single zero. For example, an address in hex of 0bcd:0000:8060:2105 would be represented by 5.33.96.128.0.bcd.SIP-ADDR.ARPA 3. IP-to-SIPP Transition During transition, some hosts will have IP addresses only, others SIPP addresses only and others both addresses. DNS must support all three cases efficiently. Moreover, some name servers will have been modified to support SIPP and IP address records, and others not. This section discusses the modifications required to support the use of two different address spaces efficiently. It also discusses how tran- sition of the name service itself is expected to take place and the assumptions made about existing implementations for this to work. 3.1. Resolver/Application Extensions Since it is in general not known whether a host is IP or SIPP before SIPP WG, Expires April 30, 1994 [Page 3] INTERNET-DRAFT SIPP DNS October 1993 its address is looked up in DNS, resolvers or application alibraries must be modified to query for both types of address. This change affects both full-service resolvers and stub resolvers (or the appli- cation libraries that use them). In particular, full-service resolvers need to determine the SIPP or IP addresses of name servers to be contacted during a lookup. 3.2. Modifications to other RR types To enable efficient operation, all RR types that perform type A addi- tional section processing, i.e. NS, MX and MB record types, must be redefined to perform both type A and type ASEQ additional section processing. Additional section processing is thus useful whether a host named in one of these records has an IP address, a SIPP address or both. 3.3. DNS Transition During transition, there will be name servers modified to support both SIPP and IP address records and unmodified name servers that store IP addresses only. Any zone that has a SIPP host must have a name server that stores SIPP records. IP-only zones may or may not have a SIPP-modified name server. Parents of SIPP-modified name servers should be converted to store SIPP address records as quickly as possible (if they have not been converted already) so that they cache these records when the opportunity arises. 3.4. Assumptions Made This transition scheme assumes existing IP name servers have been implemented to accept requests for RR types that they do not recog- nize, and that IP resolvers ignore all RR types received that they do not understand. In particular, an unmodified resolver that receives a SIPP address as part of additional section processing should ignore it. SIPP WG, Expires April 30, 1994 [Page 4]