Keyboard Shortcuts
Thread View
j
: Next unread messagek
: Previous unread messagej a
: Jump to all threadsj l
: Jump to MailingList overview

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
________________________________________________________________________
prop-090-v001: Optimizing IPv6 Allocation Strategies ________________________________________________________________________
Author: Owen DeLong
Version: 1
Date: 12 January 2011
1. Introduction - ----------------
This is a proposal to change how the size of IPv6 allocations and end site assignments are determined, allowing more room for LIRs to grow within their allocation, while also preventing excessive address consumption. The proposal also assists to prevent potential human errors in configuration that can be caused by the current IPv6 policies, which allow allocations and assignments to be made on non-nibble boundaries.
2. Summary of the current problem - ----------------------------------
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6 address block.
This assumption has led to such problems as end user customers receiving single /64s, minimal /60s, or even /56s. If the practice of unnecessarily limited address spaces becomes widespread, vendors will not produce the innovations that are possible in home networking with larger address spaces. Just as NAT has delayed or prevented many forms of innovation in IPv4, small customer assignment sizes could seriously reduce innovation in IPv6.
If this proposed policy were to be implemented, in 50 years, the projected IPv6 free pool would be 99.54% of total IPv6 space vs 99.9975% if the current policy were still in place at that time. Given the small amount of extra IPv6 addresses that would be consumed by implementation of this proposed policy, it would be a shame for innovation to be stifled by continuing the current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in calculating the end address of the prefix. For example, if a network were allocated
2001:0db8::/30
The LIR would need to calculate that the end address of that /30 was
2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff
However, even experienced engineers can make mistakes when making such calculations. In fact, to clarify the problem, as I was writing the above example, I initially made the mistake of calculating the end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff.
When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also eventually lead to unnecessary disaggregation and larger routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in the community.
Therefore, this proposal replaces the HD ratio with simple ratios for utilization thresholds and reduces the frequency with which utilization thresholds would need to be calculated.
3. Situation in other RIRs - ---------------------------
ARIN:
Submitted. Currently undergoing a process of staff review before being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations, the author currently has no intention of submitting this proposal to RIPE. However, the author may eventually submit a proposal to RIPE to address the problem of non-nibble boundary allocations.
4. Details - -----------
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates customer connections, including, but not limited to Points of Presence (POPs), Datacenters, Central or Local switching offices or regional or local combinations thereof.
Provider The prefix of the smallest IPv6 block a given ISP assignment assigns to end sites. unit:
Nibble A network mask which aligns on a 4-bit boundary. boundary: This means that the prefix length must be divisible by 4. For example, /24, /28, /32, and /48 are all aligned on a nibble boundary while /22, /26, /29, /30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or a single tenant within a multi-tenant structure
- The aim of this more generous interpretation of end site to provide a clear definition which is easily understood and provides maximum flexibility for service providers to meet the needs of their customers.
Utilized: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end site.
(ii) The utilization percentage of a block at the LIR level is calculated as the fraction of total provider assignment units which have been assigned to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries makes it easier for end addresses of IPv6 blocks to be calculated.
For example, if the next allocation one size larger than /32 is /28, then, 2001:0db0::/28 has an end address of:
2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff
Allocating and assigning on nibble boundaries also makes DNS delegations easier.
4.4 Change the size of initial allocations to LIRs according to the following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32, unless the LIR specifically requests a /36.
4.4.2 The maximum allocation unit shall be the smallest block which:
- Is nibble-boundary aligned - Permits the largest serving site to be assigned a large enough block to allow <=0.75 (75%) utilization - Can provide an equal-sized block to each serving site - Permits each serving site's block to be nibble-boundary aligned
This can be summarized as /N where:
N = 48-(X+Y) where:
X is a multiple of 4 such that 2^X is greater than 4/3*(serving sites)
Y is a multiple of 4 such that 2^Y is greater than 4/3*(end sites served by the largest serving site)
In addition:
(i) An end site which can justify more than a /48 under the current end-user assignment policy [1] shall count as the appropriate number of /48s that would be assigned under that policy.
(ii) An LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as APNIC. In such a case, the prefixes necessary for such an allocation shall be treated as fully utilized in determining the block sizing for the parent LIR.
(iii) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3:
4.5.1 The LIR:
- Has a previously justified IPv4 allocation from APNIC, OR
- Has a previously justified IPv4 allocation from one of APNIc's predecessor registries, OR
- Can qualify for an IPv4 ISP allocation under current APNIC criteria.
4.5.2 The LIR:
- Will be making reassignments to other organizations AND
- Is currently multihomed for IPv6, OR - Will immediately become multihomed for IPv6 using a valid assigned global AS number
4.5.3 The LIR must provide APNIC a reasonable technical justification of why an allocation is necessary including:
- The intended purposes for the allocation - A description of the network infrastructure the allocation will be used to support. - A plan detailing assignments to other organizations or customers for one, two, and five year periods, with a minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of the following two criteria:
- Utilization of 75% or more of their total address space, OR - One the LIR/ISP's serving sites has a 90% utilization rate
Note: the process for calculating the utilization rate is detailed in Appendix A.
When making subsequent allocations to LIRs, APNIC will follow the allocation procedure below:
- Wherever possible, APNIC will make an allocation that expands one or more existing allocations.
- Where APNIC cannot expand one or more existing allocations, APNIC shall make a new allocation based on the initial allocation criteria described in section 4.5 above.
When this occurs, the LIR is encouraged, but not required, to renumber into the new allocation over time and return any allocations no longer in use. In such a case, it is legitimate for an end-site to have assignments from as many as two of these blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end users
The recommended provider assignment unit is /48. In no case will policy consider a provider assignment unit larger than /48. Instead, if an LIR/ISP chooses to assign more than a /48 to an end site, that will be considered to be multiples of the provider assignment unit.
If the LIR/ISP chooses to have a provider assignment unit smaller than a /48, then calculations of its address space utilization will accordingly use the smaller prefix size.
An LIR may issue up to a /48 to an end site without requiring justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their allocation size if they are eligible for a larger block under the allocation criteria suggested in this proposal.
Any LIR which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years.
If possible, APNIC will simply expand their existing allocation rather than requiring renumber and return.
5. Pros/Cons - -------------
Advantages:
- Provides nibble-boundaries for direct allocations and for at least one level of network hierarchy within the LIR, reducing the potential for human factors errors.
- Increases the potential for network aggregation by issuing very large blocks to ISPs.
- Reduces the potential for harmful under-sized assignments to end users by removing any incentive to do so.
- Simplifies the IPv6 allocation policy by removing logarithmic computations in favor of simple ratios.
- Reduces the number of times any given LIR will need to return to APNIC for additional allocations.
- Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50 years, free pool drops from 99.9995% to 99.62%.
6. Effect on APNIC - -------------------
APNIC LIR members will be able to obtain significantly larger blocks of IPv6 addresses and both receive and make their allocations and assignments on nibble boundaries to simplify human factors and network management while improving aggregation.
7. Effect on NIRs - ------------------
This policy should not significantly impact NIRs.
8. References - --------------
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy' http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A - ----------
In general, the following formula is used to calculate the utilization rate in IPv6:
No. of provider assignment units assigned Utilization % = ----------------------------------------- x 100 Total no. of provider assignment units within allocation block(s)
However, there may be occasions when the calculation may need to be amended if an LIR is in the process of renumbering out of an earlier IPv6 block into a subsequent block from APNIC. If this is the case, the following is permitted:
- An LIR can count provider assignment units made to end sites in both the original and newer block into which the LIR is in the process of renumbering into.
- The LIR can count assignments made to serving sites in both the original and newer block into which the LIR is in the process of renumbering into.
This double-counting during renumbering means that APNIC would always allocate enough space to an LIR to encompass both existing customers and growth of the LIR within a single new aggregatable block.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to
the Policy SIG for review. It will be presented at the Policy SIG at
APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
________________________________________________________________________
prop-090-v001: Optimizing IPv6 Allocation Strategies
________________________________________________________________________
Author: Owen DeLong
Version: 1
Date: 12 January 2011
1. Introduction
- ----------------
This is a proposal to change how the size of IPv6 allocations and end
site assignments are determined, allowing more room for LIRs to grow
within their allocation, while also preventing excessive address
consumption. The proposal also assists to prevent potential human errors
in configuration that can be caused by the current IPv6 policies, which
allow allocations and assignments to be made on non-nibble boundaries.
2. Summary of the current problem
- ----------------------------------
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6
address block.
This assumption has led to such problems as end user customers
receiving single /64s, minimal /60s, or even /56s. If the practice
of unnecessarily limited address spaces becomes widespread, vendors
will not produce the innovations that are possible in home
networking with larger address spaces. Just as NAT has delayed or
prevented many forms of innovation in IPv4, small customer
assignment sizes could seriously reduce innovation in IPv6.
If this proposed policy were to be implemented, in 50
years, the projected IPv6 free pool would be 99.54% of total
IPv6 space vs 99.9975% if the current policy were still in place
at that time. Given the small amount of extra IPv6 addresses that
would be consumed by implementation of this proposed policy, it
would be a shame for innovation to be stifled by continuing the
current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble
boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in
calculating the end address of the prefix. For example, if a network
were allocated
2001:0db8::/30
The LIR would need to calculate that the end address of that /30 was
2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff
However, even experienced engineers can make mistakes when making
such calculations. In fact, to clarify the problem, as I was writing
the above example, I initially made the mistake of calculating the
end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff.
When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also
eventually lead to unnecessary disaggregation and larger
routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in
the community.
Therefore, this proposal replaces the HD ratio with simple ratios
for utilization thresholds and reduces the frequency with which
utilization thresholds would need to be calculated.
3. Situation in other RIRs
- ---------------------------
ARIN:
Submitted. Currently undergoing a process of staff review before
being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations, the
author currently has no intention of submitting this proposal to
RIPE. However, the author may eventually submit a proposal to RIPE
to address the problem of non-nibble boundary allocations.
4. Details
- -----------
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates
customer connections, including, but not limited to
Points of Presence (POPs), Datacenters, Central or
Local switching offices or regional or local
combinations thereof.
Provider The prefix of the smallest IPv6 block a given ISP
assignment assigns to end sites.
unit:
Nibble A network mask which aligns on a 4-bit boundary.
boundary: This means that the prefix length must be divisible
by 4. For example, /24, /28, /32, and /48 are all
aligned on a nibble boundary while /22, /26, /29,
/30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or
a single tenant within a multi-tenant structure
- The aim of this more generous interpretation of end
site to provide a clear definition which is easily
understood and provides maximum flexibility for
service providers to meet the needs of their
customers.
Utilized: (i) A provider assignment unit shall be considered
fully utilized when it is assigned to an
end site.
(ii) The utilization percentage of a block at the LIR
level is calculated as the fraction of total
provider assignment units which have been assigned
to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries
makes it easier for end addresses of IPv6 blocks to be calculated.
For example, if the next allocation one size larger than /32 is /28,
then, 2001:0db0::/28 has an end address of:
2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff
Allocating and assigning on nibble boundaries also makes DNS
delegations easier.
4.4 Change the size of initial allocations to LIRs according to the
following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32, unless
the LIR specifically requests a /36.
4.4.2 The maximum allocation unit shall be the smallest block which:
- Is nibble-boundary aligned
- Permits the largest serving site to be assigned a large
enough block to allow <=0.75 (75%) utilization
- Can provide an equal-sized block to each serving site
- Permits each serving site's block to be nibble-boundary
aligned
This can be summarized as /N where:
N = 48-(X+Y) where:
X is a multiple of 4 such that 2^X is greater than
4/3*(serving sites)
Y is a multiple of 4 such that 2^Y is greater than
4/3*(end sites served by the largest serving site)
In addition:
(i) An end site which can justify more than a /48 under
the current end-user assignment policy [1] shall count
as the appropriate number of /48s that would be
assigned under that policy.
(ii) An LIR which has subordinate LIRs shall make such
allocations according to the same policies and
criteria as APNIC. In such a case, the prefixes
necessary for such an allocation shall be treated as
fully utilized in determining the block sizing
for the parent LIR.
(iii) An LIR is not required to design or deploy their
network according to this structure. It is strictly a
mechanism to determine the largest IP address block to
which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria
described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3:
4.5.1 The LIR:
- Has a previously justified IPv4 allocation from APNIC, OR
- Has a previously justified IPv4 allocation from one
of APNIc's predecessor registries, OR
- Can qualify for an IPv4 ISP allocation under current
APNIC criteria.
4.5.2 The LIR:
- Will be making reassignments to other organizations AND
- Is currently multihomed for IPv6, OR
- Will immediately become multihomed for IPv6 using a valid
assigned global AS number
4.5.3 The LIR must provide APNIC a reasonable technical
justification of why an allocation is necessary including:
- The intended purposes for the allocation
- A description of the network infrastructure the allocation
will be used to support.
- A plan detailing assignments to other organizations or
customers for one, two, and five year periods, with a
minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of the
following two criteria:
- Utilization of 75% or more of their total address space, OR
- One the LIR/ISP's serving sites has a 90% utilization rate
Note: the process for calculating the utilization rate is detailed
in Appendix A.
When making subsequent allocations to LIRs, APNIC will follow the
allocation procedure below:
- Wherever possible, APNIC will make an allocation that expands one
or more existing allocations.
- Where APNIC cannot expand one or more existing allocations, APNIC
shall make a new allocation based on the initial allocation
criteria described in section 4.5 above.
When this occurs, the LIR is encouraged, but not required, to
renumber into the new allocation over time and return any
allocations no longer in use. In such a case, it is legitimate for
an end-site to have assignments from as many as two of these
blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end users
The recommended provider assignment unit is /48. In no case will
policy consider a provider assignment unit larger than /48.
Instead, if an LIR/ISP chooses to assign more than a /48 to an
end site, that will be considered to be multiples of the provider
assignment unit.
If the LIR/ISP chooses to have a provider assignment unit
smaller than a /48, then calculations of its address space
utilization will accordingly use the smaller prefix size.
An LIR may issue up to a /48 to an end site without requiring
justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their allocation
size if they are eligible for a larger block under the allocation
criteria suggested in this proposal.
Any LIR which received an allocation under previous policies which
is smaller than what they are entitled to under this policy may
receive a new initial allocation under this policy provided that
they agree to renumber into that new allocation and return their
prior allocation(s) within 5 years.
If possible, APNIC will simply expand their existing allocation
rather than requiring renumber and return.
5. Pros/Cons
- -------------
Advantages:
- Provides nibble-boundaries for direct allocations and for at least
one level of network hierarchy within the LIR, reducing the
potential for human factors errors.
- Increases the potential for network aggregation by issuing very
large blocks to ISPs.
- Reduces the potential for harmful under-sized assignments to end
users by removing any incentive to do so.
- Simplifies the IPv6 allocation policy by removing logarithmic
computations in favor of simple ratios.
- Reduces the number of times any given LIR will need to return to
APNIC for additional allocations.
- Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50 years,
free pool drops from 99.9995% to 99.62%.
6. Effect on APNIC
- -------------------
APNIC LIR members will be able to obtain significantly larger blocks of
IPv6 addresses and both receive and make their allocations and
assignments on nibble boundaries to simplify human factors and network
management while improving aggregation.
7. Effect on NIRs
- ------------------
This policy should not significantly impact NIRs.
8. References
- --------------
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy'
http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A
- ----------
In general, the following formula is used to calculate the utilization
rate in IPv6:
No. of provider assignment units assigned
Utilization % = ----------------------------------------- x 100
Total no. of provider assignment units
within allocation block(s)
However, there may be occasions when the calculation may need to be
amended if an LIR is in the process of renumbering out of an earlier
IPv6 block into a subsequent block from APNIC. If this is the case,
the following is permitted:
- An LIR can count provider assignment units made to end sites
in both the original and newer block into which the LIR is in
the process of renumbering into.
- The LIR can count assignments made to serving sites in both the
original and newer block into which the LIR is in the process of
renumbering into.
This double-counting during renumbering means that APNIC would always
allocate enough space to an LIR to encompass both existing customers and
growth of the LIR within a single new aggregatable block.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0tiYwACgkQSo7fU26F3X0KsQCdElGxRr6KLdD1BC7wfbHgbZ0y
vPAAnRMjQpN0o3Uhzy0rJoJQERdllebj
=OJ8L
-----END PGP SIGNATURE-----
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
Matthew Moyle-Croft
Email: mmc@internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909

Prop 90 doesn't say you can't use /56s, it says you don't have to and that you canHi,This is my first post to sig-policy, so be gentle :-)We're an ISP in Australia who are in the process of productionising our dual stack trial. We've run into this kind of issue where a /32 does run into issues for us allocating /48s to customers and have looked at allocating less to them. (We obtained the /32 back before most of these policies existed and when we were much smaller).We have a /32 and approx 250k customers which clearly isn't enough (65k /48s). But /56s as per the current policy with HD ratios (http://www.apnic.net/policy/ipv6-address-policy#5.3) in 5.3.1 means we do have enough but are in a bit of a gray space (16M /56s) as we do have a reasonable number of customers who match the /48 allocation policy.
Correct.We have 11 serving sites for the bulk of our broadband customers. The largest terminates approximately 50k customers.As I understand it this means:X=4Y=20 (50k * 4/3 is slightly more than 65k (2^16) so becomes 20)N=48-(4+20) = 24
Correct.Which gives us 16M /48s assuming my ability to use basic maths hasn't degraded that much :-)
Yes... That is the intent.Effectively this means we can allocate /48s to all customers.
That was, indeed, the goal.This would mean a much easier allocation strategy for us and allow us to allocate to customers space as they expect. I can't see we'd ever come back for another allocation (more efficient in the global table).
* sig-policy: APNIC SIG on resource management policy *MMCOn 12/01/2011, at 9:29 PM, Gaurab Raj Upadhaya wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to
the Policy SIG for review. It will be presented at the Policy SIG at
APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
________________________________________________________________________
prop-090-v001: Optimizing IPv6 Allocation Strategies
________________________________________________________________________
Author: Owen DeLong
Version: 1
Date: 12 January 2011
1. Introduction
- ----------------
This is a proposal to change how the size of IPv6 allocations and end
site assignments are determined, allowing more room for LIRs to grow
within their allocation, while also preventing excessive address
consumption. The proposal also assists to prevent potential human errors
in configuration that can be caused by the current IPv6 policies, which
allow allocations and assignments to be made on non-nibble boundaries.
2. Summary of the current problem
- ----------------------------------
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6
address block.
This assumption has led to such problems as end user customers
receiving single /64s, minimal /60s, or even /56s. If the practice
of unnecessarily limited address spaces becomes widespread, vendors
will not produce the innovations that are possible in home
networking with larger address spaces. Just as NAT has delayed or
prevented many forms of innovation in IPv4, small customer
assignment sizes could seriously reduce innovation in IPv6.
If this proposed policy were to be implemented, in 50
years, the projected IPv6 free pool would be 99.54% of total
IPv6 space vs 99.9975% if the current policy were still in place
at that time. Given the small amount of extra IPv6 addresses that
would be consumed by implementation of this proposed policy, it
would be a shame for innovation to be stifled by continuing the
current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble
boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in
calculating the end address of the prefix. For example, if a network
were allocated
2001:0db8::/30
The LIR would need to calculate that the end address of that /30 was
2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff
However, even experienced engineers can make mistakes when making
such calculations. In fact, to clarify the problem, as I was writing
the above example, I initially made the mistake of calculating the
end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff.
When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also
eventually lead to unnecessary disaggregation and larger
routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in
the community.
Therefore, this proposal replaces the HD ratio with simple ratios
for utilization thresholds and reduces the frequency with which
utilization thresholds would need to be calculated.
3. Situation in other RIRs
- ---------------------------
ARIN:
Submitted. Currently undergoing a process of staff review before
being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations, the
author currently has no intention of submitting this proposal to
RIPE. However, the author may eventually submit a proposal to RIPE
to address the problem of non-nibble boundary allocations.
4. Details
- -----------
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates
customer connections, including, but not limited to
Points of Presence (POPs), Datacenters, Central or
Local switching offices or regional or local
combinations thereof.
Provider The prefix of the smallest IPv6 block a given ISP
assignment assigns to end sites.
unit:
Nibble A network mask which aligns on a 4-bit boundary.
boundary: This means that the prefix length must be divisible
by 4. For example, /24, /28, /32, and /48 are all
aligned on a nibble boundary while /22, /26, /29,
/30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or
a single tenant within a multi-tenant structure
- The aim of this more generous interpretation of end
site to provide a clear definition which is easily
understood and provides maximum flexibility for
service providers to meet the needs of their
customers.
Utilized: (i) A provider assignment unit shall be considered
fully utilized when it is assigned to an
end site.
(ii) The utilization percentage of a block at the LIR
level is calculated as the fraction of total
provider assignment units which have been assigned
to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries
makes it easier for end addresses of IPv6 blocks to be calculated.
For example, if the next allocation one size larger than /32 is /28,
then, 2001:0db0::/28 has an end address of:
2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff
Allocating and assigning on nibble boundaries also makes DNS
delegations easier.
4.4 Change the size of initial allocations to LIRs according to the
following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32, unless
the LIR specifically requests a /36.
4.4.2 The maximum allocation unit shall be the smallest block which:
- Is nibble-boundary aligned
- Permits the largest serving site to be assigned a large
enough block to allow <=0.75 (75%) utilization
- Can provide an equal-sized block to each serving site
- Permits each serving site's block to be nibble-boundary
aligned
This can be summarized as /N where:
N = 48-(X+Y) where:
X is a multiple of 4 such that 2^X is greater than
4/3*(serving sites)
Y is a multiple of 4 such that 2^Y is greater than
4/3*(end sites served by the largest serving site)
In addition:
(i) An end site which can justify more than a /48 under
the current end-user assignment policy [1] shall count
as the appropriate number of /48s that would be
assigned under that policy.
(ii) An LIR which has subordinate LIRs shall make such
allocations according to the same policies and
criteria as APNIC. In such a case, the prefixes
necessary for such an allocation shall be treated as
fully utilized in determining the block sizing
for the parent LIR.
(iii) An LIR is not required to design or deploy their
network according to this structure. It is strictly a
mechanism to determine the largest IP address block to
which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria
described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3:
4.5.1 The LIR:
- Has a previously justified IPv4 allocation from APNIC, OR
- Has a previously justified IPv4 allocation from one
of APNIc's predecessor registries, OR
- Can qualify for an IPv4 ISP allocation under current
APNIC criteria.
4.5.2 The LIR:
- Will be making reassignments to other organizations AND
- Is currently multihomed for IPv6, OR
- Will immediately become multihomed for IPv6 using a valid
assigned global AS number
4.5.3 The LIR must provide APNIC a reasonable technical
justification of why an allocation is necessary including:
- The intended purposes for the allocation
- A description of the network infrastructure the allocation
will be used to support.
- A plan detailing assignments to other organizations or
customers for one, two, and five year periods, with a
minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of the
following two criteria:
- Utilization of 75% or more of their total address space, OR
- One the LIR/ISP's serving sites has a 90% utilization rate
Note: the process for calculating the utilization rate is detailed
in Appendix A.
When making subsequent allocations to LIRs, APNIC will follow the
allocation procedure below:
- Wherever possible, APNIC will make an allocation that expands one
or more existing allocations.
- Where APNIC cannot expand one or more existing allocations, APNIC
shall make a new allocation based on the initial allocation
criteria described in section 4.5 above.
When this occurs, the LIR is encouraged, but not required, to
renumber into the new allocation over time and return any
allocations no longer in use. In such a case, it is legitimate for
an end-site to have assignments from as many as two of these
blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end users
The recommended provider assignment unit is /48. In no case will
policy consider a provider assignment unit larger than /48.
Instead, if an LIR/ISP chooses to assign more than a /48 to an
end site, that will be considered to be multiples of the provider
assignment unit.
If the LIR/ISP chooses to have a provider assignment unit
smaller than a /48, then calculations of its address space
utilization will accordingly use the smaller prefix size.
An LIR may issue up to a /48 to an end site without requiring
justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their allocation
size if they are eligible for a larger block under the allocation
criteria suggested in this proposal.
Any LIR which received an allocation under previous policies which
is smaller than what they are entitled to under this policy may
receive a new initial allocation under this policy provided that
they agree to renumber into that new allocation and return their
prior allocation(s) within 5 years.
If possible, APNIC will simply expand their existing allocation
rather than requiring renumber and return.
5. Pros/Cons
- -------------
Advantages:
- Provides nibble-boundaries for direct allocations and for at least
one level of network hierarchy within the LIR, reducing the
potential for human factors errors.
- Increases the potential for network aggregation by issuing very
large blocks to ISPs.
- Reduces the potential for harmful under-sized assignments to end
users by removing any incentive to do so.
- Simplifies the IPv6 allocation policy by removing logarithmic
computations in favor of simple ratios.
- Reduces the number of times any given LIR will need to return to
APNIC for additional allocations.
- Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50 years,
free pool drops from 99.9995% to 99.62%.
6. Effect on APNIC
- -------------------
APNIC LIR members will be able to obtain significantly larger blocks of
IPv6 addresses and both receive and make their allocations and
assignments on nibble boundaries to simplify human factors and network
management while improving aggregation.
7. Effect on NIRs
- ------------------
This policy should not significantly impact NIRs.
8. References
- --------------
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy'
http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A
- ----------
In general, the following formula is used to calculate the utilization
rate in IPv6:
No. of provider assignment units assigned
Utilization % = ----------------------------------------- x 100
Total no. of provider assignment units
within allocation block(s)
However, there may be occasions when the calculation may need to be
amended if an LIR is in the process of renumbering out of an earlier
IPv6 block into a subsequent block from APNIC. If this is the case,
the following is permitted:
- An LIR can count provider assignment units made to end sites
in both the original and newer block into which the LIR is in
the process of renumbering into.
- The LIR can count assignments made to serving sites in both the
original and newer block into which the LIR is in the process of
renumbering into.
This double-counting during renumbering means that APNIC would always
allocate enough space to an LIR to encompass both existing customers and
growth of the LIR within a single new aggregatable block.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0tiYwACgkQSo7fU26F3X0KsQCdElGxRr6KLdD1BC7wfbHgbZ0y
vPAAnRMjQpN0o3Uhzy0rJoJQERdllebj
=OJ8L
-----END PGP SIGNATURE-----
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy--
Matthew Moyle-CroftPeering Manager and Team Lead - Commercial and DSLAMsInternode /AgileLevel 5, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc@internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

On Jan 12, 2011, at 4:46 PM, Matthew Moyle-Croft wrote:Prop 90 doesn't say you can't use /56s, it says you don't have to and that you canHi,This is my first post to sig-policy, so be gentle :-)We're an ISP in Australia who are in the process of productionising our dual stack trial. We've run into this kind of issue where a /32 does run into issues for us allocating /48s to customers and have looked at allocating less to them. (We obtained the /32 back before most of these policies existed and when we were much smaller).We have a /32 and approx 250k customers which clearly isn't enough (65k /48s). But /56s as per the current policy with HD ratios (http://www.apnic.net/policy/ipv6-address-policy#5.3) in 5.3.1 means we do have enough but are in a bit of a gray space (16M /56s) as we do have a reasonable number of customers who match the /48 allocation policy.get more than a /32...
Correct.We have 11 serving sites for the bulk of our broadband customers. The largest terminates approximately 50k customers.As I understand it this means:X=4Y=20 (50k * 4/3 is slightly more than 65k (2^16) so becomes 20)N=48-(4+20) = 24Correct.Which gives us 16M /48s assuming my ability to use basic maths hasn't degraded that much :-)Yes... That is the intent.Effectively this means we can allocate /48s to all customers.That was, indeed, the goal.This would mean a much easier allocation strategy for us and allow us to allocate to customers space as they expect. I can't see we'd ever come back for another allocation (more efficient in the global table).Can I take it from this that you support the proposal?
Owen* sig-policy: APNIC SIG on resource management policy *MMCOn 12/01/2011, at 9:29 PM, Gaurab Raj Upadhaya wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to
the Policy SIG for review. It will be presented at the Policy SIG at
APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
________________________________________________________________________
prop-090-v001: Optimizing IPv6 Allocation Strategies
________________________________________________________________________
Author: Owen DeLong
Version: 1
Date: 12 January 2011
1. Introduction
- ----------------
This is a proposal to change how the size of IPv6 allocations and end
site assignments are determined, allowing more room for LIRs to grow
within their allocation, while also preventing excessive address
consumption. The proposal also assists to prevent potential human errors
in configuration that can be caused by the current IPv6 policies, which
allow allocations and assignments to be made on non-nibble boundaries.
2. Summary of the current problem
- ----------------------------------
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6
address block.
This assumption has led to such problems as end user customers
receiving single /64s, minimal /60s, or even /56s. If the practice
of unnecessarily limited address spaces becomes widespread, vendors
will not produce the innovations that are possible in home
networking with larger address spaces. Just as NAT has delayed or
prevented many forms of innovation in IPv4, small customer
assignment sizes could seriously reduce innovation in IPv6.
If this proposed policy were to be implemented, in 50
years, the projected IPv6 free pool would be 99.54% of total
IPv6 space vs 99.9975% if the current policy were still in place
at that time. Given the small amount of extra IPv6 addresses that
would be consumed by implementation of this proposed policy, it
would be a shame for innovation to be stifled by continuing the
current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble
boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in
calculating the end address of the prefix. For example, if a network
were allocated
2001:0db8::/30
The LIR would need to calculate that the end address of that /30 was
2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff
However, even experienced engineers can make mistakes when making
such calculations. In fact, to clarify the problem, as I was writing
the above example, I initially made the mistake of calculating the
end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff.
When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also
eventually lead to unnecessary disaggregation and larger
routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in
the community.
Therefore, this proposal replaces the HD ratio with simple ratios
for utilization thresholds and reduces the frequency with which
utilization thresholds would need to be calculated.
3. Situation in other RIRs
- ---------------------------
ARIN:
Submitted. Currently undergoing a process of staff review before
being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations, the
author currently has no intention of submitting this proposal to
RIPE. However, the author may eventually submit a proposal to RIPE
to address the problem of non-nibble boundary allocations.
4. Details
- -----------
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates
customer connections, including, but not limited to
Points of Presence (POPs), Datacenters, Central or
Local switching offices or regional or local
combinations thereof.
Provider The prefix of the smallest IPv6 block a given ISP
assignment assigns to end sites.
unit:
Nibble A network mask which aligns on a 4-bit boundary.
boundary: This means that the prefix length must be divisible
by 4. For example, /24, /28, /32, and /48 are all
aligned on a nibble boundary while /22, /26, /29,
/30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or
a single tenant within a multi-tenant structure
- The aim of this more generous interpretation of end
site to provide a clear definition which is easily
understood and provides maximum flexibility for
service providers to meet the needs of their
customers.
Utilized: (i) A provider assignment unit shall be considered
fully utilized when it is assigned to an
end site.
(ii) The utilization percentage of a block at the LIR
level is calculated as the fraction of total
provider assignment units which have been assigned
to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries
makes it easier for end addresses of IPv6 blocks to be calculated.
For example, if the next allocation one size larger than /32 is /28,
then, 2001:0db0::/28 has an end address of:
2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff
Allocating and assigning on nibble boundaries also makes DNS
delegations easier.
4.4 Change the size of initial allocations to LIRs according to the
following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32, unless
the LIR specifically requests a /36.
4.4.2 The maximum allocation unit shall be the smallest block which:
- Is nibble-boundary aligned
- Permits the largest serving site to be assigned a large
enough block to allow <=0.75 (75%) utilization
- Can provide an equal-sized block to each serving site
- Permits each serving site's block to be nibble-boundary
aligned
This can be summarized as /N where:
N = 48-(X+Y) where:
X is a multiple of 4 such that 2^X is greater than
4/3*(serving sites)
Y is a multiple of 4 such that 2^Y is greater than
4/3*(end sites served by the largest serving site)
In addition:
(i) An end site which can justify more than a /48 under
the current end-user assignment policy [1] shall count
as the appropriate number of /48s that would be
assigned under that policy.
(ii) An LIR which has subordinate LIRs shall make such
allocations according to the same policies and
criteria as APNIC. In such a case, the prefixes
necessary for such an allocation shall be treated as
fully utilized in determining the block sizing
for the parent LIR.
(iii) An LIR is not required to design or deploy their
network according to this structure. It is strictly a
mechanism to determine the largest IP address block to
which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria
described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3:
4.5.1 The LIR:
- Has a previously justified IPv4 allocation from APNIC, OR
- Has a previously justified IPv4 allocation from one
of APNIc's predecessor registries, OR
- Can qualify for an IPv4 ISP allocation under current
APNIC criteria.
4.5.2 The LIR:
- Will be making reassignments to other organizations AND
- Is currently multihomed for IPv6, OR
- Will immediately become multihomed for IPv6 using a valid
assigned global AS number
4.5.3 The LIR must provide APNIC a reasonable technical
justification of why an allocation is necessary including:
- The intended purposes for the allocation
- A description of the network infrastructure the allocation
will be used to support.
- A plan detailing assignments to other organizations or
customers for one, two, and five year periods, with a
minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of the
following two criteria:
- Utilization of 75% or more of their total address space, OR
- One the LIR/ISP's serving sites has a 90% utilization rate
Note: the process for calculating the utilization rate is detailed
in Appendix A.
When making subsequent allocations to LIRs, APNIC will follow the
allocation procedure below:
- Wherever possible, APNIC will make an allocation that expands one
or more existing allocations.
- Where APNIC cannot expand one or more existing allocations, APNIC
shall make a new allocation based on the initial allocation
criteria described in section 4.5 above.
When this occurs, the LIR is encouraged, but not required, to
renumber into the new allocation over time and return any
allocations no longer in use. In such a case, it is legitimate for
an end-site to have assignments from as many as two of these
blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end users
The recommended provider assignment unit is /48. In no case will
policy consider a provider assignment unit larger than /48.
Instead, if an LIR/ISP chooses to assign more than a /48 to an
end site, that will be considered to be multiples of the provider
assignment unit.
If the LIR/ISP chooses to have a provider assignment unit
smaller than a /48, then calculations of its address space
utilization will accordingly use the smaller prefix size.
An LIR may issue up to a /48 to an end site without requiring
justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their allocation
size if they are eligible for a larger block under the allocation
criteria suggested in this proposal.
Any LIR which received an allocation under previous policies which
is smaller than what they are entitled to under this policy may
receive a new initial allocation under this policy provided that
they agree to renumber into that new allocation and return their
prior allocation(s) within 5 years.
If possible, APNIC will simply expand their existing allocation
rather than requiring renumber and return.
5. Pros/Cons
- -------------
Advantages:
- Provides nibble-boundaries for direct allocations and for at least
one level of network hierarchy within the LIR, reducing the
potential for human factors errors.
- Increases the potential for network aggregation by issuing very
large blocks to ISPs.
- Reduces the potential for harmful under-sized assignments to end
users by removing any incentive to do so.
- Simplifies the IPv6 allocation policy by removing logarithmic
computations in favor of simple ratios.
- Reduces the number of times any given LIR will need to return to
APNIC for additional allocations.
- Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50 years,
free pool drops from 99.9995% to 99.62%.
6. Effect on APNIC
- -------------------
APNIC LIR members will be able to obtain significantly larger blocks of
IPv6 addresses and both receive and make their allocations and
assignments on nibble boundaries to simplify human factors and network
management while improving aggregation.
7. Effect on NIRs
- ------------------
This policy should not significantly impact NIRs.
8. References
- --------------
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy'
http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A
- ----------
In general, the following formula is used to calculate the utilization
rate in IPv6:
No. of provider assignment units assigned
Utilization % = ----------------------------------------- x 100
Total no. of provider assignment units
within allocation block(s)
However, there may be occasions when the calculation may need to be
amended if an LIR is in the process of renumbering out of an earlier
IPv6 block into a subsequent block from APNIC. If this is the case,
the following is permitted:
- An LIR can count provider assignment units made to end sites
in both the original and newer block into which the LIR is in
the process of renumbering into.
- The LIR can count assignments made to serving sites in both the
original and newer block into which the LIR is in the process of
renumbering into.
This double-counting during renumbering means that APNIC would always
allocate enough space to an LIR to encompass both existing customers and
growth of the LIR within a single new aggregatable block.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0tiYwACgkQSo7fU26F3X0KsQCdElGxRr6KLdD1BC7wfbHgbZ0y
vPAAnRMjQpN0o3Uhzy0rJoJQERdllebj
=OJ8L
-----END PGP SIGNATURE-----
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy--
Matthew Moyle-CroftPeering Manager and Team Lead - Commercial and DSLAMsInternode /AgileLevel 5, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc@internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
Matthew Moyle-Croft
Email: mmc@internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909

Right. I was pointing out that if you still wanted to use /56s, Prop-90 includes provisionsOn 13/01/2011, at 1:21 PM, Owen DeLong wrote:On Jan 12, 2011, at 4:46 PM, Matthew Moyle-Croft wrote:Prop 90 doesn't say you can't use /56s, it says you don't have to and that you canHi,This is my first post to sig-policy, so be gentle :-)We're an ISP in Australia who are in the process of productionising our dual stack trial. We've run into this kind of issue where a /32 does run into issues for us allocating /48s to customers and have looked at allocating less to them. (We obtained the /32 back before most of these policies existed and when we were much smaller).We have a /32 and approx 250k customers which clearly isn't enough (65k /48s). But /56s as per the current policy with HD ratios (http://www.apnic.net/policy/ipv6-address-policy#5.3) in 5.3.1 means we do have enough but are in a bit of a gray space (16M /56s) as we do have a reasonable number of customers who match the /48 allocation policy.get more than a /32...I was referring to the existing policy which bases the HD ratio on /56 allocations.

Allocation on nibble boundries are operationally sensible and should be put forward as best practice. Having the allocation policy to support this (and the calculations required for justification and subsequent allocations) will be required to support the best practice.
I support this proposal.
On 12/01/2011 6:59 PM, "Gaurab Raj Upadhaya" gaurab@lahai.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
prop-090-v001: Optimizing IPv6 Allocation Strategies ________________________________________________________________________
Author: Owen DeLong
Version: 1
Date: 12 January 2011
- Introduction
This is a proposal to change how the size of IPv6 allocations and end site assignments are determined, allowing more room for LIRs to grow within their allocation, while also preventing excessive address consumption. The proposal also assists to prevent potential human errors in configuration that can be caused by the current IPv6 policies, which allow allocations and assignments to be made on non-nibble boundaries.
- Summary of the current problem
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6 address block.
This assumption has led to such problems as end user customers receiving single /64s, minimal /60s, or even /56s. If the practice of unnecessarily limited address spaces becomes widespread, vendors will not produce the innovations that are possible in home networking with larger address spaces. Just as NAT has delayed or prevented many forms of innovation in IPv4, small customer assignment sizes could seriously reduce innovation in IPv6. If this proposed policy were to be implemented, in 50 years, the projected IPv6 free pool would be 99.54% of total IPv6 space vs 99.9975% if the current policy were still in place at that time. Given the small amount of extra IPv6 addresses that would be consumed by implementation of this proposed policy, it would be a shame for innovation to be stifled by continuing the current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in calculating the end address of the prefix. For example, if a network were allocated 2001:0db8::/30 The LIR would need to calculate that the end address of that /30 was 2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff However, even experienced engineers can make mistakes when making such calculations. In fact, to clarify the problem, as I was writing the above example, I initially made the mistake of calculating the end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff. When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also eventually lead to unnecessary disaggregation and larger routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in the community.
Therefore, this proposal replaces the HD ratio with simple ratios for utilization thresholds and reduces the frequency with which utilization thresholds would need to be calculated.
- Situation in other RIRs
ARIN:
Submitted. Currently undergoing a process of staff review before being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations, the author currently has no intention of submitting this proposal to RIPE. However, the author may eventually submit a proposal to RIPE to address the problem of non-nibble boundary allocations.
- Details
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates customer connections, including, but not limited to Points of Presence (POPs), Datacenters, Central or Local switching offices or regional or local combinations thereof. Provider The prefix of the smallest IPv6 block a given ISP assignment assigns to end sites. unit: Nibble A network mask which aligns on a 4-bit boundary. boundary: This means that the prefix length must be divisible by 4. For example, /24, /28, /32, and /48 are all aligned on a nibble boundary while /22, /26, /29, /30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or a single tenant within a multi-tenant structure - The aim of this more generous interpretation of end site to provide a clear definition which is easily understood and provides maximum flexibility for service providers to meet the needs of their customers. Utilized: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end site. (ii) The utilization percentage of a block at the LIR level is calculated as the fraction of total provider assignment units which have been assigned to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries makes it easier for end addresses of IPv6 blocks to be calculated. For example, if the next allocation one size larger than /32 is /28, then, 2001:0db0::/28 has an end address of: 2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff Allocating and assigning on nibble boundaries also makes DNS delegations easier.
4.4 Change the size of initial allocations to LIRs according to the following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32, unless the LIR specifically requests a /36. 4.4.2 The maximum allocation unit shall be the smallest block which: - Is nibble-boundary aligned - Permits the largest serving site to be assigned a large enough block to allow <=0.75 (75%) utilization - Can provide an equal-sized block to each serving site - Permits each serving site's block to be nibble-boundary aligned This can be summarized as /N where: N = 48-(X+Y) where: X is a multiple of 4 such that 2^X is greater than 4/3*(serving sites) Y is a multiple of 4 such that 2^Y is greater than 4/3*(end sites served by the largest serving site) In addition: (i) An end site which can justify more than a /48 under the current end-user assignment policy [1] shall count as the appropriate number of /48s that would be assigned under that policy. (ii) An LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as APNIC. In such a case, the prefixes necessary for such an allocation shall be treated as fully utilized in determining the block sizing for the parent LIR. (iii) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3: 4.5.1 The LIR: - Has a previously justified IPv4 allocation from APNIC, OR - Has a previously justified IPv4 allocation from one of APNIc's predecessor registries, OR - Can qualify for an IPv4 ISP allocation under current APNIC criteria. 4.5.2 The LIR: - Will be making reassignments to other organizations AND - Is currently multihomed for IPv6, OR - Will immediately become multihomed for IPv6 using a valid assigned global AS number 4.5.3 The LIR must provide APNIC a reasonable technical justification of why an allocation is necessary including: - The intended purposes for the allocation - A description of the network infrastructure the allocation will be used to support. - A plan detailing assignments to other organizations or customers for one, two, and five year periods, with a minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of the following two criteria: - Utilization of 75% or more of their total address space, OR - One the LIR/ISP's serving sites has a 90% utilization rate Note: the process for calculating the utilization rate is detailed in Appendix A. When making subsequent allocations to LIRs, APNIC will follow the allocation procedure below: - Wherever possible, APNIC will make an allocation that expands one or more existing allocations. - Where APNIC cannot expand one or more existing allocations, APNIC shall make a new allocation based on the initial allocation criteria described in section 4.5 above. When this occurs, the LIR is encouraged, but not required, to renumber into the new allocation over time and return any allocations no longer in use. In such a case, it is legitimate for an end-site to have assignments from as many as two of these blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end users
The recommended provider assignment unit is /48. In no case will policy consider a provider assignment unit larger than /48. Instead, if an LIR/ISP chooses to assign more than a /48 to an end site, that will be considered to be multiples of the provider assignment unit. If the LIR/ISP chooses to have a provider assignment unit smaller than a /48, then calculations of its address space utilization will accordingly use the smaller prefix size. An LIR may issue up to a /48 to an end site without requiring justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their allocation size if they are eligible for a larger block under the allocation criteria suggested in this proposal.
Any LIR which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, APNIC will simply expand their existing allocation rather than requiring renumber and return.
- Pros/Cons
Advantages:
- Provides nibble-boundaries for direct allocations and for at least one level of network hierarchy within the LIR, reducing the potential for human factors errors. - Increases the potential for network aggregation by issuing very large blocks to ISPs. - Reduces the potential for harmful under-sized assignments to end users by removing any incentive to do so. - Simplifies the IPv6 allocation policy by removing logarithmic computations in favor of simple ratios. - Reduces the number of times any given LIR will need to return to APNIC for additional allocations. - Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50 years, free pool drops from 99.9995% to 99.62%.
- Effect on APNIC
APNIC LIR members will be able to obtain significantly larger blocks of IPv6 addresses and both receive and make their allocations and assignments on nibble boundaries to simplify human factors and network management while improving aggregation.
- Effect on NIRs
This policy should not significantly impact NIRs.
- References
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy' http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A
In general, the following formula is used to calculate the utilization rate in IPv6:
No. of provider assignment units assigned Utilization % = ----------------------------------------- x 100 Total no. of provider assignment units within allocation block(s)
However, there may be occasions when the calculation may need to be amended if an LIR is in the process of renumbering out of an earlier IPv6 block into a subsequent block from APNIC. If this is the case, the following is permitted:
- An LIR can count provider assignment units made to end sites in both the original and newer block into which the LIR is in the process of renumbering into. - The LIR can count assignments made to serving sites in both the original and newer block into which the LIR is in the process of renumbering into.
This double-counting during renumbering means that APNIC would always allocate enough space to an LIR to encompass both existing customers and growth of the LIR within a single new aggregatable block. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0tiYwACgkQSo7fU26F3X0KsQCdElGxRr6KLdD1BC7wfbHgbZ0y vPAAnRMjQpN0o3Uhzy0rJoJQERdllebj =OJ8L -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

I concur with Raphael's argument in regard to the use of nibble boundaries. The hexadecimal arithmetic involved when using odd-bit-aligned boundaries makes my brain hurt, and I'm keen to avoid such pain either in my own head or in anyone else's.
I also agree with Owen that treating IPv6 addresses as a scarce commodity is short-sighted. Allowing 'generous' allocations / assignments not only recognises the fact that IPv6 addresses are not in any way scarce, it should also have a positive longer-term effect in reducing the size of routing tables, in that an organisation is less likely to need multiple blocks.
I support prop-090
Regards
Mike __________________________________________________ Mike Henderson | Manager Information Systems Policy Communications and Information Systems Branch NZ Defence Force, Private Bag 39997, Wellington, New Zealand
DDI: +64 4 496 0186 |Mobile: +64 21 243 8183
-----Original Message----- From: sig-policy-bounces@lists.apnic.net On Behalf Of Raphael Ho Sent: Thursday, 13 January 2011 4:08 p.m. To: Gaurab Raj Upadhaya; APNIC Policy SIG List Subject: Re: [sig-policy] prop-090: Optimizing IPv6 allocation strategies
Allocation on nibble boundries are operationally sensible and should be put forward as best practice. Having the allocation policy to support this (and the calculations required for justification and subsequent allocations) will be required to support the best practice.
I support this proposal.
On 12/01/2011 6:59 PM, "Gaurab Raj Upadhaya" gaurab@lahai.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
_
prop-090-v001: Optimizing IPv6 Allocation Strategies _______________________________________________________________________
_
Author: Owen DeLong
Version: 1
Date: 12 January 2011
- Introduction
This is a proposal to change how the size of IPv6 allocations and end site assignments are determined, allowing more room for LIRs to grow within their allocation, while also preventing excessive address consumption. The proposal also assists to prevent potential human
errors
in configuration that can be caused by the current IPv6 policies, which allow allocations and assignments to be made on non-nibble boundaries.
- Summary of the current problem
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6 address block.
This assumption has led to such problems as end user customers receiving single /64s, minimal /60s, or even /56s. If the practice of unnecessarily limited address spaces becomes widespread,
vendors
will not produce the innovations that are possible in home networking with larger address spaces. Just as NAT has delayed or prevented many forms of innovation in IPv4, small customer assignment sizes could seriously reduce innovation in IPv6. If this proposed policy were to be implemented, in 50 years, the projected IPv6 free pool would be 99.54% of total IPv6 space vs 99.9975% if the current policy were still in place at that time. Given the small amount of extra IPv6 addresses that would be consumed by implementation of this proposed policy, it would be a shame for innovation to be stifled by continuing the current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in calculating the end address of the prefix. For example, if a
network
were allocated 2001:0db8::/30 The LIR would need to calculate that the end address of that /30
was
2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff However, even experienced engineers can make mistakes when making such calculations. In fact, to clarify the problem, as I was
writing
the above example, I initially made the mistake of calculating the end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff. When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also eventually lead to unnecessary disaggregation and larger routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in the community.
Therefore, this proposal replaces the HD ratio with simple ratios for utilization thresholds and reduces the frequency with which utilization thresholds would need to be calculated.
- Situation in other RIRs
ARIN:
Submitted. Currently undergoing a process of staff review before being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations,
the
author currently has no intention of submitting this proposal to RIPE. However, the author may eventually submit a proposal to RIPE to address the problem of non-nibble boundary allocations.
- Details
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates customer connections, including, but not limited to Points of Presence (POPs), Datacenters, Central or Local switching offices or regional or local combinations thereof. Provider The prefix of the smallest IPv6 block a given ISP assignment assigns to end sites. unit: Nibble A network mask which aligns on a 4-bit boundary. boundary: This means that the prefix length must be divisible by 4. For example, /24, /28, /32, and /48 are all aligned on a nibble boundary while /22, /26, /29, /30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or a single tenant within a multi-tenant structure - The aim of this more generous interpretation of
end
site to provide a clear definition which is
easily
understood and provides maximum flexibility for service providers to meet the needs of their customers. Utilized: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end site. (ii) The utilization percentage of a block at the LIR level is calculated as the fraction of total provider assignment units which have been
assigned
to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries makes it easier for end addresses of IPv6 blocks to be calculated. For example, if the next allocation one size larger than /32 is
/28,
then, 2001:0db0::/28 has an end address of: 2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff Allocating and assigning on nibble boundaries also makes DNS delegations easier.
4.4 Change the size of initial allocations to LIRs according to the following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32,
unless
the LIR specifically requests a /36. 4.4.2 The maximum allocation unit shall be the smallest block
which:
- Is nibble-boundary aligned - Permits the largest serving site to be assigned a large enough block to allow <=0.75 (75%) utilization - Can provide an equal-sized block to each serving site - Permits each serving site's block to be nibble-boundary aligned This can be summarized as /N where: N = 48-(X+Y) where: X is a multiple of 4 such that 2^X is greater than 4/3*(serving sites) Y is a multiple of 4 such that 2^Y is greater than 4/3*(end sites served by the largest serving site) In addition: (i) An end site which can justify more than a /48 under the current end-user assignment policy [1] shall
count
as the appropriate number of /48s that would be assigned under that policy. (ii) An LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as APNIC. In such a case, the prefixes necessary for such an allocation shall be treated as fully utilized in determining the block sizing for the parent LIR. (iii) An LIR is not required to design or deploy their network according to this structure. It is strictly
a
mechanism to determine the largest IP address block
to
which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria described in one of the following sections: 4.5.1, 4.5.2, or
4.5.3:
4.5.1 The LIR: - Has a previously justified IPv4 allocation from APNIC, OR - Has a previously justified IPv4 allocation from one of APNIc's predecessor registries, OR - Can qualify for an IPv4 ISP allocation under current APNIC criteria. 4.5.2 The LIR: - Will be making reassignments to other organizations AND - Is currently multihomed for IPv6, OR - Will immediately become multihomed for IPv6 using a
valid
assigned global AS number 4.5.3 The LIR must provide APNIC a reasonable technical justification of why an allocation is necessary including: - The intended purposes for the allocation - A description of the network infrastructure the allocation will be used to support. - A plan detailing assignments to other organizations or customers for one, two, and five year periods, with a minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of
the
following two criteria: - Utilization of 75% or more of their total address space, OR - One the LIR/ISP's serving sites has a 90% utilization rate Note: the process for calculating the utilization rate is detailed in Appendix A. When making subsequent allocations to LIRs, APNIC will follow the allocation procedure below: - Wherever possible, APNIC will make an allocation that expands
one
or more existing allocations. - Where APNIC cannot expand one or more existing allocations,
APNIC
shall make a new allocation based on the initial allocation criteria described in section 4.5 above. When this occurs, the LIR is encouraged, but not required, to renumber into the new allocation over time and return any allocations no longer in use. In such a case, it is legitimate
for
an end-site to have assignments from as many as two of these blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end
users
The recommended provider assignment unit is /48. In no case will policy consider a provider assignment unit larger than /48. Instead, if an LIR/ISP chooses to assign more than a /48 to an end site, that will be considered to be multiples of the provider assignment unit. If the LIR/ISP chooses to have a provider assignment unit smaller than a /48, then calculations of its address space utilization will accordingly use the smaller prefix size. An LIR may issue up to a /48 to an end site without requiring justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their
allocation
size if they are eligible for a larger block under the allocation criteria suggested in this proposal. Any LIR which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, APNIC will simply expand their existing allocation rather than requiring renumber and return.
- Pros/Cons
Advantages:
- Provides nibble-boundaries for direct allocations and for at
least
one level of network hierarchy within the LIR, reducing
the
potential for human factors errors. - Increases the potential for network aggregation by issuing very large blocks to ISPs. - Reduces the potential for harmful under-sized assignments to end users by removing any incentive to do so. - Simplifies the IPv6 allocation policy by removing logarithmic computations in favor of simple ratios. - Reduces the number of times any given LIR will need to return to APNIC for additional allocations. - Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50
years,
free pool drops from 99.9995% to 99.62%.
- Effect on APNIC
APNIC LIR members will be able to obtain significantly larger blocks of IPv6 addresses and both receive and make their allocations and assignments on nibble boundaries to simplify human factors and network management while improving aggregation.
- Effect on NIRs
This policy should not significantly impact NIRs.
- References
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy' http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A
In general, the following formula is used to calculate the utilization rate in IPv6:
No. of provider assignment units assigned Utilization % = ----------------------------------------- x 100 Total no. of provider assignment units within allocation block(s)
However, there may be occasions when the calculation may need to be amended if an LIR is in the process of renumbering out of an earlier IPv6 block into a subsequent block from APNIC. If this is the case, the following is permitted:
- An LIR can count provider assignment units made to end sites in both the original and newer block into which the LIR is in the process of renumbering into. - The LIR can count assignments made to serving sites in both the original and newer block into which the LIR is in the process of renumbering into.
This double-counting during renumbering means that APNIC would always allocate enough space to an LIR to encompass both existing customers
and
growth of the LIR within a single new aggregatable block. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0tiYwACgkQSo7fU26F3X0KsQCdElGxRr6KLdD1BC7wfbHgbZ0y vPAAnRMjQpN0o3Uhzy0rJoJQERdllebj =OJ8L -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it.
If you have received this message in error, please Email or telephone the sender immediately.

On 12/01/11 Wed, Jan 12, 23:59, Gaurab Raj Upadhaya wrote:
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 31 in Hong Kong, 21-25 February 2011.
- Details
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates customer connections, including, but not limited to Points of Presence (POPs), Datacenters, Central or Local switching offices or regional or local combinations thereof. Provider The prefix of the smallest IPv6 block a given ISP assignment assigns to end sites. unit:
In the RIPE DRAFT: IPv6 Address Allocation and Assignment Policy http://ripe.net/ripe/draft-documents/ripe-481-draft2010-06.html there's discussion about changes to their section 5.5 on Registration to add a new attribute called "assignment-size:". This sounds similar to Owen's proposed name.
This is part of a proposal to make changes to the way in which RIPE NCC record IPv6 addresses. It would seem to be a good idea to read that RIPE document in conjunction with this proposal so that things can be harmonised.
I'd like to see this community consider something similar to the proposed RIPE changes in due course. We're clearly not required to adopt the RIPE policy automatically but if they have an idea we like we should consider it.
Happy with the proposal to allocate on nibble boundaries etc.

Owen,
Prop-090 seems to completely make sense. Nibble boundaries certainly make sense.
I will point out that under APNIC membership fees:
/32 - $1993 ex-Tax /28 - $5696 ex-Tax (nearly 3 times the amount).
This is of course only if your v6 allocation is larger than your v4.
I will also point out that your Free spool statistics, in my opinion are flawed as being linked to this proposal as APNIC does not have control over IANA and how it allocates resources to the RIR's.
I don't think this proposal as such negates the need for Prop-083 - yet.... As if you are allocating on nibble boundaries and going to a /28, that is only 16 * /32's. While I am not suggesting Prop-083 would facilitate that much extra allocation - it may be possible - and under my philosophy for the proposal - should be allowed if it falls within allocation guidelines.
That said, this policy as it stands, for specifically the purpose it is proposed for, I support it.
...Skeeve
-- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis
-----Original Message----- From: Gaurab Raj Upadhaya gaurab@lahai.com Date: Wed, 12 Jan 2011 21:59:24 +1100 To: APNIC Policy SIG List sig-policy@apnic.net Subject: [sig-policy] prop-090: Optimizing IPv6 allocation strategies
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
prop-090-v001: Optimizing IPv6 Allocation Strategies ________________________________________________________________________
Author: Owen DeLong
Version: 1
Date: 12 January 2011
- Introduction
This is a proposal to change how the size of IPv6 allocations and end site assignments are determined, allowing more room for LIRs to grow within their allocation, while also preventing excessive address consumption. The proposal also assists to prevent potential human errors in configuration that can be caused by the current IPv6 policies, which allow allocations and assignments to be made on non-nibble boundaries.
- Summary of the current problem
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6 address block.
This assumption has led to such problems as end user customers receiving single /64s, minimal /60s, or even /56s. If the practice of unnecessarily limited address spaces becomes widespread, vendors will not produce the innovations that are possible in home networking with larger address spaces. Just as NAT has delayed or prevented many forms of innovation in IPv4, small customer assignment sizes could seriously reduce innovation in IPv6. If this proposed policy were to be implemented, in 50 years, the projected IPv6 free pool would be 99.54% of total IPv6 space vs 99.9975% if the current policy were still in place at that time. Given the small amount of extra IPv6 addresses that would be consumed by implementation of this proposed policy, it would be a shame for innovation to be stifled by continuing the current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in calculating the end address of the prefix. For example, if a network were allocated 2001:0db8::/30 The LIR would need to calculate that the end address of that /30 was 2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff However, even experienced engineers can make mistakes when making such calculations. In fact, to clarify the problem, as I was writing the above example, I initially made the mistake of calculating the end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff. When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also eventually lead to unnecessary disaggregation and larger routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in the community.
Therefore, this proposal replaces the HD ratio with simple ratios for utilization thresholds and reduces the frequency with which utilization thresholds would need to be calculated.
- Situation in other RIRs
ARIN:
Submitted. Currently undergoing a process of staff review before being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations, the author currently has no intention of submitting this proposal to RIPE. However, the author may eventually submit a proposal to RIPE to address the problem of non-nibble boundary allocations.
- Details
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates customer connections, including, but not limited to Points of Presence (POPs), Datacenters, Central or Local switching offices or regional or local combinations thereof. Provider The prefix of the smallest IPv6 block a given ISP assignment assigns to end sites. unit: Nibble A network mask which aligns on a 4-bit boundary. boundary: This means that the prefix length must be divisible by 4. For example, /24, /28, /32, and /48 are all aligned on a nibble boundary while /22, /26, /29, /30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or a single tenant within a multi-tenant structure - The aim of this more generous interpretation of end site to provide a clear definition which is easily understood and provides maximum flexibility for service providers to meet the needs of their customers. Utilized: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end site. (ii) The utilization percentage of a block at the LIR level is calculated as the fraction of total provider assignment units which have been assigned to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries makes it easier for end addresses of IPv6 blocks to be calculated. For example, if the next allocation one size larger than /32 is /28, then, 2001:0db0::/28 has an end address of: 2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff Allocating and assigning on nibble boundaries also makes DNS delegations easier.
4.4 Change the size of initial allocations to LIRs according to the following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32, unless the LIR specifically requests a /36. 4.4.2 The maximum allocation unit shall be the smallest block which: - Is nibble-boundary aligned - Permits the largest serving site to be assigned a large enough block to allow <=0.75 (75%) utilization - Can provide an equal-sized block to each serving site - Permits each serving site's block to be nibble-boundary aligned This can be summarized as /N where: N = 48-(X+Y) where: X is a multiple of 4 such that 2^X is greater than 4/3*(serving sites) Y is a multiple of 4 such that 2^Y is greater than 4/3*(end sites served by the largest serving site) In addition: (i) An end site which can justify more than a /48 under the current end-user assignment policy [1] shall count as the appropriate number of /48s that would be assigned under that policy. (ii) An LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as APNIC. In such a case, the prefixes necessary for such an allocation shall be treated as fully utilized in determining the block sizing for the parent LIR. (iii) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3: 4.5.1 The LIR: - Has a previously justified IPv4 allocation from APNIC, OR - Has a previously justified IPv4 allocation from one of APNIc's predecessor registries, OR - Can qualify for an IPv4 ISP allocation under current APNIC criteria. 4.5.2 The LIR: - Will be making reassignments to other organizations AND - Is currently multihomed for IPv6, OR - Will immediately become multihomed for IPv6 using a valid assigned global AS number 4.5.3 The LIR must provide APNIC a reasonable technical justification of why an allocation is necessary including: - The intended purposes for the allocation - A description of the network infrastructure the allocation will be used to support. - A plan detailing assignments to other organizations or customers for one, two, and five year periods, with a minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of the following two criteria: - Utilization of 75% or more of their total address space, OR - One the LIR/ISP's serving sites has a 90% utilization rate Note: the process for calculating the utilization rate is detailed in Appendix A. When making subsequent allocations to LIRs, APNIC will follow the allocation procedure below: - Wherever possible, APNIC will make an allocation that expands one or more existing allocations. - Where APNIC cannot expand one or more existing allocations, APNIC shall make a new allocation based on the initial allocation criteria described in section 4.5 above. When this occurs, the LIR is encouraged, but not required, to renumber into the new allocation over time and return any allocations no longer in use. In such a case, it is legitimate for an end-site to have assignments from as many as two of these blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end users
The recommended provider assignment unit is /48. In no case will policy consider a provider assignment unit larger than /48. Instead, if an LIR/ISP chooses to assign more than a /48 to an end site, that will be considered to be multiples of the provider assignment unit. If the LIR/ISP chooses to have a provider assignment unit smaller than a /48, then calculations of its address space utilization will accordingly use the smaller prefix size. An LIR may issue up to a /48 to an end site without requiring justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their allocation size if they are eligible for a larger block under the allocation criteria suggested in this proposal.
Any LIR which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, APNIC will simply expand their existing allocation rather than requiring renumber and return.
- Pros/Cons
Advantages:
- Provides nibble-boundaries for direct allocations and for at least one level of network hierarchy within the LIR, reducing the potential for human factors errors. - Increases the potential for network aggregation by issuing very large blocks to ISPs. - Reduces the potential for harmful under-sized assignments to end users by removing any incentive to do so. - Simplifies the IPv6 allocation policy by removing logarithmic computations in favor of simple ratios. - Reduces the number of times any given LIR will need to return to APNIC for additional allocations. - Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50 years, free pool drops from 99.9995% to 99.62%.
- Effect on APNIC
APNIC LIR members will be able to obtain significantly larger blocks of IPv6 addresses and both receive and make their allocations and assignments on nibble boundaries to simplify human factors and network management while improving aggregation.
- Effect on NIRs
This policy should not significantly impact NIRs.
- References
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy' http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A
In general, the following formula is used to calculate the utilization rate in IPv6:
No. of provider assignment units assigned Utilization % = ----------------------------------------- x 100 Total no. of provider assignment units within allocation block(s)
However, there may be occasions when the calculation may need to be amended if an LIR is in the process of renumbering out of an earlier IPv6 block into a subsequent block from APNIC. If this is the case, the following is permitted:
- An LIR can count provider assignment units made to end sites in both the original and newer block into which the LIR is in the process of renumbering into. - The LIR can count assignments made to serving sites in both the original and newer block into which the LIR is in the process of renumbering into.
This double-counting during renumbering means that APNIC would always allocate enough space to an LIR to encompass both existing customers and growth of the LIR within a single new aggregatable block. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0tiYwACgkQSo7fU26F3X0KsQCdElGxRr6KLdD1BC7wfbHgbZ0y vPAAnRMjQpN0o3Uhzy0rJoJQERdllebj =OJ8L -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

On Jan 27, 2011, at 3:28 AM, Skeeve Stevens wrote:
Owen,
Prop-090 seems to completely make sense. Nibble boundaries certainly make sense.
I will point out that under APNIC membership fees:
/32 - $1993 ex-Tax /28 - $5696 ex-Tax (nearly 3 times the amount).
This is of course only if your v6 allocation is larger than your v4.
I will also point out that your Free spool statistics, in my opinion are flawed as being linked to this proposal as APNIC does not have control over IANA and how it allocates resources to the RIR's.
IANA allocates to RIRs in /12 increments based on need.
My free pool statistics were an effort to show the net impact on the free pool if this proposal was adopted vs. if it wasn't, not an effort at explaining global IPv6 policy in general.
I believe that the statistics provide an accurate comparison for that purpose and that they are accurate so long as there is no change to the current IANA->RIR mechanism.
Finally, while APNIC does not directly set IANA->RIR policy, APNIC does actually have veto power over any change to IANA->RIR policy, as does any RIR. In order for that policy to change, a global policy proposal is required. A successful global policy requires that each RIR pass a substantially similar proposal in their region through their own PDP which is then ratified by the ASO AC and finally the ICANN board.
I don't think this proposal as such negates the need for Prop-083 - yet.... As if you are allocating on nibble boundaries and going to a /28, that is only 16 * /32's. While I am not suggesting Prop-083 would facilitate that much extra allocation - it may be possible - and under my philosophy for the proposal - should be allowed if it falls within allocation guidelines.
I agree it doesn't obviate the need for something like PROP-083 in order to support 6rd deployments and the like.
However, I would like to see a 6rd policy (that's really what prop-083 is aimed at, right?) be more limited along the lines of what was passed in the ARIN region 2010-12.
https://www.arin.net/policy/proposals/2010_12.html
That said, this policy as it stands, for specifically the purpose it is proposed for, I support it.
Thanks!
Owen
-----Original Message----- From: Gaurab Raj Upadhaya gaurab@lahai.com Date: Wed, 12 Jan 2011 21:59:24 +1100 To: APNIC Policy SIG List sig-policy@apnic.net Subject: [sig-policy] prop-090: Optimizing IPv6 allocation strategies
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear SIG members,
The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 31 in Hong Kong, 21-25 February 2011.
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
Gaurab, Ching-Heng, and Terence
prop-090-v001: Optimizing IPv6 Allocation Strategies ________________________________________________________________________
Author: Owen DeLong
Version: 1
Date: 12 January 2011
- Introduction
This is a proposal to change how the size of IPv6 allocations and end site assignments are determined, allowing more room for LIRs to grow within their allocation, while also preventing excessive address consumption. The proposal also assists to prevent potential human errors in configuration that can be caused by the current IPv6 policies, which allow allocations and assignments to be made on non-nibble boundaries.
- Summary of the current problem
2.1 Many ISPs expect to make all of their users fit within a /32 IPv6 address block.
This assumption has led to such problems as end user customers receiving single /64s, minimal /60s, or even /56s. If the practice of unnecessarily limited address spaces becomes widespread, vendors will not produce the innovations that are possible in home networking with larger address spaces. Just as NAT has delayed or prevented many forms of innovation in IPv4, small customer assignment sizes could seriously reduce innovation in IPv6.
If this proposed policy were to be implemented, in 50 years, the projected IPv6 free pool would be 99.54% of total IPv6 space vs 99.9975% if the current policy were still in place at that time. Given the small amount of extra IPv6 addresses that would be consumed by implementation of this proposed policy, it would be a shame for innovation to be stifled by continuing the current policy.
2.2 Mistakes are made when calculating end addresses for non-nibble boundary allocations and assignments
In IPv6, non-nibble boundary prefixes can lead to human error in calculating the end address of the prefix. For example, if a network were allocated
2001:0db8::/30
The LIR would need to calculate that the end address of that /30 was
2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff
However, even experienced engineers can make mistakes when making such calculations. In fact, to clarify the problem, as I was writing the above example, I initially made the mistake of calculating the end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff.
When mistakes like this are made in routers, it causes outages.
2.3 If /32s continue to be the default allocation size, it will also eventually lead to unnecessary disaggregation and larger routing tables.
2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in the community.
Therefore, this proposal replaces the HD ratio with simple ratios for utilization thresholds and reduces the frequency with which utilization thresholds would need to be calculated.
- Situation in other RIRs
ARIN:
Submitted. Currently undergoing a process of staff review before being handed to the ARIN Address Council for further review.
http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html
The author intends to submit a similar proposal to LACNIC and AfriNIC.
RIPE:
As RIPE NCC seems to be currently issuing generous allocations, the author currently has no intention of submitting this proposal to RIPE. However, the author may eventually submit a proposal to RIPE to address the problem of non-nibble boundary allocations.
- Details
This is a proposal to amend the IPv6 policy to:
4.1 Add the following definitions:
Serving site: A location where an ISP terminates or aggregates customer connections, including, but not limited to Points of Presence (POPs), Datacenters, Central or Local switching offices or regional or local combinations thereof.
Provider The prefix of the smallest IPv6 block a given ISP assignment assigns to end sites. unit:
Nibble A network mask which aligns on a 4-bit boundary. boundary: This means that the prefix length must be divisible by 4. For example, /24, /28, /32, and /48 are all aligned on a nibble boundary while /22, /26, /29, /30, and /47 are not.
4.2 Redefine the following terms:
End site: A single structure or service delivery address, or a single tenant within a multi-tenant structure
- The aim of this more generous interpretation of end site to provide a clear definition which is easily understood and provides maximum flexibility for service providers to meet the needs of their customers.
Utilized: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end site.
(ii) The utilization percentage of a block at the LIR level is calculated as the fraction of total provider assignment units which have been assigned to end sites.
4.3 Make all allocations and assignments on nibble boundaries
Removing the ability to make delegations on non-nibble boundaries makes it easier for end addresses of IPv6 blocks to be calculated.
For example, if the next allocation one size larger than /32 is /28, then, 2001:0db0::/28 has an end address of:
2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff
Allocating and assigning on nibble boundaries also makes DNS delegations easier.
4.4 Change the size of initial allocations to LIRs according to the following criteria:
4.4.1 The minimum allocation size for an LIR shall be a /32, unless the LIR specifically requests a /36.
4.4.2 The maximum allocation unit shall be the smallest block which:
- Is nibble-boundary aligned - Permits the largest serving site to be assigned a large enough block to allow <=0.75 (75%) utilization - Can provide an equal-sized block to each serving site - Permits each serving site's block to be nibble-boundary aligned This can be summarized as /N where: N = 48-(X+Y) where: X is a multiple of 4 such that 2^X is greater than 4/3*(serving sites) Y is a multiple of 4 such that 2^Y is greater than 4/3*(end sites served by the largest serving site) In addition: (i) An end site which can justify more than a /48 under the current end-user assignment policy [1] shall count as the appropriate number of /48s that would be assigned under that policy. (ii) An LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as APNIC. In such a case, the prefixes necessary for such an allocation shall be treated as fully utilized in determining the block sizing for the parent LIR. (iii) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled.
4.5 Change the criteria for an allocation
To qualify for an allocation, an LIR must meet the criteria described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3:
4.5.1 The LIR:
- Has a previously justified IPv4 allocation from APNIC, OR - Has a previously justified IPv4 allocation from one of APNIc's predecessor registries, OR - Can qualify for an IPv4 ISP allocation under current APNIC criteria.
4.5.2 The LIR:
- Will be making reassignments to other organizations AND - Is currently multihomed for IPv6, OR - Will immediately become multihomed for IPv6 using a valid assigned global AS number
4.5.3 The LIR must provide APNIC a reasonable technical justification of why an allocation is necessary including:
- The intended purposes for the allocation - A description of the network infrastructure the allocation will be used to support. - A plan detailing assignments to other organizations or customers for one, two, and five year periods, with a minimum of 50 assignments within 5 years.
4.6 Change the way subsequent allocations to LIRs are made
To qualify for a subsequent allocation, an LIR must meet one of the following two criteria:
- Utilization of 75% or more of their total address space, OR
- One the LIR/ISP's serving sites has a 90% utilization rate
Note: the process for calculating the utilization rate is detailed in Appendix A.
When making subsequent allocations to LIRs, APNIC will follow the allocation procedure below:
Wherever possible, APNIC will make an allocation that expands one or more existing allocations.
Where APNIC cannot expand one or more existing allocations, APNIC shall make a new allocation based on the initial allocation criteria described in section 4.5 above.
When this occurs, the LIR is encouraged, but not required, to renumber into the new allocation over time and return any allocations no longer in use. In such a case, it is legitimate for an end-site to have assignments from as many as two of these blocks at a time to facilitate transition to the new range.
4.7 Change the recommendations for LIRs to make assignments to end users
The recommended provider assignment unit is /48. In no case will policy consider a provider assignment unit larger than /48. Instead, if an LIR/ISP chooses to assign more than a /48 to an end site, that will be considered to be multiples of the provider assignment unit.
If the LIR/ISP chooses to have a provider assignment unit smaller than a /48, then calculations of its address space utilization will accordingly use the smaller prefix size.
An LIR may issue up to a /48 to an end site without requiring justification.
4.8 Allow LIRs with existing IPv6 allocations to expand their allocation size if they are eligible for a larger block under the allocation criteria suggested in this proposal.
Any LIR which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years.
If possible, APNIC will simply expand their existing allocation rather than requiring renumber and return.
- Pros/Cons
Advantages:
Provides nibble-boundaries for direct allocations and for at least one level of network hierarchy within the LIR, reducing the potential for human factors errors.
Increases the potential for network aggregation by issuing very large blocks to ISPs.
Reduces the potential for harmful under-sized assignments to end users by removing any incentive to do so.
Simplifies the IPv6 allocation policy by removing logarithmic computations in favor of simple ratios.
Reduces the number of times any given LIR will need to return to APNIC for additional allocations.
Allows for better network planning and growth.
Disadvantages:
- Increases IPv6 address allocation. Probable impact over 50 years, free pool drops from 99.9995% to 99.62%.
- Effect on APNIC
APNIC LIR members will be able to obtain significantly larger blocks of IPv6 addresses and both receive and make their allocations and assignments on nibble boundaries to simplify human factors and network management while improving aggregation.
- Effect on NIRs
This policy should not significantly impact NIRs.
- References
[1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy' http://www.apnic.net/policy/ipv6-address-policy#5.5
Appendix A
In general, the following formula is used to calculate the utilization rate in IPv6:
No. of provider assignment units assigned
Utilization % = ----------------------------------------- x 100 Total no. of provider assignment units within allocation block(s)
However, there may be occasions when the calculation may need to be amended if an LIR is in the process of renumbering out of an earlier IPv6 block into a subsequent block from APNIC. If this is the case, the following is permitted:
An LIR can count provider assignment units made to end sites in both the original and newer block into which the LIR is in the process of renumbering into.
The LIR can count assignments made to serving sites in both the original and newer block into which the LIR is in the process of renumbering into.
This double-counting during renumbering means that APNIC would always allocate enough space to an LIR to encompass both existing customers and growth of the LIR within a single new aggregatable block. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0tiYwACgkQSo7fU26F3X0KsQCdElGxRr6KLdD1BC7wfbHgbZ0y vPAAnRMjQpN0o3Uhzy0rJoJQERdllebj =OJ8L -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Activity Summary
- 4693 days inactive
- 4693 days old
- sig-policy@lists.apnic.net
- 7 participants
- 9 comments