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

Re: v6 multihoming and route filters

On 5-jul-2006, at 3:12, Christian Huitema wrote:


What would be the purpose of filtering at /48?



That allows for 2^45 = 351 trillion prefixes in the routing table,
which I suspect won't work too well on current routers. And it only
takes a handful of /32s deaggregated into /48s to inflate the IPv6
global routing table to a size larger than the current IPv4 routing
table.
But then, filtering at /32 allows for 2^30 = 1 billion prefixes, which I 
suspect also won't work too well on current routers.
Yes, that's true. But a billion is still a lot closer to something reasonable than another nearly six orders of magnitude. And the crucial difference is that there is little chance of the the full ::/ 3 space being deaggregated into individual /32s, while leaking of significant numbers of "private" /48s into the global routing table is something I fully expect to happen based on experiences with IPv4. 


Setting narrow filtering constraints is also counter-productive, as it
encourage a rush on the short prefixes. An organization that could have 
done just fine with a /48 or maybe a /40 will request a /32 just in
case, so that organization can eventually multi-home.
This assumes that people will get anything they request. Currently, you can't really get a /40: ISPs get /32 or shorter, end-users rarely get something shorter than /48. 


In the end, the size of the routing table will equal the number of
entities that want multi-homing hard enough. Playing around with prefix 
sizes will not change that, and will probably generate undesirable
counter effects.
Besides, there are networks in which advertizing /48 or even /64 in BGP makes perfect sense. Take for example the "metropolitan aggregation" in 
which all users in an area get numbered from the same long prefix. The
local ISP will have to exchange the short prefixes with each other. The 
will use BGP. Do we want to have a rule cast in stone that prevents
them?



We should really think twice before asking the IETF to publish a
position on this subject. Silence may well be the right approach.
On the other hand, no filtering at all is asking for trouble, so it would make sense for us to come up with a good filtering strategy. One would be to make a filter based on actual allocations, which is still possible in IPv6 today because of the small size of the global table.
Another approach is to filter on prefix size depending on the size of the prefixes RIRs give out in a certain part of the address space. (Possibly allowing one or two extra bits for traffic engineering purposes.) I think this is the best way to do it currently, but the problem is that the RIRs are still coming up with new stuff here so if we write this up it's likely that the list of parts of the address space where /48s are given out will change soon after, so the resulting document won't be all that useful in practice. (I'm also VERY much annoyed by the fact that the RIRs say you can filter on /32 (see quote yesterday) but give out /48s at the same time, I've brought this up YEARS ago and no action so far. The fact that each RIR reinvents the wheel with little global coordination but we're dealing with a GLOBAL routing table and not several regional ones doesn't help.)
Third approach: use prefixes shorter than /48 for anything that should be in the routing table and then filter at /47. This avoids problems with accidental leaking of /48s from internal routing, but the ship has sailed on /48 for "micro allocations" so this approach would have to be combined with the previous one.
Finally, it would be possible to tag prefixes longer than /32 that are injected into global routing intentionally, especially in the case of shorter prefixes that are drawn from a larger address block for multihoming purposes, with a BGP community that indicates why this is done so that people can filter appropriately. For instance, as a network operator I may want to allow such prefixes from "close by" but not from other continents, so that there is a more or less dynamic tradeoff between routing table size and optimum traffic flow through the network, which is really what we want. (With PI you're forced to carry the route or the destination is unreachable, not a very nice choice.)