Dear SIG members
The proposal "prop-102-v001: Sparse allocation guidelines for IPv6
resource allocations" has been sent to the Policy SIG for review.
It will be presented at the Policy SIG at APNIC 33 in New Delhi, India,
Thursday, 1 March 2012.
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
Andy, Skeeve, Masato
------------------------------------------------------------------------
prop-102-v001: Sparse allocation guidelines for IPv6 resource
allocations
------------------------------------------------------------------------
Author: Dean Pemberton
<dean at deanpemberton dot com>
Co-authors: None at present
Co-authors welcome
1. Introduction
----------------
This proposal formalises the current use of a sparse allocation strategy
when allocating IPv6 resources from the APNIC free pool. This also has
the effect of bringing the algorithm and its parameters under the
oversight of the APNIC policy development process.
The proposal also seeks to give members some assurance that if they are
able to show a growth plan for 5 years upon applying for an initial 2
year assignment, that subsequent assignments will be allocated from a
sufficiently sized, sparsely allocated block.
2. Summary of the current problem
----------------------------------
Large networks and economies are requesting blocks of IPv6 space larger
than the current allocation models allow. At present the allocation
strategies look at a timeline on the order of 1-2 years. Organisations
are now having to look to a 5-10 year time-frame when deploying large
IPv6 networks.
They are understandably concerned about their ability to secure access
to 5-10 years of aggregatable address space if they are only allocated
on 1-2 year needs basis. We have seen requests in proposals such as
prop-98, prop-99 and prop-100, which seek to find ways to allow for
larger allocations or reserve an amount of space for future
organisational use. All of these proposals seek to make large changes to
the way that IPv6 addresses are allocated by APNIC in order to address
these legitimate concerns.
It would seem however that there is an alternative solution which would
only require a small change to current operating procedure.
At present the APNIC operating procedure is for hostmasters to use a
method of sparse-allocation when allocating IPv6 addresses out of the
APNIC free pool. An in depth discussion of sparse-allocation, and indeed
the implementation used by APNIC is beyond the scope of this proposal.
Suffice to say however, that sparse-allocation allows for allocations to
be given from a larger pool in such a way that members can request
neighbouring allocations at a later date and aggregate these together in
to a larger routable allocation.
While this has been APNIC operating procedure for some time, it is not
subject to oversight by any particular APNIC policy. As such the exact
algorithm used as well as the parameters around this sparse-allocation
algorithm are not open to member input or adjustment through the policy
development process.
While members may surmise that a neighbouring allocation may be waiting
for them should they need it, this is not guarenteed and therefore can
not be used as part of the members future planning process.
3. Situation in other RIRs
---------------------------
Unknown at this point - Investigation under way
4. Details
-----------
This proposal seeks to make the following additions/changes to APNIC
policy
1. Mandate the use of sparse allocation when allocating IPv6
resources from APNIC address pools
2. Publish the details of the sparse allocation algorithm and
ensure that it is able to be debated through the existing policy
development framework.
3. Ensure that if a member can show a growth plan for the next 5
years that this amount is sparsely allocated when an allocation
is made under existing apnic-089-v010 guidelines.
5. Pros/Cons
-------------
Advantages:
- APNIC Members are able to ensure that they will receive
aggregatable blocks within a 5 year growth projection. They can
use this surety in their internal network planning processes.
- APNIC Members will have the surety that the current sparse
allocation mechanism will continue to be used.
- Rather than simply providing a member with an allocation of 5
years worth of space which may go unused due to imprecise
planning. Under this proposal, the majority of the space remains
in the APNIC free pool and can be reallocated after the 5 year
sparse allocation window expires.
Disadvantages:
- It is possible that this proposal may require APNIC to keep a
larger pool in reserve that previously. This could be modelled
using information from the secretariat.
6. Effect on APNIC Members
-------------------
APNIC members would be able to see the published details of the sparse
allocation policy used by APNIC to allocate IPv6 resources from its
address pool.
APNIC members would apply for address space much like they do today and
an allocation would be made under the same rules as apnic-089-v010. The
only different would be that if the member can show a growth estimate
for up to 5 years, APNIC will allocate their resources from a sparse
allocation to accommodate this growth and future resource requests.
7. Effect on NIRs
------------------
The policy would apply when NIRs request address space from APNIC
The proposal allows NIRs to choose when to adopt this policy for their
Members.
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy