ietf
[Top] [All Lists]

Re: The IPv6 Transitional Preference Problem

2010-06-23 09:03:27
Joel Jaeggli wrote:

On Jun 23, 2010, at 6:06 AM, Martin Rex <mrex(_at_)sap(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf