idnits 2.17.1 draft-eromenko-ipff-dns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 213 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 181: '...ts), and DNS servers MUST enforce this...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2017-03-29) is 2585 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IPFF-Addressing-RFC-draft' on line 140 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol Five Fields - Domain Name System extensions", 3 Alexey Eromenko, 2016-09-29, 4 5 expiration date: 2017-03-29 7 Intended status: Standards Track 9 A.Eromenko 10 September 2016 12 DNS Extensions to Support IP Version 5 13 (a.k.a Internet Protocol "Five Fields") 14 Specification Draft 16 Abstract 18 This document defines the changes that need to be made to the Domain 19 Name System (DNS) to support hosts running IP version 5 (IPFF). The 20 changes include a resource record type to store an IPFF address, a 21 domain to support lookups based on an IPFF address, and updated 22 definitions of existing query types that return Internet addresses as 23 part of additional section processing. The extensions are designed 24 to be compatible with existing applications and, in particular, DNS 25 implementations themselves. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. New resource record definition and domain. . . . . . . . . . . 2 61 2.1. AA record type . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. AA data format . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. AA query . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.4. Textual format of AA records . . . . . . . . . . . . . . 3 65 2.5. Reverse Lookups and PTR records. . . . . . . . . . . . . 3 66 3. Modifications to existing query types. . . . . . . . . . . . . 4 67 4. Enforcing 999-per-field limit. . . . . . . . . . . . . . . . . 4 68 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 70 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 Authors' Contacts . . . . . . . . . . . . . . . . . . . . . . . . 7 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Current support for the storage of Internet addresses in the Domain 77 Name System (DNS) cannot easily be extended to support IPFF 78 addresses [IPFF-Addressing-RFC-draft] since applications assume that 79 address queries return 32-bit IPv4 or 128-bit IPv6 addresses only. 81 To support the storage of IPFF addresses in the DNS, this document 82 defines the following extensions: 84 o A resource record type is defined to map a domain name to an 85 IPFF address. 87 o A domain is defined to support lookups based on address. 89 o Existing queries that perform additional section processing to 90 locate IPFF addresses are redefined to perform additional 91 section processing on both IPv4 and IPFF addresses. 93 The changes are designed to be compatible with existing software. 94 The existing support for IPv4 addresses is retained. 96 The IP protocol version used for querying resource records is 97 independent of the protocol version of the resource records; e.g., 98 IPv4 or IPv6 transport can be used to query IPFF records and vice 99 versa. 101 2. New resource record definition and domain 103 A record type is defined to store a host's IPFF address. A host that 104 has more than one IPFF address must have more than one such record. 106 AA explanation: 108 "AA record" was chosen, as it mimics the idea behind "A" being a 109 32-bit value of IPv4, compared to "AAAA" (Quad A) being a 128-bit 110 value of IPv6. Since internal representation of 50-bit addresses in 111 IPFF are pre-padded to full 64-bits, double A, or "AA" seems 112 appropriate. 114 The proposed draft value is to be determined... 116 2.1 AA record type 118 The AA resource record type is a record specific to the Internet 119 class that stores a single IPFF address. 121 2.2 AA data format 123 A 50 bit IPFF address is encoded in the data portion of an AA 124 resource record in network byte order (high-order byte first), 125 pre-padded by a set of 14-bit zeros, forming an internal 64-bit data 126 structure. 128 2.3 AA query 130 An AA query for a specified domain name in the Internet class 131 returns all associated AA resource records in the answer section of 132 a response. 134 A type AA query does not trigger additional section processing. 136 2.4 Textual format of AA records 138 The textual representation of the data portion of the AA resource 139 record used in a master database file is the textual representation 140 of an IPFF address as defined in [IPFF-Addressing-RFC-draft]. 142 2.5 Reverse Lookups and PTR records 144 A special domain is defined to look up a record given an IPFF 145 address. The intent of this domain is to provide a way of mapping an 146 IPFF address to a host name, although it may be used for other 147 purposes as well. The domain is proposed to be IP5.ARPA. 149 An IPFF address is represented as a name in the IP5.ARPA domain by a 150 sequence of decimal digits separated by dots with the suffix 151 ".IP5.ARPA". The sequence of digits is encoded in reverse order, 152 i.e., the low-order digit is encoded first, followed by the next 153 low-order digit and so on. 155 For example, the reverse lookup domain name corresponding to the 156 address 158 382.21.968.2.133 160 would be 162 3.3.1.2.0.0.8.6.9.1.2.0.2.8.3.IP5.ARPA 164 3. Modifications to existing query types 166 All existing query types that perform type A additional section 167 processing, i.e., name server (NS), location of services (SRV) and 168 mail exchange (MX) query types, must be redefined to perform both 169 type A and type AA additional section processing. These 170 definitions mean that a name server must add any relevant IPv4 171 addresses and any relevant IPFF addresses available locally to the 172 additional section of a response when processing any one of the above 173 queries. 175 4. Enforcing 999-per-field limit 177 IP-FF, be design has 10-bits per field, which theoretically allows 178 to put any values between 0 and 1023 into any field. 179 The valid addresses, however, are only up to 999. 181 Both DNS resolvers (DNS clients), and DNS servers MUST enforce this 182 limit; DNS Servers by refusing to write it, and clients by refusing 183 to accept resource records with field values higher than 999. 185 5. Security Considerations 187 This specification is not believed to cause any new security 188 problems, nor to solve any existing ones. 190 Acknowledgments 192 Thanks to all previous DNS and DNSv6 developers, paricularly those 193 people, "Susan Thomson", "Christian Huitema", "Vladimir Ksinant", 194 "Mohsen Souissi", whom written RFC-3596 (DNSv6). 196 Authors' Contacts 198 Alexey Eromenko 199 Israel 201 Skype: Fenix_NBK_ 202 EMail: al4321@gmail.com 203 Facebook: https://www.facebook.com/technologov 205 INTERNET-DRAFT 206 Alexey 207 expiration date: 2017-03-29