Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant

[Maoke <[e-mail]>]

2012/1/30 Rémi Després <[e-mail]>

>
> and definitely there is no compatibility to single translation in RFC6145
> at all. as the result, RFC6145 provides a unified solution, while 4rd-U
> requires ISP (who prefer to use translation) disjointly deploy their
> networks for single and double translations.
>
>
>>
>>
>> If you have a specific configuration that illustrates your concern, it
>> could be discussed with more details.
>>
>
> Could you, for the sake of a less abstract discussion, describe at least
> one configuration you have in mind, in which some IPv4 addresses are
> statelessly shared, and in which there is the RFC6145 compatibility you are
> talking about.
> Without that, I can't figure out what you mean.
> (The goal remains customer service, without harm if this happens to be
> possible without full support of RFC4125, right?)
>

to my best understanding, one of the merits of the translation approach is:
when an end system changes its stack from ipv4 to ipv6, as long as the
ipv4-translatable ipv6 address is applied, its peers in the past can keep
using the same ipv4 address (as the temporal-unique identifier) to have
access to it. in other words, the stack-changing doesn't impact
already-existing peers, but enlarges the opportunity for the new
connections from native ipv6 peers. separating single translation and
double translation with deploying disjoint ipv4 (as well as corresponding
ipv6) spaces is meaningless in this term.

i think this is a clear-enough use-case but if i still make any confusion,
i may draw some pictures for you offline.

i have investigated, technically, what if we had updated RFC6145 with
carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv6,
specially for double translation, but i found 1) the necessity is weak,
according to the transparency check for RFC6145 end-to-end behavior in
double-translation; 2) it is impossible to make decision among alternatives
due to lack of knowledge about the remote stack (i.e. cannot distinguish
single or double translation with no state nor complicated dynamic
configuration); and 3) it is harmful to have ICMPv4 in IPv6 payload (as i
mentioned previously). my conclusion is: for RFC6145, it is a wise choice
to keep using a unified translation algorithm no matter the case is single
or double.

- M.


> RD
>