On 1-dec-04, at 1:17, Stephen Sprunk wrote:
So _if_ IPv6 PI space is going to be a reality, we should do what we
can to limit the damage. The only way to do this is to make it
possible to filter out the PI prefixes at least in certain parts of
the network without getting in the way of reachability.
That's not the only solution -- just the most obvious one. Clearly,
if IPv6 PI space spirals out of control like many operators think will
happen, we need to find a way to make BGP (and possibly forwarding)
performance not dependent on the number of prefixes in the table.
There's many ways to skin that cat, and maybe it's time we start
looking at that in parallel to the work on multi6 and HIP.
One obvious way to improve BGP would be to work per-AS rather than
per-prefix. We could even go so far as to remove the entire
prefix-to-AS mapping from BGP and do this out of band, as this mapping
is fairly static, and it's much easier to secure it this way.
Unfortunately, this mostly helps with ASes that source many prefixes,
but it doesn't help much when the number of prefixes per AS is small
(which is what we expect in IPv6). Another interesting improvement
would be "bitmap routing" where a bunch of PI blocks are grouped
together into a large aggregate and an accompanying bitmap that
indicates whether a specific prefix within that aggregate is reachable
or not. This would save a lot of memory and allow for vector based BGP
processing. :-)
But all of this is only delaying the inevitable (not that that can't be
useful sometimes): at some point, we need to move away from the premise
that all default-free routers must know about all reachable prefixes.
With this ball and chain removed we can start looking at new
interdomain routing paradigms, such as an idr link state protocol that
can function in a never fully converged state. (Which would make for
some nice PhD work...)
Worst case is we'll end up eliminating IP addresses as locators and
build another layer beneath IP (and thus transparent to TCP) that
actually handles routing, at least in the DFZ. In some sense we
already have a foundation for that with MPLS, but we'd need to
hack/replace BGP to make the new layer scale across ASes. Or perhaps
we'll find a way to route based on ASNs in the DFZ, and the mapping
from destination IP to ASN will be made only at the edge of the DFZ.
MPLS can save you a bunch of router hops, but it doesn't really change
anything because you still need a router at both ends of the MPLS
cloud. Currently, the most efficient way to move packets to/from random
systems across organizations et al is IPv6. Moving to a new
internetworking layer is going to take A LOT of time. Even tunneling is
non-trivial because of the destination to tunnel endpoint mapping
that's required. In essence, doing something like this would be
starting multi6 from scratch. The whole point of my message (and one of
the points of Margaret's message that started the thread) was that
operators don't want to wait for multi6 and/or want provider
independence anyway.
So we're back at: how do we limit the fallout from PI in IPv6, and
without significant protocol work at that? I understand that Tony Hain
has asked / will ask for a BoF in this area at the next IETF meeting.
Hopefully this will lead to something.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf