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 elvis@velea.eu
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
| > fujisaki@syce.net mailto:fujisaki@syce.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.
| >
| > - 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-guidelin...
| >
| > [3] Packet Filter and Route Filter Recommendation for IPv6 at xSP
| > routers
| > https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat...
| >
| > [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
| > sig-policy@lists.apnic.net
| > http://mailman.apnic.net/mailman/listinfo/sig-policy
|