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, <http://
www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/
0146.html>.
[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]