[sig-policy] prop-056-v001: IPv4 soft landing
The proposal 'IPv4 soft landing' has been sent to the Policy SIG for
review. It will be presented during the Policy SIG sessions at APNIC 25
in Taipei, Taiwan, 25-29 February 2008.
The proposal's history can be found at:
http://www.apnic.net/policy/proposals/prop-056-v001.html
We invite you to review and comment on the proposal on the mailing list
before the meeting.
The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to:
- Ask the proposer questions if anything in the proposal is
unclear
- Point out advantages and disadvantages you see in the proposal
- State whether you support or oppose the proposal
Mailing list discussions will be taken into account when the proposal
is discussed at the upcoming APNIC meeting. So please make sure you have
your say.
APNIC Policy SIG Chairs
Toshiyuki Hosaka
Randy Bush
Jian Zhang
________________________________________________________________________
prop-056-v001: IPv4 soft landing
________________________________________________________________________
Author: David Conrad
Version: 1
Date: 24 January 2008
1. Introduction
----------------
This is a proposal to tighten the criteria for receiving subsequent
IPv4 allocations from APNIC.
The rationale for this proposal is threefold:
- to prolong the availability of IPv4 addresses for requesters who
can provide sufficient justification;
- to encourage the deployment of IPv6 as an alternative to IPv4 by
making the requirements to justify IPv4 allocations increasingly
stringent over time;
- to promote the more efficient use of increasingly scarce IPv4
resources.
2. Summary of current problem
------------------------------
Under current policies, the administrative cost of obtaining IPv4
addresses will not track the scarcity of that resource. As IPv4
becomes increasingly scarce, the lack of an increased administrative
(or financial) cost in obtaining addresses will likely result in
increased pressure on the resource that could have negative
implications (e.g., "land rush" behavior).
At the same time, IPv6 has not gained significant traction in
deployment. Since the IETF community has determined that the best
course moving forward to avoid constraining Internet growth is to
deploy IPv6, efforts should be undertaken to encourage IPv6 deployment.
3. Situation in other RIRs
----------------------------
This proposal has been submitted in the ARIN region and will be
submitted in the other regions in the near future.
4. Details of the proposal
----------------------------
4.1 Overview of proposal
It is proposed that APNIC institute a set of IPv4 address
allocation "phases" that vary the requirements for address allocation
using the amount of address space remaining unallocated by IANA as
a metric.
As the amount of address space in the IANA free pool is reduced,
the requirements for IPv4 address allocation are made more stringent.
When an ISP requests additional IPv4 address space from APNIC:
1. ISPs must meet the utilization requirements of the IPv4 address
allocation phase APNIC was in when the request was submitted.
2. Depending on the IPv4 address allocation phase APNIC was in
when the request was submitted, the requestor may need to
meet additional requirements.
Additional requirements include completing a survey on IPv6
deployment plans, documentation of non-private address space
used for internal infrastructure, documentation of IPv6
plans for offering connectivity and services, etc.
3. APNIC can begin the process of approving a request for
additional addresses after all requirements are met and the
requester's prior utilization is verified to meet the
requirements specified in the IPv4 address allocation phase
in which the request was received.
4.2 IPv4 allocation phases
The proposal creates a set of IPv4 address allocation "phases" that
are triggered when number of remaining /8s in the IANA free pool
reach certain thresholds.
The four phases require the requester to demonstrate increasingly
efficient utilisation of previously allocated IPv4 address space,
including all space reassigned to their customers.
The allocation phases will move through phase 0 to 3 based on the
number of /8s that are at or below the threshold specified for
each phase.
Phase 0
-------
Threshold: Greater than 40 /8s
Requirements:
Requesters must:
1. Demonstrate efficient utilization of 100% of all previous
IPv4 allocations and at least 80% utilization of the most
recent allocation.
2. For downstream customers:
- Demonstrate an immediate requirement of 25% utilization
- Demonstrate a one year requirement of 50% utilization
Phase 1
-------
Threshold: 40 /8s
Requirements:
Requesters must:
1. Provide a response to a survey (individual responses to be
held in confidence by APNIC staff) exploring requester IPv6
transition plans and impediments, anonymized summary data
of which may be published by APNIC.
2. Demonstrate efficient utilization of 100% of all previous
IPv4 allocations and at least 80% utilization of the most
recent allocation.
3. For downstream customers:
- Demonstrate an immediate requirement of 25% utilization
- Demonstrate a one year requirement of 50% utilization
4. Provide a detailed listing of all non-RFC 1918 address
space used for internal infrastructure and how it is used.
Phase 2
-------
Threshold: 25 /8s
Requirements:
Requesters must:
1. Provide a response to a survey (individual responses to be
held in confidence by APNIC staff) exploring requester IPv6
transition plans and impediments, anonymized summary data
of which may be published by APNIC.
2. Demonstrate efficient utilization of 100% of all previous
IPv4 allocations and at least 85% utilization of the most
recent allocation.
3. For downstream customers:
- Demonstrate an immediate requirement of 50% utilization
- Demonstrate a one year requirement of 75% utilization
4. Provide a detailed listing of all non-RFC 1918 address
space used for internal infrastructure and how it is used.
5. Provide plans for migrating all non-RFC 1918 address space
used for internal infrastructure either to IPv6 (preferred)
or to private addressing where possible. Where such
migration is not possible, provide documentation listing
the use of addresses that are not migratable and the reasons
for the inability to migrate.
6. Demonstrate documented plans for availability of production
IPv6 infrastructure and connectivity services within 6
months of submitting the request.
Phase 3
-------
Threshold: 10 /8s
Requirements:
Requesters must:
1. Provide a response to a survey (individual responses to be
held in confidence by APNIC staff) exploring requester IPv6
transition plans and impediments, anonymized summary
data of which may be published by APNIC.
2. Demonstrate efficient utilization of 100% of all previous
IPv4 allocations and at least 90% utilization of the most
recent allocation.
3. For downstream customers:
- Demonstrate an immediate requirement of 75% utilization
- Demonstrate a one year requirement of 90% utilization
4. Provide documentation demonstrating migration (where
possible) of non-RFC 1918 address space used for internal
infrastructure to either IPv6 (preferred) or private
addressing.
5. Provide a detailed listing of all non-RFC 1918 address
space used for internal infrastructure, how it is used, and
why it is not possible to migrate those addresses to either
IPv6 (preferred) or private addressing.
6. Demonstrate availability of production IPv6 infrastructure
and connectivity services.
4.3 Timetable for implementation
This would be implemented immediately upon the endorsement of the
APNIC Executive Council.
Notes:
- Phase 0 reflects current allocation requirements.
- Phases 1 through 3 are to be implemented 30 days after IANA
allocates address space from the IPv4 free pool that reduces that
free pool to a number of /8s that are at or below the threshold
specified.
- If multiple thresholds are crossed within a 30 day period, the
requirements from the last threshold crossed will be applied
to requesters for additional address space at the time of the
request.
- The time for transition between phases of this policy are not
fixed. Rather, they depend on the rate of consumption of IPv4
address space from the IANA free pool. Current RIR operational
procedure is to request 2 /8s from the IANA when the RIR's
current pool of free IPv4 address space is depleted. This
procedure should ensure transitions between phases will have
some lead-time, so organizations can prepare for the next
phase of IPv4 address allocation.
- Given the highly volatile nature of IPv4 consumption and the
inability to define a predictive model rooted in an underlying
theory rather than extrapolating over existing data, the
thresholds chosen are acknowledged to be somewhat arbitrary.
The intent of the chosen values is to provide a "reasonable"
amount of time, approximately 18 months, between transitions
at current consumption rates (approximately 10 /8s per year).
However, it should be explicitly noted that one of the intents
of this policy is to extend the IPv4 free pool lifetime, thus
as the policy becomes effective, the amount of time between
phase transitions would presumably increase.
5. Advantages and disadvantages of the proposal
-------------------------------------------------
Advantages:
This proposal:
- Provides for a smoother transition away from IPv4 towards IPv6;
- Encourages the deployment of IPv6;
- Increases the efficiency of utilization of the IPv4 address
space;
- Reduces the likelihood of a "run" on the remaining free pool of
IPv4 address space;
- Encourages migration of internal infrastructure to either IPv6
or private (e.g., RFC 1918) thereby reserving the scarce IPv4
resources for purposes for which IPv6 or private addresses are
not suitable.
Disadvantages:
This proposal:
- May make it difficult for some ISPs to obtain IPv4 addresses
earlier than would be the case if there was no change in IPv4
allocation policy.
6. Effect on APNIC members
----------------------------
This proposal should result in encouraging APNIC members to migrate
to IPv6 if they require additional IPv4 addresses.
7. Effect on NIRs
-------------------
See "Effect on APNIC members".
Appendix: rationale for this proposal
-------------------------------------
As the lack of significant deployment of IPv6 can attest, the cost of
deploying IPv6 currently outweighs the benefits that protocol would
appear to provide. This proposal aims to encourage the deployment of
IPv6 by over time, making the allocation of IPv4 both more difficult
and contingent on the requester demonstrating both support for IPv6 as
well as requiring a demonstration that the IPv4 address space they
administer is being used efficiently. The goal of these measures is to
rebalance the IPv6 deployment cost/benefit ratio thereby encouraging
greater uptake of IPv6 before the IPv4 free pool is exhausted.
The "IPv4 Soft Landing" policy aims to provide for a smoother transition
away from IPv4 towards IPv6 by imposing increasingly strict requirements
for new address allocations as the amount of address space available in
the IANA unallocated IPv4 address pool decreases. These increased
requirements include both more stringent reassignment and utilization
percentages as well as requiring documented IPv6 infrastructure
services and connectivity provision and the documentation or reuse of
public IPv4 address space used for internal infrastructure.
The increased stringency in the allocation requirements is intended both
to increase the efficiency of utilization of the IPv4 address space and
to reduce the likelihood of a "run" on the remaining free pool of IPv4
address space. APNIC staff would be expected to use the same mechanisms
in use today to verify conformance to the specified requirements.
The requirements for demonstration of IPv6 infrastructure services and
connectivity are intended to motivate ISPs to provide those services
before the only address space they can offer their customers is IPv6,
thereby offering an opportunity to break the "chicken-and-egg" problem
limiting significant IPv6 deployment. Verification of these requirements
can be done by APNIC staff by using IPv6 transport to connect to
published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as
well as using IPv6 ping to identified addresses internal to the ISP.
Obviously, false positive responses for most any objective mechanism
for verifying the availability can be engineered, so APNIC staff may
also consider subjective reports of an inability to obtain IPv6
services by customers as an indicator of (lack of) conformance to this
requirement.
The requirements to migrate internal infrastructure to either IPv6 or
private (e.g., RFC 1918) addressing are intended to improve the
efficiency of utilization of IPv4 address space, reserving the scarce
IPv4 resources for purposes for which IPv6 or private addresses are not
suitable. These requirements acknowledge that pragmatically, the use of
IPv4 is absolutely essential only for servers in client-server
architectures, machines engaged in peer-to-peer applications, and entry
points for NAT/ALG devices. As such, use of IPv4 for purposes such as
router interface numbering, client-only devices, and devices which
should not be available from external networks should be discouraged.
Since there can be circumstances in which migration of internal
infrastructure addresses to private addressing would not be feasible,
this policy allows for requesters to document those situations in
which it is not possible to do the migration.
(end of document)