Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

[Ole Troan <[e-mail]>]

>> Garbage.  At worst it would have been growing IPv6 traffic + dropping
>> NAT44 traffic.  THE OPERATORS ONLY HAD TO TURN ON DUAL STACK.
> 
> NAT64 and the other ipv4-over-ipv6 technologies have the advantage of allowing not having to deploy IPv4 at the edge with all that entails in form of BCP38 functions, routing protocols, addressing, CGN boxes traffic needs to be routed to, etc. Instead you can put your NAT64 machines whereever they fit best and don't have to worry about how to get your RFC1918 prefix traffic to it. Instead it's tunneled there. Less complexity.

This discussion would benefit from us using terms with precision.

NAT64 is not an IPv4 over IPv6 technology. NAT64 allows an IPv6 application to speak to an IPv4 application.
NAT64 + DNS64 has the issue of breaking DNS64, and forcing every IPv6 application for eternity to be restricted in functionality to what an IPv4 application can do.

464xlat, while reusing the NAT64 component on the network side (which is just a CGN btw), offers shared IPv4 service. From the "user" perspective the '6' part really doesn't matter. It could be any form of transport.

> 
> So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn't have to do DNS64 (apart from the well-known "prefix detection" zones.

I don't understand what you mean here. These are in my mind two completely different use cases.
NAT64+DNS64 solves the problem of an IPv6 application talking to an IPv4 application (and we can argue if that should really be solved at all). 464XLAT solves the problem, of IPv4 exhaustion by extending IPv4 to live forever (sic!). (Yeah, that last one was meant to be a little provocative, but We are currently in a state where 32 + 16 > 128 appears true).

Best regards,
Ole