Re: (multi6) requirements draft comments

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: Michael Richardson <mcr@sandelman.ottawa.on.ca>

    > I believe that there are three solution spaces:
    > 1) ... if you have geographically relevant addressing, either via
    >    geo-PI ... This is more or less the BGP solution space.
    > 2) network layer solutions.
    >    mobile-IP like systems.
    >    ...            
    >    opportunistic-encryption-like-tunnel systems.
    >    ...
    >    HIP-like systems- a variation of the above where IP addresess
    >           become meaningless, and hashes of public keys terminate
    >            connections.
    > 3) transport layer solutions.
    >    Just use SCTP for everything

I've been thinking about this in the back of my mind, and I see a somewhat
different way to divide the solution space (perhaps related to looking at it
architecturally, rather than from a mechanism point of view).

The first split I come to is between "let the routing do it", and "use
multiple routing-names". What I mean by this is that either:

- i) you have, *and retain*, a single routing-name, and the routing has to
somehow keep track of where it is / how to get to it, or
- ii) you somehow use multiple different routing-names

In other messages in the thread, I've been exploring stuff about the "have
the routing do it" path. Here I'd like to expand some on the "use multiple
routing-names" option.


The first thing you have to settle is "how do higher level things (which
could be either a transport protocol, or an application) keep track of who
they are talking to"?

Again, there are two ways to go:

i) those things can be aware of the fact that the thing is now at a new
and/or more than one routing-name (and I recall a proposal by Dave Crocker to
the CIDRD WG some years back that proposed just this - he wanted a way to
take one end of a TCP connection and rehome it from one IP address to
another), or

ii) those things can have some other way of referring to the thing they are
talking to, and somewhere "else" in the software, that thing gets mapped to
multiple routing-names.


There are a multitude of ways to do the latter, depending on at what layer in
the system the alternative name exists.

- Classic mobile IP says that the "true" name is an internetwork address
(which also doubles as a rendezvous point), and that maps to one or more
"real" routing-names.

- HIP creates a new namespace, roughly at the tranport level, and uses that.

- SCTP again creates a new namespace, but at slightly higher level,
closer to the application.

Etc, etc...


The interesting thing in all this is that mobility and multi-homing wind up
both a) using much the same breakdown, and therefore b) potentially using
very similar mechanisms. You can take that "architectural decision tree"
above, and substitute "mobility" for "multi-homing" in it, and it will look
basically indentical. So perhaps there's some place for a certain common
mechanism?

It also highlights some issues with some possible solutions. E.g. as I
mentioned in a message to the IETF list, regarding mobile IP,

  tying the rendezvous to the original topological location of the host does
  have potential failure modes (e.g. if that part of the network goes
  unreachable, the mobile host may become unreachable even if it's still
  online elsewhere)

This is doubly true of multi-homing stuff. If a multi-homed and/or mobile
node has an address which is related to its "primary" ISP, and that ISP
becomes unreachable, the node will perforce also be unreachable.


    > None of these solutions are even exclusive. I can see all three systems
    > occuring at the same time.

Yes, but... if you have a solution which works for 10^7 multi-homed houses,
and works well, why bother to have a separate one for companies?

	Noel