[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BCP for multisite multihoming

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.