NAT66 Experimental Draft - RFC6296

[S.P.Zeidler]

Thus wrote Olipro (olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa):

> So, it would appear that things on the NAT66 front have progressed from the 
> IETF over to RFC status.

Note that RFC6296 is strictly algorithmic prefix translation, NPT66.

> Whilst NAT66 is certainly something that could prove invaluable if you wish to 
> setup a network without having to worry about renumbering problems down the 
> line, it does also raise the issue of making a number of daft things possible 
> - namely, whilst the RFC does state that the NAT/NPT itself will only perform 
> 1:1 mappings, it doesn't make any requirement that you must not use it with 
> connection tracking or anything else that could run atop the translator and 
> affect exactly what addresses it translates to.

NPT66 tells you how to calculate the translation, it contains the formula:

--- cite ---
o  The internal prefix is overwritten with the external prefix, in
   effect subtracting the difference between the two checksums (the
   adjustment) from the pseudo-header's checksum, and

o  A 16-bit word of the address has the adjustment added
   to it using one's complement arithmetic.  If the result is
   0xFFFF, it is overwritten as zero.  The choice of word is
   as specified in Sections 3.4 or 3.5 as appropriate.
--- /cite ---

This determines which address you must translate to given an inside and
outside prefix, 100% deterministic and reversible given the same
information.

Of course that will stop nobody from doing something else entirely, but
that's as little RFC6296's fault as was translating the SMTP dialog to
German by Sinix the then SMTP RFCs fault.

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)