idnits 2.17.1 draft-ietf-ipngwg-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 March 1995) is 10625 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) -- No information found for draft-ietf-ipngwg-ipv6-addr-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Thomson 3 INTERNET-DRAFT Bellcore 4 C. Huitema 5 INRIA 6 24 March 1995 8 DNS Extensions to support IP version 6 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 26 munnari.oz.au. 28 Abstract 30 This document defines the changes that need to be made to the Domain 31 Name System to support hosts running IP version 6 (IPv6). The 32 changes include a new resource record type to store an IPv6 address, 33 a new domain to support lookups based on an IPv6 address, and updated 34 definitions of existing query types that return Internet addresses as 35 part of additional section processing. The extensions are designed 36 to be compatible with existing applications and, in particular, DNS 37 implementations themselves. 39 1. INTRODUCTION 41 Current support for the storage of Internet addresses in the Domain 42 Name System (DNS)[1,2] cannot easily be extended to support IPv6 43 addresses[3] since applications assume that address queries return 44 32-bit IPv4 addresses only. 46 To support the storage of IPv6 addresses we define the following 47 extensions: 49 A new resource record type is defined to map a domain name to an 50 IPv6 address. 52 A new domain is defined to support lookups based on address. 54 Existing queries that perform additional section processing to 55 locate IPv4 addresses are redefined to perform additional sec- 56 tion processing on both IPv4 and IPv6 addresses. 58 The changes are designed to be compatible with existing software. 59 The existing support for IPv4 addresses is retained. 61 2. NEW RESOURCE RECORD DEFINITION AND DOMAIN 63 A new record type is defined to store a host's IPv6 address. A host 64 that has more than one IPv6 address must have more than one such 65 record. 67 2.1. AAAA record type 69 The AAAA resource record type is a new record specific to the Inter- 70 net class that stores a single IPv6 address. 72 The value of the type is 28 (decimal). 74 2.2. AAAA data format 76 An IPv6 address is encoded in the data portion of an AAAA resource 77 record in network byte order (high-order byte first). 79 2.3. AAAA query 81 An AAAA query for a specified domain name in the Internet class 82 returns all associated AAAA resource records in the answer section of 83 a response. 85 A type AAAA query does not perform additional section processing. 87 2.4. Textual format of AAAA records 89 The textual representation of the data portion of the AAAA resource 90 record used in a master database file is the textual representation 91 of a IPv6 address as defined in [3]. 93 2.5. IP6.INT Domain 95 A special domain is defined to look up a record given an address. The 96 intent of this domain is to provide a way of mapping an IPv6 address 97 to a host name, although it may be used for other purposes as well. 98 The domain is rooted at IP6.INT. 100 An IPv6 address is represented as a name in the IP6.INT domain by a 101 sequence of nibbles separated by dots with the suffix ".IP6.INT". The 102 sequence of nibbles is encoded in reverse order, i.e. the low-order 103 nibble is encoded first, followed by the next low-order nibble and so 104 on. Each nibble is represented by a hexadecimal digit. For example, 105 the inverse lookup domain name corresponding to the address 107 4321:0:1:2:3:4:567:89ab 109 would be 111 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. 113 3. MODIFICATIONS TO EXISTING QUERY TYPES 115 All existing query types that perform type A additional section pro- 116 cessing, i.e. name server (NS), mail exchange (MX) and mailbox (MB) 117 query types, must be redefined to perform both type A and type AAAA 118 additional section processing. These new definitions mean that a name 119 server must add any relevant IPv4 addresses and any relevant IPv6 120 addresses available locally to the additional section of a response 121 when processing any one of the above queries. 123 4. SECURITY CONSIDERATIONS 125 Security issues are not discussed in this memo. 127 5. REFERENCES 129 [1] P. Mockapetris, "Domain Names - Concepts and Facilities", STD 130 13, RFC 1034, USC/Information Sciences Institute, November 1987. 132 [2] P. Mockapetris, "Domain Names - Implementation and Specifica- 133 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 134 November 1987. 136 [3] R. Hinden, Editor, IPng Addressing Architecture, Internet Draft, 137 draft-ietf-ipngwg-ipv6-addr-arch-00.txt, March 1995. 139 Authors' Addresses 141 Susan Thomson 142 Bellcore 143 MRE 2P343 144 445 South Street 145 Morristown, NJ 07960 146 U.S.A. 148 Phone: +1 201-829-4514 149 Email: set@thumper.bellcore.com 151 Christian Huitema 152 INRIA, Sophia-Antipolis 153 2004 Route des Lucioles 154 BP 109 155 F-06561 Valbonne Cedex 156 France 158 Phone: +33 93 65 77 15 159 EMail: Christian.Huitema@MIRSA.INRIA.FR