[sig-policy] prop-093-v002: Reducing the minimum delegation size for the
Hash: SHA1
Dear SIG members,
Version 2 of the proposal, 'Reducing the minimum delegation size for
the final /8 policy', has been sent to the Policy SIG for review. It
will be presented at the Policy SIG at APNIC 31 in Hong Kong SAR,
China, 21-25 February 2011.
Change in version 2:
- Additional author, Terence Zhang Yinghao, added, following his
decision to withdraw prop-085 and support this prop-093.
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-093-v002: Reducing the minimum delegation size for the final /8
policy
________________________________________________________________________
Author: Randy Bush
<randy at psg dot com>
Philip Smith
<pfs at cisco dot com>
Andy Linton
<asjl at lpnz dot org>
Terence Zhang Yinghao
<zhangyinghao at cnnic dot cn>
Version: 2
Date: 18 February 2011
1. Introduction
- ----------------
This is a proposal to change the minimum size of IPv4 delegations to a
/24 when the final /8 policy [1] is activated.
2. Summary of current problem
- ------------------------------
The current final /8 allocation policy requires networks to meet the
requirements for the minimum allocation size currently in place:
currently a /22. To justify a /22 allocation, a network must
demonstrate, amongst other things, an immediate need for a /24 and a
detailed plan for use of a /23 within a year. However, this could
prevent small networks, that may be multihomed, operating critical
Internet infrastructure, or connecting to IXPs, or running IPv6
transition tools such as NAT64, from justifying a need for IPv4
addresses under the final /8 policy.
3. Situation in other RIRs
- ---------------------------
There is no similar policy or proposal in other regions.
4. Details of the proposal
- ---------------------------
It is proposed that when APNIC enters the phase of the final /8
policy[1]:
4.1 The minimum delegation size be set to a /24.
4.2 The maximum delegation size any one organisation can receive from
the final /8 be set to a /22.
Note: This means that an organisation which has received a single
/24 under this proposal is entitled to request and receive
additional IPv4 address(es) from APNIC until it has received
up to a total of a /22.
4.3 Criteria for delegations under the final /8 policy will accordingly
be expanded to include the following criteria:
- Small multihoming assignments
- Internet Exchange Points
- Critical infrastructure
5. Advantages and disadvantages of the proposal
- ------------------------------------------------
5.1 Advantages
- This proposal allows a greater range of networks to access the
resources in the final /8.
- This proposal extends the maximum possible total number of
networks that can benefit from the final /8 pool from around
16,000 to around 65,000 networks, providing small amounts of
IPv4 to be available for networks, end site, etc., making the
transition to IPv6 for many years to come.
5.2 Disadvantages
- No disadvantages are foreseen.
6. Effect on APNIC members
- ---------------------------
It reduces the minimum size of the delegated address block available
to APNIC members during the final /8 phase.
7. Effect on NIRs
- ------------------
This will affect NIR members in the same way as APNIC members.
8. References
- --------------
[1] Section 9.10 "Distribution of the final /8 worth of space in the
unallocated APNIC IPv4 address pool" of "Policies for IPv4 address
space management in the Asia Pacific region"
http://www.apnic.net/policy/add-manage-policy#9.10
- --
http://www.gaurab.org.np/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1eOQMACgkQSo7fU26F3X2xUwCgjS86ncpjmGy0o+lmRq3xzFJp
3RMAoPZtNxa20k2dJLJwG7B/3lcK7t5G
=mgob
-----END PGP SIGNATURE-----