Congxiao, None of what follows leaves AFAIK what would be a flaw preventing operational deployments to be successful. Yet, thank you for this clarification of your understanding. Unless you wish to pursue, this is enough for me.
Le 2012-04-04 à 04:35, Congxiao Bao a écrit : > Hi Remi, > > 2012/4/2 Rémi Després <[email protected]> >> >> Hi, Congxiao, >> >> During the Softwire meeting, you came to the mike to assert that the 4rd-U >> specification was known to have "flaws". >> >> > > Yes, I said that and I insist on saying that again today. >> >> >> >> >> Yet, you do know that the 4rd-U specification has been reviewed by competent >> contributors of widely varied origin, with no identified flaw left in the >> draft. > > That's NOT true. What I can see in the mailing-list before and after > WG meeting is that many points which indicated that 4rd-U are flawed > have been raised by the MAP-E/T authors and DT members, like Maoke, > etc, and several operators. I am sorry to say that even though they > repeated the same arguments several times, you ignored their > statements and said there is no identified flaw left. > > I have to say this makes the discussion in the mailing-list without > efficiency, even the conclusion is OBVIOUSLY clear. > >> >> >> Since you have AFAIK made no previous contribution on the mailing list to >> justify such an assertion, would you be kind enough to explain what, in your >> understanding, wouldn't work in 4rd-U? > > For my perspective, 4rd-U is not on the same level compared with MAP > for the technical maturity if we freeze the current version of MAP > Series and 4rd-U. The MAP series are the extensions of existing RFCs > and have well tested running codes, while 4rd-U redefined things in > existing RFCs and have not been tested. Per your request, I can > summarize my check list here, some have been already shown in the > mailing-list, > hopefully I don’t need to repeat the same arguments > again in the future: > > (1) 4rd-u tries to replace MAP-E, however, 4rd-u cannot support IPv4 > option. In the case when perfect IPv4 transparency is required, MAP-E > cannot be avoided. No ISP I know justifies having two standards just because of IPv4 options. IPv4 options have never been a requirement of Softwire stateless solutions, and shouldn't therefore be claimed to be a flaw. > (2) 4rd-u tries to replace Map-T, however, 4rd-u is not compatible > with IPv4/IPv6 single translation. For the networks which also deploy > single translation, MAP-T cannot be avoided. False. 4rd-U clearly can coexist with NAT64 and with BIH which are both single translation. This isn't an identified flaw. > For example, the web > caching in the IPv6 only network between BR and CEs requires single > translation mechanism, which 4rd-u cannot support. 4rd-U does support web caches AFAIK. Unless you provide evidence of this assertion, this doesn't make an identified flaw. > Don’t mention BIH, > if you want to combine BIH, 4rd-U is not the Unified solution as you > claimed. > > (3) 4rd-u changes the IPv6 header architecture (redefine fragmentation > header extension) and IPv6 address architecture (u/g-bits), the later > conflicts with RFC4291. A backward-compatible extension has always been one of the approaches to make progress (in this instance, a clear and simple use of an existing escape combination and of some unused bits). This isn't an identified flaw. > These are the fundamental changes, which needs > the proof from 6man. The experimental data should also be presented to > show this design is not harmful. > (4) If 4rd-u becomes the standard, then there will be new defined > “IPv6.1” packets on the Internet (new meaning of u/g-bits, new defined > fragmentation header, new type of ICMPv6, etc, more details in (6) and > (8)), and no existing IPv6 devices can understand those packets. The draft says what needs to be said. - No need for any IPv6.1! - No problem with any existing IPv6 device has been identified This isn't an identified flaw. > (5) 4rd-u is designed to achieve better transparency compared to > MAP-T, however, it only addresses a corner case (DF=1 and MF=1) and > the experimental data indicates that there is only 10e-5% of such > packets and those packets are not representing normal traffic. The > experimental data of 4rd-u deployment should be presented to show that > your redefinition of (3) and the risk of (4), is worth bringing the > benefit of just addressing to this corner case (DF=1 and MF=1). This point isn't describing a (supposed) flaw. > don't think the corner case can make significant difference to the > user experience. Further more, can you give me the use case of that > corner case? The benefit is a one standard instead of two (as transparent as E and as open to IPv6-only O&M as T). > (6) In order to address corner case (DF=1 and MF=1), 4rd-u always > inserts the IPv6 fragmentation header and overload the ID field (DF, > TTL, TOS). The IPv6 fragment header has been shown to cause > operational difficulties in practice due to limited firewall > fragmentation support. The same applies to RFC6145 when it adds a fragment header. If this would be a flaw, it would apply also to MAP-T. > In addition, the packets with MF=0 and Offset=0 > are "atomic fragments", this issues is under discussion in 6man and > likely requires the OS and security updates > (draft-gont-6man-ipv6-atomic-fragments-00). Furthermore, if an IPv6 > packet, which contains fragmentation header and the ID has “DF set by > the definition of 4rd-U”, reaches a 4rd-U end point, it will be > translated to IPv4 packets with DF=1, and the DF transparency may be > lost. The experimental data should be presented to show this design is > not harmful. > > (7) 4rd-u tries to add checksum neutral hex in the address, however, > it still cannot support new transport layer standard when NAT44 is > used. If this would be a flaw, it would apply also to MAP-T. > > (8) New types of ICMPv6 defined by 4rd-u needs the update of RFC4443. > The existing IPv6 firewall cannot support it. No new ICMPv6 type is defined AFAIK for 4rd-U. Cannot therefore be claimed to be a flaw. > (9) 4rd-u tries to reinvent the wheel by defining new schemes in > IPv6, just for the IPv4 to IPv6 transition and only addresses corner > cases. I wonder if this is worth the huge cost even the technical flaw > could be removed. The lessons I learned in Behave and v6ops is that > changing IPv6 architecutre which can only be used for the IPv4 to IPv6 > transition is a bad idea and harmful. This is a comment, not identification of a (supposed) flaw. >> Without that, your statement might be understood as an attempt at biasing >> people's understanding just before a vote (which I suppose you didn't want). > > On the Friday’s meeting, I just want to speak out my own option and I > would like to say it again here: > For a reasonable ISP, it pursues > simple (single) solution for sure, but FIRST of ALL, that solution > should be technically Correct. Agreed. > Considering both the previous > discussion in the mailing-list (before the WG meeting) and on-site > discussions before the open MIC, and the first run of concensus, I > strongly believed that the rough consensus has been reached: MAP is > superior to 4rd-U. Even for the second run of consensus, MAP still > stands out (25 to 12). I have been told 25 to 13, but in any case substantial support for both. Tom Taylor's initial perception does confirm that there was no rough consensus. > Please respect those audiences on site, who > understand MAP series and 4rd-U, they raised their hands for MAP > representing their neutral technique position, which of course can not > be biased by me. Of course, understanding MAP doesn't imply understanding also 4rd-U. Your comment was to disqualify 4rd-U for those who didn't know it yet. I respect ALL participants (but find it a duty to rectify invalid arguments, i.e. to do normal standardization work). > Please also note that on the mailing list, many > people present their comments, that sould wait more than the hands > (without voices on the mailing list) in the meeting. Applies also to 4rd-U, in particular with 3 co-authors absent in the Paris meeting. Regards, RD > > Regards, > > Congxiao > >> >> >> Thanks, >> RD >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
