Joel Jaeggli wrote: > > On Jun 23, 2010, at 6:06 AM, Martin Rex <mrex@xxxxxxx> wrote: > > > > What you described results in a negative incentive for servers to > > become accessible under IPv6 as an alternative to IPv4. That is a real > > problem. If a large number of clients would follow your proposed > > strategy, ever server that announces an IPv6 address gets hit by > > twice the amount of connection requests, half of them being killed > > prenatal or during infancy. > > We have tcp syn cookies actually to protect against the impact of > state generation on connect. As long as you as a client reply only > to one syn/ack, everything is cool. If it was the TCP stack that generated both original SYNs to decide then this might work. But it is some app code several layers higher with a non-negligible latency. Originally, there were two choices for the app: multi-threaded blocking connect()s or asynchronous non-blocking. In the blocking variant, it becomes pretty difficult to prevent TCP from completing the handshake. If the IETF really thinks that there is value in going down that path, then it should define parallel IPv4&IPv6 connects at the network level, so that either connection knows about the other one. This should be accompanied by a hint in DNS indicating that a node (a) technically supports and (b) does not mind parallel connect()s. When it is part of the network stack, it could work with any existing app. My knowledge about the TCP, IP and NAT stuff is pretty limitited. While the TCP SYN cookies might help to protect the server apps, how much resources do a single SYN/ACK use at the kernel/TCP stack layer and how much resources do they use on the NATs in between? Without FIN/ACK or RST only the "closing" client knows that the resource can be freed. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf