shim6 @ NANOG

Iljitsch van Beijnum iljitsch at muada.com
Sun Mar 5 22:12:56 UTC 2006


On 5-mrt-2006, at 17:37, Christopher L. Morrow wrote:

>> The solution is routing based on geography: give every city of ~ 250k
>> people a /32, and give people who multihome in or near that city a /
>> 48 out of that /32.

> can the v6 table/space work with 6B /48's?

It can if you distribute those 6G prefixes over 6k - 64k routers, so  
each only has to carry 100k - 1M of those prefixes.

Our approximate design goal was 1 multihomers per 10 people in the  
year 2050. That would be around one billion mulithomers. Today we  
don't see much more than 1 in 25000 in parts of the world where  
multihoming is popular, and in most places it isn't.

> Additionally, how many /32's are
> there? Does scaling that to each municipality make sense? the  
> arbitrary (I
> suspect) 250k person limit will quickly devolve into 'any  
> municipality'
> with much less restriction on it.

The idea was having 64k /32s holding 64k /48s each. That means you'll  
end up with a /32 for each area with around 250k people. Having  
aggregation below that level doesn't look worthwhile and the number  
of municipal /32s would become uncomfortably large.

Of course people living in small towns aren't left in the cold, it's  
just that they have to share a /32 with other small towns, the  
surrounding rural area or fall under a big city close by.

>> 48s that are filtered here are still known. Since every AS still has
>> all the /48s somewhere within the AS, this works without strange
>> requirements such as free transit or interconnection in every city.

> I think I'm missing how this would work... if I don't have a route  
> to you
> you don't exist.

That's the beauty of aggregation. As an example, your AS could have  
US routes split into two sets: east of the Mississippi and west of  
the Mississippi. If you then want to send a packet from Boston to a  
multihomer in San Diego, the routers in Boston don't carry the /48  
for that San Diego multihomer. But there is an aggregate for San  
Diego, so the packet is sent on its way with help from the aggregate.  
When the packet hits the first router west of the Mississippi, it is  
forwarded as per the actual /48.

> inside a single ASN aggregation may be workable. On the entire network
> it's going to be much more complex :(

As long as each AS carries its customer routers everywhere and  
announces them to other ASes everywhere, there is no need to  
coordinate, because the outward behavior of each AS is as before. The  
only difference is that internally, things happen slightly differently.

>> Obviously strange ways of multihoming (towards ISPs on different
>> continents, for instance) or strange ways of interconnecting (such as

> ah, like pipex or vnsl or ... name your extra-us provider of  
> choice. From
> the 'non-NAnog' perspective, what about US carriers in ASPAC that
> multihome to several pacific island nations at once?

Not sure what you mean, but suppose there is an island in the pacific  
where several US carriers land, but they don't interconnect there.  
Also suppose that carrier 1 links this island to LA and carrier 2 to  
Palo Alto. A packet from a customer of carrier 1 to a customer of  
carrier 2 will flow to LA because the /32 for the island points to LA  
(not to the island itself because there is no interconnection there).  
Carrier 2 doesn't have the full set of more specifics for the island  
in LA (they have those in Palo Alto) but they DO have all their  
customer routes in LA, so carrier 1 hears the /48 for carrier 2's  
customer in LA and hands the packet off to carrier 2, which  
transports it to Palo Alto and on to the island. Return packets will  
flow from carrier 2 to carrier 1 in Palo Alto.

>> two European networks interconnecting in Chicago) aren't very
>> compatible with geographic aggregation, but who cares about 10%
>> exceptions as long as you can aggregate the other 90%. Enterprises

> is it 10%? did you measure this?

No. The only thing that we can possibly measure is what's in place  
today, and that's not representative for a situation where we have  
more than a million multihomers. However, it is to be expected that  
when we reach the point where there are that many multihomers, there  
will be some reason to the way multihomers connect to their ISPs. I  
would expect that the vast majority connects to local or regional  
ISPs. Even if they don't, it's not going to be that 5% of Paris  
multihomers connects to Montana, another 5% to Cape Town, 5% to Aruba  
and so on. If they do at the point that geographical aggregation  
takes off, they'll find that their traffic takes detours, i.e. a  
packet from Montana to Paris will first flow to Paris as per the  
aggregate, then go to the multihomer's ISP, then to Montana where the  
multihomer connects and finally back to Paris. So they'll have an  
incentive to multihome to ISPs closer to home but doing that wouldn't  
be too painful because they don't have to renumber if they used a  
Paris prefix from the start.



More information about the NANOG mailing list