Hi Elvis, Thnak you for your comments!
| This proposal has been already made and approved/implemented (May2012) | in the RIPE Region and as far as I can see, it was a good proposal and | it has not caused any problems. | | The /29s are reserved anyway, why not allow the LIRs to use them if | they need a larger/additional block? | From my experience, some LIRs may need more than just the /32 used for | their main/primary network in order to test in a separate network a | transitioning protocol or equipment. For this reason only I think that | keeping the /29 reserved and not allocated is a waste. I'll introduce situation of ripe region in my presentation. Yours Sincerely, -- Tomohiro Fujisaki From: Elvis Velea <[email protected]> Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size Date: Wed, 17 Sep 2014 11:44:42 +1000 | Hi, | | you have my support. | | This proposal has been already made and approved/implemented (May2012) | in the RIPE Region and as far as I can see, it was a good proposal and | it has not caused any problems. | | The /29s are reserved anyway, why not allow the LIRs to use them if | they need a larger/additional block? | From my experience, some LIRs may need more than just the /32 used for | their main/primary network in order to test in a separate network a | transitioning protocol or equipment. For this reason only I think that | keeping the /29 reserved and not allocated is a waste. | | Offcourse, the /29 allocation should be made upon request of the | LIR. If the LIR needs it, he can just request it but not have to send | any kind of justification (other than - I need/want the extension of | the allocation from /32 to /29) | | my 2 cents, | elvis | | On 17/09/14 10:26, Masato Yamanishi 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. | > | > There are changes to section 4. Proposed policy solution only. | > | > 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 change 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-v004 Request-based expansion of IPv6 default allocation size | > | ---------------------------------------------------------------------- | > | > Author: Tomohiro Fujisaki | > [email protected] <mailto:[email protected]> | > | > | > 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. | > | > - Change /32 to /29 in "5.2.3 Larger initial allocations" | > | > Initial allocations larger than /29 may be justified if: | > | > - Add following text as 5.3.4 | > | > 5.3.4 Extend existing allocations to /29 | > 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 providing their | > network | > plan to show 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 | > <http://www.space.net/%7Egert/RIPE/ipv6-filters.html> | > | > | > | > * sig-policy: APNIC SIG on resource management policy * | > _______________________________________________ | > sig-policy mailing list | > [email protected] | > http://mailman.apnic.net/mailman/listinfo/sig-policy | * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
