idnits 2.17.1 draft-vixie-ipng-ipv4ptr-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-24) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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. ** There are 46 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC1035], [RFC1884], [RFC1886], [RFC1101]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'RFC1884' on line 138 looks like a reference -- Missing reference section? 'RFC1886' on line 142 looks like a reference -- Missing reference section? 'RFC1035' on line 130 looks like a reference -- Missing reference section? 'RFC1101' on line 134 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP: Next Generation Area Paul Vixie (ISC) 2 INTERNET-DRAFT May, 1996 3 5 Reverse Name Lookups of Encapsulated IPv4 Addresses in IPv6 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 Abstract 27 [RFC1884] specified two IPv6 address forms that encapsulated IPv4 28 addresses. [RFC1886] specified a new DNS RR type (AAAA) to map 29 domain names to IPv6 addresses, and also specified the form of the 30 PTR RR owner name used to map IPv6 addresses back to the domain name 31 of that host or interface. 33 This memo amends [RFC1886] and gives two exceptions to its rules 34 regarding PTR RR owner name correspondance to IPv6 addresses. 35 Specifically, the two IPv4 encapsulation methods are exempted from 36 [RFC1886]'s nybble mapping, and are made subject to the appropriate 37 rules from [RFC1035] and [RFC1101]. 39 1 - Overview 41 1.1. In [RFC1884 2.4.4] we see that addresses of the form ::D.D.D.D 42 (which means the first 96 bits of the address are binary zero, and the 43 last 32 bits are an IPv4 address) are used to ``tunnel IPv6 packets over 44 IPv4 routing infrastructure.'' Later in [ibid] we see that addresses of 45 the form ::FFFF:D.D.D.D (that is, 80 ``zero'' bits, 16 ``one'' bits, and 46 an IPv4 address) are used to ``represent the addresses of IPv4-only 47 nodes (those that *do not* support IPv6) as IPv6 addresses.'' 49 1.2. In [RFC1886 2.5] we see that an inverse name lookup for an IPv6 50 address is done by reversing the nybbles, formatting them as hexadecimal 51 ASCII, and using each as a DNS label under the domain IP6.INT. Thus, to 52 find the name associated with address ``4321:0:1:2:3:4:567:89ab,'' one 53 would search for a PTR RR at the name: 55 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 57 1.3. This leaves open the question of how to do inverse name lookups on 58 the two IPv6 address forms which actually describe IPv4 endpoints. 59 Should a resolver look under the IP6.INT for a nybble wise name, or 60 under IN-ADDR.ARPA for a byte wise name? Due to format differences, 61 there is no data oriented solution (such as CNAME RRs or replicate NS 62 RRs) available to simply make a union in the namespace so that it does 63 not matter which query name is used. 65 1.4. This memo recommends that the two IPv6 address forms which 66 encapsulate IPv4 addresses shall follow the usual IPv4 inverse naming 67 rules (i.e., IN-ADDR.ARPA). It is the author's view that inverse naming 68 authority and address allocation authority must always be delegated 69 together, and that any IPv4 address, no matter what context it is used 70 in, has a single correct PTR RRset denoting the name(s) of the host or 71 interface to which that address is bound. 73 2 - Detail 75 2.1. For a mapped or tunnelled IPv4 address represented in IPv6 76 notation, inverse name lookups are to be done by stripping off the first 77 96 bits of the address, and using the last 32 bits as a raw IPv4 78 address. From [RFC1884]: 80 IPv6-Tunnelled IPv4 Address 82 | 80 bits | 16 | 32 bits | 83 +--------------------------------------+--------------------------+ 84 |0000..............................0000|0000| IPv4 address | 85 +--------------------------------------+----+---------------------+ 87 IPv6-Mapped IPv4 Address 89 | 80 bits | 16 | 32 bits | 90 +--------------------------------------+--------------------------+ 91 |0000..............................0000|FFFF| IPv4 address | 92 +--------------------------------------+----+---------------------+ 94 2.2. The encapsulated 32 bit IPv4 is to be broken down into four octets, 95 and these octets are reversed, formatted in decimal ASCII, and used as 96 labels under the IN-ADDR.ARPA domain. 98 IPv4 Address 100 | 8 bits | 8 bits | 8 bits | 8 bits | 101 +----------------+----------------+----------------+----------------+ 102 | Octet1 | Octet2 | Octet3 | Octet4 | 103 +----------------+----------------+----------------+----------------+ 105 IN-ADDR.ARPA Owner Name 107 . . . . IN-ADDR . ARPA 109 2.3. A normal DNS query for a PTR RR is done. If the response contains 110 an RRset matching the owner name and PTR type, then the RDATA(s) of 111 these RRs are the names associated with the hosts or interfaces using 112 the IPv4 address corresponding to this owner name. Multiple RRs can be 113 present in the response PTR RRset, if this address is reachable by more 114 than one A RR name. Thus, A RRs and PTR RRs are symmetric, while CNAME 115 aliases are single ended. 117 3 - Example 119 IPv6 Address PTR Owner Name 120 -------------------------------------------------- 121 ::13.1.68.3 3.68.1.13.IN-ADDR.ARPA 122 ::FFFF:129.144.52.38 38.52.144.129.IN-ADDR.ARPA 124 4 - Security Considerations 126 None. 128 5 - References 130 [RFC1035] 131 P. Mockapetris, ``Domain Names - Implementation and Specification,'' 132 RFC 1035, USC/Information Sciences Institute, November 1987. 134 [RFC1101] 135 P. Mockapetris, ``DNS Encoding of Network Names and Other Types,'', 136 RFC 1101, USC/Information Sciences Institute, April 1898. 138 [RFC1884] 139 R. Hinden, S. Deering, ``IP Version 6 Addressing Architecture,'' RFC 140 1884, Ipsilon Networks and Xerox PARC, December, 1995. 142 [RFC1886] 143 S. Thomson, C. Huitema, ``DNS Extensions to support IP version 6,'' 144 RFC 1886, Bellcore and INRIA, December 1995. 146 6 - Acknowledgements 148 The mailing list was instrumental in 149 crystallizing the views presented in this document. 151 7 - Author's Address 153 Paul Vixie 154 Internet Software Consortium 155 Star Route Box 159A 156 Woodside, CA 94062 157 +1 415 747 0204 158