On Dec 15, 2010, at 10:39 AM, Christian Huitema wrote: > 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.
No problem. > 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. Which, btw, I disagree with. Privacy addresses are in essence 64 bit random numbers, and I don't see anything to prevent them putting 0xFFFF in the bit field. Unlikely, perhaps, but not precluded. > 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. Very much agree. Is there some text you'd like to see in the draft, or are you simply making a comment? _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
