Hi,
Thus wrote Rémi Després ([email protected]):
> 1.
> In a mail of Oct. 31 to yourself with copies to Margaret and to the list, I
> wrote:
> <<<
> Your draft-mrw-nat66-00 says:
> (a) "If the resulting value is 0xFFFF, it is changed to 0x0000" (sec. 8,
> second paragraph)
> ...
> I found in the draft no technical justification for these rules, so that:
In one's complement arithmetic, 0xFFFF and 0x0000 are indistinguishable
variants of zero. Since they happen to not be the same in an actual IPv6
address, you have to forbid one variant to have the math produce
unambiguous results.
> ... until you would provide TECHNICAL REASONS showing how (a) ..., or some
> revised rules, would ensure address-mapping reversibility, it is legitimate
> to doubt, as I do, that your new proposal works in all identified cases.
It's math. Doubt or opinion should not be involved.
> 2.
> Here is, then, a further explanation on the problem I see:
> - If a translation includes a last step that forces a single final result for
> two different intermediate results, *it cannot be reversible*.
> - Sec. 8 says "If the resulting value is 0xFFFF, it is changed to 0x0000",
> this applying to both translation directions as confirmed in the example.
> - Thus, two different original values of the 16-bit modified 16-bit word can,
> in the outgoing translation, give the same final value 0x0000. There is then
> no way in the reverse direction to determine which was the original value.
i.e. you want "you MUST NOT use a subnet of 0xFFFF with this method"
spelled out?
Example? take the one from 3.6, but with the subnet one lower:
FD01:0203:0405:0000::1234 -> 2001:0DB8:0001:D54F::1234
On the return path: 0x2AB0 + 0xD54F = 0xFFFF
(One's Complement Arithmetic isn't -that- hard, is it?)
regards,
spz
--
[email protected] (S.P.Zeidler)
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
