Thanks Colin, I agree with your rationale but I wonder if we need to support every broken device out there. In any case, if we have to, I prefer to require encryption than to add the XORED address option. I'd like to hear what people in MEXT think about this, comments from MEXT? Hesham On 1/12/08 9:13 PM, "Colin Perkins" <csp@xxxxxxxxxxxxx> wrote: > On 1 Dec 2008, at 09:00, Hesham Soliman wrote: >>>> => Well, I'm not sure how a NAT can do that. You mean the NAT will >>>> parse the binding update message deep inside the IPv6 extension >>>> header in the inner IP packet? This is where the original address >>>> is preserved. To do that, a NAT would have to understand the >>>> various MIPv6 options, and if it did, it would know not to do >>>> that :) The inner header is IPv6, so a NAT should not touch that. >>> >>> My understanding from the STUN work is that NATs have been observed >>> which rewrite any sequence of four aligned bytes matching the source >>> IP address, irrespective of its location within the packet (section >>> 15.2 of RFC 5389). >> >> => Sounds freightning! May be we need to mandate encryption and >> hope that no 4-byte sequence matched the IP address? What do they >> do with encrypted packets? How do they know they're encrypted? > > One would assume these broken devices will potentially corrupt > encrypted packets, the same as they will potentially corrupt any > other packet. Hiding the source address when it appears in the > payload (either by encryption, or using some trivial obfuscation as > does STUN) simply reduces the probability of such corruption so it's > no longer 100% guaranteed that the payload will be mangled. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf