Individual Submission P. Wilson Internet-Draft G. Michaelson Intended status: Informational G. Huston Expires: April 3, 2009 APNIC September 30, 2008 Redesignation of 240/4 from "Future Use" to "Private Use" draft-wilson-class-e-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 3, 2009. Abstract This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for Private Use. 1. Redesignation of 240.0.0.0/4 This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for Private Use. Wilson, et al. Expires April 3, 2009 [Page 1] Internet-Draft 240.0.0.0/4 Private Use September 2008 The address block spanning 240.0.0.0 to 255.255.255.255 (240.0.0.0/4), formerly designated as "Class E", and noted as being "Reserved" in the IANA IPv4 address registry, is no longer to be held in reserve by IANA for the IETF. IANA is directed to redesignate the address block 240.0.0.0/4 as unicast address space intended for Private Use. While the particular form of private use is not specified here, it is envisaged that this address prefix would have use in large private Internets that require more address space than is available in the private use address space designated by [RFC1918] during the dual stack transition to IPv6. Potential users of this address space need to ensure that their envisaged deployment can satisfy the caveats noted here. 2. Caveats of Use Many implementations of the TCP/IP protocol stack have the 240.0.0.0/4 address block marked as experimental, and prevent the host from forwarding IP packets with addresses drawn from this address block. For this reason, it is strongly suggested that private network addressing requirements which can be fulfilled from the private use address space designated by [RFC1918] should continue to use that space. Network administrators with very large scale requirements for private use address space who wish to use addresses drawn from 240.0.0.0/4 are advised to conduct appropriate tests to ensure that such addresses can be used in their envisaged private use context. [Note: not for publication. It is suggested that in order to assist with verification of equipment compatibility, a separate informational RFC or other mechanism be developed to assist with the recording of specific test results, upgrade status, etc.] 3. Considerations Note: This section is to assist in the discussion of the recommendation proposed in this draft. It is intended that this section would be removed prior to publication. The option of using this "top part" of the IPv4 address space as a means of mitigating to some extent the issues related to the exhaustion of the IPv4 unallocated address pool date back to at least 1998, if not earlier [Lear]. Wilson, et al. Expires April 3, 2009 [Page 2] Internet-Draft 240.0.0.0/4 Private Use September 2008 A related internet-draft, [ID.240space], advocates changing the designation of this addres prefix to that of a "useable" unicast address block, without specifying whether the designation should be for private or public use, so the "reserved" status was proposed in this draft for the 240.0.0.0/address block. This proposal differs from [ID.240space] in advocating that the address block not be used for publically routed address space, but is to be limited to private use contexts. The reason for this decision to propose a designation of Private Use is that for public use the entire installed base of IPv4 hosts un the public Internet, as well as associated private Internet realms that are attached to the public internet via NATs need to be able to generate and forward IPv4 packets that are addressed to 240.0.0.0/4 addresses. The set of changes to host systems may not be undertaken to a generally useful extent within any reasonable timeframe. The alternative approach is to limit its intended useof 240.0.0.0/4 to private network realms where the population of end devices and forwarding systems that need to support the use of 240.0.0.0/4 address space is limited. In private use contexts the utility of using this space in a private context is a local decision that is not impacted by any external factors of private use elsewhere. It has been noted that many end host operating system protocol stacks do not support the use of 240.0.0.0/4 address space. However, [ID.240space] reported in March 2008 that: "Apple OSX has been confirmed to support the use of 240.0.0.0/4 as unicast address space. Changes have been incorporated into recent versions of Sun Solaris and have been submitted for inclusion in the Linux kernel tree. No plans have been announced for modifications to any version of Microsoft Windows, in part because of uncertainty over how to perform 6-to-4 tunneling in the absence of a definitive statement on whether 240.0.0.0/4 is "public" or "private" space. This draft advocates the adoption of a definitive statement in the IPv4 address registry that 240.0.0.0/4 is Private Use space to allow transitonal tunnelling mechanisms to perform correctly in the context of use of 6to4 [RFC3056], Teredo [RFC4380], and similar forms of IPv6 transitional mechanisms that use IPv6 tunnelling as an overlay on an IPv4 substrate. It has been commented that this draft requires a similar level of effort in terms of deployment overheads to that involved in the deployment of IPv6 itself. This observation has been used to argue against adopting this proposal and instead reiterate the calls for the adoption of IPv6 and avoid any unnecessary distaction of effort in articifially prolonging the useful lifespan of IPv4. In response Wilson, et al. Expires April 3, 2009 [Page 3] Internet-Draft 240.0.0.0/4 Private Use September 2008 to such arguments it is noted that the adoption of IPv6 in an orderly transition context requires the exctended use of dual stack support in networks where both IPv6 and IPv4 is available for use. The problem is that the transition phase is now anticipated to last for far longer than the remaining lifetime of the unallocated address pool of IPv4 addresses, and in supporting the dual stack IPv6 transition, there is a need for additional IPv4 addresses in any case. The 240.0.0.0/4 address block allows service provider infrastructure to be numbered in a manner that would not conflict with either customer private address space use from [RFC1918] space, or public address space. This private use address pool is intended to assist in the IPv6 transition of larger networks who are using IPv4 in the context of a dual stack deployment. In such contexts it is reported to be the case that the reuse of network 10.0.0/8 is not an option because of existing use and potential address clashes [ID.1918bis]. The use of 240.0.0.0/4 offers a more conventional method to interconnect CPE NATs and network border carrier NATs without having to use more involved solutions such as [ID.DualStackLite] or [ID.NAT464]. 4. Security Considerations Equipment deployed on the public Internet is configured by default to treat addresses in the block 240.0.0.0/4 as experimental addresses that cannot be forwarded. This implies that accidental leakage of packets destined to such addresses would conventionally be discarded. 5. IANA Considerations The IANA is directed to redesignate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 as unicast address space reserved for "Private Use". 6. Acknowledgements The authors would like to acknowledge the thoughtful assistance of David Conrad, Andy Davidson and Robert Seastrom in the preparation of this document. 7. References Wilson, et al. Expires April 3, 2009 [Page 4] Internet-Draft 240.0.0.0/4 Private Use September 2008 7.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 7.2. Informative References [ID.1918bis] Hain, T., "Expanded Address Allocation for Private Internets", Work in progress: Internet Drafts draft-hain-1918bis-01.txt, January 2005. [ID.240space] Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 as usable unicast address space", Work in progress: Internet Drafts draft-fuller-240space-02.txt, March 2008. [ID.DualStackLite] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion", Work in progress: Internet Drafts draft-durand-dual-stack-lite-00.txt, July 2008. [ID.NAT464] Durand, A., "Non dual-stack IPv6 deployments for broadband providers", Work in progress: Internet Drafts draft-durand-v6ops-v4v6v4nat-00.txt, November 2007. [Lear] Lear, E., ""Re: Running out of Internet addresses?"", TCP/IP Mailing List , November 1988, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. Wilson, et al. Expires April 3, 2009 [Page 5] Internet-Draft 240.0.0.0/4 Private Use September 2008 Authors' Addresses Paul Wilson Asia Pacific Network Information Centre Email: pwilson@apnic.net URI: http://www.apnic.net George Michaelson Asia Pacific Network Information Centre Email: ggm@apnic.net URI: http://www.apnic.net Geoff Huston Asia Pacific Network Information Centre Email: gih@apnic.net URI: http://www.apnic.net Wilson, et al. Expires April 3, 2009 [Page 6] Internet-Draft 240.0.0.0/4 Private Use September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Wilson, et al. Expires April 3, 2009 [Page 7]