Ohta-san's draft

[Sean Doran <smd@ebone.net>]

Ohta-san -

  Firstly a small thing: I will accept as a given that you
are not proposing fundamental changes to things in the
middle, both in the sense of, "no change [to] routing
protocols", but also in the sense of routers performing
hop-by-hop destination-based forwarding.  Instead of
eliminating this intelligence in the network, your draft
proposes adding intelligence into end systems.  (That is,
you do not outright propose removing intelligence from
routers, by doing full-blown source-routing from the edge
and forbidding them from second-guessing the
source-route).  This makes things much easier to consider,
but also leads me to offer a revision to "Traditionally
with IPv4, multihoming has been offered ONLY through
intelligence in the routing system..."  However, that's
just a quibble. :-)

  Moving along, I have some very broad comments on your draft.

  Your draft proposes multihoming via a specialization of
site renumbering.  The specialization primarily is
concerned with optimizing the *sending* of traffic from a
given host, and effectively proposes the building of a
session layer into the IPv6 protocol stack to allow hosts
to adapt to renumberings.  (However, the session layer is
tightly coupled to TCP in your draft, and so is "hidden"
except for some changes to the socket API which you suggest).

  The meat of what you are proposing is to separate the
"who" from the "where" in much the same way as many others
have argued -- if using 8+8 like you suggest, the
lower-order 8 bytes indicate the identity of a system,
while the higher-order bytes you propose using to indicate
a path through part of the Internet.

  When establishing a connection, hosts will do a DNS
lookup to equip themselves with an initial set of
path-indicators to reach a given destination, will select
the best of these, and attempt to establish a connection.
The list of paths may be refined through information from
the destination, which may choose to expose more possibly
viable paths-indicators at the start of, and later during
the course of a conversation.  Moreover, information
learned by the sender will allow the sender to choose the
best path-indicator to use as the destination address
towards the destination.   This all looks tractable.

   I say "looks" because the optimizing-information can be
gained by observation of the different behaviours of
traffic sent to different path-indicators, reflected back
from the other party in the form of DUPACKs, timestamps,
no traffic, or a number of other possible things.
It is very important to note that the separation of
the "what" from the "where" means that a receiving host
must be prepared for nearly ARBITRARY "where" values to be
coupled to the lower order 8 bytes as a sender may switch
among many different path-indicators during the cours of a
long conversation.

   While I have some doubts about the utility to sending
systems of information gained from the current routing
system, a map-exchanging routing system would indeed make
it possible to make more optimal choices (or prune non-working
possibilities) among available path-indicators based on
knowledge of distant topology.   In any event, there are
many inputs which could be used in sorting several options
by _local_ (i.e., local to the sending system) preference,
and there is no reason for a host to make a decision in
the same way as any other host would in its place.

   I think TCP etc. can be finessed into cooperating with
path changes (including topology changes) -- I can imagine
sender-host policies like shifting to the next most
preferred of the (sorted) available path-indicators in the
event of an RTO or lots of DUPACKs/retransmits/delay/etc.

   Also, your not-quite-explicit session layer could
easily advertise or withdraw potential path-indicators
from the receiver.  In other words, a sender may be
constrained by the target to select from a subset of
possible path-indicators, or could be alerted to newly
available path-indicators.  This (implementable by virtue
of the location/identity split) does fix a large source of
trouble for using multiple addresses: rendezvous upon a
mutually acceptable combination of addresses.

   So, this is a very interesting architecture indeed.
However, now we turn to addresses.

   A host can find out a set of potential path-indicators
for a target fqdn in the DNS, some of which will be a
subset of working path-indicators, and some may be "dead",
and will time out if used.  This is not particularly
difficult to consider, since there are ways to analyse
dynamism in the DNS, and enable occasional changes such
as not advertising known-dead path-indicators or adding
new path-indicators, soon after they become available.
But...

    How does a host know its address?

    That is, how does a host learn what set of path-indicators
_can_ (not should, can) be advertised during the initial
handshaking of a new TCP connection (or thereafter)?

        Sean.

P.S.: I am basically asking for an explanation from you about
      what should go into the first 8 bytes.

      An example set of issues that your answer hopefully will
      make obvious based on this small graph follows.
                                 
                          MultihomedSender
                           |          |
                           v          v
           LocalISPNumberThree       LocalISPNumberFour
              |      |                 |       |
              V      V                 V       V
      RegionalISPZ RegionalISPY RegionalISPX RegionalISPW
                        (Really big ISPs)
      RegionalISPA RegionalISPB RegionalISPC RegionalISPD
           |             |           |           |
           |             |           |           |
           |             |           |           |
           v             v           v           v
           LocalISPNumberOne         LocalISPNumberTwo
                           |         |
                           |         |
                           v         v
                          MultihomedSite
                                |
                             Receiver

        How many path-indicators should MultihomedSender
        announce to the Receiver?  Two?  More than two?
        How many path-indicators will Receiver announce
        back in reply to the Sender's SYN (which uses a
        path-indicator from the DNS)?  
        
        (We assume that the entity that informs the
        Receiver what path-indicators it has can also
        inform the DNS if desired, directly or indirectly)

        Next: change.  What happens on the host if
        MultihomedSite multihomes to another network?
        What happens if some time (days?) subsequently
        MultihomedSite permanently disconnects from
        LocalISPNumberOne?  If the answer is: the host
        acquires via some protocol (or manual
        configuration) a new path-indicator, who assigned
        the path-indicator in the first place?

        Incidentally, any solution to this which does not
        require changes to the current routing system is
        also a general solution to site renumbering, which
        is much-missed feature in IPv4 and IPv6, and
        likely would be worthy of an RFC of its own.