idnits 2.17.1 draft-ietf-ipngwg-dns-rr-rgadd-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-26) 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 == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 79 has weird spacing: '...ol used to...' -- 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 (March 1997) is 9904 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) ** Obsolete normative reference: RFC 1884 (ref. '3') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1886 (ref. '4') (Obsoleted by RFC 3596) -- No information found for draft-ipngwg-gseaddr - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Jim Bound 3 IPng Working Group Digital Equipment Corp 4 March 1997 6 Synthesis of Routing Goop and AAAA Records in IPv6 8 10 Status of this Memo 12 This document is a submission to the IPng Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the ipng@sunroof.eng.sun.com mailing list. This document is not 15 at this time a product of the IPng Working Group, but a proposal to 16 become a product of the IPng Working Group. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this document is unlimited. 36 Abstract 38 This document is a proposal to redefine the existing DNS AAAA 39 resource record into two resource records: an RG record to define the 40 routing topology of an IPv6 address and an aAA record to define the 41 End System Identifier of an IPv6 address. The document will define 42 the synthesis of the RG and aAA record at the DNS primary server, 43 which will return an AAAA record to DNS resolvers. The objective of 44 this work is to split the AAAA record in the DNS into location and 45 identifier to provide future capabilities for dynamic renumbering of 46 addresses. This work was spawned by the GSE - Alternate Addressing 47 Architecture Proposal for IPv6. 49 Table of Contents: 51 1. Introduction.................................................3 52 2. Terminology and Definitions..................................3 53 3. New Resource Record Definitions..............................3 54 3.1 aAA record type.............................................3 55 3.2 RG record type..............................................4 56 3.3 aAA data format.............................................4 57 3.4 RG data format..............................................4 58 3.5 AAAA query..................................................4 59 3.6 Textual format of aAA and RG records........................4 60 4. Modifications to existing Query Types........................4 61 5. Security Considerations......................................5 62 Acknowledgements................................................5 63 References......................................................5 64 Authors' Address................................................5 65 1. Introduction 67 This document is a proposal to redefine the existing DNS AAAA 68 resource record [3,4] into two resource records: an RG record to 69 define the routing topology of an IPv6 address and an aAA record to 70 define the End System Identifier of an IPv6 address. The document 71 will define the synthesis of the RG and aAA record at the DNS primary 72 server, which will return an AAAA record to DNS resolvers. The 73 objective of this work is to split the AAAA record in the DNS into 74 location and identifier to provide future capabilities for dynamic 75 renumbering of addresses. This work was spawned by the GSE - 76 Alternate Addressing Architecture Proposal for IPv6 [5]. 78 The design objective of these two record types is to make it 79 transparent to existing DNS resolvers and the DNS protocol used to 80 query for AAAA records. 82 This proposal is dependent on the IPng WG buying into new definitions 83 via a new addressing architecture proposal, support for clear 84 boundaries for an end system identifier, and the definition of the 85 routing goop to define location for the end system identifier. Upon 86 completion of that work in the WG if it moves forward the author can 87 finish this specification where "????" and "TBD" exists presently. 89 2. Terminology and Definitions 91 node - A device that implements IPv6. 93 interface - A node's attachment to the link. 95 address - An IP layer identifier for an interface or a set 96 of interfaces. 98 3. New Resource Record Definitions 100 Two new record types are defined to store a node's IPv6 address. A 101 node that has more than one IPv6 address must have more than one such 102 record or record combinations. 104 3.1 aAA record type 106 The aAA resource record type is a new record specific to the Internet 107 class that stores a single IPv6 address for a nodes interface. It is 108 an ESD as defined in TBD. 110 The value of the type is TBD (decimal). 112 3.2 RG record type 114 The RG resource record type is a new record specific to the Internet 115 class that stores a single IPv6 address for a nodes location within a 116 routing domain. It is RG as defined in TBD. 118 The value of the type is TBD (decimal). 120 3.3 aAA data format 122 A ??? bit IPv6 ESD address is encoded in the data portion of an aAA 123 resource record in network byte order (high-order byte first). 125 3.4 RG data format 127 A ??? bit IPv6 RG address is encoded in the data portion of an RG 128 resource record in network byte order (high-order byte first). 130 3.5 AAAA query 132 An AAAA [1,2,4] query for a specified domain name in the Internet 133 class returns all associated AAAA resource records in the answer 134 section of a response. The DNS primary server [2] will synthesize 135 the RG and aAA records to produce an AAAA record in the answer 136 section of the response for a query for an AAAA record. 138 A type AAAA query does not perform additional section processing. 140 3.6 Textual format of aAA and RG records 142 The textual representation of the data portion of an aAA and RG 143 resource record used in a master database file is the textual 144 representation of a IPv6 address as defined in [3 + update for aAA 145 and RG TBD]. 147 4. Modifications to existing Query Types 149 Query processing as defined for AAAA records [4] would continue to be 150 processed as defined presently for IPv6. The DNS primary server 151 would bee responsible for concatentating the RG and aAA records to 152 respond to an AAAA query from resolvers. There may be multiple RG's 153 defined for each aAA record, and in those cases the DNS primary 154 server after synthesis of RG's to a specific aAA record must return 155 muliple AAAA record types in the answer section of a query response 156 for AAAA records. 158 The exception for the present AAAA records as defined is the IP6.INT 159 domain. The IPng WG at present is discussing a new methodology to 160 obtain addresses for names in a query but use of an ICMP message to 161 determine the name for an address. This needs further investigation 162 to determine it if has an affect on AAAA records. 164 But the same synthesis of RG + aAA records can be done for the 165 reverse address requirement for DNS PTR records [2], to process AAAA 166 reverse lookups in the DNS. 168 5. Security Considerations 170 Security issues are not discussed in this memo. 172 Acknowledgements 174 The attendees at the IPng Interim WG meeting to review the GSE 175 proposal at Sun Microsystems in Palo Alto, CA on February 27/28, 176 1997. 178 References 180 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 181 13, RFC 1034, USC/Information Sciences Institute, November 1987. 183 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 184 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 185 November 1987. 187 [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing 188 Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 189 1995. 191 [4] Tompson, S., and Huitema, C. "DNS Extensions to Support IP 192 version 6", RFC 1886, Bellcore, December 1995. 194 [5] O'dell, M. "GSE - An Alternate Addressing Architecture for IPv6" 195 draft-ipngwg-gseaddr-00.txt, UUNET Technologies, Februrary 1997. 197 Authors' Address 199 Jim Bound 200 Digital Equipment Corporation 201 110 Spitbrook Road, ZKO3-3/U14 202 Nashua, NH 03062 203 Phone: (603) 881-0400 204 Email: bound@zk3.dec.com