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"

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 3, 2009.


   This document directs the IANA to designate the block of IPv4
   addresses from to ( as unicast
   address space for Private Use.

1.  Redesignation of

   This document directs the IANA to designate the block of IPv4
   addresses from to ( as unicast
   address space for Private Use.

Wilson, et al.            Expires April 3, 2009                 [Page 1]

Internet-Draft  Private Use          September 2008

   The address block spanning to
   (, 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 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 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 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  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 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 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 to private network realms where the
   population of end devices and forwarding systems that need to support
   the use of 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 address space.  However,
   [ID.240space] reported in March 2008 that:

      "Apple OSX has been confirmed to support the use of 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 is "public" or
      "private" space.

   This draft advocates the adoption of a definitive statement in the
   IPv4 address registry that 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  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 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 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 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 to 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  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

              Hain, T., "Expanded Address Allocation for Private
              Internets", Work in progress: Internet
              Drafts draft-hain-1918bis-01.txt, January 2005.

              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.

              Durand, A., "Dual-stack lite broadband deployments post
              IPv4 exhaustion", Work in progress: Internet
              Drafts draft-durand-dual-stack-lite-00.txt, July 2008.

              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://

   [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  Private Use          September 2008

Authors' Addresses

   Paul Wilson
   Asia Pacific Network Information Centre


   George Michaelson
   Asia Pacific Network Information Centre


   Geoff Huston
   Asia Pacific Network Information Centre


Wilson, et al.            Expires April 3, 2009                 [Page 6]

Internet-Draft  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

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

   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

Wilson, et al.            Expires April 3, 2009                 [Page 7]