[jump-admins] IPv6 multihoming
James A. T. Rice
james_r-ipv6ops at jump.org.uk
Tue Feb 8 10:34:31 CET 2011
On Tue, 8 Feb 2011, Gert Doering wrote:
>> No they don't, give them extra separate space.
> That's just playing pingpong with politics. "So the routing folks are
> not able to come up with a recommendation, so we put the pressure on
> the address policy group to come up with criteria who is allowed to
> have a second slot in the routing table (and bonus addres space that
> comes with it!) and who is not".
> This is the approach that hasn't worked for the last 10 years, which is
> why the ball is in the operator's camp now.
The reason it's not worked for the last 10 years is because if someone
deaggregates their /16 into a bunch /24, it simply works. If we make sure
it doesn't work, then they won't be able to do it.
Making ISPs go to the extra effort of getting another prefix from an RIR
does put more workload on the RIR, it also makes sure that people can't
overnight deaggregate for no reason at all, not being answerable to anyone
(whereas at least they will have to provide a valid reason to the RIR for
their extra prefixes).
In IPv4 people deaggregate because they can. There's noone to say make
sure you announce an aggregate prefix too, there's noone to say try using
more specifics with no-export. If withdrawing your aggregate and spewing a
bunch of /24s into the global tables works fine, people have no reason to
As for the arguement that it's up to operators to not accept these
prefixes, the commercial reality is that if everyone else is accepting the
deaggregations, you have to too, otherwise lose customers. Commercial
reality of today means that common sense long term technical
considerations can't be taken into account.
PA is Provider Aggregatable. If a provider can't aggregate the block, make
the policy be to give them another one. This ensures we can stop the
insanity of deaggregation happening from day one, and if the
abovementioned "Deaggregation works because everyone accepts the
deaggregated routes, so there's no reason not to do it" isn't available,
then we'll end up with a tidy table, decent convergence times, and a
hardware refresh cycle that will be good for the ISPs, not the vendors.
More information about the ipv6-ops