BCP for multisite multihoming

[Iljitsch van Beijnum]

On 23-mei-2007, at 10:08, Gert Doering wrote:

>> Is one allocation/assignment per site really scalable?

> Regarding address space usage, yes.  (Because a /32 more or less does
> not really make any difference anywhere.  Even burning a million /32s
> isn't going to bring us anywhere near *address space* shortage issues.
> [OK, come flame me.  *I* can do maths.  Can you?]).

Ok, I can't resist that one...

Randy doesn't seem to think I can. And with the sorry state of  
education these days, a computer science degree doesn't guarantee  
anything, either... So proceed at your own risk.

IPv6 is 128 bits long. We used up 64 bits for stateless autoconfig.  
We used another 16 bits up for subnetting. If we then use up another  
16 bits to arrive at a common minimum allocation size, we're left  
with 32 bits, the same number that is proving problematic with IPv4.  
The difference is that with IPv4, many sites need much more than a  
single /32 while with IPv6, it's a /32 per site according to the  
logic presented in this discussion.

Obviously, the IPv6 address space can stand to lose a few /32s here  
and there, as there are 536 million of them available. But a year  
ago, some people made the case that with many levels of hierarchy,  
we'd get pretty close to the limits of what IPv6 has to offer under  
current policies. I.e., we have 29 bits, applying a 80% HD ratio this  
means we'll effectively be able to use only 9.6 million /32s. The HD  
ratio doesn't apply wholesale here, as there will be significant flat  
routing, but considering that there are 1.4 million businesses in the  
Netherlands alone, I'm thinking we can screw this up if we try hard  
enough and take enough time to do it.

(75000 of those business have at least 10 people working there. NL is  
about 0.25% of the world population so the world figure for 10+  
business could be in the order of 30 million.)

So giving away /32s when something smaller would do isn't the  
greatest idea ever.

And you can't ignore the routing issue. If you could, we'd do flat  
routing on individual IP addresses and IPv4 would last until the the  
3.7 billionth user connects to the network. Let me quote a few lines  
from the IPv4 routing table to show you why relaxed filters are not a  
good idea:

    Network          Next Hop            Metric LocPrf Weight Path
*> 12.201.48.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.50.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.52.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.56.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.58.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.60.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.64.0/21   12.0.1.63                              0 7018 6478 i
*> 12.201.72.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.74.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.76.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.78.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.80.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.82.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.84.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.88.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.90.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.92.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.96.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.100.0/23  12.0.1.63                              0 7018 6478 i
*> 12.201.102.0/23  12.0.1.63                              0 7018 6478 i
*> 12.201.104.0/23  12.0.1.63                              0 7018 6478 i
*> 12.201.106.0/23  12.0.1.63                              0 7018 6478 i

(It goes on like this for another 1100 lines, about the size of the  
entire IPv6 routing table.)

Since we obviously can't depend on the address space holders to do  
the right thing, it's necessary to filter. A good filter catches  
everything that's in the routing table by mistake, and allows  
everything that's in there by design. Unfortunately, today's policies  
and practice don't make this very easy, for two reasons:

1. PA assignments are (often) /48s, same thing for PI blocks, so it's  
not possible to see the difference between leaked PA deaggregates and PI

2. /32 and larger allocations are made from the same bunches of  
address space. This means that someone with a /21 can inject 2048 / 
32s. However, due to the HD ratio, people can get a /21 if they need  
around 450 /32s. So giving out larger blocks to aid aggregation can  
actually make deaggregation worse.

Fixes:

1. Make PI blocks a different size than PA end-user assignments. /44  
makes sense, this is a good deal bigger than /48 so even fewer people  
are going to need more and it's on a nibble boundary for easy DNS  
delegation and no need to reserve for growth. Filtering could happen  
on /47 which rejects leaked /48s but allows 3 bits for traffic  
engineering

2. Make all allocations from a given block of address space the same  
size, so there would be ranges for /32s allocations, for /28  
allocations, /44 assignments, etc.

> Regarding routing table: it doesn't make a difference what you do
> ("own /32, deaggregated single /32, PI networks") - with current
> routing technology, you end up with one routing table slot per  
> location.
> Which is not perfect, but as long as it stays at *one* prefix per
> location,

Oh, now we're doing a PI block per location? I'm guessing a PI block  
per plane is next, then one per car, one per mobile phone... After  
all, I don't want to have to renumber when I take my laptop from home  
to work.