On 13/02/15 11:26, Mikael Abrahamsson wrote:
On Fri, 13 Feb 2015, Thomas Schäfer wrote:
and the practice in Germany to blocking all IPv6-inbound traffic the
result is the problem for some gamers.
So I guess applications should use the same technique as one does to
traverse NAT44:s, ie both ends of the connection send packets to each
other to open their respective firewall.
I do agree that the firewall in question needs to not send rejects for
this traffic for this to work. I am happy this use-case was brought up,
because I hadn't heard and thought about this before. Personally I don't
want to silently drop packets, so I guess clients need to try a few
times and not listen to the (initial) ICMP messages until the "hole" is
open.
It all depends on the behaviour of the device(s)
It's perfectly possible for a CPE to send ICMP errors without those
errors creating a NAT table entry and blocking the "real" (inside) host
from using that 5-tuple.
In the situation I described yesterday, the CPE is Linux, and it could
have done something like:
iptables -t raw -A OUTPUT -p icmp -j NOTRACK
Or it could not send errors for unknown UDP flows directed to high ports
e.g.:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j PERMIT
iptables -A INPUT -p udp --dport 1024:65545 -j DROP
There's a bunch of different solutions.
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.
If you're NATing IPv6, well... you brought it on yourself ;o)
Cheers,
Phil
