APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists sig-policy 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sig-policy] draft-submission - draft-wilson-class-e-00.txt



Dear all,

The following Internet draft has been submitted today, proposing the redesignation of the IPv4 class-E address space (240/4) for private use, in particular for private networks which are too large to use the existing RFC1918 private address space.

This matter is not strictly one for RIR address policy processes, as Class E is not considered to be global unicast, nor is it subject to RIR policies.

However I believe that this is of interest to the APNIC address policy SIG. If there is some interest, I am sure there will be opportunity for discussion of this matter during APNIC 24 next months.

All the best

Paul Wilson
APNIC.
====



Individual Submission                                          P. Wilson
Internet-Draft                                             G. Michaelson
Intended status: Standards Track                               G. Huston
Expires: February 4, 2008                                          APNIC
                                                         August 3, 2007


  Redesignation of 240/4 from "Future Use" to "Limited Use for Large
                          Private Internets"
                     draft-wilson-class-e-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 February 4, 2008.

Copyright Notice

  Copyright (C) The IETF Trust (2007).

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 limited use in large private Internets.






Wilson, et al.          Expires February 4, 2008                [Page 1]

Internet-Draft              240/4 Private Use                August 2007


1.  Redesignation of 240.0.0.0/4

  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 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 in large private
  Internets that require more address space than is available in the
  private use address space designated by [RFC1918].

  Potential users of this address space would need to ensure that their
  envisaged deployment can satisfy the use caveats noted here.


2.  Caveats of Use

  Many implementations of the TCP/IP protocol stack have the
  204.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.  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.


4.  IANA Considerations

  The IANA is directed to redesignate the block of IPv4 addresses from



Wilson, et al.          Expires February 4, 2008                [Page 2]

Internet-Draft              240/4 Private Use                August 2007


  240.0.0.0 to 255.255.255.255 as unicast address space reserved for
  "Limited Use for Large Private Internets".


5.  Acknowledgements

  The authors would like to acknowledge the thoughtful assistance of
  David Conrad, Andy Davidson and Robert Seastrom in the preparation of
  this document.


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


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 February 4, 2008                [Page 3]

Internet-Draft              240/4 Private Use                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).





Wilson, et al.          Expires February 4, 2008                [Page 4]