Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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@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
_______________________________________________
On 03/02/2010, at 9:45 PM, Terence Zhang YH(CNNIC) wrote:
- Do you support or oppose this proposal?
Not sure.. yet.
- Does this proposal solve a problem you are experiencing? If so, tell the community about your situation.
In past it did, and the sub-optimal solution was announce de-aggregates as well as the aggregate and hope that nearer entities listed to the more specifics and forwarded appropriately.
- Do you see any disadvantages in this proposal?
here lies the quandary, do we: a) allow members with topologically separate networks to get additional ipv6 prefixes for each site, probably providing far in excess of what they need?
or
b) remove any language about aggregation (for which many network filters' lives cling to) which, might I add, may not change the actual route-ability/reach of the de-aggregates?
or both?
knowing in both cases the net addition to the IPv6 routing system will be approximately the same (well "b" may be +1 for the aggregate) where all else (such as traffic engineering) remain the same.
so which is seen as more attractive? conservation?, or aggregation?
I further find in interesting that such a topic, separate sites that require separate prefixes and separate announcements from presumably (but not always) separate ASNs, is not covered in either the v4 or v6 policies from what I could see.
How is this handled now by the secretariat? Networking plans? case by case? ie "I have 5 sites across the asia pacific that are not, and never will be, connected."
perhaps this points to an omission in prop-73 regarding initial allocations.
thinking aloud: Consider the ISP with POPs in 3 locations that has a different upstream for each site. They have 2 x /24s and a single /21 IPv4 allocations advertised with different ASNs. Current policy would probably provide them with a 'justification free' initial allocation of a /32. However if they de-aggregate they might find that the more specifics have no reach. And further the HD ratio would most likely prevent them from getting an additional v6 allocation/assignment.
- Is there anything in the proposal that is not clear?
nope.
- What changes could be made to this proposal to make it more effective?
not sure yet.
Terry
Hey Terry,
When you refer to needs... 'needs' can be more than the sheer number of single addresses. Even APNIC in their utilisation measures based on a percentage relating to /56's. 'Needs' could be network design and other considerations.
As of the 10th of February, the requirement to aggregate your first ipv6 block has been removed. So anyone with a v6/32 has de-aggregate if they like. The issue here is community standards may make you un-routable to anyone utilising the common bogon filters.
I've already seen this in the /35 we announce out of our /32 where the visibility in the US has been some 75% (not sure what measurement RIPE use to measure this) - but fluctuates.
...Skeeve
-- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve@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?
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Terry Manderson Sent: Thursday, 4 February 2010 4:49 PM To: Policy SIG Subject: Re: [sig-policy] prop-083: Alternative criteria for subsequentIPv6 allocations
On 03/02/2010, at 9:45 PM, Terence Zhang YH(CNNIC) wrote:
- Do you support or oppose this proposal?Not sure.. yet.
- Does this proposal solve a problem you are experiencing? Ifso,
tell the community about your situation.In past it did, and the sub-optimal solution was announce de-aggregates as well as the aggregate and hope that nearer entities listed to the more specifics and forwarded appropriately.
- Do you see any disadvantages in this proposal?here lies the quandary, do we: a) allow members with topologically separate networks to get additional ipv6 prefixes for each site, probably providing far in excess of what they need?
or
b) remove any language about aggregation (for which many network filters' lives cling to) which, might I add, may not change the actual route-ability/reach of the de-aggregates?
or both?
knowing in both cases the net addition to the IPv6 routing system will be approximately the same (well "b" may be +1 for the aggregate) where all else (such as traffic engineering) remain the same.
so which is seen as more attractive? conservation?, or aggregation?
I further find in interesting that such a topic, separate sites that require separate prefixes and separate announcements from presumably (but not always) separate ASNs, is not covered in either the v4 or v6 policies from what I could see.
How is this handled now by the secretariat? Networking plans? case by case? ie "I have 5 sites across the asia pacific that are not, and never will be, connected."
perhaps this points to an omission in prop-73 regarding initial allocations.
thinking aloud: Consider the ISP with POPs in 3 locations that has a different upstream for each site. They have 2 x /24s and a single /21 IPv4 allocations advertised with different ASNs. Current policy would probably provide them with a 'justification free' initial allocation of a /32. However if they de-aggregate they might find that the more specifics have no reach. And further the HD ratio would most likely prevent them from getting an additional v6 allocation/assignment.
- Is there anything in the proposal that is not clear?nope.
- What changes could be made to this proposal to make it more effective?not sure yet.
Terry
sig-policy: APNIC SIG on resource management policysig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On 04/02/2010, at 9:32 PM, Skeeve Stevens wrote:
Hey Terry,
When you refer to needs... 'needs' can be more than the sheer number of single addresses. Even APNIC in their utilisation measures based on a percentage relating to /56's. 'Needs' could be network design and other considerations.
I think this is a fine distinction that needs to be made in the APNIC policies. To date, all text that I have read (and promptly forgotten) angles the "need" definition mostly toward usage as a volume or consumption metric.
As of the 10th of February, the requirement to aggregate your first ipv6 block has been removed. So anyone with a v6/32 has de-aggregate if they like. The issue here is community standards may make you un-routable to anyone utilising the common bogon filters.
Indeed - the community does what it does.. Even with complete removal of aggregation (which is really growing on me) the visibility of more specifics (when you actually want it for a disparate network) comes with less than ideal properties. Certainly nothing is guaranteed in routing.
The only thing I would like to see is some wording that suggests that such allocations should be advertised from separate autonomous systems (taking the academic definition of an autonomous system). From that I support the proposal.
I've already seen this in the /35 we announce out of our /32 where the visibility in the US has been some 75% (not sure what measurement RIPE use to measure this) - but fluctuates.
Yep..
Terry
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
We can understand the needs for a seperate globally routable prefix, but feel we should consider this proposal in balance with the consumption of the /32s.
I think some data would be helpful to give us an idea and make up our mind - Skeeve/anyone has any data about this?
For example, in case of Japan, JPNIC makes about 3-4% of multiple ASNs to the same organization out of 705 total assignments.
If seperate network = seperate global ASN, we can probably assume the % will be similar for additional /32s and have a rough idea on if this could be acceptable. The figure could grow if seperate networks don't bind to global ASN.
izumi/JPNIC
Activity Summary
- 5035 days inactive
- 5035 days old
- sig-policy@lists.apnic.net
- 4 participants
- 4 comments