Le 29 nov. 2011 à 22:55, Mark Townsley a écrit : > > My *principle* objection to anything other than basic encapsulation is that > it is not basic encapsulation. Plain and simple. > > I did say in the meeting that I didn't like anything that caused "destination > spray" but that wasn't my principle concern. It's great to know that 4rd-U is > actually immune to that concern. It's a very clever mechanism. > > But to the point of what I tried to convey in the meeting - my point was that > *if* the world would agree to move to 4rd-U and leave both basic encap and > NAT64 behind, then it would be to the good of all. One standard is better > than two or three in this case.
On this, we agree (supposing that it is the stateless double translation that may be "left behind" if 4rd-U is adopted, not the NAT64 of behave which won't disappear) > Failing that, I'd personally like to see basic encap as a MUST and anything > else as an alternative, though I admit that there are some that would like to > see NAT64 as the MUST and everything else as the alternative. > From my point of view (and now I think I am repeating what I said at the > microphone) is that when tunneling, basic encapsulation is very well > understood, consistent with RFC 6333 already defined in the softwires WG, and > that I could go to any operator in the world and say "tunneling via IP in IP > encapsulation" and they immediately understand what it means, pros as well as > cons. AFAIK, it is also easy to immediately understand that, for IPv4-across-IPv6 tunnels, IPv4 headers can be reversibly mapped into IPv6 headers having their fragmentation extension. This is just a tunneling variant. For 6rd, the same simple idea couldn't apply because IPv6 headers are too large to be be reversibly mapped into IPv4 headers. Encapsulation was then the obvious solution. But here we deal with IPv4 in IPv6, a simpler case. > Anything beyond this is an optimization. Perhaps a very worthy optimization, > but an optimization nonetheless. If the optimization is important enough to > override the ubiquity of simple encapsulation, fantastic, let's do that. If > not, let's keep it as an alternative. No, it isn't just "optimization" of the encapsulation solution: it satisfies operational requirements of double translation proponents, the only chance to have a single standard without forcefully ignoring these requirements. At this stage, the best is I believe to complete specifications of double translation, of encapsulation, and of unified, and THEN to compare and decide. Regards, RD > > > - Mark > > > On Nov 29, 2011, at 7:11 PM, Rémi Després wrote: > >> Le 29 nov. 2011 à 17:15, Ole Troan a écrit : >> >>> Remi, >>> >>>> For those who attended the Softwire session in Taipei, please note that >>>> the serious objection against 4rd-U expressed by several participants >>>> during the meeting has been, soon after, acknowledged to be invalid >>>> (www.ietf.org/mail-archive/web/softwires/current/msg03281.html). >>>> Also, other (less important) objections have been answered in >>>> www.ietf.org/mail-archive/web/softwires/current/msg03284.html, without >>>> reaction so far. >>> >>> I do not think that's a fair representation. >> >> It was intended to be one, and is still believed to be so (see below) >> >>> the main objection to 4rd-u is that it is 'just another translation' >>> solution. >> >> a) >> That's not what I heard during the meeting. >> Both Mark Townsley and Dave Thaler, taking for granted your statement that >> checksum-neutral addresses of 4rd-U would cause "address spray", said firmly >> that 4rd-U should be rejected because it wouldn't work. >> >> In my understanding, not working is a show stopper, which I call a "main >> objection". >> >> b) If your main objection is that 4rd-U would be 'just another translation', >> it is ALSO invalid. >> If you have read my answer to your list of objections, you should know that >> 4rd-U is a reversible-header-mapping solution, and as such is based on >> neither translation nor encapsulation. (actually a tunnel closer to >> encapsulation in my understanding). >> >> >>> how many do we need? >> >> Many consider that, if there is the choice, ONE standard is better than >> several. >> >> The point is that 4rd-U combines advantages of double translation and >> encapsulation with only a slightly different tradeoff between optimizations >> of header-length and processing time. >> >> Doubts are legitimate as long as the specification is incomplete, but that's >> why more work is needed. >> >> >>> it doesn't appear to offer any benefits compared to the already specified >>> solution. >> >> Which solution? (So far, there are two in the pipe - translation and >> encapsulation.) >> Meeting requirements of both solutions is AFAIK a benefit. >> >> >>> as it stands it will just result in 3 ways of doing the same thing, instead >>> of 2. >> >> Different view on this. >> Three standards would make no sense. >> >> >>> the topic discussed in softwires, wasn't the main objection. as far as I >>> can see, "checksum neutrality" does not offer any advantages over >>> incrementally updating the L4 checksum. >> >> Again, commenting my previous answer to your list of objections would be be >> more constructive than repeating that 4rd-U doesn't do anything without >> arguing on substance. >> >> Since there is no obligation to comment, please refrain from criticizing a >> solution without commenting previous answers made for you. >> >> >>> every node doing this will have to look into the L4 header anyway. >> >> Sure. IPv4 address sharing implies _looking_ at port fields (true also for >> encapsulation). >> >> But this doesn't imply that L4 data need to be modified, especially if >> these modifications need to depend on whether the protocol is TCP UDP, DCCP, >> etc. >> Encapsulation and reversible header mapping don't care about this, which is >> one of their virtues. >> >> Cheers, >> 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
