Transitional non-conflicting
reusable IPv4 address block
Telstra Corporation
28/242 Exhibition Street
Melbourne
VIC
3000
AU
+61.3.9634.3640
greg.davies@team.telstra.com
http://www.telstra.com
Telstra Corporation
32/242 Exhibition Street
Melbourne
VIC
3000
AU
+61.3.8647.6389
cdl@asgaard.org
http://www.telstra.com
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.
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.
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 addresses (used
extensively within customer networks and in management of IP
infrastructure).
The idea of a reusable address space has also been discussed in
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).
The address block MUST NOT conflict with existing 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.
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.
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.
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.
The address block MUST be considered a bogon in the global routing
table, and filtered as the RFC1918
address space is currently in the public Internet.
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.
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.
IANA is to record the allocation of the IPv4 global unicast address
as ‘Transitional IPv4 to IPv6 address block’ in the IPv4
address registry.
Security considerations for this address block would be equivalent to
those associated with RFC1918
addresses.
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.