Host-based may be the way to go, but network controls are neccessary

["Aldrin Isaac" <aisaac@bloomberg.com>]

More opinions from the enterprise camp:

I've come to the conclusion that a host-based host-only multihoming
solution may be the only solution required for true end-to-end
multihoming since a *good solution* should meet all requirements, bar
simplicity, and should include mobility as well.

However there are currently no routing knobs for a multi-homed site to
control via which site-exit a packet should be forwarded based on the
packet's source prefix (there are a hundred reasons why NAT is used
today, and this is one of them).  This will result in unnecessary
"misses" (which means delay, dead packets, IDS alarms, etc) during the
connection setup of any host-based solution within a multi-homed site
because of the current source address selection process.

Network controls are therefore required to allow for the forwarding of
packets over paths that will obviously *not* reject them, and provide
an early warning to a host when it selects a source address that will
result in failed transmission.

This form of network control is certainly missing even in today’s IPv4
routing toolkit, but the difference is that with IPv4 it is acceptable
to “fix” this using NAT, DFZ aggregation hole punching and other
methods.  I think if this routing issue can be solved multi6 can focus
on a true host-based end-to-end multihoming solution.

-- aldrin