Re: [Int-area] practical issues with using v4-mapped addresses for nat64

[Iljitsch van Beijnum <iljitsch at muada.com>]

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
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area