Network Working Group V. Fuller Internet-Draft E. Lear Updates: 3330 (if approved) D. Meyer Intended status: Standards Track Cisco Systems Expires: March 2, 2008 August 30, 2007 Reclassifying 240/4 as usable unicast address space draft-fuller-240space-00.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 March 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo reclassifies the address block 240.0.0.0/4 as usable address space. While the community has not concluded as to whether the block should be considered public or private, it is clear given the current consumption rate that the block should not be left unused. This document also makes several recommendations on ways that current implementations of the IP protocol stack will need to be modified to make this address space usable. Fuller, et al. Expires March 2, 2008 [Page 1] Internet-Draft Implementation of 240/4 space August 2007 1. Introduction Recent estimates [1] indicate that the Internet Assigned Numbers Authority (IANA) will exhaust the unallocated pool of 32-bit IPv4 addresses some time sometime between 2008 and 2010. As that time rapidly approaches, the Internet community must consider what it should do with address space currently reserved for future use. [RFC3330] states that the address range 240.0.0.0/4 is reserved for future use. There are several possible uses of this block. One would be to reclassify the block as private address space, as defined in [RFC1918], so that large private organizations that have outgrown the other private blocks have additional room for network expansion. Another possibility is for the address space to be made available for public Internet use. A decision on which of these alternatives (if either) is chosen requires additional analysis and debate; what is clear, though, is that today's IP protocol stack implementations will need to be modified to support any use of the currently-reserved space as most today return errors when such addresses are used. This memo requires implementors to make the changes necessary to receive, transmit, and forward packets that contain addresses in this block as if they were within any other unicast address block. It is envisioned that utility of this block will grow over time. Some devices may never be able to use it as their IP implementations have no update mechanism. This is not to say that the block will find no use. For example, home implementations that make use of network address translation [RFC2766] can also make use of this range as their public facing address once the resources people wish to access have been updated. Similarly, organizations building new networks, composed of equipment with new IP implementations that will not need to interoperate with legacy equipment, may benefit from the availability of this address space. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Implementation considerations At the present time, most IP implementation consider any IP address in the range 240.0.0.0 through 255.255.255.255 to be invalid as the source or destination of a datagram. The check for such "illegal" addresses may be made in many places, including at datagram receipt, before IP datagram transmission, when an IP address is assigned to a network interface, or even by router and firewall configuration parsers. Because 240.0.0.0/4 is henceforth reclassified as usable Fuller, et al. Expires March 2, 2008 [Page 2] Internet-Draft Implementation of 240/4 space August 2007 address space, implementations MUST treat this range as they would any other unicast address range. Hence implementors should review all of the above mentioned places and possibly others as they update their implementations and remove those checks. How the check is implemented may vary, but a common method is to treat the IP address as a 32-bit quantity in network byte order, performing a logical AND operation with the value hexidecimal F0000000, and testing to see if the result is hexidecimal F0000000. If the test succeeds, the address is rejected. Note that the broadcast address, 255.255.255.255, still must be treated specially in each case: it is illegal as a source IP address, it is illegal as an network interface address, and it matches the local system when used as the destination address in a received datagram. 3. Security Considerations The reclassification of 240.0.0.0/4 as a unicast block presents the same security issues as any other unicast block, with the possible addition that attackers may attempt to exploit poorly developed security software that cannot handle the change. The authors have not explored whether such implementations exist. 4. IANA Considerations Although this memo requires implementations to treat addresses in the range 240.0.0.0/4 the same as any other unicast addresses, it does not change the "reserved" status of the 240.0.0.0/4 address block. The IANA is requested to continue to reserve this block for future use, with the understanding that future standards action will define how it is to be allocated. 5. References 5.1. Normative References [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Fuller, et al. Expires March 2, 2008 [Page 3] Internet-Draft Implementation of 240/4 space August 2007 5.2. Informative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation", RFC 2766, February 2000. URIs [1] Appendix A. Changes Authors' Addresses Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Eliot Lear Cisco Systems Glatt-com, 2nd Floor Glattzentrum, Zurich 8301 Switzerland Email: lear@cisco.com David Meyer Cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dmm@cisco.com Fuller, et al. Expires March 2, 2008 [Page 4] Internet-Draft Implementation of 240/4 space August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Fuller, et al. Expires March 2, 2008 [Page 5]