But encapsulation methods intended for endhosts wind up in middleboxes. Look at Cisco's RBSCP and WAAS (and the recently discontinued NCE), which already rewrite between SCTP and TCP checksums. Any new encap method blessed by the IETF must be considered for worst-case middlebox use - where rewriting stronger with weaker checksums and breaking end-to-end integrity will happen. It will pop up in middleboxes. This is why I prefer simple UDP tunnels. -----Original Message----- From: Fred Baker [mailto:fred@xxxxxxxxx] Sent: 27 April 2010 11:52 To: Wood L Dr (Electronic Eng) Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx Subject: Re: UDP encaps for SCTP and SCCP willing enough to use UDP-lite. BTW, I didn't say "change the encapsulation in some magic box in the network". I should hope that whatever encapculation is used would be used end to end. My point is "do those functions once". On Apr 27, 2010, at 11:37 AM, <L.Wood@xxxxxxxxxxxx> wrote: > Fred, > > advocating removing the interior protocol checksum across header and payload (and reconstituting/recomputing it afterwards) violates end-to-endidness and weakens the reliability guarantee. Bad idea. From a checksum perspective, you'd do better saying 'use UDP lite with a minimal check just across its own headers and pseudo-header' to decrease the computational overhead - that should be a fixed value. > > Using a UDP (or lite) port to indicate what is being done here with a particular weird encap, as well as the original ports on the interior packet, is something that this approach is stuck with, I think. > > Lloyd Wood > http://sat-net.com/L.Wood > ________________________________________ > From: Fred Baker [fred@xxxxxxxxx] > Sent: 27 April 2010 10:55 > To: Lars Eggert > Cc: bidulock@xxxxxxxxxxx; dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg > list; Wood L Dr (Electronic Eng); Michael Welzl > Subject: Re: UDP encaps for SCTP and SCCP > > From my perspective, I would prefer to run a native encapsulation rather than host it in UDP. If one wants a UDP encapsulation, I have no opinion on which of the choices to make, but I would suggest a characteristic you want to have. There is no point having UDP ports *and* SCTP/DCCP ports, and no point in having a UDP checksum *and* an SCTP checksum. I would recommend removing the duplicated functions from the interior protocol and relying on UDP's counterpart, even if it is inferior, as it will be more readily deployed. > > On Apr 27, 2010, at 10:42 AM, Michael Welzl wrote: > >> Hi, >> >> Okay, I herewith speak up: yes I want to see UDP encapsulation for >> both these protocols (but right now I'm not sure which one). >> >> Both SCTP and DCCP are useful - if there was no consensus on that, >> ever, these groups would never have been formed, and the protocols >> would never have been developed. >> >> Now, they are not used much (on the Internet involving NATs); at >> least DCCP isn't. That's a problem. UDP encapsulation is a way to try >> to solve this problem - and saying that we shouldn't do this because >> the protocols aren't used is a bit stupid, isn't it? >> >> To repeat this more clearly and bluntly: >> >> tool X isn't working well => noone uses it. >> So let's not fix tool X because noone uses it anyway. >> Hmmm... >> >> Cheers, >> Michael >> >> >> On Apr 27, 2010, at 9:47 AM, Lars Eggert wrote: >> >>> Hi, >>> >>> please keep this discussion focused on which approach we should follow for UDP-encapsulating DCCP and SCTP. >>> >>> I'm happy Lloyd posted his views. I'm hoping other community members >>> will speak up as well. If I were asked to characterize current >>> consensus, I'd probably say "disinterest for either approach." >>> (Which would be fine, but doesn't quite match the earlier feeling I >>> got from the community, i.e., that we do want UDP encaps for these >>> protocols.) >>> >>> Lars >> > > http://www.ipinc.net/IPv4.GIF > http://www.ipinc.net/IPv4.GIF
