Le 2012-04-01 à 00:15, Maoke a écrit : > hi all, > > i listented to the softwire wg live on March 30 online and recorded my > comments in the jabber room. as the person who was mentioned by the presenter > not less than twice, i have to point out that it is unfair that the presenter > mentioned me with only acknowledgment to my effort but my point of views.
I acknowledged that some of the recent progress to complete 4rd-U was due to the technical quality of our dialogue on the ML (... even if sometimes more aggressive than really needed). I thought it was fair to say it. Sorry if the words I used seemed unfair to you. Please be sure the intention was the opposite. > my summerized comment on 4rd-u is: > it is flawed in both architecture and technical aspects, Which ones? > and now still uncertain in several details. Which ones? I confirm that, in my understanding, all points that were argued with technical substance, had been dealt with in 4rd-u-06. This is not to negate that you wrote in your last answer, as anyone can verify: "with your newly proposed solution, yes, IPv4 TTL is fine. but on the other hand, the IPv6 also needs TTL(HopLimit)=255 to protect something. we have to concern if 4rd-u possibly introduces some new measures for the attackers breaking such kind of protection mechanism, as putting the first bit of IPv4 TTL into IPv6 HopLimit CHANGES the semantics of IPv6's HopLimit!" Frankly, I don't understand the new objection: "concern if 4rd-u possibly introduces..." is IMHO an incitation to FUD, but not a technically justified issue. If you can detail what you mean, with a point an experiment might reveal, dialogue will continue. Without that, I don't understand what you mean. > it would become as a ridiculous and weird record in the ietf history, had > the wg made a decision of putting two as experimental, That was Alain's plan in case no consensus on a single standard would emerge. It was expressed on the ML well before the meeting. You didn't object to it then, did you? > one is well-understood, This "one" obviously being, in your opinion, MAP-T+E, but: a) The need for disjoint packet IDs form shared address CEs is still uncovered in MAP-T. b) The MAP-E specification is claimed to work in hub-and-apoke topology, but when a BR receives an IPv6 packer, "If the CE IPv6 address is equal to the IPv6 source address in the received IPv6 packet, BR decapsulates the IPv4 packet and then forward it via the IPv4 interface." c) It has been said during the meeting that, in the tested double-translation implementation, BRs compute UDP checksums of IPv4 datagrams when not computed by sources (Null checksums). Nothing is specified AFAIK specified in the MAP-T document. Is it a MUST, a SHOULD, a MAY? d) The hub-and-spoke domain parameter, which is needed as Ole acknowledged on the ML, is still not documented in MAP. (Very easy to fix, of course, but a sign that there is still work to be done to have a clear specification.) e) The Port Parameter option of MAP-DHCP specifies 3-bits "offset" AND a 16-bit "excluded-ports". Which combinations of these values have been actually tested? Why to have "excluded-ports" if there is an offset parameter? If these remarks can help E+T proponents to improve their approach, good, but my interest here is ONLY to make WG members understand that MAP-E+T isn't the well specified design it is sometimes claimed to be. > well-coded and well-practised A list of once practiced mapping rules for each representative configuration (for T AND for E, and for mesh AND hub-and-spoke) is still missing to support this assertion. > while the other is misleading the understanding on the Internet architecture, If it is a reference to the V octet of 4rd-U, none of the experts I talked to others than MAP-T+E strong proponents has found any architectural problem. (It is new, yes, but is also backward compatible with existing RFCs. No misleading.) If it is a reference to something else, please explain. > not yet coded, not yet tested by any operators. Fair enough, but when Free decided to deploy 6rd, there was not even a document describing it! Yet, it has been the most effective step toward IPv6 availability on a large scale. Understanding the specification was found sufficient. Conclusion: clear theory is sometimes more convincing than "I ran a successful experiment". > our company, as an ISP and as a provider doing also application services, > including those over mobile platforms, is waiting for the MAP standard > desirably. > we have no interest in introducing the 4rd-u elements into our platforms. Fair enough, but standardization is a collective effort. Regards, RD > personally i won't code a stuff with obvious architectural flaws but, if i > were believing in the 4rd-u, i would do the code and operational test with > serious self-checking as MAP-T and MAP-E teams already have done, before > talking on any doc-track issue with the community. this is the way of being > responsible. > > thanks, > maoke > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
