dear Remi, sorry but your change of the title of this thread is misleading. i mean: no change to RFC6145 needed for practice of operation. my observation on the ICMP transparency of RFC6145 in double translation is relatively independent, without much relationship to 4rd-U. well, the only connection is: 4rd-U REQUIRES IPv6 carrying ICMPv4 messages without translation.
2012/2/2 Rémi Després <[email protected]> > > Le 2012-02-01 à 03:04, Maoke a écrit : > > ... > > 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, > > > Introducing ICMPv4 messages in IPv6 packets "instead of" ICMPv6 messages > in RFC6145 would be an incompatible change. > I don't think anyone proposed that. > > What might be envisaged without the same backward incompatibility, is that > IPv6-only hosts would accept in IPv6 packets BOTH IPv6 ICMP messages and > ICMPv4 messages. > > Yet, it remains to be analyzed whether it would be useful in real world. > > This depends on a detailed use case being identified, where double RFC6145 > translation would have a substantial advantage over the header-mapping > variant of 4rd-U-03 (4rd-H). (This advantage would have to compensate for > the loss of IPv4 transparency as good as that of 4rd-E, and for the loss of > the tunnel-specific traffic class which can be used in 4rd-E.) > > This use case, key for this discussion, is subject of another e-mail > thread. > i (and others) have tested the single/double-compatibility in practice and confirmed it is useful at least for some users. another mail thread might fall into pure philosophical debate, which is not preferred, especially considering that carrying ICMPv4 in IPv6 is not secure. in other words, even if the philosopher had thought the compatibility with single translation was useless, he'd better not to deploy the IPv6 network carrying ICMPv4 payload without IPv4 header encapsulated. - maoke > > RD >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
