One document matched: draft-davies-reusable-ipv4-address-block-00.txt

Network Working Group                                          G. Davies
Internet-Draft                                           C. Liljenstolpe
Intended status: Standards Track                     Telstra Corporation
Expires: May 13, 2010                                  November 09, 2009


        Transitional non-conflicting reusable IPv4 address block
              draft-davies-reusable-ipv4-address-block-00

Abstract

   Although IPv6 is being introduced globally, the entire IP ecosystem
   will not have transitioned to IPv6 before the forecast exhaustion of
   the global IPv4 address pools.

   This document describes a new transitional non-conflicting reusable
   IPv4 address block which will facilitate a smooth IPv4 to IPv6
   transition for customers and transit providers.

   The address block would be assigned by IANA and have a limited time
   horizon to match its transitional purpose.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.



Davies & Liljenstolpe     Expires May 13, 2010                  [Page 1]

Internet-Draft         reusable-ipv4-address-block         November 2009


   This Internet-Draft will expire on May 13, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.























Davies & Liljenstolpe     Expires May 13, 2010                  [Page 2]

Internet-Draft         reusable-ipv4-address-block         November 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Characateristics of the address block . . . . . . . . . . . . . 3
     2.1.  Transitional  . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Non-conflicting . . . . . . . . . . . . . . . . . . . . . . 3
     2.3.  Re-usable . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.4.  Address range . . . . . . . . . . . . . . . . . . . . . . . 4
     2.5.  Size of address block . . . . . . . . . . . . . . . . . . . 4
     2.6.  Global routing table  . . . . . . . . . . . . . . . . . . . 4
     2.7.  Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.8.  Traffic Filters . . . . . . . . . . . . . . . . . . . . . . 5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
































Davies & Liljenstolpe     Expires May 13, 2010                  [Page 3]

Internet-Draft         reusable-ipv4-address-block         November 2009


1.  Introduction

   IPv6 is being introduced globally, however the entire IP ecosystem
   will not have transitioned to IPv6 before the exhaustion of the
   global IPv4 address pool.

   During the transition, IPV4 connectivity will still be required for
   customers with IPv4-only devices, IPv4-only operating systems and for
   accessing remaining IPv4-only content and applications.

   To facilitate a smooth transition to IPv6 for customers and transit
   providers an address block is required that will not conflict with
   existing RFC1918 [RFC1918] addresses (used extensively within
   customer networks and in management of IP infrastructure).

   The idea of a reusable address space has also been discussed in
   [I-D.shirasaki-isp-shared-addr]


2.  Characateristics of the address block

2.1.  Transitional

   The address block is not proposed as a permanent solution as it is
   intended to aid the transition from IPv4 to IPv6.  It is therefore
   RECOMMENDED that a time horizon of 2020 be set for the retirement of
   this address block.  This will provide sufficient time for the
   successful lifecycle transition of the customer environment from IPv4
   to IPv6 (given support from device vendors).

2.2.  Non-conflicting

   The address block MUST NOT conflict with existing RFC1918 [RFC1918]
   addresses which are used extensively within customer networks and by
   transit providers in the management of IP infrastructure.

   This address block MUST NOT be used as a default range in any CPE
   equipment.

2.3.  Re-usable

   It is proposed that the address block can be re-used by any transit
   provider.  The address block MUST NOT be used in global routing on
   the public Internet.







Davies & Liljenstolpe     Expires May 13, 2010                  [Page 4]

Internet-Draft         reusable-ipv4-address-block         November 2009


2.4.  Address range

   A suitable address range for this purpose should be selected and
   reserved by IANA from the unallocated IPv4 address pool.  This
   address could be from previously reclaimed space, or space reclaimed
   for this purpose.

   It is noted that although in principle an address block from the
   reserved 240/4 range could be used for this purpose, it is understood
   that the actual use of this range is prevented within the
   implementation of many current IPv4 protocol stacks.  Any proposed
   use of 240/4 would therefore appear to require major changes to
   deployed equipment, which would be impractical for the purposes of a
   transitional IPv4 solution because of the time needed for deployment
   to customers and the financial requirements involved.

2.5.  Size of address block

   An address block with a /10 CIDR mask should be reserved for this
   purpose.

   The size of the reserved address block is not associated with any
   specific network architectures, but it is intended to accommodate the
   potential requirements of different network designs used by
   individual providers.

   In particular, this address block is sized to the minimal level
   expected for the addressing needs of a major provider offering
   services to a large broadband domain such as a single large city.  It
   is believed that a block smaller than /10 would require duplicate use
   of the same address space within such a domain, which could force the
   provider to use an inefficient network design and could introduce
   significant complexity in network operations such as service identity
   management.

2.6.  Global routing table

   The address block MUST be considered a bogon in the global routing
   table, and filtered as the RFC1918 [RFC1918] address space is
   currently in the public Internet.

2.7.  Reverse DNS

   Reverse DNS queries for addresses in this block MUST NOT be forwarded
   to the global DNS infrastructure.

   Any provider using this address block SHOULD provide reverse DNS
   infrastructure for this block, or the portions of it that they



Davies & Liljenstolpe     Expires May 13, 2010                  [Page 5]

Internet-Draft         reusable-ipv4-address-block         November 2009


   utilize.

   The in-addr.arpa root servers MUST return NXDOMAIN for this address
   block, if queried.

2.8.  Traffic Filters

   Any provider utilizing this address block MUST filter traffic with
   source or destination addresses within this block at their external
   borders

   All networks SHOULD apply the same filters.


3.  IANA Considerations

   IANA is to record the allocation of the IPv4 global unicast address
   as 'Transitional IPv4 to IPv6 address block' in the IPv4 address
   registry.


4.  Security Considerations

   Security considerations for this address block would be equivalent to
   those associated with RFC1918 [RFC1918] addresses.


5.  Contributors

   The authors wish to acknowledge the contributions of Yasuhiro
   Shirasaki and Shin Miyakawa (NTT Communications Corporation) as well
   as Akira Nakagawa (KDDI Corporation) for their work on the ISP Shared
   Address.


6.  References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.






Davies & Liljenstolpe     Expires May 13, 2010                  [Page 6]

Internet-Draft         reusable-ipv4-address-block         November 2009


6.2.  Informative References

   [I-D.shirasaki-isp-shared-addr]
              Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "ISP Shared Address",
              draft-shirasaki-isp-shared-addr-03 (work in progress),
              September 2009.


Authors' Addresses

   Greg Davies
   Telstra Corporation
   28/242 Exhibition Street
   Melbourne, VIC  3000
   AU

   Phone: +61.3.9634.3640
   Fax:
   Email: greg.davies@team.telstra.com
   URI:   http://www.telstra.com


   Christopher Liljenstolpe
   Telstra Corporation
   32/242 Exhibition Street
   Melbourne, VIC  3000
   AU

   Phone: +61.3.8647.6389
   Fax:
   Email: cdl@asgaard.org
   URI:   http://www.telstra.com


















Davies & Liljenstolpe     Expires May 13, 2010                  [Page 7]