[ppml] Practical alternatives to v6 deaggregation for ISP/NSPs
kevin at your.org
Wed Mar 12 02:22:58 EDT 2008
On Mar 12, 2008, at 12:14 AM, Scott Leibrand wrote:
> A couple thoughts:
> You could try announcing your deaggregates (/36 or whatever), in
> addition to announcing the /32, and *without* no-export set. This
> is what I envision we'll do when we deploy IPv6. Most people I've
> talked to agree that, as long as you're announcing the /32, that
> should be allowed, and it's up to everyone to decide whether or not
> to accept the more-specifics. If you're paying a transit provider
> to do so, they should accept them, and should accept the same more-
> specifics from their peers. As long as your ISPs (or their transit
> providers) peer with each other, and accept the more-specifics from
> each other, you should have full reachability, and you shouldn't
> have to transport the packets yourself (you're paying your ISPs to
> do that).
That doesn't work though... Imagine this scenario:
POP A = 2001:1234:1000/36.
POP B = 2001:1234:2000/36.
POP A <---> Transit 1 <--> Big NSP 1 <---> Big NSP 2 <--> Transit 2
<---> POP B
POP A announces to Transit 1 2001:1234:1000/36.
I convince Transit 1 to accept that, because I'm paying them to. They
in turn announce it to Big NSP 1.
Transit 1 may or may not have enough pull with the Big NSP 1 to make
them make exceptions to their filters. Even in the most optimistic
case, assume they do.
Big NSP 2 probably isn't going to accept deaggregates of all of Big
NSP 1's customers, so Big NSP 2 doesn't accept it.
POP B advertises that /32 and 2001:1234:2000/36 to Transit 2.
Transit 2's view of the world is:
2001:1234::/32 -> POP B.
2001:1234:2000/36 -> POP B.
The /36 for POP A got filtered out several hops before it reached
Transit 2, so Transit 2 has no choice but to send traffic for
2001:1234:1000/36 to POP B.
I can ensure that my direct upstreams accept all my deaggregates, I
can't ensure that they get propagated to all my other upstreams at
other POPs. There are any number of intermediaries between the transit
providers at each POP, and if ALL of them accept the deaggregates then
it means that nobody is doing any filtering at all. If you don't
believe my example with just two "Big NSPs", add 5 of them.. do you
really believe that many of them are going to accept deaggregates from
customers of customers of customers....? (And no, that's not entirely
unreasonable, even in v4 right now, our path from our Amsterdam POP to
our Tokyo POP is 7 ASNs long)
You are right, if all of our upstreams peer with each other then it
probably does work. But, for example, our small upstream provider in
Sydney probably doesn't peer with our upstream provider in Berlin.
There are a lot of networks between those two, and there's no way
every one is going to accept deaggregates from everyone else unless
they just aren't filtering at all. Personal experience and views from
the SIxXS GRH pages seem to indicate that people are filtering
already. I'm also not really that comfortable in basing my network on
unrelated party's peering. If one gets into a peering war with
another, I don't want my network to go down.
> Alternately, you could perhaps give back your /32, and instead get a
> PI /48 from ARIN (under the end user policy) for each site (or
> perhaps a contiguous /44 to get you a /48 per site). I'm not sure
> if that policy applies in your case, or if that would be a better
> idea overall in your situation than using a /32, but it seems more
> reasonable than trying to get additional /32's or "critical
> infrastructure" blocks.
Well... For one, we need to be able to assign /48's to our customers,
so I'm not sure an end-user allocation is going to work for us.
Secondly, I don't believe current policy allows for getting more than
one /48 without using up the first.
We could ask for a /44, but from the sounds of it, that will cause
people who are filtering on RIR allocations to filter at /44.
I went through the same lines of thinking myself when I started with
this... It's only when actually trying to do it that I'm running into
I really appreciate your reply though, it shows others are coming up
with the same potential solutions that I did.
More information about the ARIN-PPML