I'm Sorry my comments was for prop-110. On Fri, 28 Feb 2014 10:19:57 +0900 Tomoya Yoshida <[email protected]> wrote:
|Hi Dean, | |We already know 1.2.3.4 is very dirty. |In this condition, when the leakage accidentally happen from ISP |who use 1.2.3.4, dirty packets(I think attackers will focus on the DNS |vulnerability) go to that cache server. | |I know the risk is for that ISP who use 1.2.3.4 but also for all |the people who use 1.2.3.4 for their cache sometime casually. | |Of course 1.2.3.4 is a good number for everybody, it's very |easy to remember but in this context I doubt now |the advantages is much higher than disadvantages. | |Thanks, | | -tomoya | |On Thu, 27 Feb 2014 15:11:08 +1300 |Dean Pemberton <[email protected]> wrote: | ||As mentioned in the Policy-SIG. || ||I would like to see a proposal that looked to discuss and possibly ||extend the list of justifications available for members when ||requesting prefixes (such as Traffic Engineering). || ||I encourage the proposer of prop-111 to look at authoring such a ||proposal for discussion by the community. || ||Regards ||Dean Pemberton || ||Technical Policy Advisor ||InternetNZ ||+64 21 920 363 (mob) ||[email protected] || ||To promote the Internet's benefits and uses, and protect its potential. || || ||On Fri, Feb 14, 2014 at 12:29 PM, Andy Linton <[email protected]> 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 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? ||> ||> Regards, ||> ||> Andy and Masato ||> ||> ||> ---------------------------------------------------------------------- ||> prop-111-v002 Request-based expansion of IPv6 default allocation size ||> ---------------------------------------------------------------------- ||> ||> Author: Tomohiro Fujisaki ||> [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). ||> ||> - 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 an initial IPv6 allocation up to a /29 (/32 - /29) by ||> request basis. ||> ||> ||> 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. For allocations ||> up to /29 no additional documentation is necessary. ||> ||> - 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 and providing ||> further documentation. ||> ||> ||> ||> 5. Explain the advantages of the proposal ||> ----------------------------------------- ||> - It is possible to utilize address blocks which is potentially ||> unused into the future. ||> - It will be possible for LIRs to control traffic easier. ||> - Organizations can design their IPv6 networks more flexibly. ||> ||> ||> 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 ||> ------------- ||> [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 ||> ||> ||> * 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 | |-- |Tomoya Yoshida <[email protected]> | |* sig-policy: APNIC SIG on resource management policy * |_______________________________________________ |sig-policy mailing list |[email protected] |http://mailman.apnic.net/mailman/listinfo/sig-policy -- Tomoya Yoshida <[email protected]> * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
