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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf