Policy Proposal 2007-12 - Staff Assessment
Member Services
info at arin.net
Fri Apr 13 14:22:31 EDT 2007
Policy Proposal 2007-12
IPv4 Countdown Policy Proposal
ARIN Staff Assessment
The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.
I. Proposal
Policy Proposal 2007-12 is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_12.html
II. Understanding of the proposal
ARIN staff understands that this proposal would halt direct IPv4
allocations and assignments from ARIN on the day which is exactly two
years after the day that the IANA pool is equal to 30 /8 IPv4 address
blocks.
III. Issues and concerns
A. ARIN Staff
1. It is unclear what the reference to “There will be no change to
the policy on A-date” is. What does this mean? On this day and in the
future?
2. What happens to customers who come in after T-date to request
IPv4 space? Do we deny these requests? Do we recommend IPv6? Do we do
nothing? How can we deny a legitimate request when v4 resources still
exist?
3. Author did not indicate placement. Could be put in as new
section 4.9 of the NRPM Section 4.9. Also, that section would need a
heading, perhaps, "Availability of IPv4 Address Space".
4. Need to make clear this applies to both assignments and allocations.
5. Change text that says "RIRs must" to "ARIN must". And references
such as, "set the date" to "ARIN will set the date…"
6. Change /8 references to have amounts written out, such as
"10*/8" to "ten /8s".
7. The following text lacks criteria and detail, "- It is however
possible to move T-date forward at the point where address consumption
exceeds the projections during the course of two years". Who decides,
what projections, how much?
8. Remove "Allocations or assignments to "critical infrastructure"
after T-date should be defined by a separate policy."
9. Prior to T date, there may be an increase in requests, perhaps
necessitating more staff.
10. What happens to reserved space?
11. If IPv4 is replaced by IPv6 then one could assume that
organizations would return their IPv4 back to ARIN and that space would
be available for reallocation. However, this policy would effectively
preclude ARIN from reusing this returned space.
12. The proposal would hasten the loss of revenue by approximately
12% per year (4% if the IPv6 fee waiver was lifted).
B. ARIN General Counsel
This proposal addresses an important policy issue that is worthy of
extended debate and consideration, but it proposes to do so in a way
that may inadvertently create profound legal issues that would
dramatically increase ARIN's potential legal liabilities. The policy
proposes to set a hard date to terminate IPv4 allocations. Adoption and
implementation of such a policy has a clear legal impact: it could, for
example, be deemed a denial of service by ARIN, which is a utility
provider of such services. For example, if IPV4 is exhausted and
unavailable from IANA, there is little or no legal risk to ARIN.
However, there are dramatically increased risks to ARIN associated with
refusing to provide IPv4 addresses if ARIN has such addresses available,
and is refusing to issue any of them to anyone based on a well
intentioned but absolute policy.
ARIN's legal counsel will need to carefully evaluate any policy which
results from this activity. Based on my current understanding, and I am
willing to constantly reconsider and do additional research, I am
likely to recommend that ARIN not adopt such a policy in its current
form because of the profound legal risks it creates. This is one of the
few times my advice prior to consideration of a policy has been so
direct.
IV. Resource Impact - Minimum
The resource impact of implementing this policy is viewed as minimum.
Barring any unforeseen resource requirements, this policy could be
implemented within 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees. Determining A and T dates assumes
coordination among the RIRs. Implementation would not require the
acquisition of staff personnel or equipment. It will require the following:
- Revisions to registration guidelines
- Staff Training
Respectfully submitted,
Member Services
American Registry for Internet Numbers (ARIN)
##*##
Annex A
Policy Proposal 2007-12
IPv4 Countdown Policy Proposal
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
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 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.
Rationale:
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
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.
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
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 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
allocations.
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
ISP.
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
this.
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
period,
- 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
principles.
--------------------------------------------------------------------
(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
separately.
--------------------------------------------------------------------
(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
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.
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
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.
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
policy.
More information about the Info
mailing list