Message: 2
Date: Wed, 29 Jul 2009 09:11:54 +0200
From: Randy Bush <randy at psg dot com>
Subject: [sig-policy] prop-077: Proposal to supplement transfer policy
of historical IPv4 addresses
To: Policy SIG <sig-policy at apnic dot net>
Message-ID: <m2fxcg0xqd.wl%randy at psg dot com>
Content-Type: text/plain; charset=US-ASCII
Dear SIG members,
The proposal, 'Proposal to supplement transfer policy of historical IPv4
addresses', has been sent to the Policy SIG for review. It will be
presented at the Policy SIG at APNIC 28 in Beijing, China, 25-28 August
2009.
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
express your views on the proposal:
- Do you support or oppose this proposal?
- Does this proposal solve a problem you are experiencing? If
so, tell the community about your situation.
- Do you see any disadvantages in this proposal?
- Is there anything in the proposal that is not clear?
- What changes could be made to this proposal to make it more
effective?
Information about this and other policy proposals is available from:
http://www.apnic.net/policy/proposals
Randy, Jian and Ching-Heng
________________________________________________________________________
prop-077-v001: Proposal to supplement transfer policy of historical IPv4
addresses
________________________________________________________________________
Authors: Wendy Zhao Wei
<zhaowei at cnnic dot cn>
Jane Zhang
<zhangjian at cnnic dot cn>
Terence Zhang Yinghao
<zhangyinghao at cnnic dot cn>
Version: 1
Date: 29 July 2009
1. Introduction
----------------
This policy proposal seeks to supplement current policy for the transfer
of historical Internet resources, by requiring recipients of transferred
historical IPv4 address space to justify its use or subjected to the
justification criteria of transfer policy of current IPv4 resources.
2. Summary
-----------
Under current policy, transfers of historical resources to current APNIC
members are recognized and registered by APNIC; APNIC does not require
any technical review or approval of the resource's current use
to approve the transfer.
This may allow the opportunity for an organization to stockpile IPv4
address space without any actual demand, which is contrary to the
current goal of address space management.
3. Situation in other RIRs
---------------------------
AfriNIC:
If an LIR plans to exchange or transfer address space, it needs to
contact AfriNIC so that the changes are properly registered. The LIR
remains responsible for all the allocations registered in the
AfriNIC database until they have been transferred to another LIR or
returned to AfriNIC. There is no requirement to justify the
transfer.
ARIN:
ARIN has two different transfer policies:
1. Mergers and acquisitions
Under this policy, organizations must show documentation that
justifies use of the resources. However, organizations do not
need to meet the current criteria for receiving IPv4 addresses
to justify the transfer of historical space as part of a merger
or acquisition. The recipient has the option of signing either
the Legacy Resource Services Agreement or the standard Resource
Services Agreement.
2. Transfers to specified recipients
Under this policy, historical resources, like current resources,
must first be returned to ARIN. The space can be transferred only
if the recipient can demonstrate the need for the resources under
current ARIN policies. The recipient must sign the standard
Resource Services Agreement.
LACNIC:
LACNIC permits transfers of historical IPv4 resources in cases of
mergers and acquisitions only. Organizations must show documentation
that they are not only transferring IP addresses but also equipment
and end users of the IP addresses. In these cases, organizations do
not need to meet the current criteria for receiving IPv4 addresses
to justify the transfer of historical space as part of a merger or
acquisition. Once historical resources have been transfered this
way, they are considered to be "current".
RIPE:
Member LIRs can transfer complete or partial blocks of historical or
current IPv4 addresses. Such address space must not contain any
block that is assigned to an end user. An LIR may only receive a
transferred allocation after their need is evaluated and approved by
the RIPE NCC according to the existing allocation policies. LIRs
that receive a transfer from another LIR cannot re-allocate complete
or partial blocks of the same address space to another LIR within 24
months of receiving the re-allocation.
4. Details
-----------
It is proposed to modify the current policy for the transfer of
historical Internet resources, it is proposed that:
4.1 Until the allocation principles of the "final /8" policy [1] take
effect, transfers of historical IPv4 address must meet the
justification criteria of applied to transfers of current IPv4
address space, if such a policy exists;
4.2 If a transfer policy for current IPv4 transfers does not exist,
then the recipient of a transfer of historical IPv4 address must
justify use of the transferred space using the allocation and
assignment policies in force at the time of the transfer.
4.3 After the allocation principles of the "final /8" policy [1] take
effect, no justification is needed to transfer historical resources.
5. Pros/Cons
-------------
5.1 Advantages
The utilization of historical IPv4 addresses will comply with
address management policy for current resources.
5.2 Disadvantages
None.
6. Effect on APNIC members
---------------------------
All APNIC members will have to justify transfers of historical IPv4
addresses they receive, or subjected to justification criteria of
transfer policy of current IPv4 resources.
7. Effect on NIRs
------------------
The proposal has no direct impact on NIRs, but impacts members of NIRs
in the same way it impacts APNIC members.
8. References
--------------
[1] See section 9.10, "Policies for IPv4 address space
management in the Asia Pacific region"
http://www.apnic.net/policy/add-manage-policy.html#9.10
------------------------------
Message: 3
Date: Wed, 29 Jul 2009 09:12:23 +0200
From: Randy Bush <randy at psg dot com>
Subject: [sig-policy] prop-078: Reserving /10 IPv4 address space to
facilitate IPv6 deployment
To: Policy SIG <sig-policy at apnic dot net>
Message-ID: <m2eis00xpk.wl%randy at psg dot com>
Content-Type: text/plain; charset=US-ASCII
Dear SIG members,
The proposal, 'Reserving /10 IPv4 address space to facilitate IPv6
deployment', has been sent to the Policy SIG for review. It will be
presented at the Policy SIG at APNIC 28 in Beijing, China, 25-28 August
2009.
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
express your views on the proposal:
- Do you support or oppose this proposal?
- Does this proposal solve a problem you are experiencing? If
so, tell the community about your situation.
- Do you see any disadvantages in this proposal?
- Is there anything in the proposal that is not clear?
- What changes could be made to this proposal to make it more
effective?
Information about this and other policy proposals is available from:
http://www.apnic.net/policy/proposals
Randy, Jian and Ching-Heng
________________________________________________________________________
prop-078-v001: Reserving /10 IPv4 address space to facilitate IPv6
deployment
________________________________________________________________________
Authors: Terence Zhang Yinghao
<zhangyinghao at cnnic dot cn>
Jane Zhang
<zhangjian at cnnic dot cn>
Wendy Zhao Wei
<zhaowei at cnnic dot cn>
Version: 1
Date: 29 July 2009
1. Introduction
----------------
This proposal seeks to ensure some small blocks of IPv4 space will
remain available to LIRs for a long time to ease the co-existence of
IPv4 and IPv6 and to facilitate IPv6 deployment.
It is proposed that when APNIC receives its last /8 IPv4 allocation from
IANA, a contiguous /10 IPv4 block will be set aside and dedicated to
facilitate IPv6 deployment.
2. Summary of the current problem
----------------------------------
The IPv4 address pool is expected to be depleted in the near future, but
the Internet will still use IPv4 for many years during the adoption of
IPv6, during this period, LIRs will need to connect to the IPv4 Internet
while they deploy services using the IPv6 Internet.
APNIC's current "final /8" policy [1] prevents any one organization
consuming too many IPv4 address from the final /8, which ensure new LIRs
can participate in the IPv4 Internet. However, the final /8 policy
does not require LIRs to deploy IPv6. Therefore, it is possible that
LIRs use those allocated address entirely for IPv4 services. Later, when
they intend to deploy IPv6, they will have no chance to get another IPv4
allocation from APNIC under the "final /8" policy, even if there are
a certain amount of unallocated IPv4 addresses remaining in APNIC's
pool. Instead, the LIR would have to re-organize their IPv4 network to
set aside some addresses. This would impact their progress in IPv6
deployment.
To remedy this problem, this policy proposal seeks to encourage LIRs to
deploy IPv6 and ensure IPv4 space will remain available for LIRs' IPv6
deployment.
3. Situation in other RIRs
---------------------------
ARIN has adopted a similar policy:
2008-5: Dedicated IPv4 block to facilitate IPv6 Deployment
https://www.arin.net/policy/proposals/2008_5.html
RIPE has similar policy proposal under discussion:
2009-04: IPv4 Allocation and Assignments to Facilitate IPv6
Deployment
http://www.ripe.net/ripe/policies/proposals/2009-04.html
AfriNIC and LACNIC currently have no similar policies or proposals.
4. Details
-----------
It is proposed that when APNIC receives its last /8 IPv4 allocation from
IANA, a contiguous /10 IPv4 block from the /8 will be set aside and
dedicated to facilitate IPv6 deployment.
Allocations and assignments from this dedicated /10 block must be
justified by immediate IPv6 deployment needs; examples of such needs
include: IPv4 addresses for key dual stack devices, NAT-PT or NAT464
translators, etc.
The size of each allocation from this /10 block is /24, or APNIC's
minimum allocation size in force at time of the allocation, which ever
is smaller.
Each LIR may apply for and receive the specified allocation size
regardless of LIR size or intended membership tier.
In order to receive a first allocation or assignment under this policy:
1. The applicant must demonstrate immediate IPv6 deployment needs,
especially for IPv6 to IPv4 internetworking.
2. The applicant must either have existing IPv6 addresses or valid
application for IPv6 addresses.
3. The applicant must be a current APNIC account holder or a member
of an NIR.
In order to receive subsequent allocation or assignment under this
policy:
1. The applicant must demonstrate immediate IPv6 deployment needs,
especially for IPv6 to IPv4 internetworking.
2. The applicant may not have received resources under this policy
in the preceding 12 months.
3. Previous allocations/assignments under this policy must be
strictly used to facilitate IPv6 deployment, and the utilization
rate is higher than 75%;
4. The utilization rate of previous allocations/assignments of other
IPv4 addresses allocated from APNIC must reach 80%, or APNIC's
current IPv4 allocation policy required utilization rate at the
time of the allocation.
5. The applicant must be a current APNIC account holder or a member
of an NIR.
Allocations under this policy do not affect an LIR's eligibility to
apply for IPv4 addresses under the "final /8' policy", and vice versa.
5. Pros/Cons
-------------
5.1 Advantages:
- This proposal will encourage IPv6 deployment as it ensures LIRs
can receive dedicated IPv4 address space from the APNIC if they
have an immediate need to deploy IPv6.
- The dedicated /10 block provides 16,384 allocations, which ensures
that no organization lacks IPv4 address space for IPv6 deployment
for many years.
5.2 Disadvantages:
- There is a remote possibility that, after setting aside one /10
under this proposal, the remainder of the last /8 may be used
up. If that were to happen, LIR would need to have immediate IPv6
deployment needs to qualify for IPv4 addresses from APNIC.
However, with 12,288 possible allocations from the current minimum
allocation (at time of writing), and considering that the
projection of APNIC members in 2013 is 4000, it is not likely the
12,288 allocations will be used up. In addition, if it does
happen, applying for IPv4 address without any intent to deploy
IPv6 is not practical.
Also, the size of allocation under this policy (/24) can be
reduced to suit future needs, if necessary.
6. Effect on APNIC members
---------------------------
This proposal allows APNIC LIRs (existing and new) to receive dedicated
IPv4 address space from APNIC to facilitate IPv6 deployment.
7. Effect on NIRs
------------------
This proposal has no direct impact to NIRs. NIR members (existing and
new) can receive dedicated IPv4 address space from APNIC to facilitate
IPv6 deployment.
8. References
-------------
[1] See section 9.10, "Policies for IPv4 address space
management in the Asia Pacific region"
http://www.apnic.net/policy/add-manage-policy.html#9.10
9. Appendix A
-------------
Reason for reserving a contiguous /10
The IPv6 Internet may take a long time to develop, and since IPv4
and IPv6 may co-exist for many years, the demand for IPv6 to IPv4
internetworking will be sustained for many years.
The intention of the proposal is to stimulate native IPv6 deployment
as much as possible, while supporting the need for IPv6 networks to
communicate with the IPv4 world.
The current policy for allocations from the "final /8" will provide
16384 allocations. Setting aside a /10 from that /8 will reduce the
allocations to 12288. Since currently APNIC has about 2000 members
and is projected to have 4000 members in 2013, it is feasible to set
aside a /10 to encourage and ensure IPv6 deployment.
The dedicated /10 block itself can provide 16384 allocations with
the /24 maximum allocation size. This, in addition to the
requirements of a 12-month interval between allocations from this
block and a 75% utilization rate for previous allocations from this
/10 before additional allocations from this block can be made, would
prevent hoarding and ensure this pool will last many years.
Reason for /24 allocation size
Allocations under this policy are mainly for IPv6 to IPv4
internetworking purpose, such as IPv4 addresses for key dual stack
devices, NAT-PT or NAT464 translators, etc. Therefore, we need only
a few addresses to do the job. In most cases we can foresee, a /24,
or even a /27, can perfectly satisfy the deployment needs for one
organization.
The reason we choose /24 is we do not want to create longer prefixes
in the Internet routing table just because of this policy. Based on
knowledge of current Internet's route filtering culture, we believe
/24 is the most generally accepted longest prefix currently.
Of course, it is possible routing practices will change when we are
running out of IPv4. Therefore, in the future, if longer route
prefixes are more generally accepted, or a smaller minimum
allocation size takes effect, we can certainly reduce the size of
allocation under this policy to suit future needs, and ensure more
allocations from this block are possible.
Finally, a relatively larger allocation size will minimize the
possibility of an organization getting multiple non-contiguous small
blocks in multiple allocations.
------------------------------
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy
End of sig-policy Digest, Vol 62, Issue 20
******************************************