idnits 2.17.1 draft-ietf-ipngwg-prefix-rr-disc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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. ** The abstract seems to contain references ([A6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 17, 2000) is 8561 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) ** Downref: Normative reference to an Historic RFC: RFC 2874 (ref. 'A6') ** Obsolete normative reference: RFC 2672 (ref. 'DNAME') (Obsoleted by RFC 6672) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng Working Group Matt Crawford 2 Internet Draft Fermilab 3 November 17, 2000 5 Discovery of Resource Records Designating IPv6 Address prefixes 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 The A6 resource record type [A6] was introduced to store IPv6 30 addresses in a manner which facilitates prefix changes and 31 assignment of addresses from multiple prefixes. In order to allow 32 use of dynamic DNS updates while still respecting whatever prefix 33 hierarchy may be in use in a site's "reverse" DNS zone, a method is 34 needed for discovering the name(s) of the A6 record(s) which specify 35 an address prefix. 37 This memo specifies such a method of prefix name discovery. 39 1. Introduction 41 The A6 resource record type [A6] was introduced to store IPv6 42 addresses in a manner which facilitates prefix changes and 43 assignment of addresses from multiple prefixes. In order to allow 44 use of dynamic DNS updates while still respecting whatever prefix 45 hierarchy may be in use in a site's "reverse" DNS zone, a method is 46 needed for discovering the name(s) of the A6 record(s) which specify 47 an address prefix. 49 This memo specifies such a method. No new protocols or DNS record 50 types are involved -- only a convention for storing the required 51 information and a procedure for finding it. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [KWORD]. 57 2. Prefix Name Storage 59 Recall from [A6] that address-to-name mapping information may be 60 stored in a subzone of IP6.ARPA, or in another zone reached by a 61 chain of one or more DNAME records. Nodenames are stored in PTR 62 records in such a zone. Extending that custom, we specify that 63 prefixes are to be named in PTR records in the same way. For a 64 prefix "P" of length "L" bits there should be a PTR whose RDATA 65 contains the owner name of an A6 record suitable for designating the 66 prefix P/L, and this PTR record is to be stored so that it will be 67 returned by a DNS query for the QNAME \[P/L].IP6.ARPA (possibly 68 after resolving intervening DNAMEs [DNAME]). 70 Since the purpose of prefix name discovery is to facilitate dynamic 71 registration by hosts of their IPv6 addresses in DNS, only the names 72 of "longest" prefixes need to be discoverable. Accordingly, this 73 example will show just a prefix which is not subnetted further. 75 Building on the example from [A6], section 5.2.3, the addition of 76 the required PTR record is shown below. 78 $ORIGIN X.EXAMPLE. 79 N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 80 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 81 PTR SUBNET-1.IP6 ; added record 82 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. 83 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. 84 $ORIGIN IP6 85 \[x0001/16] DNAME SUBNET-1 86 \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. 88 Notice that the owner and RDATA are the same. This is a consequence 89 of a somewhat arbitrary choice. The new record could equally well 90 have been 92 \[x0001/16].IP6.X.EXAMPLE. PTR SUBNET-1.IP6.X.EXAMPLE. 94 It cannot be determined by inspecting an A6 DNS record whether that 95 record is meant to specify all the trailing bits of a 128-bit IPv6 96 address or merely a prefix. Inclusion of the trailing bits does not 97 preclude its being pointed to as a prefix by some other A6 record. 98 Nevertheless, a human or automated zone maintainer will generally 99 know the intended purpose of each A6 record and which one should be 100 named in a PTR for prefix name discovery. 102 3. Prefix Name Discovery 104 If a process wishing to do prefix name discovery has the prefix 105 itself available (as opposed to a full address of which an unknown 106 initial portion is the prefix), the prefix can be looked up 107 directly. Otherwise, two heuristics are available. 109 First, it is possible that looking up a PTR record based on the full 110 IPv6 address, as would be done for ordinary address-to-name mapping, 111 will yield a PTR record containing a hostname. That hostname will 112 then be the owner of an A6 record. If its prefix length field is 113 non-zero, its prefix name field will contain the desired name. 115 Otherwise, looking up a PTR record will fail, returning an 116 authoritative name error no no data of the requested type. There 117 will be a set of DNAME records in the answer section of the reply. 118 The last of these DNAMEs will indicate where to start looking for 119 the required PTR record. First its target should be tried, then its 120 owner. An especially persistent implementation can then prepend one 121 bit at a time from the portion of the IPv6 address not mapped by the 122 DNAME records to the target name, looking for a PTR record which was 123 not at a DNAME cut point of its own. An authoritative name error is 124 a stopping signal for this search. 126 4. Security Considerations 128 No security concerns are raised by this specification beyond those 129 which apply to all uses of the DNS. 131 5. References 133 [A6] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 134 Address Aggregation and Renumbering", RFC 2874, July 2000. 136 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate 137 Requirement Levels," RFC 2119. 139 [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, 140 August 1999. 142 6. Authors' Addresses 144 Matt Crawford 145 Fermilab 146 MS 368 147 PO Box 500 148 Batavia, IL 60510 149 USA 151 +1 630 840-3461 152 crawdad@fnal.gov