idnits 2.17.1 draft-huston-ip6-int-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 171. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 177. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 27, 2005) is 6902 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 3152 (Obsoleted by RFC 3596) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft APNIC 4 Expires: November 28, 2005 May 27, 2005 6 Deprecation of "ip6.int" 7 draft-huston-ip6-int-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 28, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document advises of the deprecation of the use of "ip6.int" for 41 Standards Conformant IPv6 implementations. 43 Notes 45 [START: This section not for RFC publication] 47 This memo has been prepared as part of the activities of an ad hoc 48 advisory committee to advise the IAB on a number of matters relating 49 to IPv6. It is proposed that the note be published as an Internet 50 Standards action for IPv6 as a BCP. 52 This advice does not directly address legacy issues relating to 53 continued of the "ip6.int" domain. While the use of the ip6.int 54 domain was deprecated in August 2001 upon the publication of BCP 49 55 (RFC 3152), the document indicated that the use of the ip6.int domain 56 would "likely be phased out in an orderly fashion." 58 While it is apparent that implementors of IPv6 protocol stacks have 59 noted this advice, and configured more recent IPv6 implementations to 60 use the "ip6.arpa" domain as a means of mapping from an IPv6 address 61 to a fully qualified domain name, there is still some level of 62 activity associated with the ip6.int domain, including continued 63 delegation requests and some level of queries. The justification of 64 the operational costs of continued maintenance of this domain is 65 questionable, given its deprecated status, the now piecemeal 66 population of the domain with delegated zones, and the continuing 67 level of confusion to end users and network administrators while two 68 reverse mapping domains remain operational. 70 This document proposes the action to complete the phase out of 71 ip6.int from use in IPv6 for the IPv6 DNS reverse mapping function on 72 1 September 2005. 74 There has been consideration of the inclusion in this document of an 75 examination of the current status of implementations with respect to 76 their support of ip6.int, a commentary on the implications of 77 operating a protocol stack that continued to attempt reverse 78 resolution using ip6.int queries, and an examination of possible 79 mechanisms for an indefinite legacy functionality. This has not been 80 done here, as the consideration has been to constrain the scope of 81 this document to that of a standards-related action related 82 specifically to the deprecation of ip6.int. 84 As a further note regarding legacy and backward compatibility 85 measures, some exploratory activity has been noted that proposes the 86 use of DNAME records in "ip6.int" using a redirection pointer to the 87 relevant delegation points in the "ip6.arpa" domain. There are some 88 associated issues with the use of base relative names in reverse 89 domains to allow the DNAME to work, and there may also be a need for 90 some further investigatory activity relating to the soundness of the 91 use of DNAME redirection in this context. This activity falls more 92 into an operational task regarding legacy management, and is 93 considered to be outside the intentionally limited scope of this 94 particular document. 96 [END: section not for RFC publication] 98 1. IPv6 Standards Action 100 In August 2001 the IETF published [RFC3152], which advised that the 101 use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses 102 to DNS names was deprecated. The document noted that the use of 103 "ip6.int" would be phased out in an orderly fashion. 105 As of 1 September 2005, the IETF advises the community that the DNS 106 domain "ip6.int" should no longer be used to perform reverse mapping 107 of IPv6 addresses to domain names, and that the domain "ip6.arpa" 108 should be used henceforth, in accordance with the IANA Considerations 109 described in [RFC3596]. The domain "ip6.int" is deprecated, and its 110 use in IPv6 implementations that conform to the IPv6 Internet 111 Standards is discontinued. 113 The Regional Internet Registries (RIRs) are advised that maintenance 114 of delegation of entries in "ip6.int" is no longer required as part 115 of infrastructure services in support of Internet Standards 116 conformant IPv6 implementations as of 1 September 2005. The RIRs are 117 requested to work with their communities to adopt a schedule 118 regarding cessation of support of registration services for the 119 "ip6.int" domain. 121 2. IANA Considerations 123 IANA is advised that the "ip6.int" domain for reverse mapping of IPv6 124 addresses to domain names is no longer part of Internet Standards 125 Conformant support of IPv6 as of 1 September 2005. 127 3. Security Considerations 129 While DNS spoofing of address to name mapping has been exploited in 130 IPv4, removal of the "ip6.int" zone from the standard IPv6 131 specification creates no new threats to the security of the internet. 133 4. Acknowledgements 135 The document was prepared with the assistance of Kurt Lindqvist, 136 Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian 137 Haberman, and Bill Manning. 139 5. Normative References 141 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 142 August 2001. 144 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 145 "DNS Extensions to Support IP Version 6", RFC 3596, 146 October 2003. 148 Author's Address 150 Geoff Huston 151 APNIC 153 Email: gih@apnic.net 155 Intellectual Property Statement 157 The IETF takes no position regarding the validity or scope of any 158 Intellectual Property Rights or other rights that might be claimed to 159 pertain to the implementation or use of the technology described in 160 this document or the extent to which any license under such rights 161 might or might not be available; nor does it represent that it has 162 made any independent effort to identify any such rights. Information 163 on the procedures with respect to rights in RFC documents can be 164 found in BCP 78 and BCP 79. 166 Copies of IPR disclosures made to the IETF Secretariat and any 167 assurances of licenses to be made available, or the result of an 168 attempt made to obtain a general license or permission for the use of 169 such proprietary rights by implementers or users of this 170 specification can be obtained from the IETF on-line IPR repository at 171 http://www.ietf.org/ipr. 173 The IETF invites any interested party to bring to its attention any 174 copyrights, patents or patent applications, or other proprietary 175 rights that may cover technology that may be required to implement 176 this standard. Please address the information to the IETF at 177 ietf-ipr@ietf.org. 179 Disclaimer of Validity 181 This document and the information contained herein are provided on an 182 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 183 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 184 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 185 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 186 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 187 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 189 Copyright Statement 191 Copyright (C) The Internet Society (2005). This document is subject 192 to the rights, licenses and restrictions contained in BCP 78, and 193 except as set forth therein, the authors retain all their rights. 195 Acknowledgment 197 Funding for the RFC Editor function is currently provided by the 198 Internet Society.