Using NAT64 in front of IPv6-only servers

[Gert Doering]

Hi,

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")

> That said, an the v6-only servers would probably also have access to a
> traditional NAT64/DNS64 system so that it could acquire security updates
> and such from the vendors' servers. But that would have to be a
> completely independent system with a different NAT64 prefix because it
> has to be a stateful device.

Yes.

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110401/a8a62019/attachment-0001.bin