Hi, Remi: I don't think my case illustrates MAP-T needs to remain experimental, my comments are below:
2012/4/3 Rémi Després <[email protected]> > 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. > RFC6145 says in Section 6: "It SHOULD be possible to configure a translator for either of the two approaches", the first approach is that "IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be administered in compliance with Section 4.3.1 of [RFC4890]", the second approach is to change PTB MTU value to 1280 in case PTB<1280 and set DF bit to 0 in case the packet is less than or equal to 1280 bytes, if the requirements of the first approach can't be met. It doesn't mean the administrator can refuse to take the second approach according to his will. > > 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. > Actually, what I worry about is whether IPv6 packets of 4rd-U embedding ICMPv4 packets could traverse current IPv6 firewalls successfully. > > 3. > Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from > RFC6145, and therefore from MAP-T. > Please see Section 6 of RFC6145. > > 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 > In fact, MAP-T is clear enough to be deployed without any problems, if you read RFC6145 carefully. Regards, Guoliang > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
