Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
william at elan.net
Thu Mar 2 12:44:27 UTC 2006
On Thu, 2 Mar 2006, Owen DeLong wrote:
>>> I think that is overly pessimistic. I would say that SHIM6 _MAY_
> Yes, I am well aware of 32bit ASNs. However, some things to consider:
> 1. Just because ASNs are 32 bits doesn't mean we'll instantly
> issue all 4 billion of them. The reality is that we probably
> only need about 18 bits to express all the ASNs well need for
Probably 20 bits or 24 bits rather then 18. It maybe worth it to reserve
top 8 bits for some experimental future use.
> the life of IPv6, but, 32 is the next convenient size and there's
> really no benefit to going with less than 32.
> 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.
I thought of something of this sort some time ago but never got around
to full proposal on it (maybe somebody else did?). I'm trying to go
through my notes now - maybe it could prove useful if research or
engineering people do indeed want to work on something like that.
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. As an example
lets take some ip block like say A100:1000::/32 that is allocated to an
ISP 'A' by RIR. Now lets say that this ISP 'A' (AS1) has a customer who
received A100:1000:0010::/48 and later same customer got connection from
ISP 'B' (AS2) as well and wants to multihome. For normal BGP that would
mean that full route of A100:1000:0010::/48 would appear in BGP and
increase its size quite a bit.
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)
Where "0010/16" indicates subroute as seen within A100:1000::/32 ip block
(i.e. netmask here is added to netmask of A100:1000 route to get full
netmask on the internet) and "(2)" is an additional ASN that such subroute
can also be found through. Now if properly designed, such subroute
attribute can be compacted to be around 64 bits extra each (slightly
more if multihoming is through more then one ASN and subblock is smaller
size then /16) and 64bits data for each multi-homed customer in BGP appear
to me something that we can deal with.
Unfortunately with this design, the issue then becomes how some AS10
(the end-site) knows how to get to AS2 (one way maybe to do ASN routes
as part of BGP in addition to ipv4 and ipv6 routes). As well as what to
do if connection from customer to AS1 or from AS1 to internet drops
since its AS1 that announces such subroutes as part of its aggregate
and purpose of multi-homing it to let it work without it (this can be
done with AS2 also announcing A100:1000::/32 but with special attribute
indicating its valid only for subroutes and such route should not be
propagated if same ASN also sees primary AS1 direct route).
Another possibility of similar design (kind-of already mentioned above)
is to allow AS2 to announce A100:1000::/32 on the internet as it would
its own route but indicate that it is valid only for specific subroutes
and not as an aggregate (in fact in this design AS1 would not even have
subroutes in its main route announcement). While this means entire full
route on the net, the hope is that if AS1 and AS2 have number of common
multi-homed customers, the net would be spared from separate BGP routes
for each one and the end-site AS10 would only see something like:
BGP routing table for A1000:1000::/32
9 8 7 6 1
5 4 3 2
Origin IGP, Subroutes-Only
Subroutes: 0010/16 0101/16
So from above if router needs to send data to either A1000:1000:0010::/48
or A100:1000:0101::/48 it would choose 2nd path through peer AS5 as
having smaller as-path.
All these approaches (especially second one) however certain problems when
you have to consider route security & authorization (i.e. SIDR/SBGP space)
as its necessary to convey that AS2 is to be allowed to announce A100:1000:
block for specific subroutes. But I think these issues can be worked out
like having AS2 sendscertificate request for subblock to AS1 which it then
signs and gives new certificate authorizing announcement with specific
subblock attribute to AS2.
More general issues with these approaches is obviously that there is no
possibility of PI space as customers that need multi-homing would have to
get space from one of its ISPs (well, actually it is still possible to do
PI - it is just that multiple ISPs would be expected to announce large
aggregate of the PI block with bunch of subroutes on equal basis).
Anyway, if you have comments or if something like this has already been
discussed and tested, I'd like to hear. Otherwise, hopefully knowing about
this design may prove useful if shim6 does not work out.
william at elan.net
More information about the NANOG