BCP for multisite multihoming

Thomas Narten narten at us.ibm.com
Tue May 22 17:14:50 CEST 2007


> 2) Obtain a single /32, and announce /34s (or /36, or /40 or  
> whatever, if they want to leave room for expansion) from each POP.

I think this is exactly what should be done.

> Probably not possible - A lot of people are filtering on the RIR's  
> allocation size. If this company is assigned a /32, there's an  
> expectation (correct or not) that it's the only thing going to be  
> announced.

So, if people filter on /32s and that forces people to go get
additional (unjustified) /32s -- just to be able to have separate
announcements -- exactly what problem has been solved, and how have we
made the Internet scale better?

>From my perspective, one of the myths that has been propagated out of
the IPv6 address architecture is that "all deaggration is bad" and
"you MUST filter everything longer than a /32".

The original IPv6 address allocation policies were written to favor
aggregation over utilization, but an important reason for that was to
ensure that if - or when - routing tables got bloated and filtering
was necessary to keep the internet intact, one could filter the longer
prefixes without breaking overall connectivity. Yes, filtering out
longer prefixes would impact multihoming and traffic engineering, but
those are optimizations designed to create better paths for certain
traffic flows. If you filter those, you can still have overall
connectivity (via the aggregate), which is far better than NO
connectivity! Thus, the RIR policies need to ensure (to the degree
possible) that larger aggregates will always be available to cover
reachability for all should it become necessary to fliter longer
prefixes in order to keep the routing system intact.

ISPs have always been able to route/accept whatever prefixes they
want. There is no (enforceable) policy that says they MUST filter
everything longer than a /32. My sense is they are doing that today
partly as a combination of:

 - older IPv6 documents (and culture) that suggested deaggration was
   very bad and had to be avoided at all costs.

 - current operators afraid to loosen filters because they fear that
   once loosened, they cannot put the Genie back in the bottle.

Thomas


More information about the ipv6-ops mailing list