INTERNET-DRAFT "Internet Protocol Five Fields - Domain Name System extensions", Alexey Eromenko, 2015-12-10, expiration date: 2016-06-10 Intended status: Standards Track A.Eromenko December 2015 DNS Extensions to Support IP Version 5 (a.k.a Internet Protocol "Five Fields") Specification Draft Abstract This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 5 (IPFF). The changes include a resource record type to store an IPFF address, a domain to support lookups based on an IPFF address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 9, 2014. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. New resource record definition and domain. . . . . . . . . . . 2 2.1. AA record type . . . . . . . . . . . . . . . . . . . . . 3 2.2. AA data format . . . . . . . . . . . . . . . . . . . . . 3 2.3. AA query . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4. Textual format of AA records . . . . . . . . . . . . . . 3 2.5. Reverse Lookups and PTR records. . . . . . . . . . . . . 3 3. Modifications to existing query types. . . . . . . . . . . . . 4 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Contacts . . . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Current support for the storage of Internet addresses in the Domain Name System (DNS) cannot easily be extended to support IPFF addresses [IPFF-Addressing-RFC-draft] since applications assume that address queries return 32-bit IPv4 or 128-bit IPv6 addresses only. To support the storage of IPFF addresses in the DNS, this document defines the following extensions: o A resource record type is defined to map a domain name to an IPFF address. o A domain is defined to support lookups based on address. o Existing queries that perform additional section processing to locate IPFF addresses are redefined to perform additional section processing on both IPv4 and IPFF addresses. The changes are designed to be compatible with existing software. The existing support for IPv4 addresses is retained. The IP protocol version used for querying resource records is independent of the protocol version of the resource records; e.g., IPv4 or IPv6 transport can be used to query IPFF records and vice versa. 2. New resource record definition and domain A record type is defined to store a host's IPFF address. A host that has more than one IPFF address must have more than one such record. AA explanation: "AA record" was chosen, as it mimics the idea behind "A" being a 32-bit value of IPv4, compared to "AAAA" (Quad A) being a 128-bit value of IPv6. Since internal representation of 50-bit addresses in IPFF are pre-padded to full 64-bits, double A, or "AA" seems appropriate. The proposed draft value is to be determined... 2.1 AA record type The AA resource record type is a record specific to the Internet class that stores a single IPFF address. 2.2 AA data format A 50 bit IPFF address is encoded in the data portion of an AA resource record in network byte order (high-order byte first), pre-padded by a set of 14-bit zeros, forming an internal 64-bit data structure. 2.3 AA query An AA query for a specified domain name in the Internet class returns all associated AA resource records in the answer section of a response. A type AA query does not trigger additional section processing. 2.4 Textual format of AA records The textual representation of the data portion of the AA resource record used in a master database file is the textual representation of an IPFF address as defined in [IPFF-Addressing-RFC-draft]. 2.5 Reverse Lookups and PTR records A special domain is defined to look up a record given an IPFF address. The intent of this domain is to provide a way of mapping an IPFF address to a host name, although it may be used for other purposes as well. The domain is proposed to be IP5.ARPA. An IPFF address is represented as a name in the IP5.ARPA domain by a sequence of decimal digits separated by dots with the suffix ".IP5.ARPA". The sequence of digits is encoded in reverse order, i.e., the low-order digit is encoded first, followed by the next low-order digit and so on. For example, the reverse lookup domain name corresponding to the address 382.21.968.2.133 would be 3.3.1.2.0.0.8.6.9.1.2.0.2.8.3.IP5.ARPA 3. Modifications to existing query types All existing query types that perform type A additional section processing, i.e., name server (NS), location of services (SRV) and mail exchange (MX) query types, must be redefined to perform both type A and type AA additional section processing. These definitions mean that a name server must add any relevant IPv4 addresses and any relevant IPFF addresses available locally to the additional section of a response when processing any one of the above queries. 4. Security Considerations This specification is not believed to cause any new security problems, nor to solve any existing ones. Acknowledgments Thanks to all previous DNS and DNSv6 developers, paricularly those people, "Susan Thomson", "Christian Huitema", "Vladimir Ksinant", "Mohsen Souissi", whom written RFC-3596 (DNSv6). Authors' Contacts Alexey Eromenko Israel Skype: Fenix_NBK_ EMail: al4321@gmail.com INTERNET-DRAFT Alexey expiration date: 2016-06-10