Tom P. >From a quick glance to your message, it is not clear why one would need or want IP tunneling from end-node to end-node in this case - sorry if I missed the explanation. Both Inner and Outer IP headers seem to have the same IP addresses, if I get it right. Is perhaps the role given to IP tunneling just to have "some" header as a separator between the UDP header and the SCTP header? On using UDP just to encapsulate a transport packet, While thinking out loudly, I will go back to the basics. UDP has three functions - (1) identify the end points of Communications - port numbers, (2) ensure end points and data integrity - checksum, and (3) define/carry an atomic datagram - datagram length. The duplication of functions with SCTP has been recognized already as a fact. UDP is being given the role, or function of bypassing NATs, who seem to be agnostic of SCTP/DDCP - this has nothing to do with the basic functions of UDP, but rather with the shortcomings of NATs.... I imagine the IPv6 guys would have something to say about this... I wonder if any of the two drafts is going to be on the Standards track. Regards, Alex Conta > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx] > Sent: Tuesday, April 27, 2010 1:46 PM > To: Alex Conta; L.Wood@xxxxxxxxxxxx; fred@xxxxxxxxx > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx > Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it? > > > Hi All, > > Well, quite a few issues have been brought up here. Here are > my thoughts on one of them. > > Why not just tunnel it? "Just tunnel it" means IP header/UDP > header/inner IP header/"real" transport header. The problem > here is in the addresses in the inner IP header. > > In most uses of IPv4 tunneling, the tunnel endpoints either > both have public IP addresses or they both exist in the same > private IP address space. This provides a coordination of > the inner addresses such that they are meaningful to both the > sender and receiver. In these conditions, DCCP can be > tunneled just like everything else. > > However, there are many situations where these conditions > don't apply. One very common situation where these conditions > don't exist is when the client, managed by one organization, > is in a private address space behind a NAT and the server, > managed by another organization, is in the public address > space. This situation, and the several variants that are > possible, are more the target of the DCCP encap draft. > > In the private-client-nat-public-server configuration, the > client will initially set the outer and inner source > addresses to private addresses (possibly the same address for > both, possibly different). The NAT will change the outer > source address to a public address, but not the inner. When > the inner packet is extracted at the server, the inner source > address will be meaningless (and leaks information that is > normally held private). On the return path, it'll be the > destination address that's meaningless. > > You can imagine many ways that the client can set inner > addresses to values that would mean something to the server, > but it's difficult to see how the server could set the inner > addresses meaningfully without having the client's private > address leaked to it (define a "neutral" address space?). > > But if you do solve the inner address meaning problem, what > have you gained? Nothing, I believe. The inner addresses > are fundamentally useless. So why carry useless fields? > Make it IP header/UDP header/transport header. This is the > approach all three current drafts take. > > Tom P. > > > > -----Original Message----- > > From: tsv-area-bounces@xxxxxxxx > [mailto:tsv-area-bounces@xxxxxxxx] On > > Behalf Of Alex Conta > > Sent: Tuesday, April 27, 2010 9:54 AM > > To: L.Wood@xxxxxxxxxxxx; fred@xxxxxxxxx > > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx > > Subject: RE: UDP encaps for SCTP and SCCP > > > > IMHO, what should drive the use or no use of UDP is "the > need and use > of > > UDP functons", rather then "the need to make the SCTP and SCCP more > > popular because of using a popular transport". Perhaps I am not > reading > > right the motivation, but I somehow get that frm the thread > - sorry... > > > > Which is to say that I agree with Fred's concern 100% about > duplications > > of functions. > > > > I would perhaps even go a little further, if the > counter-argument is > > that with "UDP lite", there is a minimization of > duplication, and that > > is: > > > > my concern would be that besides the dupplication, there is some > > additional burden in processing a packet that has mutliple header > > layers, when passing the packet from one layer to the > other. It's not > > much, but there is, and can add-up - there are the little > things that, > > when in larhe numbers, contribute to a considerable load. > If that can > > be eliminated, I see it as a plus... > > > > Alex Conta > > > > > -----Original Message----- > > > From: tsv-area-bounces@xxxxxxxx > [mailto:tsv-area-bounces@xxxxxxxx] > > > On Behalf Of L.Wood@xxxxxxxxxxxx > > > Sent: Tuesday, April 27, 2010 6:38 AM > > > To: fred@xxxxxxxxx > > > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx > > > Subject: RE: UDP encaps for SCTP and SCCP > > > > > > > > > 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 > > > > > >
