Differentiating multihoming in IPv6 requirements

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

Over the course of a private discussion we (Harold Grovesteen and
Iljitsch van Beijnum) have come to the conclusion the way both multi6
and ipv6mh handle the "requirements problem" is unsatisfactory. Multi6
is still set on delivering a requirements document, but it is generally
recognized that it is impossible for a single solution to meet all the
requirements in the current document. Ipv6mh on the other hand, rejects
any requirements in order to avoid getting stuck. This means multi6
fails to develop any solutions, while ipv6mh develops too many, and
quite possibly ones that fail to meet user expectations. (Anyone who
has ever owned a V2000 or Betamax VCR knows that too many solutions for
a single problem isn't good.)

We believe we can find middle ground here by not pursuing single
solutions that meet all requirements, but recognizing that there are
three classes of solutions that each require different requirements:
short, intermediate and long term solutions. This way, we can have both
a solution that can be deployed in the near future, and a solution that
provides near-unlimited scalability and a clean architecture, rather
than something that takes too long to develop and still doesn't provide
everything we want.

The most important requirement for short term solutions is that they
can indeed be deployed in the short term. That means either doing
something in routing using current protocols, or doing something in
hosts that works if only one side of the connection is a modified host.
Short term solutions don't have to scale to more than a few million
multihomers (although it wouldn't hurt if they could), as long as any
"pollution" (of the global routing table, for instance) can be cleaned
up at some point. There can be several short term solutions.

The requirements for long term solutions are very different. Here
scalability is key. This, and the end-to-end principe suggest that long
term solutions be implemented in individual hosts. Long term solutions
also need a clean architecture, preferably one where we know we can
support future developments at  the transport and lower layers without
another round of changes to applications. For long term solutions, it
isn't much of a problem that both ends of a connection must be modified
for it to work. (Although a smoother upgrade path than just sit out the
whole chicken/egg thing would be good.) More than a single long term
solution would be undesirable.

Intermediate solutions should bridge the gap. For an intermediate
solution, it's still not acceptable to have to change all hosts, but
changing all sites or all ISPs (by putting in proxy multihoming
processing boxes) should be acceptable. Intermediate solutions should
be very scalable and have a decent (but presumably  not perfect)
architecture because the life time of intermediate term solutions could
be longer than expected as it might be a very long time before a long
term solution is widely implemented. An important feature for
intermediate solutions is that they work well with both short term
solutions and with long term solutions. This probably means explicit
support for all short term solutions in all intermediate
implementations, and some kind of meta-solution that makes it possible
for intermediate and long term solutions to work together.

Some comments on the requirements document in this light:

     By multihoming, a site must be able to distribute both inbound and
     outbound traffic between multiple transit providers.  This
     requirement is for concurrent use of the multiple transit 
providers,
     not just the usage of one provider over one interval of time and
     another provider over a different interval.

Short: since we can do this for inbound with multiple A records and for
outbound with some (static) routes, at solution doesn't really have to 
support this
Intermediate: highly desired / required
Long: required, preferably even load balance a single session over
multiple paths

     By multihoming, a site must be able to protect itself from
     performance difficulties directly between the site's transit
     providers.

This is a good example of something we could easily drop for short term 
solutions.

     Multihoming solutions must provide re-homing transparency for
     transport-layer sessions; i.e.  exchange of data between devices on
     the multihomed site and devices elsewhere on the Internet may 
proceed
     with no greater interruption than that associated with the 
transient
     packet loss during the re-homing event.

Again, something that would definitely be a requirement for 
intermediate or long term solutions, but if we can have the ability to 
set up new sessions for a short term solution, that's better than 
nothing.

     A new IPv6 multihoming architecture must scale to accommodate 
orders
     of magnitude more multihomed sites without imposing unreasonable
     requirements on the routing system.

Short: has to be much better than simple PI, but a billion or more 
isn't necessary
Intermediate: required, as there may not be a long term solution after 
all
Long: required

     The solution may require changes to IPv6 router implementations, 
but
     these changes must be either minor, or in the form of logically
     separate functions added to existing functions.

Short: required
Intermediate: required
Long: desired: forklift upgrades are bad, but if we then get the 
perfect solution it may be worth it and/or we can wait out the natural 
economic life span of existing equipment

     The solution must not destroy IPv6 connectivity for a legacy host
     implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other 
basic
     IPv6 specifications current in November 2002.  That is to say, if a
     host can work in a single-homed site, it must still be able to work
     multihoming.

Short: required
Intermediate: required
Long: interoperability should remain but we can expect people to 
upgrade at some point, so just "desired"

     A multihoming strategy may require cooperation between a site and 
its
     transit providers, but must not require cooperation (relating
     specifically to the multihomed site) directly between the transit
     providers.

Short: required (not all ISPs will upgrade immediately)
Intermediate: highly desired (if this is the only downside, we can live 
with it, for a while anyway)
Long: required

Harold Grovesteen
Iljitsch van Beijnum