It's not uncommon to see a FQDN point to several IP addresses so that
the service identified by the FQDN can be provided either by
(a) multiple hosts, or
(b) a host with multiple addresses.
Now if we want to support moving from one addresses to another in the
middle of an (application level) session, we have two choices: build a
mechanism that assumes (a) and by extension also works with (b), or
focus on (b) exclusively.
It looks like Tony Hain wants to go for (a) while Keith Moore assumes
(b),
No. A client can't tell whether multiple addresses associated with an
DNS name indicate multiple hosts or multiple addresses for the same
host. No matter where the stabilization layer(s) live, using DNS as a
means to map from identity to locations simply won't work. It might be
good enough for initial connection (assuming that if a service exists on
multiple hosts, any of them will do), but it's not good enough for
re-establishing an already-open connection, because you might get a
different host the next time.
hence the insanity claims because a solution for (a),
I don't know whether Tony assumes (a) or not. But that has nothing to
do with why I made that particular claim.
As a member of the multi6 design team that works on a (b) solution I'm
convinced that such a solution will provide many benefits and should
be developed and implemented.
And I'm equally convinced that a solution that assumes (b) is a
nonstarter. There is already too much practice that conflicts with
it. Like it or not, DNS names are no longer "host" names in practice;
they're "service" names. A service can be a host but it's not
reasonable to assume that a service _is_ a host.
Also, the current socket API isn't exactly the optimum way for
applications to interact with the network. It would make sense to
create something new that sits between the transport(s) and the
application, and delegate some tasks that are done by applications
today, most notably name resolution. This allows us to implement new
namespaces or new address formats without any pain to application
developers or users stuck with applications that aren't actively
maintained by developers.
No it doesn't. What it allows "us" to do is impose subtle changes in
the behavior of lower layers, and introduce new failure modes, without
giving applications any way to deal with them.
But the real question here is: does this new "thing" have to be a
layer?
It depends on which "thing" you are talking about. For the L3-L4 thing,
it's either a new layer or a change to an existing layer. If you
have both the L4-L7 thing and the L3-L4 thing, the former is either a
new layer or (my personal opinion) a new API that knowledgable apps
call explicitly.