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. That may be OK in practice, e.g. create deployment rules that reserve one of 0 or 0xFFFF for internal only operation. 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. I do not like that suggestion, because it makes assumption on the structure of the host identifier that are difficult to control. 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. 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. -- Christian Huitema _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
