Hi, Margaret and Fred, 1. Your draft-mrw-nat66-00 says: (a) "If the resulting value is 0xFFFF, it is changed to 0x0000" (sec. 8, second paragraph) (b) "NAT66 devices with more than one internal interface SHOULD assign a (non-0xFFFF) subnet number to each link" (sec. 11 last paragraph)
I found in the draft no technical justification for these rules, so that: - The reason for (a) remains obscure to me. - Constraint (b), if it is the right one, should apparently not depend on the number of NAT66-device interfaces. After I pointed out in 2008 that address-mapping reversibility wasn't achieved in your first proposal (draft-mrw-behave-nat66-00), you have added (a) and (b), presumably to achieve reversibility this time. But, until you would provide TECHNICAL REASONS showing how (a) and (b), 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. (For new readers to understand where the problem comes from, UDP/TCP checksums use 1's complement arithmetic, and this arithmetic has two representations of 0 (+0 and -0). With it, when X is added to Y, the result Z=X+Y is the same for X=+0 and X=-0. The difference between two values of X is therefore lost in this case. The reverse computation X=Z-Y, depending on how the computation is made, can give in this case either X=+0 or X=-0. The choice of +0 or -0 is free provided it is 0, and has in any case no relationship with the original value of X.) 2. In view of the mathematical complexity of this problem, and in view of the following, it is unclear that the energy to be spent to rigorously check what works and what doesn't is worth spending (we have so many useful problems to solve): - "stateful NAT66" doesn't have this problem - It apparently satisfies those that claim they do need NAT66. Sorry not to be more in agreement with your draft, but this is intended to be useful to the community. Regards, RD _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
