On Fri, 13 Feb 2015, Phil Mayers wrote:
None of this should be a problem for non-NATed IPv6. The absence of NAT
will mean an ICMP error doesn't "block" a NAT translation - there's no
such thing to block - so a CPE can send errors or not.
Ah, thanks for pointing that out.
So currently there are multiple providers disallowing incoming connections
to IPv6 addresses for customers. But if I understand correctly, including
what you described before, this would work:
U1=User1, U2=User2...
HGW1=HomeGateWay, belonging to U1.
Assume IPv6 and no NAT.
U1 and U2 are going to play a game together. They're speaking to the game
server. U1 says "please talk to me on <U1IP> UDP port <U1PORT). U2 says
"please talk to me on <U2IP> UDP port <U2PORT>. Game server informs
respective user about the other users' IP/PORT combination.
Now, U1 sends a UDP packet from U1IP,U1PORT to U2IP,U2PORT.
HGW1 creates flow state for U1IP,U1PORT<->U2IP,U2PORT.
Packet reaches HGW2, which has no flow state, and is dropped. ICMP error
message might be created.
In case of ICMP error message, U1 should ignore this.
U2 sends a packet from U2IP,U2PORT to U1IP,U1PORT.
HGW2 creates flow state.
Packet hits HGW1 which already has a flow state, and packet successfully
reaches U1.
U1 now can start sending packets to U2 as well and they've worked around
both of them having HGWs with stateful firewalls disallowing new
connections to them.
Right?
The crucial step here seems to be the fact that initial packets might be
dropped and error messages be generated, but these should be ignored by
the application. Is this commonplace? Is it a problem at all?
--
Mikael Abrahamsson email: swm...@swm.pp.se
