Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)

Iljitsch van Beijnum iljitsch at muada.com
Thu Mar 2 13:22:04 UTC 2006


On 2-mrt-2006, at 13:44, william(at)elan.net wrote:

>> 2.	In my current thinking on how to achieve ASN based IDR, we
>> 	would not need ASNs for every organization that multihomes,
>> 	only for each organization that provides transit.  This
>> 	would greatly reduce some of the current and future demand
>> 	for ASNs.

Yes, we wouldn't want to run out of AS numbers just now we're  
creating 4.29 billion new ones...

> My thinking was that its a big waste of memory (in the global bgp  
> table) to announce every IPv6 route in full in particular for cases  
> when its sub-allocation and aggregate is already being announced.

Yes, it would be cool if the routers or route servers could  
automatically detect this and clean up the routing table. Unfortunately:

     A --- B
   /         \
X             Y
   \         /
     C --- D

If X uses 172.16.1.0/24 but A also announces 172.16.0.0/12, then A or  
B could decide to suppress the /24. However, Y will see the /24  
through D and C but not through B and A, so Y will now send all of  
its traffic to X through C and D.

> But it maybe possible to do limited bgp multi-homing by having  
> such /48 and similar routes included as attributes of the main  
> route, i.e.
>  A100:1000::/32 route would appear with extended attributes like
>    Subroutes: 0010/16 (2)

Some years ago, I suggested doing this by adding a bitmap to the  
aggregate route: a single bit is enough to convey holes in the  
aggregate, with two or three bits you can also do some traffic  
engineering. This will get you from a /16 aggregate to individual / 
24s with 32 bytes (1 bit per more specific) or a /32 to /48s with 8  
kilobytes.

Such an approach does depend on relatively tight packing of end-users  
that share the same ISPs, though.

> All these approaches (especially second one) however certain  
> problems when
> you have to consider route security & authorization (i.e. SIDR/SBGP  
> space)

IDR security doesn't come cheap anyway: be prepared to double or  
quadruple your router's memory and install crypto hardware.



More information about the NANOG mailing list