> 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.