Le 2012-04-03 à 15:41, Guoliang a écrit : > Hi, Remi: > > Pls read my comments below. > > 2012/4/3 Rémi Després <despres.r...@laposte.net> > > Le 2012-04-03 à 14:43, guoliang han a écrit : > >> 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 <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. >> >> >> 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. > > Typical use cases of 4rd-U have no firewall between BRs and CEs. > If some would exist, they should be configured to let ICMPv4 payloads go > through (Protocol = 1) > This is like configuring them to accept IPv4 headers in IPv6 payloads > (Protocol = 4) > > Hope so. Still anticipating experimental results proving that yet. > > > >> 3. >> Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from >> RFC6145, and therefore from MAP-T. >> >> See Section 6 of RFC6145. > > This isn't in RFC6145, simply a reference to (*) below. > If I misunderstood, please explain what. > > You surely misunderstood that. I mentioned "in that case", instead of > replacing DF=1 by DF=0 in all cases. Replacing DF bit only occurs in the case > that incoming packet size is less that 1280 bytes, which is exactly the > requirement of RFC6145.
The so called "corner case" where RFC6145 looses the DF=1 is when a packet with DF=1 is already fragmented by its source. In this case, because there are several fragments, translates back to IPv4 with DF=0. In the example you give, RFC6145 doesn't add a fragment header, in the IPv4 to IPv6 translation because the packet has DF=1 and isn't fragmented (sec 4). The inverse translation, seeing no fragment header, the DF bit is normally set to 1 (sec 5.1). (A configuration option is mentioned so that the node MAY set it to 0 in some conditions, but MAP-T makes clear this must not be the case: "the IPv4 packets with DF=1 will be translated to IPv6 packets without fragmentation header and will be translated back to IPv4 packets with DF=1".) >> 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. > > Replacing IPv4 PTB<1280 by IPv4 PTB=1280 should AFAIK be avoided for IPv4 > PMTU discovery to work. > Still waiting for a clarification on this issue. > > If the translator set DF bit to 0 in case the packet is less than or equal to > 1280 bytes, and replace PTB<1280 by PTB=1280, there are no problems on the > data path, whether in single/double translation. In any case, not a MAP-T feature. RD > > Regards, > Guoliang > > > Regards, > RD > > > > >> >> 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
