[ppml] Policy Proposal: IPv4 countdown policy proposal

Member Services info at arin.net
Thu Feb 22 10:59:06 EST 2007

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The AC will review this proposal and may decide to:

1. Accept the proposal as a formal policy proposal as it is presented;

2. Work with the author to:
      a) clarify the language or intent of the proposal;
      b) divide the proposal into two (2) or more proposals; or
      c) combine the proposal with other proposals; or,

3. Not accept the proposal as a formal policy proposal.

The AC will review this proposal at their next meeting. If the AC
accepts the proposal, then it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting. If the AC
does not accept the proposal, then the AC will explain that decision;
and at that time the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:

Mailing list subscription information can be found at:


Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Policy Proposal Name: IPv4 countdown policy proposal

Author: Toshiyuki Hosaka (Japan Network Information Center (JPNIC))

        Takashi Arano (Intec Netcore, Inc.)
        Kuniaki Kondo (Atelier Mahoroba)
        Tomohiro Fujisaki (NTT)
        Akinori Maemura (JPNIC)
        Kosuke Ito (IRI Ubitech)
        Shuji Nakamura (IPv6 Promotion Council)
        Tomoya Yoshida (NTT Communications)
        Susumu Sato (JPNIC)
        Akira Nakagawa (KDDI)

Proposal Version: 1

Submission Date: 22 February 2007

Proposal type: new

Policy term: renewable

Policy statement:

-  Set the date for termination of (IPv4) 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

          (*) 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

           - It is however possible to move T-date forward at the point
             where address consumpution 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.


   1.  Introduction

      The exhaustion of IPv4 address is approaching round the corner.
      Geoff Huston's latest projection at Potaroo (as of January 6,
      2007) (http://www.potaroo.net/tools/ipv4/) draws the date of IANA
      pool exhaustion as 31st May 2011, and that of RIR pool as 14th
      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

      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.

   2.  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 are taking place on any of the RIR's policy fora.
      (we have submitted the same proposal to APNIC on January 2007)

      This section lists possible problems if no policies are defined
      to prepare for the terminal period of allocations.

      2-1.  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

       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

       As new IPv4 address allocations space will no longer be
       available, LIRs have no choice but to build networks based on
       IPv6. 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.

      2-2.  RIR/NIR

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

      2-3.  End users

       End users generally receive address assignments from ISPs
       accompanied with Internet connection service. If an ISP no longer
       has IPv4 address space available, nor unable to provide IPv6
       service, end users will not be able to receive services from that

       Moreover, if the terminal date of allocations remains ambiguous,
       it may leave end users behind to prepare for IPv6 ready network.

   3.  Benefits

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

      3-1.  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.

      3-2.  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

      3-3. 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 enduers, 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
          - indicate a roadmap to exhaustion after raising awareness on
            the issue, and
          - allow enough time for LIRs to plan timing of addressing of
            their networks, submit allocation requests, and consider
            how to switch to IPv6.

   4.  Proposal principles

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

	(1) Global synchronization:
              All five RIRs will proceed at the same time for measures
              on IPv4 address exhaustion.
	(2) Some Blocks to be left:
              Keep a few /8 stocks instead of distributing all.
	(3) Keeping current practices until the last moment :
              Maintain the current policy until the last allocation.
	(4) Separate discussions on "Recycle" issue :
              Recovery of unused address space should be discussed

         (1) Global synchronization:

           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 alsot 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) Some blocks to be left:

           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) Maintaining current practices until the last moment :

           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

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

   5.  Rationale for "A-date" & "T-date"

      A-date is set in order to:

       - Allow some grace period and period for networks to be IPv6
         ready 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

			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.

   6.  Effect on RIR members

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

Timetable for implementation: Immediate after all 5 RIRs ratified this

More information about the ARIN-PPML mailing list