Re: [sig-policy] New version of prop-111 Request-based expansion of IPv6
On Fri, 28 Feb 2014 10:19:57 +0900
Tomoya Yoshida <yoshida at mfeed dot ad dot jp> 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 <dean at internetnz dot net dot nz> 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)
||dean at internetnz dot net dot nz
||
||To promote the Internet's benefits and uses, and protect its potential.
||
||
||On Fri, Feb 14, 2014 at 12:29 PM, Andy Linton <asjl at lpnz dot org> 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
||> 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).
||>
||> - 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
||> sig-policy at lists dot apnic dot net
||> http://mailman.apnic.net/mailman/listinfo/sig-policy
||>
||* sig-policy: APNIC SIG on resource management policy *
||_______________________________________________
||sig-policy mailing list
||sig-policy at lists dot apnic dot net
||http://mailman.apnic.net/mailman/listinfo/sig-policy
|
|--
|Tomoya Yoshida <yoshida at mfeed dot ad dot jp>
|
|* sig-policy: APNIC SIG on resource management policy *
|_______________________________________________
|sig-policy mailing list
|sig-policy at lists dot apnic dot net
|http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Tomoya Yoshida <yoshida at mfeed dot ad dot jp>