Hi, Remi: Pls read my comments below. 2012/4/3 Rémi Després <[email protected]>
> > 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) > 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. > > 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. 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. >> >> > > >> >>
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
