Le 2012-02-01 à 03:04, Maoke a écrit : > > > 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,
If it is on a V6-only network, isn't the end system already dual stack? Then, if it needs to be reachable in IPv4, why would it change IPv6-only while the 4rd service remains available? RD > 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. ...
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
