Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

[Rémi Després <[e-mail]>]

Le 18 oct. 2011 à 04:37, Maoke a écrit :

> hi Remi, 
> 
> 2011/10/18 Rémi Després <[e-mail]>
> Hi Maoke,
> 
> On 2011/10/12, you wrote:
> "... considering the double translation is a case of translation. it is possible that a src host with an IPv4-translatable IPv6 address generates a fragment header with a 32-bit identifier happening to have the first 16 bit as either 0x8000 or 0x0000, making a fake D bit in your current proposal."
> 
> An important point is that the IP identifier needs to be unique ONLY for each <SRC, DST> pair.
> If 4rd addresses are deterministically recognizable (with the V octet in bits 64-71), there is no risk of confusion with an IP identification generated for another purpose than 4rd.
> 
> thus i understand. then you didn't try to decouple the header processing from the mapping algorithm, right? sorry but i was confused here. :P

The 4rd-U header format builds on a useful property of the address mapping algorithm, the fact that <SRC, DST> pairs of 4rd packets are distinguishable from those of native IPv6 packets.
Other than that, it doesn't depend on any particular address mapping. 

With RFC 6052, for instance, addresses that have the well-known or network-specific prefixes are recognizable as being IPv4-embedded addresses? They are therefore compatible with the 4rd-U header format. (It remains that the V octet is AFAIK easier for O&M, and permits to have the same CE IPv6 prefix for native IPv6 and embedded IPv4, a useful property for some use cases).

I should have made this clearer, thanks for your remark. 

Cheers,
RD