Le 15 déc. 2010 à 19:39, Christian Huitema a écrit : > So we seem to agree that if we want to adjust for checksum neutrality by > changing the 16 bit subnet number (bit 48-63), we cannot have both subnet 0 > and subnet 0xFFFF.
Yes. > That may be OK in practice, e.g. create deployment rules that reserve one of > 0 or 0xFFFF for internal only operation. Since this restriction can be easily avoided, keeping it would a criticizable design. Here is a the proposal to avoid it. (a) NPTv6 discards packets whose translatable addresses has IIDs start with 0xFFFF (with returned ICMPv6 error messages) (b) It always makes its checksum adjustments in address bits 64..79. (c) In both directions, if the computation of the adjusted field gives 0xFFFF, this value is replaced by 0x0000 It isn't proved that, in practical NPTv6 configurations, the replacement of 0xFFFF by 0x0000 is needed in the outgoing direction, but: - At least it doesn't hurt. - The symmetry of the replacement rule can be viewed as a simplification of the specification. - Even if NPTv6 might be cascaded (a subject I would prefer to leave aside at this stage), this ensures that adjusted IIDs would also never start with 0xFFFF. (The fact that the replacement applies to both directions is a change from the initial proposal.) > In any case, we should have a more prominent discussion of the issue than the > single line statement in the current draft. > > Rémi proposed an alternative where we adjust for checksum by changing the > bits 64-79, on the rationale that the value 0xFFFF is not encountered in > practice in these bits. More than their being "not encountered in practice", it is that host IIDs starting with 0xFFFF are formally precluded. (Fred said in another mail that they are "unlikely, perhaps, but not precluded" because of privacy addresses. But this was overlooking that privacy addresses can never start wit 0xFFFF (their bit 6 is always forced to 0). > I do not like that suggestion, because it makes assumption on the structure > of the host identifier that are difficult to control. In my understanding, checking that a precluded IID value isn't used fits with the general idea of prevention against error propagation. Ensuring that a subnet ID which is otherwise permitted isn't used when NPTv6 is activated is likely to create operational problems. Note in particular that all subnet values are permitted with a NAT66 that isn't NPTv6 (an NAPTv6). > We cannot exclude that some device manufacturers or some software developers > will come up in the future with host identifiers that falsify Rémi's > assumption. When that happen, the failures will be very hard to debug and fix. NPTv6, when having to translate an address whose IID starts with 0xFFFF should, as usual, drop the invalid packet and return an ICMPv6 message with an error code. This code should signal an invalid IID format. > They will trigger a butting of heads between the site admin who deployed the > NAT66, the local user whose device does not work, the manufacturer of the > device and the developer of the software. In contrast, a simple rule like > "reserve subnet 0xFFFF for subnet that will not cross the NAT" is entirely > under the control of the site admin, thus much less likely to cause > operational problems. I don't see that: - Bugged IID formats are easy to detect, and are likely to be also detectable by other functions than NPTv6. - I foresee more butting of heads if the 0xFFFF subnet prefix, perfectly legitimate without NPTv6, is forbidden with it. (Keeping designs simple and orthogonal generally simplifies operations). Conclusion: I still hope that my proposal, updated as above, will be understood as a constructive one, and as one whose sole purpose is to improve IETF originated designs. Regards, RD _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
