It seems everyone has espoused the idea that the application *must*
talk directly to the network transport in order to be efficient and/or
resilient, but given the capabilities IPv6 is supposed to have, I
wonder how much of a good idea it is to cling to that concept.
These "capabilities" should be regarded as bugs which are being fixed.
In particular, the fact that IPv6 hosts can, in ordinary circumstances,
have multiple addresses has led people to believe that it's reasonable
to expect IPv6 apps to deal with an arbitrary number of addresses per
host, some of which work to send traffic to the destination and some of
which don't, and to have this behavior vary from one source location to
another. First, nobody has ever explained how these hosts can reliably
determine which addresses will work. Neither source address
selection nor multi-faced DNS are satisfactory answers. Second, this
robs apps of the best endpoint identifier they have.
It is not worthwhile to suggest that the direct application/transport
interface be eliminated, but it should be possible for an application
to specify what kind of service it wants from the (transport, network)
combination and something is there to handle that where the requested
service is different from that natively provided by the
(transport,network) combination.
No, it's not worthwhile. Any kind of routing needs to happen below the
transport layer rather than above it. That's not to say that you can't
make something work above the transport layer, but that to do so you
have to re-implement routing, acknowledgements, buffering and
retransmissions, duplicate suppression, and windowing in this new layer
when transport protocols already provide it.
Keith Moore's statement is quite correct, viz:
Application developers need
reasonably stable and reliable endpoint identifiers. At present,
the IP address is the closest available approximation to such an
identifier.
Two questions arise out of that though, at least as far as Keith
Moore's statement is concerned. The first one is how stable is
stable? That is, how long is that identifier supposed to remain
stable.
Good question. My best answer so far is: stable enough so that the
vast majority of applications don't have to implement additional logic
to allow them to survive broken TCP/SCTP/etc. connections, or (to put it
another way) stable enough so that failures due to address/prefix
changes are not a significant source of failure for most applications
(as compared to, say, uncorrectable network failures and host failures).
IMHO, apps should be able to assume that an advertised address-host
binding is valid for a minimum of a week. This is a minimum - it
should be longer whenever possible. (however there's no requirement to
maintain addresses longer than the nets will be accessible anyway -
i.e., you don't expect the addresses for the ietf conference net to
remain valid after the net is unplugged...but they shouldn't be reused
within a week either.)
And the second question is what should be the context of that
identifier's validity?
The identifier should be unique within the entire Internet. In some
cases (e.g. small networks without connectivity to the Internet core)
"very likely to be unique within the Internet" would probably
suffice. That doesn't mean that you can send to any point from any
other point, because there will still be access controls. But if an
address is advertised for a host, and you have permission to send to
that host, you should be able to use that address to send to that host.
Also from Keith Moore:
Disagree. The layer needs to be between the current network and
transport layers. If the layer were between transport and
applications, many of the services provided by transport would end
up having to be re-implemented in higher layers.
And
It would also force routing decisions to be made by layers
much more distant from the network layer that maintains reachability
and state information than the transport layer.
Does Mr. Moore care to explain a little why he believes these two
statements? As far as I can tell it needs not necessarily be so.
The first one I explained above in slightly more detail. The second one
should be obvious. If an address becomes invalid because of a topology
change somewhere distant in the network, how is a layer above layer 4
going to know about it? It doesn't have access to routing protocol
updates - those happen at layer 3 and aren't normally propagated to
hosts anyway. When you think about it, you probably don't want hosts to
have to listen for information about distant state changes in the
network - that would place a tremendous burden on small hosts and nets
with low-bandwidth connections.