Why do we still need IPv4 when we are migrating to IPv6...
p.mayers at imperial.ac.uk
Fri Feb 13 14:16:33 CET 2015
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
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
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)
More information about the ipv6-ops