[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01 02
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] <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]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/