2012-04-03 14:43, guoliang han : > 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.
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) > 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. > 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. Regards, RD (retransmitted after deletion of unnecessary old text, message too big for the ML!) > > 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
