Re: [sig-policy] New version of prop-111: Request-based expansion of IPv
Hi Mike, Sanjeev and Owen,
Thank you for your comments.
>From the technical point of view, I agree IPv6 allocations should be
in 'nibble boundaries'.
However, as some of you mentioned, main purpose of this policy is to
utilize address blocks which might be unused in the future. And in my
current proposal, I propose to allow to extend up to /29 (same size as
RIPE-NCC) for all LIRs (both in the legacy address block and in the
sparse allocation block) from the view point of fairness.
I currently think to extend this /29 to /28 will be next step, and
we should consider about LIRs who have /29 upper limit.
Yours Sincerely,
--
Tomohiro Fujisaki
From: "HENDERSON MICHAEL, MR" <MICHAEL.HENDERSON@NZDF.mil.nz>
Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]
Date: Tue, 2 Sep 2014 23:07:01 +0000
| I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that basis, the next allocation larger than /32 would be /28, not /29.
| Address masking and calculation on /29 boundaries will in my view be quite nasty, and the size of the IPv6 address space is sufficiently large that we need not, and therefore should not, impose such inconveniences on ourselves.
|
| Hence, in my IPv6 allocation world, a resource holder who has a demonstrated need (for whatever value of ‘need’ seems appropriate) for address space larger than /32, should be allocated a /28.
| If they are ‘growing’ an existing /32, then the new /28 would very preferably be one that includes the currently-allocated /28.
|
|
| However, I understand the current situation is that the ‘legacy’ IPv6 address allocation was for smaller allocations within blocks on /29 boundaries, if I read the Proposition correctly.
| As a special case only, I would support the allocation of these ‘legacy /29’ blocks. The provisos being that firstly they do fall into this ‘legacy’ category, and that secondly it is not possible (owing to allocation to a third party) to allocate a /28 to the relevant resource holder
|
|
|
| Regards
|
|
| Mike
|
| From: sig-policy-bounces at lists dot apnic dot net [mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Masato Yamanishi
| Sent: Wednesday, 3 September 2014 10:40 a.m.
| To: sig-policy at apnic dot net
| Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size
|
| Dear Colleagues,
|
| While next APNIC meeting is reaching 3 weeks later, we saw just couple of comments for this revised proposal.
|
| Our process for reaching consensus relies on hearing the opinions of those who can only take part via this list
| as well as those who can attend the Policy SIG sessions at the APNIC meetings.
|
| It would be very helpful for the community to hear any opinions including favor or against.
|
| Regards,
| Policy SIG Chairs,
|
|
| On 2014/07/31 11:42, "Masato Yamanishi" <myamanis at japan-telecom dot com<mailto:myamanis at japan-telecom dot com>> wrote:
|
| Dear SIG members
|
| A new version of the proposal “prop-111: Request-based expansion of IPv6 default allocation size has been sent to the Policy SIG for review.
|
| Information about earlier versions is available from:
|
| http://www.apnic.net/policy/proposals/prop-111
|
| You are encouraged to express your views on the proposal:
|
| - Do you support or oppose the proposal?
| - Is there anything in the proposal that is not clear?
| - What changes could be made to this proposal to make it more effective?
|
| Please find the text of the proposal below.
|
| Kind Regards,
|
| Andy and Masato
|
|
|
| ----------------------------------------------------------------------
|
| prop-111-v003 Request-based expansion of IPv6 default allocation size
|
| ----------------------------------------------------------------------
|
|
|
| Author: Tomohiro Fujisaki
|
| fujisaki at syce dot net<mailto:fujisaki at syce dot net>
|
|
|
|
|
| 1. Problem statement
|
| --------------------
|
|
|
| IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6
|
| address allocation and assignment policy"[1]. It's better to
|
| expand this minimum allocation size up to /29 (/32 - /29) since:
|
|
|
| - Before sparse allocation mechanism implemented in late 2006, /29
|
| was reserved for all /32 allocations by sequential allocation
|
| method made from those old /23 blocks. These reserved blocks
|
| might be kept unused in the future.
|
|
|
| - Sparse allocation mechanism was implemented in late 2006 with a
|
| /12 allocation from the IANA. Under the sparse allocation
|
| mechanism, there is no reservation size defined, and the space
|
| between allocations continues to change, depending on the
|
| remaining free pool available in APNIC.
|
|
|
| However, the "APNIC guidelines for IPv6 allocation and
|
| assignment requests"[2] stated:
|
|
|
| "In accordance with APNIC's "IPv6 address allocation and
|
| assignment policy", where possible, subsequent delegations to the
|
| same resource holder are made from an adjacent address block by
|
| growing the delegation into the free space remaining, unless
|
| disaggregated ranges are requested for multiple discrete
|
| networks."
|
|
|
| So, it is expected that allocation up to /29 is guaranteed for
|
| consistency with allocations above. Based on the current
|
| situation, contiguous allocation of /29 can still be accommodated
|
| even under the sparse allocation mechanism (Current /32
|
| allocations from the /12 block can grow up to /24 at this stage).
|
|
|
| - After amended HD Ratio (0.94) and base calculation size (/56) was
|
| introduced (prop-031 and prop-033), to obtain address blocks larger
|
| than /32 and to request additional address blocks became harder
|
| especially for small and middle size ISPs.
|
|
|
| - For traffic control purpose, some LIRs announce address blocks
|
| longer than /32 (e.g. /35). However, some ISPs may set filters to
|
| block address size longer than /32 since some filtering
|
| guidelines recommend to filter longer prefix than /32([3][4]). If
|
| LIRs have multiple /32, they can announce these blocks and its
|
| reachability will be better than longer prefix.
|
|
|
| - If an LIR needs address blocks larger than /32, LIRs may tend to
|
| announce as a single prefix if a /29 is allocated initially at
|
| once. i.e., total number of announced prefixes in case 1 may be
|
| smaller than in case 2.
|
|
|
| case 1:
|
| The LIR obtains /29 at the beginning of IPv6 network construction.
|
|
|
| case 2:
|
| The LIR obtains /32, and /31, /30 additionally with the subsequent
|
| allocation mechanism.
|
|
|
| 2. Objective of policy change
|
| -----------------------------
|
|
|
| This proposal modifies the eligibility for an organization to
|
| receive or extend an IPv6 address space up to a /29 (/32 -/29) by
|
| explaining how the extended space up to /29 will be used.
|
|
|
|
|
| 3. Situation in other regions
|
| -----------------------------
|
|
|
| RIPE-NCC:
|
| The policy "Extension of IPv6 /32 to /29 on a per-allocation vs
|
| per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get
|
| up to /29 by default.
|
|
|
|
|
| 4. Proposed policy solution
|
| ----------------------------
|
|
|
| - Change the text to "5.2.2 Minimum initial allocation size" of
|
| current policy document as below:
|
|
|
| Organizations that meet the initial allocation criteria are
|
| eligible to receive an initial allocation of /32. The organizations
|
| can receive up to /29 by providing utilization information of the whole
|
| address space.
|
|
|
| - Add following text in the policy document:
|
|
|
| for Existing IPv6 address space holders
|
|
|
| LIRs that hold one or more IPv6 allocations are able to request
|
| extension of each of these allocations up to a /29 without meeting
|
| the utilization rate for subsequent allocation by explaining
|
| how the whole address space will be used.
|
|
|
|
|
| 5. Explain the advantages of the proposal
|
| -----------------------------------------
|
|
|
| - It is possible to utilize address blocks which is potentially
|
| unused into the future.
|
|
|
| - Organizations can design their IPv6 networks more flexibly.
|
|
|
| - It will be possible for LIRs to control traffic easier.
|
|
|
|
|
| 6. Explain the disadvantages of the proposal
|
| --------------------------------------------
|
|
|
| Some people may argue this will lead to inefficient utilization of
|
| IPv6 space since LIRs can obtain huge address size unnecessarily.
|
| However, this will not happen because larger address size needs
|
| higher cost to maintain that address block.
|
|
|
|
|
| 7. Impact on resource holders
|
| -----------------------------
|
|
|
| NIRs must implement this policy if it is implemented by APNIC.
|
|
|
|
|
| 8. References (if required)
|
| ---------------------------
|
|
|
| [1] IPv6 address allocation and assignment policy
|
| http://www.apnic.net/policy/ipv6-address-policy
|
|
|
| [2] APNIC guidelines for IPv6 allocation and assignment requests
|
| https://www.apnic.net/publications/media-library/documents/resource-guidelines/ipv6-guidelines
|
|
|
| [3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers
|
| https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendations.html
|
|
|
| [4] IPv6 BGP filter recommendations
|
| http://www.space.net/~gert/RIPE/ipv6-filters.html
|
|
| 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.