host or border router

[Iljitsch van Beijnum <iljitsch@muada.com>]

[Peter, I was going to reply to your message but decided against it in
order to more easily maintain my own train of thought.]

If we are going to create a multihoming solution that uses identifiers
that are usable as IPv6 adresess for end-to-end identification and
regular unicast IPv6 adresses that replace the identifiers in transit, I
see three ways to handle the address replacement:

1. In the end-host
2. In a site border router (SBR)
3. In some kind of middlebox

I believe doing it in the actual SBR is a non-starter. Sure, you can
build a box that can replace addresses and maintain the state that goes
with this. And sure, you can build a box that can forward IP real fast.
I'm just not sure you can do both at the same time, and even if it's
possible, it won't be cost effective. As far as I know, there are no
software-based routers that can handle IP(v6) forwarding at line rate
for gigabit interfaces. Now obviously this changes all the time (I've
done some tests recently and it looks like off-the-shelf PC hardware has
about reached this performance level not too long ago) but bandwidth
requirements also go up so the fundamental problem should remain the
same.

Anyway, not all that many people have more than 1000 Mbps worth of
bandwidth to the net, but those that do need hardware support. But
AFAIK, most of the really fast boxes are deployed either inside
corporate networks or in ISP networks, where address rewriting for
multihoming support isn't an issue. So this means router vendors have to
bake much more complex silicon for a very small group of customers. I
just don't see this happening, with the result that very large edge
networks (think Google, Yahoo, Amazon) won't be able to talk
multihomedly to their correspondents. That would be very bad.

There is little value in requiring that this happens in the real SBR
anyway. This type of processing can be done on middleboxes (ie existing
firewalls or new special purpose boxes) which either select the right
SBR or work together with the SBR(s) so the source/destination addresses
are compatible with the routing decisions made by the SBRs.

Doing this in middleboxes has the advantage that neither the routers nor
the hosts have to change.

Having said this, I think it is possible to do it on the hosts. This has
the advantage that the state the host has to maintain anyway can be used
to do quick failover to an alternate address. This would be
hard/expensive to implement in an external box.

Whether it's the hosts or middleboxes that do this, we need to support
some important policy/traffic engineering requirements. The ones that I
can think of are:

1. Always prefer link A, use link B only as a backup
2. Use link A for certain destinations/applications, link B for everything else
3. Send/receive x% of traffic over link A, 100-x% over link B
4. Select shortest path path for each destination
5. Combinations of the above

Currently, the routing system only supports 1. relatively well. The
others are doable to a certain degree, but the routing system doesn't
fully support them. To support these, we need:

1 outbound: statically configured policy, reachability information
1 inbound:  statically configured policy must be conveyed to
            correspondent, reachability information
2 outbound: same as 1 outbound
2 inbound:  same as 1 inbound
3 outbound: link usage information
3 inbound:  link usage information must be conveyed to correspondent
4 outbound: topology information or path attribute measurements +
            ability to measure both paths simultaneously
4 inbound:  will be determined by correspondent
5 outbound: 1, 3 and 4 outbound combined
5 inbound:  1 and 3 inbound combined

To make a long story short, we need:

- statically configured policies
- link usage information
- topology information and path measurements, preferably for both
  paths at the same time
- a way to negotiate session parameters with the correspondent
- a way to map identifiers to locators in order to bootstrap the
  negotiation process

Obviously querying the SBRs for link statistics isn't something we want
all hosts to do. So we need a small number of boxes that manage at least
part of the policy/traffic engineering. However, this doesn't mean these
boxes should also handle the traffic: it would be perfectly reasonable
to aggregate the P/TE info here and then distribute this to hosts. A
good way to do this would be "DNSng" where the host looks up a hostname
for a remote host and receives not only one or several IP addresses, but
also extra information such as the preference for each of those
addresses and the source address that goes with them, and DSCP or flow
label suggestions. Note that such a DNSng box wouldn't be able to
provide conclusive mapping information as it doesn't have the very
granular reachability information hosts or boxes that sit in the middle
of the traffic stream have.

Alternatively, all of this can be handled in middleboxes that also do
the actual mapping, so they are aware of which addresses work and which
don't. Then we probably want a protocol to distribute information
between those, but there is no rush there.

Iljitsch