Hi Lloyd, See inline... Tom P. > -----Original Message----- > From: L.Wood@xxxxxxxxxxxx [mailto:L.Wood@xxxxxxxxxxxx] > Sent: Tuesday, April 27, 2010 4:44 PM > To: Phelan, Tom; aconta@xxxxxxxxxxxxx; fred@xxxxxxxxx > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx > Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it? > > Why not craft the inner packet with inner src and destination to a local > loopback address (127.0.0.1) before sticking it in the UDP header? > [Tom P.] Well, then you aren't "just tunneling it", are you? > Preserves layering, preserves multihoming, avoids public/private address > space concerns, prevents similar tunnelling by middleboxes. > > Of course, there's tracking the real src and dst in the added/discarded > UDP header, and associating those with the decapped inner packet -- tch, > implementation details... > [Tom P.] I think that after examining these implementation details that it's better to eliminate the inner addresses -- why carry something that has no real function? > L. > > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx] > Sent: 27 April 2010 18:46 > To: Alex Conta; Wood L Dr (Electronic Eng); 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 > > > >
