Hi,
I see two ways to make the addresses in the last /8 available sooner (if that is a goal):
a) distribute the 2nd-last /9 under normal rules (this prop-091), or
b) distribute the last /8 in bigger than /22 lumps.
I haven't seen any discussion of why a) is better/worse than b).
My guess is that the 2nd-last /9 would to go in a few very large allocations to bulk up a few current incumbents late this year.
If we distribute the 2nd-last /9 then we have restricted our later flexibility.
If we keep current policies, later we can increase the allocation size later, or let every member have 2 x /22s, or ...
I recommend we keep current policies for now.
Thanks,
John
On 20 January 2011 21:34, Owen DeLong <owen at delong dot com> wrote:
- I completely disagree. Keeping significant reserves of IPv4 on the shelf such that it can effectively never be utilized makes absolutely no sense to me.
- I think that reserving a /9 is prudent and provides more than enough cushion for any foreseeable growth in the APNIC region after IPv4 runout. I think that a /8 is, as the math has shown, excessive and that failing to correct this will actually present an image of poor resource management to the broader community impacted by this decision.
- Owen
- On Jan 20, 2011, at 2:20 AM, Matthew Moyle-Croft wrote:
- 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
- * 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
* 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