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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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.

This Internet-Draft will expire on May 15, 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.

Table of Contents

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

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 (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) [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] (Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, “ISP Shared Address,” March 2010.)

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 (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) [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.

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 (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) [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 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 (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) [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

6.2. Informative References

Authors' Addresses