Why do we still need IPv4 when we are migrating to IPv6...

[Phil Mayers]

On 12/02/15 11:05, Tore Anderson wrote:
> * Ole Troan
>
>> When will IPv6 provide me as an end-user with more "value" than what
>> my current NATed IPv4 connection does?
>
> If you, like me, like to play games online, and at some point find
> yourself googling for the cause of connectivity problems (it is just

+100

Let me document something I ran into recently. Playstation 4 "party 
chat" wasn't working for me, with some people.

Detailed examination showed the fault was causes by a complex 
interaction between the UDP NAT traversal on the client, race conditions 
with the HTTPS-based control channel, and the iptables/conntrack NAT 
code on the CPE[1].

It made me mad, and made me want IPv6 :o(

Cheers,
Phil

[1] Details for the curious:

1. Client binds a UDP port and does a STUN discovery to determine 
external IP/port

2. Client sends external IP/port to HTTPS-based "control" channel

3. Client requests IP/port of other participants from control channel
    <client goes to sleep waiting for a reply here>

4. Remote participant receives our client IP/port and starts sending UDP 
traffic to that port

5. Packets arrive at local CPE; no "conntrack" entry present, so traffic 
is punted to local IP stack on CPE

6. Local IP stack generates ICMP port-unreachable

7. Conntrack inspects content of ICMP port-unreachable, extracts 
"original" 5-tuple, creates a conntrack entry and links ICMP to it

8. Client receives remote participant IP/port from control channel, 
sends UDP data to it, from already-bound UDP port

9. CPE sees UDP traffic; tries to map internal port to same external 
port, finds a conflicting 5-tuple already present (from step #7) and 
instead maps to random port.

10. Remote CPE sees traffic from random port; no conntrack mapping; goto 
step 7...


The only way to get around this is to use the "DMZ" (forward all unknown 
ports) functionality, which you can only point to one device - good luck 
if you have two - or for the people managing the CPE to make the local 
"iptables" INPUT chain DROP, not REJECT, at least for unknown UDP. Good 
luck persuading lazy residential providers to fix that...

Grr. NAT sucks.