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

[Phil Mayers]

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