On Jun 17, 2010, at 12:18 PM, Martin Rex wrote:
Maybe because it would be a big waste of network bandwidth and close
to a Denial of Service (DoS) attack if every client would try every
IPv4 and IPv6 address in parallel that it can get hold of for a hostname.
In a world of broadband, gigabit ethernet interfaces, high speed wireless,
etc., I have some skepticism that attempting both v4 and v6 connections in
parallel is a "big waste", much less anywhere near "close to a Denial of
Service (DoS) attack".
Well, first of all, there are plenty of places that do not enjoy the benefits
of all that fancy stuff. What may be a tiny bit of meaningless overhead may
be something else entirely for someone else.
But this is all really beside the point. The big problem, as John Klensin, PHB,
and others have pointed out repeatedly but to no avail, is support overhead.
Not network overhead.
And those failed lookups have a real support overhead cost. Among other things,
they create entries in appliction and firewall logs. In many cases lots of
entries. And when customers see those entries - and don't understand what they
mean - they call up and complain.
And please don't try and convince me this won't happen. I know better. I've
been on the other end of these sorts of calls more times than I can count.
At this point I wouldn't consider shipping an application that doesn't support
at least basic IPv6 connectivity, but there's also no way I'd consider shipping
an application that has that support enabled by default, because it's
guaranteed to be a support call generator.
Similarly, it could require a major redesign of lots of applications
in order to be able to manage several parallel requests
-- multi-threaded with blocking DNS-lookups and blocking connect()s
or parallel asynchronous/non-blocking DNS-lookups and connect()s.
Well, yes. However, applications already have to be modified to deal with
IPv6. I'd agree that modifying applications from a simple synchronous path to
dealing with parallel asynchronous connections would not be a good idea.
Personally, I'm of the strong opinion that the socket() API is fundamentally
broken as is the separation of naming lookup from connection
initiation/address
management. In the vast majority of cases, applications should not know or
care
what about anything but the destination name/service. As I understand it, new
APIs are evolving towards something conceptually like
connection_id = connect_by_name( hostname, service )
allowing the kernel to manage the address, expiration of the address, name to
address mapping change, etc. transparently to the application.
The situation is a lot more complex than this. For one thing, most new
applications are being written in languages that provide their own
connectbyname APIs, often tightly bound into the overall I/O infrastructure.
An immediate consequence of this is that the "evolution" of the socket API is
no longer directly relevant to many if not most application developers. They're
going to use the calls the language they've chosen provides, end of story. To
the extent the evolution of the socket interface retains any indirect
relevance, it is that the language implementors may decide to take advantage of
it. But that's unlikely because (a) Language developers are especially
sensitive to being able to run seamlessly on old, and sometimes very old,
operating system versions, versions that do not have any form of the stuff
we're talking about, and (b) THey've already done the work to write their own
connectbyname API they know works, why switch?
And for applications written in a language like C, the present lack of a
well-specified and full-featured cross-platform API of this kind is a problem
that, in a very sense, it is now too late to solve. When we surveyed the
platforms and OS versions we have to support, several had no connectbyname call
of any sort available, and of those that did, not a single one had a call with
the feature set we needed. We had no choice but to write our own, and I doubt
very much we're alone in reaching this conclusion.
The painful reality is that in order to be effective a connectbyname API needed
to have been specified at least five years ago and probably more like ten. At
this point the work is really too little too late.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf