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. (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. For example, the web caching in the IPv6 only network between BR and CEs requires single translation mechanism, which 4rd-u cannot support. 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. 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. (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). I 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? (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. 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. (8) New types of ICMPv6 defined by 4rd-u needs the update of RFC4443. The existing IPv6 firewall cannot support it. (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. > > > 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. 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). 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. 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. 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
