[LACNIC/Politicas] IPv4 Countdown policy

[Toshiyuki Hosaka]

Dear all,

Please find the policy proposal to be presented next LACNIC meeting, as
below. Should you have any comments or questions please feel free to
contact me.

regards,
toshi
--
Toshiyuki Hosaka
Japan Network Information Center (JPNIC)


Summary of Proposal:
--------------------

This policy proposal proposes four general principles, which will be
needed to accomplish the smooth termination of IPv4 address allocation.

The four general principles are described below:

   1. Global Synchronisation:
      All five RIRs will proceed at the same time for measures on IPv4
      address exhaustion.

   2. To set and announce the date when the allocation is terminated:
      To set the date when RIRs cease the allocation in accordance with
      a precise estimation and to announce the date far before the
      termination date

   3. Not to change the current address policy stricter for the
      extension of IPv4 address lifetime:
      Keeping the current allocation criteria as it is until the last
      date to ensure the steady provision of IPv4 address space

   4. Separate discussions on "Recycle" issue:
      Recovery of unused address space should be discussed separately


Draft Policy Text
-----------------

i. Introduction

The exhaustion of IPv4 address is approaching round the corner. Geoff
Huston's latest projection at Potaroo (as of 6 January 2007) draws the
date of IANA pool exhaustion as 31 May 2011, and that of RIR pool as 14
July 2012.

Tony Hain projects similar dates based on a different algorithm of his
own. From these data, we may observe that if that the current allocation
trend continues, the exhaustion of IPv4 address space is expected to
take place as early as within the next five years.

ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth
termination of IPv4 address space as the Internet bodies responsible for
stable management and distribution of IP number resources.

This proposal provides some ideas as well as concrete examples of the
policy that helps IPv4 allocations come to an end with "the minimum
confusion" and in "as fair manner as possible".

"Five years at the earliest" is not too far in the future for the
exhaustion of IPv4 address space. Assuming the minimum of one year is
required for sufficient policy discussions with this proposal as a
start, and two years for preparation and transfer by LIRs, we need to
start the discussions right at this time.

ii.Summary of Current Problems

Despite the fact that several projections are made on IPv4 address to
run out as early as within the next few years, no discussions had taken
place on any of the RIR's policy fora before APNIC 23 Meeting in
February 2007. This section lists possible problems if no policies are
defined to prepare for the terminal period of allocations.

ii-a LIR

LIRs currently do not consider IPv4 address exhaustion as an imminent
issue in the first place. It is possible that they will finally realize
the situation only when impacts of the exhaustion becomes visible as a
practical matter, and lead to confusions such as re-addressing their
network or making subsequent requests at the last minute in within a
limited time frame.

There could also be cases where allocations blocks cannot be allocated
to some of the LIRs even though requests are submitted on the same day.
Moreover, although it would be necessary for LIRs to announce to their
customers that IPv4 address space will not be available for assignments
eventually, it is difficult to plan this timing without clear policy for
the last phase of allocations.

As new IPv4 address allocations space will no longer be available, LIRs
will be forced to build networks with a big architectural change whether
it will be with hierarchical NAT or with IPv6 or even with another solution.

However, there are risks of trouble if preparations are made from that
point in time, as it will lead to premature actions even if some time
can be bought by re-addressing and subsequent allocations.

Lastly, using up all available IPv4 address space will disable
assignments to services inevitable for co-existence of IPv4 and IPv6
networks, such as the translator service between the two networks, which
it may create situation where transfer to IPv6 network will not even be
possible.

ii-b RIR/NIR

It is likely that smooth allocations by RIRs/NIRs will be hindered by
rush of inquiries during the terminal phase of allocations.

ii-c End Users

Regardless which out of hierarchical NAT and IPv6 is used for the
Internet connection after IPv4 address is exhausted, End Users will more
or less experience a change of specification for their Internet
connection. End Users might be confused if such a change were not
well-coordinated or informed.

iii Benefits

There will be the following benefits by implementing the policy for IPv4
address exhaustion as proposed on this paper.

iii-a LIR

LIRs will be able to consciously plan their addressing within their
networks if the final date of allocations is clearly demonstrated.
Keeping a certain amount of unallocated address blocks enables
allocations/assignments for "critical infrastructure" after the
termination of regular allocations, which will be explained later
section in more details.

iii-b RIR/NIR

Announcing the date of terminating allocations in advance and ensuring
that all allocations before this date will be made according to the
policy at the time enables RIRs/NIRs to make the last allocation without
confusions and avoids causing feelings of unfairness among LIRs and end
users. In addition, consistent policy applied to all RIRs removes bias
towards certain region as well as inter-regional unfairness. The period
which IPv6 support is completed becomes clear, therefore, RIRs/NIRs can
prepare for this.

iii-c End User

As this proposal enables LIRs to prepare for the terminal period of
allocations in advance, it reduces the risk of delays/suspensions of
assignments from LIRs to End Users, and End Users will be able to
continuously receive services from LIRs. As in the case of LIRs, End
Users will be able to prepare for IPv6 support by the date of allocation
termination is clarified. In addition, IPv6 connectivity as well as IPv4
address required during the allocation termination period will be
smoothly secured by LIRs preparing for such period.

As listed above, there will be important, notable benefits for
stakeholders as a result of this policy. It is therefore necessary to
take the following actions to achieve a smooth transfer to IPv6 and
prevent causing instability in the Internet as well as;

    * start discussions on allocation scheme during the exhaustion
      period

    * indicate a roadmap to exhaustion after raising awareness on the
      issue

    * allow enough time for LIRs to plan timing of addressing of their
      networks, submit allocation requests, and consider how to switch
      to an alternative solution

iv.Proposal

iv-a Principles

As the first step to discuss IPv4 exhaustion planning, we would like to
have an agreement (consensus) on the following four principles.

   1. Global synchronisation
   2. To set and announce the date when the allocation is terminated
   3. Not to change the current address policy stricter for the
      extension of IPv4 address lifetime
   4. Separate discussions on "Recycle" issue


1. Global synchronisation:

All RIRs must proceed at the same time to take measures for IPv4 address
exhaustion. This is important not only for ensuring fairness for LIRs
across the regions, but also to prevent confusions such as attempts to
receive allocations from an RIR outside their region. The five RIRs
should facilitate bottom-up discussions, which should be well
coordinated under the leaderships of ICANN ASO and NRO.


2. To set and announce the date when the allocation is terminated:

It is not practical to consider that IPv4 address blocks can be
allocated to the last piece. It is expected to cause confusions if one
party can receive an allocation while the other has to give up, just
with a touch of a difference. The best solution to avoid such confusion
is to set in advance, a date in which one is able to receive an
allocation if requests are submitted before this timeline.

Furthermore, there are few cases where allocations or assignments of
IPv4 address space become absolutely necessary in the future. For
example, requirements to start a translator service between IPv4 and
IPv6 networks should be supported, and there may be some requirements in
the future that are beyond our imagination at this current moment.

As such, a date to stop allocations under the current policy should be
set/defined so that certain number of IPv4 address blocks will be kept
as stocks instead of allocating all blocks without remains.


3. Not to change the current address policy stricter for the extension
of IPv4 address lifetime:

Allocations should be made based on the current policy until the time to
terminate allocations. As the IPv4 Internet has now developed into a
social infrastructure supporting large number of businesses, making
large changes in the current policy towards conservation within the next
one or two years will lead to large-scale confusions, and difficult in
the reality.

4. Separate discussion from "Recycle" issue:

Recovering unused allocated/assigned address blocks is an important
measure, and in fact, it has already be discussed and implemented in
each RIR regions. This issue, however should be considered separately
from this proposal as recovery of a few /8 blocks extends the lifetime
of IPv4 for less than one year while efforts for the recovery is
expected to require substantial time.

iv-b An Example of Detailed Policy to be Implemented

This section provides an example of a proposal in case consensus is
reached on basic principles introduced in section iv-a.

Set the date for termination of allocations and the date of announcement
Set the date to terminate allocations as a general rule, and announce it
a certain period in advance. Define the date of announcement as "A-date"
and the date to terminate allocations as "T-date". The two dates will be
set as follows:

A-date (Date of Announcement):

    * The day in which the IANA pool becomes less than 30*/8
    * RIRs must announce "T-date" on this day, which is defined later

      (*) There will be no changes in the policy on A-date

T-date (Date of Termination):

    * Exactly two years after A-date
    * 10*/8 blocks should remain at T-date, and defined as two years
      after A-date, based on the current pace of allocations
    * It is however possible to move T-date forward at the point where
      address consumption exceeds the projections during the course of
      two years

      (**) new allocations/assignments from RIRs should terminate on
           T-date as a general rule.
      Allocations or assignments to "critical infrastructure" after
      T-date should be defined by a separate policy.

A-date is set in order to:

    * Allow some grace period for networks to be ready for an
      alternative solution until the termination of allocations.
    * Prevent unfairness among LIRs by clarifying the date, such as not
      being able to receive allocations by a small difference in timing.

The rationale for setting A-date as "when IANA pool becomes less than
30*/8" is as follows:

    * The rate of allocations from IANA to RIRs after 2000 is as
      follows.

      2000 : 4*/8
      2001 : 6*/8
      2002 : 4*/8
      2003 : 5*/8
      2004 : 9*/8
      2005 : 13*/8
      2006 : 10*/8

Approximately 10*/8 has been allocated annually after 2003, and the
consumption is likely to accelerate with rise of the last minute
demands. As it is better to keep minimum stocks of address pool at IANA,
30*/8 is set as the threshold value, and allocations should be
terminated two years after it reaches the value, which ensures that
IANA/RIRs secure the address space for allocations/assignments to
critical infrastructure.

iv-c Effect on RIR Members/NIRs

RIR members are expected to concretely grasp the termination date of
allocations and take actions within their organisation to prepare for
the event.

NIRs (if any in the region) will also terminate allocations to its LIRs
in line with the RIR. Therefore, NIRs will be required to sufficiently
promote and keep the community informed on the date of termination of
allocations, just as it is expected of the RIRs.

v. Authors

Akinori MAEMURA (JPNIC)
Toshiyuki HOSAKA (JPNIC)
Takashi ARANO (Intec Netcore, Inc.)
Kuniaki KONDO (Atelier Mahoroba)
Tomohiro FUJISAKI (NTT)
Kosuke ITO (IRI Ubitech)
Shuji NAKAMURA (IPv6 Promotion Council)
Tomoya YOSHIDA (NTT Communications)
Susumu SATO (JPNIC)
Akira NAKAGAWA (KDDI)

(end of text)