Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

>> In those cases, the programmers are also crippled and prevented from
>> dealing effectively with various cases that are now increasingly
>> common in the Intenet today: NATs, multiple addresses for source and
>> destination (not all of which work equally well), IPv4 vs IPv6 (for
>> which the default address selection rules are woefully inadequate),
>> multi-faced DNS, LLMNR, etc.
>>     
>
> I strongly object to the idea of application programmers dealing with
> NAT, IPv4 vs. IPv6 or source address selection for the eternity. The
> wiring of level-3 details in the applications is precisely what makes
> the transition to IPv6 so difficult. Applications should not have to
> be "ported to IPv6". They should work the same with both level-3
> protocols (and, indeed, they do, in every language but C).
>   

In a sense, I agree with you that we don't want most applications having
to deal with these things, and we certainly don't want to saddle the
application with having to deal with these problems forever.  However, I
do not reach the same conclusion about the API that you appear to reach,
for a few reasons. 

First is that there will always be some applications (such as diagnostic
tools) that need to know more about the network, so it is necessary to
have an API that allows those applications to function.

Second, I don't share the view that many seem to have that applications
in general should be IP version agnostic.  IPv4 with NAT is far too
brain-damaged, and has such limited reach, so there is a strong case to
be made that in some point in the future, many kinds of apps should
operate only under IPv6.   Similarly there is a case to be made for some
legacy apps (e.g. apps that exist mostly to talk to obsolete hardware)
to operate only under IPv4.

Third, while it is well and good to talk about ideals, the notion that
"applications should not have to" deal with these things ignores the
fact that in the current network architecture, applications _do_ have to
deal with these things.  This isn't just a consequence of NATs, but also
of the IPv6 architecture which insists that (for a variety of reasons)
hosts shall have multiple addresses, but fails to provide hosts (and
host stacks) with an effective mechanism for selecting among those
addresses on behalf of applications.   Such selection needs to take a
variety of factors into account, including the communications topology
of the application (is it multiparty or point-to-point?) the
application's need for bandwidth, the likely duration of the
application's association with peers, the ability of the application to
tolerate and recover from changes in IP address, the way that the
different address prefixes are used by the network (ELIAs can be used
differently than globals, and link-locals are certainly used differently
than globals), and so forth.

Fourth, for a variety of reasons, DNS names are not and have never been
adequate as general purpose endpoint identifiers, and this situation is
getting worse rather than better.  One reason is that DNS names are not
equivalent to host names, and emphatically not equivalent to
distinguished host names, and haven't been so at least since the web
came into existence.  A given DNS name might be bound to a single host,
multiple hosts having more-or-less equivalent function, a service, a
community of users, or whatever; the binding might be stable or
ephemeral; and the name might or might not be suitable as a
distinguished name (one chosen preferentially over others for use in
indicating that host, group of hosts, service, whatever).  There's no
way to tell.  Another reason is that DNS is often slow and unreliable
and/or out of sync with reality - one of many factors making DNS names
less suitable for referrals between hosts.  Another reason is that
multi-faced DNS limits the visibility of DNS names even when
applications are expected to work across the boundary.  Another reason
is that DNS is increasingly polluted.  For instance, my ISP's default
DNS servers lie about DNS results for domains that have no A records,
even if there are other records in that domain, in order to redirect
HTTP requests for misspelled DNS names to a web server that will
"helpfully" offer links to alternatives (and also display
advertisements).  So however noble it might be to try to present apps
with a simple interface based on DNS names, what this really does is to
cripple apps' ability to cope with the mess that is DNS.

Fifth, trying to overload so many functions in a single API inevitably
masks error conditions that often need to be distinguished, and treated
differently, by the application. 

As for the notion that applications work the same for both v4 and v6 in
every language but C: This goes a long way toward explaining why network
applications continue to be written in C.  And that in turn goes a long
way toward explaining why network applications are notoriously
insecure.  I know that every time I've considered writing a network
application in a new language, I take a look at the network API and
conclude that it's inadequate.  (granted, I tend to write more esoteric
applications)
> If the IPv6 problems are to be useful, it is in showing that there is
> ZERO probability of splitting the identifier and the locator if we
> have to change the applications.
>   
Despite the oft-cited ideal of splitting the identifier and the locator,
nobody has ever to my knowledge provided a complete and convincing
example of how it can be made to work well.   Actually providing those
identifiers, along with a scalable, reliable, fast, and secure service
that maintains identifier-to-locator bindings is a nontrivial problem
that tends to be overlooked.
> I also really doubt that the typical application programmer is able to
> do a better job than the kernel / libraries to, choose the source
> address or other level-3 features. Plus, IMHO, if someone must
> influence this selection, it should be the system and network
> administrator, not the application programmer.
>   
Partially disagree, because the selection is heavily dependent on the
type of application and how it uses the network.  I do think that the
network admin has a role in explaining to the application or API how
particular addresses are to be used, but I don't think it flies to
expect every application to use those addresses in exactly the same
way.  There's a big difference in how you want to handle address
selection for a mounted remote file system than in how you want to
handle address selection in an email MTA.
>> only if you want to limit the deployability and/or efficiency of
>> your application.
>>     
>
> As an user, I would be very afraid of an application which tries to
> play tricks with NAT...
I guess you wouldn't use Skype then, preferring to spend lots of money
on international phone calls.

In my experience users tend to prefer applications that work reliably
over applications that don't work reliably.   Given two apps, one that
copes with NAT and another that doesn't, users will use the one that
copes and blame the one that doesn't - even though arguably the failure
of the latter app is the fault of the network.

Keith