![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Mon, 1 Dec 2008, 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?
I'd really hate to have address 32.116.104.101 (" the")....
Such devices can't possibly survive, can they?
Aghast,
--MM--
-------------------------------------------
Matt Mathis http://staff.psc.edu/mathis
Work:412.268.3319 Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.