"Simultaneous open of TCP connections" is not supported.

[ydahhrk]

The NAT64 should store IPv4-TCP packets for which there's no state for a while.
This is explained in RFC 6146 page 28.

[cetex]

What's are the implications of this being missing? / What's the reason for the need to fix this? :)
Can't you open multiple tcp sessions through jool simultaneously now?

[cetex]

Correcting myself here. :)
I read this: http://tools.ietf.org/html/rfc6146#page-28
and this: http://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.html
TLDR: If an outside host connects to the gateway-ip(v4)
src port 1, dst port 2
At the same time as the inside-host connects to the same outside host from
src port 2, dst port 1
The connection should succeed and result in one less roundtrip needed for tcp.
(chances are very very slim of this occuring in real life)

Thanks for making me learn something new! ;)

[ydahhrk]

Lol. Still, I admit I could have been more wordy.

I case someone else wants a summary:

"Simultaneous open of TCP connections" is when all of the following conditions are met:

Two endpoints

• Try to open a connection (send SYN packets),
• a TCP connection,
• the same connection (same addresses and ports, and at each other),
• at the same time.

As cetex mentioned, this happens very rarely. I far as I know, there is no reason why anyone would actually actively want this to happen (even as an attack, AFAIK); it's simply a sporadic phenomenon TCP is supposed to handle gracefully. Also, it doesn't affect other connections at all.

Instead of doing what the RFC wants, Jool simply drops the IPv4 connection attempt. Jool will not crash, but what happens at the endpoints is somewhat implementation specific. In the worst case, they will simply have to reattempt the connection.

This is currently being worked at https://github.com/NICMx/NAT64/tree/tcp_store_packet, but it's on temporary hiatus and not part of the current planned milestones.

Update 2014-06-25: This is currently being worked at https://github.com/NICMx/NAT64/tree/issue58.

[ydahhrk]

Another update:

My understanding of the consequences of the current implementation have changed.

This is what the RFC wants us to do:

If Jool receives a IPv4-TCP connection request, the packet should be stored.

1. If no IPv6-TCP packet connection request is received after 6 seconds, the IPv4 node should receive a ICMP Destination Unreachable error (because there is no Simultaneous Open) containing the stored packet.
2. If the IPv6 packet is received, there is a Simultaneous Open, so it should be forwarded normally and the stored packet discarded so the handshake can do its job.

This is what Jool currently does:

If Jool receives a IPv4-TCP connection request, the packet is discarded.

1. If no IPv6-TCP packet connection request is received after 6 seconds, nothing happens, so the IPv4 node gives up after a while.
2. If the IPv6 packet is received, it is forwarded normally and the handshake does its job.

Because the end result is the same in both second bullets, it just so happens that Jool has supported Simultaneous Open of TCP connections all along. What it does poorly is is let IPv4 nodes know that their TCP connections cannot be made when there is no Simultaneous Open...

[ydahhrk]

This was fixed and the changes were merged into the master branch; Closing.