On 25 jul 2008, at 7:23, Pekka Savola wrote:
If you choose a prefix that is supposed to be "well known" (used by all implementations), you could overload the existing use of mapped addresses, or choose something else altogether. Given that you can't depend on the existing behaviour of mapped addresses anyway, if you go this "fixed address block" route, the least astonishing failure modes could be achieved with a new special prefix.
Right.
If you don't signal anything, the result is that you spew out packets with the mapped addresses with the assumption that there is going to be a translator somewhere along the path that's going to do something to them.
Right.
Otherwise they end up transiting enterprise and backbone networks and potentially arriving at the destination which does something unexpected
No, if there's no translator the packets won't end up at the destination because the mapped prefix isn't routed on the v6 internet.
What seems to be missing is a good way to signal the prefix and some modifications to API calls. As demonstrated, stack modifications are already needed (at least in API handling), so why not do it all the way?
Because I don't think we'll see those modifications in wide use by the time we neet NAT64. If we can do something reasonable with no modifications and something that's actually good _with_ modifications that is a much stronger deployment model than to require modifications before anything can happen. Then again, if there's strong consensus that the modifications can/will/should be made within a farly short time, we can do more.
As a source address, if the node(s) on link are also provided with real IPv6 addresses, this would be indistinguishable from source address spoofing.
Only translators would transmit packets with v4mapped source addresses, so this isn't much of an issue.
(I thought the mapped addresses would have been used between a host and a translator -- or, if there doesn't happen to be translator, the packets would end up in the destination network. But maybe not..)
The source host would use a normal, global v6 address as the source, so no problem there, and a mapped address as the destination. This will either flow towards a translator or be dropped on the floor somewhere because there is no route for ::ffff:0:0/96. It won't reach the destination, because no _hosts_ have an IPv4 mapped address in its IPv6 form configured on an interface. The destination only sees IPv4 addresses.
In the direction from the translator to the host you'll see the mapped source addresses but obviously, these packets will match previous outgoing packets so they can be filtered statefully.
So we're required to trust that anyone running a translator in the Internet is honest netizen?
Well, if you don't trust someone, don't give them your packets. This is the same whether or not they run a translator. Or you can apply HMAC protection in the form of IPsec or TLS so the untrusted network can no longer do bad things to your packets except make them disappear.
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
