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


.  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].


.  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.


.  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.


.  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.


.  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

   []  <http://www.potaroo.net/ispcol/2007-07/v4end.html>


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]