Re: GSE

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

    > From: Thomas Narten <narten@us.ibm.com>

    >> when would you go from identifier to locator without the hostname?

    > The standard argument has been that if you can't perform a mapping from
    > identifier to locator, it limits the ability to recover from failures
    > where the existing binding stops working.

Right now, we seem to be happy to live without any ability to recover from
failures of the 1:1 identity-location binding, except MIPv6. So how are you
worse off?

    > I.e, either recovery is not possible (in some scenarios), or it's pushed
    > back to higher layers (e.g., application and DNS lookup). But if the
    > application is responsible for recovery, its not clear how attractive a
    > solution this would be in practice (or how much more benefit one gets
    > compared to using full-blown addresses with no separation of identifier
    > and locator, as apps could do the same sort of failure recovery today).

But it's not the *application* which does the recovery. The whole point of
doing a certain level of multihoming, i.e. keeping existing TCP connections
open, is to *avoid* having to notify the application. The client host does
find out something's changed, and has to switch to a new locator for the
destination, yes; but there's no architectural reason for the application to
know about it.

There are two cases: i) where the multi-homed end wants to switch to a second
address which was available at the time the connection opened, and ii) a
second address which was added later. I separate them out because someone
(Iljitsch?) pointed out the important difference, which is that in terms of
security, the first one is as good as what we have now (especially if you get
all the target addresses in a single DNS reply), whereas the second one
requires protection of the mechanism to do the rebinding.

Anyway, let's assume just the first case, since it's the easiest. The TCP
layer notices (or is notified via an ICMP Dest Unreach) that it can't reach
the far end. So it has to try switching to another of the addresses that it
got from the DNS lookup.

At this point, I concede that due to poor modularization of host software, it
might be that *part* of the application has to find out - i.e. the part that
got the DNS name and did the DNS lookup and passed an IP address to TCP.

However, you can think up kludges that get around this: e.g. the DNS and TCP
are modified to conspire so that the IP addresses that are passed to the TCP
are "destination identifiers" (which are perhaps local to the host); that way,
when it switches to a different destination address, the IP addresses passed
across all the network interface calls stays the same, and knowledge of the
changed real addresses is kept from the application.


It's really important when thinking about these things to look at them from an
architectural perspective, not an engineering one - the architectural
perspective makes is easier to see what is and is not possible (e.g. whether
the application really has to know).

*Then*, knowing what's possible, you can look for an engineering solution that
takes into account the current reality (e.g. deployed application code).

	Noel