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". > 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. Regards, -drc _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf