> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf