[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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