dear Remi, 1. for this issue, you are in misunderstanding.
i checked the RFC6145 logic and behavior, very carefully, with the PTB < 1280 issue. there is no two behaviors but only one behavior supporting independent working of the IPv4-to-IPv6 and the IPv6-to-IPv4 translators. there is no question on which one to choose in the MAP-T draft. (i think you may accept that a "if...else..." logic does not mean option). 2. it is necessary to verify, in practice, if the feature that IPv6 is carrying ICMPv4 message is secure. it is new to the IP/ICMP architecture. 3. please refer to RFC6145 Sec 6 for the details (but maybe other sections are also needed to read). i think your objection to RFC6145 and MAP-T here is invalid. regards, maoke 2012/4/3 Rémi Després <despres.r...@laposte.net> > Hi, Guoliang, > > Interesting enough, the example you give illustrates that MAP-T needs to > remain experimental, more than any other solution. > > 1. > RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=1280. It > specifies two behaviors, one that does this, and one that doesn't. Which > one to choose isn't AFAIK specified in the MAP-T draft. > > 2. > With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged. > This is exactly what is necessary for PMTU discovery to work. > > 3. > Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from > RFC6145, and therefore from MAP-T. > > When we have a detailed report on which parts of MAP-T have been > validated, with which options of RFC6145, it will be easier to analyze > scenarios like the one you propose. > > > In any case, thanks for providing one more evidence that the MAP-T > specification isn't as clear as claimed to all those who support it, and in > particular to some also criticize 4rd-U with invalid arguments. > > Regards, > RD > > > Le 2012-04-03 à 05:26, 韩国梁 a écrit : > > +1. > > As a follower of MAP team, I participated much in developing and deploying > double-translation in CERNET. As far as I am concerned, in the translation > scenario, > 4rd-U only solved some corner cases but missed some other cases > simultaneously. > > As an example, I suppose one fragmentation case as following: > > (IPv4 customer network)--CE---(IPv6 access network)--BR(Core > Translator)--(IPv4 network)---IPv4 host > > The minumum MTU of IPv6 access network is 1400, and the minimum MTU of > IPv4 > network on the right side is 800. Now an IPv4 host on the left side sends > a packet > with length set to 1200 and MTU set to 1, to the IPv4 host in the right > side. The packet > could traverse the IPv6 access network, but will be blocked in the IPv4 > network. > In this case, BR(Core Translator) must set DF to 0 when translating from > IPv6 back to IPv4, > instead of preserving the original IPv4 DF bit. > > In fact, according to RFC6145, if BR(Core Translator) receives an ICMP > Packet Too Big packet > whose indicating MTU is less than 1280 bytes, it will change it to 1280. > So if the BR preserve > the DF bit, the sender will always believe the path MTU is 1280, which > will certainly lead to > a black hole. > > This is only one deployment problem, and we don't know how many issues > will be encountered > in the future. So my point is that 4rd-U still needs examination in the > actual deployment, and > it's a bit early to propose it as an Informational/Standards Track > Document. > > The mail sent yesterday seemed to encounter some problems. So if you see > this mail twice, sorry for that. > > regards, > Guoliang > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
