Re: [sig-policy] prop-082: Removing aggregation criteria for IPv6 initia
Thank you so much for your comments.
From: Terry Manderson <terry at terrym dot net>
Subject: Re: [sig-policy] prop-082: Removing aggregation criteria for IPv6 initial allocations
Date: Thu, 4 Feb 2010 16:21:03 +1000
| > 1. It is inconsistent with the criteria for IPv6 allocations under
| > two other APNIC policies, which do not require aggregation. These
| > policies are:
| > - Subsequent IPv6 allocations
| can you highlight the exact section in the IPv6 policies where subsequent allocation do not require aggregation?
Current IPv6 policy:
describes the initial allocation criteria at section 5.1.1, and the
subsequent allocation criteria is defined at 5.2.1. The subsequent
allocation criteria is now an utilization requirement only.
| > - The new kickstart IPv6 allocation criteria to be
| > implemented 10 February 2010 
| I don't recall that aggregation was actually discussed either at the mic or on-list wrt prop-73.
| Prop-73 called for simplification of application criteria. I don't believe the intent (at the time) was to remove the aggregation requirement. However that said see my response to prop-83.
I agree prop-73 did not intent that, but the implementation will have no
concern about the aggregation.
| > 2. Registry policy should not concern itself strongly with routing
| > issues.
| I'm mostly in agreement here. Registries are not the routing police. In which case cast your eyes over section 5.1 of the IPv4 policy.
| > 4. Details
| > -----------
| > This is a proposal to:
| > 4.1 Remove the requirement under the initial IPv6 allocation criteria to
| > aggregate an initial IPv6 allocation as a single prefix.
| "announce an initial allocation as a single (aggregate) prefix" perhaps?
Yes, thank you. This should be same as policy description.
| > 4.2 Include a stronger recommendation about the importance of
| > aggregation to the IPv6 policy document.
| > The APNIC IPv6 policy document currently does include information
| > about the importance of aggregation. However, it is the opinion
| > of this proposal's authors that the recommendation should be more
| > strongly expressed.
| therein I see organisations taking a black and white approach to 'strong recommendations'.
| I dare say it may not affect the position on people's filtering practices.I think just leave it out.
I think this is one discussion point.
Aggregation in IPv6 will be more important than IPv4 since IPv6
address has longer bit length, will have more routes than IPv4 (I
hope so:-)), and some backbone routers will have to maintain both IPv4
and IPv6 routes. So I want to emphasize importance of aggregation to
suppress de-aggrigation without any technical requirement in this
| > 5. Pros/Cons
| > -------------
| > 5.1 Advantages
| > - This policy lowers the barriers for obtaining IPv6 address.
| Does it? I could perhaps live with the case that this policy allows IPv6 addresses be deployed in scenarios that may have a better fit to an organisations current practice.
I'm sorry this may be over-description, but my intention here is that
this policy will reduce number of requirements.
| > - Other RIR communities are discussing removing aggregation
| > requirements from their policies, so it would be appropriate for
| > APNIC policy to maintain similar criteria to other regions.
| I generally agree with removal of aggregation requirements, but not because the other RIRs are.
| I think that removing aggregation requirements also aids in conservation in multi-site/multiple AS topologies. (He says glibly when thinking about the size of IPv6 ;)
Yes, I also think that is one advantage, but I'm not sure it will work
in the initial allocation size, almost all of them are /32 in the
global internet context, in which many routers may filter longer
prefix thant /32.
| > 5.2 Disadvantages
| > - By removing the aggregation requirement in the policy,
| > deaggregated routes may begin to be announced more frequently.
| > 7. Effect on NIRs
| > ------------------
| > None.
Should I add something like 'NIRs should implement same policy ...' or
do you have other concern about NIRs?