2012/1/30 Rémi Després <[email protected]> > > 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 >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
