Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] What is our take on the central pool IPv4 exhaustion?

McTim dogwallah at gmail.com
Fri Aug 17 15:36:16 UTC 2007


HI all, this just in from ARIN mailing list.

Please note it is just a policy PROPOSAL, not a policy, though It
looks like they will be proposing it to our community soon.

greetz,

McTim

## * ##


Policy Proposal Name: End Policy for IANA IPv4 allocations to RIRs

Author: JPNIC IPv4 countdown policy team;
                  Akinori MAEMURA
                  Akira NAKAGAWA
                  Izumi OKUTANI
                  Kosuke ITO
                  Kuniaki KONDO
                  Shuji NAKAMURA
                  Susumu SATO
                  Takashi ARANO
                  Tomohiro FUJISAKI
                  Tomoya YOSHIDA
                  Toshiyuki HOSAKA

Proposal Version: 2

Submission Date: 2007/08/17

Proposal type: new

Policy term:renewable

Policy statement:

1) Distribute a single /8 to each RIR at the point when new IANA free
   pool hits 5 */8. This date is defined as "IANA Exhaustion Date".

2) It should be completely left up to each RIR communities to define a
   regional policy on how to distribute the remaining RIR free pool to
   LIRs within their respective regions after "IANA Exhaustion Date".

   Note 1: It is fine for an RIR to continue operations with the
           existing policy if that is the consensus decision of the
           respective RIR community.

   Note 2: Address recovery and re-distribution of recovered address
           space is another important measure for considerations, but
           should be treated as a separate policy proposal from
           distribution of new IANA pool.

3) RIRs should provide an official projection on IANA Exhaustion Date
   to the community through their website, at their Policy Meetings
   and through any other effective means.


Rationale:
[current problem]
There are two major issues in terms of address management if no measures
are taken for IPv4 address exhaustion.

1) Continue applying a global coordinated policy for distribution of the
   last piece(s) of RIR's unallocated address block does not match the
   reality of the situation in each RIR region.

   Issues each RIR region will face during the exhaustion period vary by
   region as the level of development of IPv4 and IPv6 are widely
   different. As a result, applying a global co-ordinated policy may not
   adequately address issues in a certain region while it could be work
   for the others.

   For example, in a region where late comers desperately need even
   small blocks of IPv4 addresses to access to the IPv4 Internet, a
   policy that defines the target of allocations/assignments of IPv4
   address space to be late comers would be appropriate in such region.
   This would allow availablilty of IPv4 address space for such
   requirements for more years.

   Another example comes from difference in IPv6 deployment rate.
   For a region where IPv6 deployment rate is low, measures may be
   necessary to prolong IPv4 address life for the existing business as
   well as for new businesses until networks are IPv6 ready. Some
   regions may have strong needs to secure IPv4 address space for
   translators.

   A globally coordinated policy which addresses all the issues listed
   above to meet the needs for all RIR regions may result in not solving
   issues in any of the regions.

2) LIRs and stakeholders remain unprepared for the situation if they are
   not informed

   If LIRs and the community are uninformed of the exhaustion, their
   services and networks remain unprepared to face the situation at the
   time of exhaustion.

[Objective of the proposal]
This proposal seeks to provide the following solutions to the problems
listed above.

1) RIR community should be able to define their own regional policies on
   how to assign the last piece(s) of allocation block in order to
   address their own regional issues during the exhaustion period.

2) RIRs should provide official projection of the date when LIRs will be
   able to receive the allocations under the current criteria. The
   criteria should remain consistent until this date in order to avoid
   confusion.

[Pros and Cons]
Pros:
+ It allows each RIR community to define a policy on how to distribute
  the last piece(s) of allocations which best matches their situation.

+ It helps LIR better informed of the date when they are able to receive
  allocations from RIRs under the current criteria and prepare for the
  event.

Cons:
+ Concerns could be raised about allocating a fixed size to all RIRs,
  that it artificially fastens the consumption rate of some RIR regions.
  However, its impact is kept to minimum by keeping the allocation size
  to a single /8 which makes merely 3-4 months difference.

+ Concerns could be raised that explicitly allowing regional policies
  will encourage RIR shopping. However, this should not happen if the
  requirements within each region is adequately reflected in each RIR's
  policy through PDP. RIR may also chose to add criteria to prevent LIRs
  from other regions submitting such requests.


Timetable for implementation:
Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy.

# #



More information about the RPD mailing list