Maoke, Please see in line.
Le 2012-04-03 à 11:21, Maoke a écrit : > 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. Although I tried, I cannot share your interpretation: - sec 6 introduces a problem due to some Host/FWs that don't support IPv6 PTB<1280 (although they should) - Two approaches are proposed. - The second one looses the IPv4 MTU information if < 1280 (creating a problem for PMTU discovery in IPv4) - The first one isn't described, but consists in avoiding the problem, apparently by ensuring that all host/FWs support PTB<1280. Implicitly, this can be understood as no replacement of <1280 by = 1280. Anything missed? > (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. If you have something in mind, please detail. AFAIK, it isn't difficult in a ISP domain to make sure IPv6 packets are transparently transmitted between BRs and CEs, even if their next header is 1 (that of ICMPv4). > > 3. please refer to RFC6145 Sec 6 for the details (but maybe other sections > are also needed to read). See 1. above. > i think your objection to RFC6145 and MAP-T here is invalid. Not convinced by your comment. Besides, even if it would be the case, the mail to which I was answering below was proposing to always change DF=1 into DF=0, instead of just in the fragmented-pcket case. To me, this illustrates that MAP-t specification isn't so easy to understand where it deals with details of ICMP v4/v6 translations. Criticisms addressed to 4rd-U should be more carefully studied before being made. Regards, RD > > regards, > maoke > > 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. > > 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
