Using NAT64 in front of IPv6-only servers

[Erik Kline]

> On Fri, Apr 01, 2011 at 10:04:40AM +0200, Tore Anderson wrote:
>> > Since you're using the NAT64 in the "inverse direction", you're
>> > effectively nullifying the benefits of "you get automatic mappings
>> > for everything you want to reach" (as the IPv4 space can be embedded
>> > in the IPv6 /96) - so it's "just" a destination-NAT that happens to
>> > be able to d-NAT into the other address family, and source-NAT v4->v6
>> > while at it.
>>
>> Precisely. That it operates in a stateless per-packet manner is
>> crucially important, I do not under any circumstance want a stateful
>> device between the public service entry point and the internet.
>
> Oh, good point.  I completely missed that aspect.
>
> Indeed, if you run the NAT64 "in reverse", and s-NAT the v4 source
> into the NAT64-/96-mapped address, it should be able to completely run
> in a stateless way - so failover to a redundant box is completely
> trivial, nullifying Ted's counter-argument.
>
> (Plus, it only needs to be in the packet path of ingress IPv4 packets
> specifically destined to the web services, not in the packet path for
> IPv6 clients, or "other IPv4 traffic")

Apart from NATing protocols that embed IP addresses, maybe pathMTU
issues?  I don't think you can send an ICMPv4 packet to big when DF
isn't set and expect the IPv4 client to be sensible about it.  All in
all an altogether avoidable problem, I would expect.