I second MMC's concern.
The key assumption and justification for this proposal is the annual account growth forecast, and your second key assumption is the time for complete migration to v6. Behaviour generally changes when a critical resource becomes scarce ? when applying for a new membership becomes the only way to get new IP addresses (because your upstream has run out of IP addresses), you will see a lot more members which can deplete this pool ahead of your estimates. Or more optimistically, perhaps this will accelerate the adoption of v6.
If the current final /8 policy begins to have a negative impact to the Internet community in AP, then we should absolutely review the and amend the final /8 policy. However I do not believe that now is the right time to accelerate depletion of the final /8.
I do not support prop-091
From: Matthew Moyle-Croft <mmc at internode dot com dot au>
Date: Thu, 20 Jan 2011 18:20:32 +0800
To: Gaurab Raj Upadhaya <gaurab at lahai dot com>
Cc: APNIC Policy SIG List <sig-policy at apnic dot net>
Subject: Re: [sig-policy] prop-091: Limiting of final /8 policy to specific /9
Hi,
I don't support this proposal. I don't see the point in deliberately running out the IPv4 space earlier for short term gain. The fact that this space may not be allocated for a long time doesn't seem important. It's the last lot, let's treat it as precious and leave some for those who will need it in small quantities.
MMC
On 20/01/2011, at 7:22 PM, Gaurab Raj Upadhaya wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear SIG members,
The proposal, 'Limiting of final /8 policy to specific /9', 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-091-v001: Limiting of final /8 policy to specific /9
_______________________________________________________________________
Author: David Woodgate
Version: 1
Date: 20 January 2011
1. Introduction
- ----------------
This is a proposal to modify the policies for distribution of the
"final /8" to only apply to a specific /9 block of the final /8, on the
basis that the current policies would unnecessarily prevent the use of
over 8 million IPv4 addresses that otherwise should be used to enable
user connections.
2. Summary of the current problem
- ----------------------------------
The original final /8 policy proposal assumed that small amounts of
IPv4 addressing would still be needed for some years into the future to
successfully operate an Internet business, even with IPv6 use growing
rapidly in the industry. Therefore, the aim of the final /8 policy was
to ensure that new ISPs and other businesses would continue to have
access to IPv4 addresses to initiate their services.
The current final /8 policy [1] allows for one minimum allocation per
APNIC account holder from the entire final APNIC /8. This results in
the following potential numbers of allocations:
No. of /22s available from /8: 16,536
No. of /22s available from /8 (reserved /16 removed): 16,320
This is a large number of potential allocations when compared with
APNIC's current numbers of account holders and recent annual growth:
No. of APNIC account holders (Aug 2010) [2]: 3,132
APNIC acount holder growth per annum [3]: around 320
If the APNIC account holder growth rate were to increase up to 480 new
account holders per year (a 150% increase on the current growth
rate), it would take over 27 years to make every one of the possible
16,320 allocations from the final /8 (minus the reserved /16).
It is reasonable to expect that within the next 10 years IPv6 will be
thoroughly deployed throughout the Internet as the preferred protocol
and that IPv4 address allocation will no longer be sought. Looking at a
10-year forecast of annual account holder growth of 480, only a /9
would be consumed within this timeframe, leaving another /9 never used
under current final /8 policy.
This would seem to be an undesirable situation for the APNIC community,
as this unused space could be used to provide IPv4 Internet connections
to millions of users (whether that be prior to or as part of dual-stack
IPv6 deployments). The release of these addresses would not be expected
to make a significant change to the overall IPv4 exhaustion timeframes,
but it would allow the addresses to be used for their designed purpose
of enabling user connections.
If the pool reserved for the final /8 allocation policies were to be
reduced to a /9, it would result in the following potential numbers of
allocations:
No. of /22s available from /9: 8,192
No. of /22s available from /9 (reserved /16 removed): 8,128
3. Situation in other RIRs
- ---------------------------
AfriNIC:
AfriNIC do not have a confirmed final /8 policy yet, but are
considering the "IPv4 Soft Landing Proposal". If this proposal is
adopted, AfriNIC would continue to allocate from their final /8,
but with greater limitations on allocations particularly for their
final /11:
http://www.afrinic.net/docs/policies/AFPUB-2010-v4-005.htm
ARIN:
Section 4.10, "Dedicated IPv4 block to facilitate IPv6 Deployment",
of the ARIN Number Resource Policy Manual, specifies that ARIN will
reserve a /10 from their final /8 to facilitate IPv6 deployment.
https://www.arin.net/policy/nrpm.html#four10
LACNIC:
Section 11, "Policies Relating to the Exhaustion of IPv4 Address
Space", of the LACNIC Policy Manual specifies that LACNIC will
restrict allocations for their final /12:
http://www.lacnic.net/en/politicas/manual11.html
RIPE:
Proposal 2010-02, "Allocations from the last /8", which appears to
be based on APNIC's current final /8 policy is currently "Awaiting
Decisions from WG Chairs".
http://www.ripe.net/ripe/policies/proposals/2010-02.html
It therefore appears that most of the RIRs have policies or are
considering proposals that will reserve blocks that would be smaller
than the /9 being considered by this proposal. Only RIPE is considering
a proposal that would duplicate APNIC's current policy for the entire
final /8.
4. Details
- -----------
It is proposed that the policy, "Distribution of the final /8 worth of
space in the unallocated APNIC IPv4 address pool" be adjusted as
follows:
4.1 The policies be applied to a specific contiguous /8 block received
from IANA.
4.2 The specific block from IANA be divided into two /9 blocks.
4.3 One of the two /9 blocks will have the following policies applied
to it:
- The policy for allocations to LIRs currently described in
section 9.10.1, "Allocations to LIRs"
- The policy for reserving a /16 for future use, currently
described in section 9.10.2, "Allocations for future uses"
4.4 The other /9 block will be allocated according to current IPv4
allocation policies, and in particular the policies described by:
- 9.3 Criteria for initial allocation
- 9.4 Criteria for subsequent allocations
5. Pros/Cons
- -------------
Advantages:
- - Adoption of this proposal would provide over 8 million additional
IPv4 addresses for use by the APNIC community for user connections
Disadvantages:
- - If there were an unforeseen explosion of APNIC account holders in the
the near future, there would be a slight risk that new Internet
businesses might not be able to obtain IPv4 addresses for their
business before IPv6 were generally deployed. However, historical
data [2][3][4] indicates that this would seem a very unlikely
scenario within a 10-year timeframe.
6. Effect on APNIC
- -------------------
Adoption of this proposal would require APNIC to manage the allocation
of an additional /9 prior to moving to the "exhaustion phase" of
allocations. This would be expected to add only a couple of months at
most of allocations according to current practices, and this extra work
would be within the standard scope of APNIC's purpose.
7. Effect on NIRs
- ------------------
There would be no significant impact on NIRs arising from this proposal
other than the potential allocation of additional IPv4 address space
to them by APNIC.
8. References
- --------------
[1] Section 9.10.1, "Allocations to LIRs", in "Policies for IPv4
address space management in the Asia Pacific region"
http://www.apnic.net/policy/add-manage-policy#9.10.1
[2] Slide 12, "APNIC Service Levels", APNIC Services Area Report,
APNIC 30
http://meetings.apnic.net/30/Services-Report-Sanjaya.pdf
[3] Inferred from slide 2, "APNIC Service Levels", APNIC Services Area
Report, APNIC 29, http://meetings.apnic.net/29/Services-Report.pdf
and by comparison with the figures in reference [2]
[4] APNIC Membership graph, page 3, APNIC Annual Report 2009
http://www.apnic.net/2009-APNIC-Annual-Report.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0399gACgkQSo7fU26F3X1nyACgm0vAMFHNpnJHe3lugy8bydYo
mvMAn1R2pGGp6nsuwpJaJRT8A0F08oo4
=3pwv
-----END PGP SIGNATURE-----
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Matthew Moyle-Croft
Peering Manager and Team Lead - Commercial and DSLAMs
Internode /Agile
Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc at internode dot com dot 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: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy