[arin-ppml] FW: [sig-policy] prop-083: Alternative criteria for subsequentIPv6 allocations
David Farmer
farmer at umn.edu
Fri Feb 5 09:55:58 EST 2010
Thanks for the pointer.
But, this sounds more like ARIN 2009-5: IPv6 Multiple Discrete Networks
to me.
https://www.arin.net/policy/proposals/2009_5.html
This was just implemented into ARIN's NRPM.
https://www.arin.net/policy/nrpm.html#six_11
The intent of my question is how do we want to deal with networks that
are not connected to the Internet. In other words, networks that have
no intention of achieving global reachability but still many need or
want globally unique addresses. ARIN specifically addresses a special
case of what I am asking about in 6.10.2 Micro Allocation for Internal
Infrastructure. Also, by the fact that current end-user assignments are
based on IPv4 Policy, then section 4.3.5. Non-connected Networks allows
such networks to get an IPv6 assignment.
But, I believe we need to address this issue much more directly and
cleanly than in current policy.
Skeeve Stevens wrote:
> Hey all,
>
> Given the current topic of 'IPv6 Non-Connected Networks', I thought that I would let you know of a policy that is presently in discussion on the APNIC lists that I submitted.
>
> The crux is that even if aggregation of announcements as a policy is dropped, there is no policy that satisfies the need of LIR's to be able to build non-connected IPv6 networks in the APNIC region.
>
> With some basic justification, an LIR should be able to gain subsequent /32 allocations for the purpose of remaining 'as routable as possible'.
>
> While APNIC, like other RIR's do not set routing policy, they do heavily influence it. And while they cannot control the practice of community filtering lists based on their own allocation pools, they should not ignore the situation.
>
> Given that IPv6 is not a scarce resource and by no means am I suggesting we just burn it for the fun of it, this seems to be a philosophical debate rather than a technical one. This is due to that even if an LIR could de-aggregate its /32 to say, 8 /35's or 16 36's, these entries in the routing table would have the exact same result as if they had 16 * /32's.
>
> So due to this, the only restriction here is the pool allocation which the community filter lists are based on - which the RIR's essentially have created and now have the responsibility to consider.
>
> ...Skeeve
>
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
> From: sig-policy-bounces at lists.apnic.net [mailto:sig-policy-bounces at lists.apnic.net] On Behalf Of Terence Zhang YH(CNNIC)
> Sent: Wednesday, 3 February 2010 10:46 PM
> To: sig-policy at apnic.net
> Subject: [sig-policy] prop-083: Alternative criteria for subsequentIPv6 allocations
>
> Dear SIG members,
>
> The proposal, 'Alternative criteria for subsequent IPv6 allocations',
> has been sent to the Policy SIG for review. It will be presented at the
> Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
>
> - Do you support or oppose this proposal?
> - Does this proposal solve a problem you are experiencing? If so,
> tell the community about your situation.
> - Do you see any disadvantages in 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?
>
>
> Information about this and other policy proposals is available from:
>
> http://www.apnic.net/policy/proposals
>
>
> Randy, Ching-Heng, and Terence
>
>
> ___________________________________________________________________
>
> prop-083-v001: Alternative criteria for subsequent IPv6 allocations
> ___________________________________________________________________
>
>
> Author: Skeeve Stevens
> <skeeve at eintellego.net>
>
> Version: 1
>
> Date: 3 February 2010
>
>
> 1. Introduction
> ----------------
>
> This is a proposal to enable current APNIC account holders with existing
> IPv6 allocations to receive subsequent IPv6 allocations from APNIC for
> use in networks that are not connected to the initial IPv6 allocation.
>
>
> 2. Summary of current problem
> ------------------------------
>
> An APNIC account holder with an existing /32 IPv6 allocation (or larger)
> is unable to deaggregate that allocation into routes smaller than a /32
> due to the community practice of 'filter blocking' or 'bogon lists'
> associated with RIR blocks which are known to have a minimum allocation
> size of /32 [1].
>
> An LIR may want to build a network in a separate location and provide
> IPv6 connectivity; however, because the LIR risks routability problems
> if they deaggregate, they cannot use a subset of their initial
> allocation in the new location.
>
> For example:
>
> An ISP has a /32 allocation which they announce via an upstream
> in New Zealand. The ISP wants to build a new network in Singapore.
> The ISP's new network in Singapore is not connected to the existing
> New Zealand network and the ISP is using a local transit provider
> to obtain dual stacked connectivity.
>
> If the network was using IPv4 addresses, the ISP would usually
> be able to deaggregate their allocation and announce one part of
> the deaggregated range to the local transit provider.
>
> In IPv6, however, this is not possible due to 'community filtering'
> on ranges smaller than a /32.
>
> Such a filter may look like the following:
>
> ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32
>
> This above statement in the IPv6 BGP filter recommendations would
> cause any announcements by an ISP which had an allocation,
> such as 2400:0000::/32, to announce smaller routes from that block,
> such as multiple /35s for example, to be filtered. In a default
> free situation, connectivity to the ISP would be problematic.
>
> Instead, the ISP needs to obtain a new /32 allocation to be able to
> have IPv6 connectivity in the new location with an independent
> (from their primary network) transit provider.
>
>
> 3. Situation in other RIRs
> ---------------------------
>
> AfriNIC, ARIN, LACNIC and RIPE currently have no similar policies or
> proposals. However, ARIN mailing lists are presently discussing this
> situation and there seems to be significant support.
>
>
> 4. Details of the proposal
> ---------------------------
>
> 4.1 It is proposed that alternative criteria be added to the subsequent
> IPv6 allocation policy [2] to allow current APNIC account holders
> with networks in multiple locations but without a connecting
> infrastructure to obtain IPv6 resources for each location.
>
> 4.2 To qualify for subsequent IPv6 allocations under the proposed
> alternative criteria, account holders must:
>
> - Be a current APNIC account holder with an existing IPv6
> allocation
> - Be announcing its existing IPv6 allocation
> - Demonstrate that the LIR has additional networks that are not
> connected to the network announcing its existing IPv6 allocation
>
>
> 5. Advantages and disadvantages of the proposal
> ------------------------------------------------
>
> 5.1 Advantages
>
> - This proposal enables current APNIC account holders to avoid
> problematic network design issues and policy issues related to
> deaggregation.
>
> - Current APNIC account holders will be able to acquire resources
> and announce them separately to transit providers in disparate
> locations.
>
>
> 5.2 Disadvantages
>
> - This proposal could cause faster consumption of IPv6 address
> space. However, given the size of the total IPv6 pool, the author
> of this proposal does not see this as a significant issue.
>
>
> 6. Effect on APNIC members
> ---------------------------
>
> APNIC members would be able to build networks in separate locations and
> obtain local IPv6 connectivity and announce their own resources.
>
>
> 7. Effect on NIRs
> ------------------
>
> The proposal allows for NIRs to have the choice as to when to adopt this
> policy for their members.
>
>
> 8. References
> ---------------
>
> [1] For example, see "IPv6 BGP filter recommendations"
> http://www.space.net/~gert/RIPE/ipv6-filters.html
>
> [2] See section 5.2, "Subsequent Allocation Section" in "IPv6 Address
> Allocation and Assignment Policy"
> http://www.apnic.net/policy/ipv6-address-policy#5.2
> _______________________________________________
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
More information about the ARIN-PPML
mailing list