idnits 2.17.1 draft-wilson-class-e-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 281. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust 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 (September 30, 2008) is 5687 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-durand-v6ops-v4v6v4nat - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission P. Wilson 3 Internet-Draft G. Michaelson 4 Intended status: Informational G. Huston 5 Expires: April 3, 2009 APNIC 6 September 30, 2008 8 Redesignation of 240/4 from "Future Use" to "Private Use" 9 draft-wilson-class-e-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 3, 2009. 36 Abstract 38 This document directs the IANA to designate the block of IPv4 39 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast 40 address space for Private Use. 42 1. Redesignation of 240.0.0.0/4 44 This document directs the IANA to designate the block of IPv4 45 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast 46 address space for Private Use. 48 The address block spanning 240.0.0.0 to 255.255.255.255 49 (240.0.0.0/4), formerly designated as "Class E", and noted as being 50 "Reserved" in the IANA IPv4 address registry, is no longer to be held 51 in reserve by IANA for the IETF. 53 IANA is directed to redesignate the address block 240.0.0.0/4 as 54 unicast address space intended for Private Use. While the particular 55 form of private use is not specified here, it is envisaged that this 56 address prefix would have use in large private Internets that require 57 more address space than is available in the private use address space 58 designated by [RFC1918] during the dual stack transition to IPv6. 60 Potential users of this address space need to ensure that their 61 envisaged deployment can satisfy the caveats noted here. 63 2. Caveats of Use 65 Many implementations of the TCP/IP protocol stack have the 66 240.0.0.0/4 address block marked as experimental, and prevent the 67 host from forwarding IP packets with addresses drawn from this 68 address block. 70 For this reason, it is strongly suggested that private network 71 addressing requirements which can be fulfilled from the private use 72 address space designated by [RFC1918] should continue to use that 73 space. Network administrators with very large scale requirements for 74 private use address space who wish to use addresses drawn from 75 240.0.0.0/4 are advised to conduct appropriate tests to ensure that 76 such addresses can be used in their envisaged private use context. 78 [Note: not for publication. It is suggested that in order to assist 79 with verification of equipment compatibility, a separate 80 informational RFC or other mechanism be developed to assist with the 81 recording of specific test results, upgrade status, etc.] 83 3. Considerations 85 Note: This section is to assist in the discussion of the 86 recommendation proposed in this draft. It is intended that this 87 section would be removed prior to publication. 89 The option of using this "top part" of the IPv4 address space as a 90 means of mitigating to some extent the issues related to the 91 exhaustion of the IPv4 unallocated address pool date back to at least 92 1998, if not earlier [Lear]. 94 A related internet-draft, [ID.240space], advocates changing the 95 designation of this addres prefix to that of a "useable" unicast 96 address block, without specifying whether the designation should be 97 for private or public use, so the "reserved" status was proposed in 98 this draft for the 240.0.0.0/address block. This proposal differs 99 from [ID.240space] in advocating that the address block not be used 100 for publically routed address space, but is to be limited to private 101 use contexts. The reason for this decision to propose a designation 102 of Private Use is that for public use the entire installed base of 103 IPv4 hosts un the public Internet, as well as associated private 104 Internet realms that are attached to the public internet via NATs 105 need to be able to generate and forward IPv4 packets that are 106 addressed to 240.0.0.0/4 addresses. The set of changes to host 107 systems may not be undertaken to a generally useful extent within any 108 reasonable timeframe. The alternative approach is to limit its 109 intended useof 240.0.0.0/4 to private network realms where the 110 population of end devices and forwarding systems that need to support 111 the use of 240.0.0.0/4 address space is limited. In private use 112 contexts the utility of using this space in a private context is a 113 local decision that is not impacted by any external factors of 114 private use elsewhere. 116 It has been noted that many end host operating system protocol stacks 117 do not support the use of 240.0.0.0/4 address space. However, 118 [ID.240space] reported in March 2008 that: 120 "Apple OSX has been confirmed to support the use of 240.0.0.0/4 as 121 unicast address space. Changes have been incorporated into recent 122 versions of Sun Solaris and have been submitted for inclusion in 123 the Linux kernel tree. No plans have been announced for 124 modifications to any version of Microsoft Windows, in part because 125 of uncertainty over how to perform 6-to-4 tunneling in the absence 126 of a definitive statement on whether 240.0.0.0/4 is "public" or 127 "private" space. 129 This draft advocates the adoption of a definitive statement in the 130 IPv4 address registry that 240.0.0.0/4 is Private Use space to allow 131 transitonal tunnelling mechanisms to perform correctly in the context 132 of use of 6to4 [RFC3056], Teredo [RFC4380], and similar forms of IPv6 133 transitional mechanisms that use IPv6 tunnelling as an overlay on an 134 IPv4 substrate. 136 It has been commented that this draft requires a similar level of 137 effort in terms of deployment overheads to that involved in the 138 deployment of IPv6 itself. This observation has been used to argue 139 against adopting this proposal and instead reiterate the calls for 140 the adoption of IPv6 and avoid any unnecessary distaction of effort 141 in articifially prolonging the useful lifespan of IPv4. In response 142 to such arguments it is noted that the adoption of IPv6 in an orderly 143 transition context requires the exctended use of dual stack support 144 in networks where both IPv6 and IPv4 is available for use. The 145 problem is that the transition phase is now anticipated to last for 146 far longer than the remaining lifetime of the unallocated address 147 pool of IPv4 addresses, and in supporting the dual stack IPv6 148 transition, there is a need for additional IPv4 addresses in any 149 case. The 240.0.0.0/4 address block allows service provider 150 infrastructure to be numbered in a manner that would not conflict 151 with either customer private address space use from [RFC1918] space, 152 or public address space. 154 This private use address pool is intended to assist in the IPv6 155 transition of larger networks who are using IPv4 in the context of a 156 dual stack deployment. In such contexts it is reported to be the 157 case that the reuse of network 10.0.0/8 is not an option because of 158 existing use and potential address clashes [ID.1918bis]. The use of 159 240.0.0.0/4 offers a more conventional method to interconnect CPE 160 NATs and network border carrier NATs without having to use more 161 involved solutions such as [ID.DualStackLite] or [ID.NAT464]. 163 4. Security Considerations 165 Equipment deployed on the public Internet is configured by default to 166 treat addresses in the block 240.0.0.0/4 as experimental addresses 167 that cannot be forwarded. This implies that accidental leakage of 168 packets destined to such addresses would conventionally be discarded. 170 5. IANA Considerations 172 The IANA is directed to redesignate the block of IPv4 addresses from 173 240.0.0.0 to 255.255.255.255 as unicast address space reserved for 174 "Private Use". 176 6. Acknowledgements 178 The authors would like to acknowledge the thoughtful assistance of 179 David Conrad, Andy Davidson and Robert Seastrom in the preparation of 180 this document. 182 7. References 183 7.1. Normative References 185 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 186 E. Lear, "Address Allocation for Private Internets", 187 BCP 5, RFC 1918, February 1996. 189 7.2. Informative References 191 [ID.1918bis] 192 Hain, T., "Expanded Address Allocation for Private 193 Internets", Work in progress: Internet 194 Drafts draft-hain-1918bis-01.txt, January 2005. 196 [ID.240space] 197 Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 198 as usable unicast address space", Work in progress: 199 Internet Drafts draft-fuller-240space-02.txt, March 2008. 201 [ID.DualStackLite] 202 Durand, A., "Dual-stack lite broadband deployments post 203 IPv4 exhaustion", Work in progress: Internet 204 Drafts draft-durand-dual-stack-lite-00.txt, July 2008. 206 [ID.NAT464] 207 Durand, A., "Non dual-stack IPv6 deployments for broadband 208 providers", Work in progress: Internet 209 Drafts draft-durand-v6ops-v4v6v4nat-00.txt, November 2007. 211 [Lear] Lear, E., ""Re: Running out of Internet addresses?"", 212 TCP/IP Mailing List , November 1988, . 216 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 217 via IPv4 Clouds", RFC 3056, February 2001. 219 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 220 Network Address Translations (NATs)", RFC 4380, 221 February 2006. 223 Authors' Addresses 225 Paul Wilson 226 Asia Pacific Network Information Centre 228 Email: pwilson@apnic.net 229 URI: http://www.apnic.net 231 George Michaelson 232 Asia Pacific Network Information Centre 234 Email: ggm@apnic.net 235 URI: http://www.apnic.net 237 Geoff Huston 238 Asia Pacific Network Information Centre 240 Email: gih@apnic.net 241 URI: http://www.apnic.net 243 Full Copyright Statement 245 Copyright (C) The IETF Trust (2008). 247 This document is subject to the rights, licenses and restrictions 248 contained in BCP 78, and except as set forth therein, the authors 249 retain all their rights. 251 This document and the information contained herein are provided on an 252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 254 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 255 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 256 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 Intellectual Property 261 The IETF takes no position regarding the validity or scope of any 262 Intellectual Property Rights or other rights that might be claimed to 263 pertain to the implementation or use of the technology described in 264 this document or the extent to which any license under such rights 265 might or might not be available; nor does it represent that it has 266 made any independent effort to identify any such rights. Information 267 on the procedures with respect to rights in RFC documents can be 268 found in BCP 78 and BCP 79. 270 Copies of IPR disclosures made to the IETF Secretariat and any 271 assurances of licenses to be made available, or the result of an 272 attempt made to obtain a general license or permission for the use of 273 such proprietary rights by implementers or users of this 274 specification can be obtained from the IETF on-line IPR repository at 275 http://www.ietf.org/ipr. 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights that may cover technology that may be required to implement 280 this standard. Please address the information to the IETF at 281 ietf-ipr@ietf.org.