Re: identity persistence and comparison issues

Christian,

Christian Huitema wrote:
>>The point is that today, the underlying assumption of most
> 
> applications
> 
>>is that the IP address they get back from an A or AAAA query, or any
>>other source including manual config, is a permanent identifier with
>>the nice property that the routing system can use it as a locator.
> 
> 
> Is that actually true?

I wish I'd written "most middleware" because that is really what I
meant, but it isn't a popular word in the IETF.

> 
> Looking at my own neighborhood, I see the following:
> 
> 1) The most popular applications, web browsing and e-mail, do not make
> the assumption that addresses are identifiers. Web servers commonly use
> techniques such as DNS load balancers, and the clients see a different
> address every time. 

For some definition of "time". Within the time that the client middleware
caches a DNS reply (which may or may not correspond to the official TTL),
the address is treated as permanent. Indeed, the clash between this
and the (sometimes egregious) behaviour of DNS load balancers can today
cause problems.... RFC 2775.


> Mail clients typically resolve a domain name before
> any attempt to communicate with a server.

Except for the bizarre case of mail to user@[IPv6:2001:xxxx]

> 
> 2) The vast majority of networking applications are not written to the
> socket API. They are typically written in Visual Basic, C# or other high
> level languages, and they interface the network through high level calls
> such as RPC, DCOM or WinInet (an API to the HTTP protocol). The
> underlying libraries do not assume that the addresses are fixed; the API
> typically uses a service name or a server name, not an IP address.

The middleware may have the illusion that the FQDN is the identifier in
use, but run time middleware such as JDK or Globus XIO uses sockets and
caches DNS replies. Indeed, if the application layer uses an FQDN for
referrals, we don't have a problem with referrals - but although we might
recommend this, we can't enforce it.

> 
> 3) Emerging applications written around instant messaging services, peer
> to peer services or SIP do not assume that a host address is fixed.
> Indeed, the SIP payloads carry the "current IP address" at which a SIP
> UA expects to receive packets. 

Yes, post-NAT applications have to deal with this - but if the "current IP
address" changes due to multihoming, how will the SIP layer know it, unless
we enhance the socket API?

> 
> Indeed, most of these applications have a concept of "session", and
> expect that the addresses will remain stable for the duration of the
> session. But many also have a capability to reconnect if the session is
> interrupted, and the reconnection procedures typically include a name
> resolution.

Yes. But do we want that to become the *expected* behaviour following a
multihoming event?

    Brian