Hi Gorry, You've raised a couple of issues below that I think we could better keep track of if we have a new thread, so I've renamed the subject here. What I'd like to discuss here is the thought that we can have a generic approach to UDP encapsulation of transport protocols. Since we have no concrete approach on the table, it's a little difficult to comment, but here are my thoughts on what I've heard bandied about. Just tunnel it -- To me this means IP Header/UDP Header/IP Header/Transport Header. The problem is the addresses in the inner IP Header. In tunneling, the endpoints of the tunnel need to understand the addresses in the inner IP Header. But in the usual situation with NAT in between client and server, at least one of the addresses won't make sense to the receiving endpoint. That address will be from the private address realm of the other endpoint, and could duplicate an address used by another device communicating with the receiver. So what do you do with these inner IP addresses? Ignore them? What do you send in the return packets? How do you form a unique 4-tuple that identifies the socket (source address/port + destination address/port) when two endpoints could have the same source address? So drop the inner IP Header -- This gives you IP Header/UDP Header/Transport Header. I think of this as "encapsulation" rather than "tunneling". You can now make the 4-tuple from the IP addresses and the Transport Header ports. But this breaks the checksum in the Transport Header. Where are the IP addresses used in the checksum pseudo-header? >From the IP Header? But those might be changed en route. So change the rules for checksums -- Fortunately, TCP, SCTP and DCCP use pretty much the same rules for computing the checksum field. Saying encapsulated transports ignore their own checksum field and use the UDP checksum probably works here. But has anything else been broken? -- For DCCP, yes. Partial checksums don't work. Also, I believe SCTP has a stronger checksum option that I believe has been broken by this approach so far. You still need some protocol-specific rules. So it looks to me like completely generic UDP encap is not possible, although mostly generic is possible. The mostly-generic draft would say use IP Header/UDP Header/Transport Header, use these generic rules for dealing with the encapsulated checksum, and then use these protocol-specific rules for dealing with protocol-specific issues. This is the approach taken by dccp-natencap, plus some additional optimizations -- since the DCCP checksum field is now useless, why carry it? And once you eliminate that, the DCCP header can be made more efficient. Are these additional optimizations worth it? I'd like to hear opinions... Note that another approach that's been talked about is to eliminate the ports from the inner Transport Header and use the ports in the UDP Header to indicate the actual application. This seems unworkable to me in that it means that a port can only be used for one transport and that's likely to break all sorts of things. Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Gorry Fairhurst > Sent: Friday, November 20, 2009 11:48 AM > To: Pasi Sarolahti > Cc: DCCP working group > Subject: Re: Soliciting input on UDP encapsulation for DCCP > > A few comments in-line, some of which I raised last time, but don't > recall the answers. > > > Pasi Sarolahti wrote: > > Hello, > > > > During the Hiroshima meeting last week some support (and some concerns) > > was voiced about working on UDP encapsulation for DCCP, with a > > suggestion to allocate an UDP port to be used for DCCP encapsulation. To > > make this happen, it was proposed that we bring back > > draft-phelan-dccp-natencap, for the WG to submit it for Experimental > > RFC. Tom has now updated the draft and the refreshed version can be > > found at http://tools.ietf.org/html/draft-phelan-dccp-natencap-03 > > > > With the above background in mind, I'm now looking for input on the > > following questions: > > > > a) in your opinion, should the DCCP WG start working on UDP > > encapsulation for DCCP? > > > No, or at least unsure. > > I'd love to see a tunnel encapsulation, however I'd also like to > consider the feasibility of a common method for all transports - or at > least one that handles UDP-Lite, SCTP and DCCP consistently with the > possibility of later extension. If I were in the DCCP meeting I would > have tried to push on this one and see what people said, hence I'd be > keen to seen feedback via the list. If there are good reasons to > continue separate approaches for each, that would be fine, but I'd > expect to see this rationale somewhere in the draft. > > > b) if yes, do you think draft-phelan-dccp-natencap is a good starting > > point for this, and therefore should become a WG document? > > > Maybe, although I would think it is worth considering a straight UDP > encapsulation that does not adjust the position and order of the fields. > > > In addition, please speak up if you have other technical comments about > > the draft. > > > Separate email sent to the list. > > > Thanks! > > > > - Pasi > > > > Finally, I think I'd say it was essential that any encapsulation draft > also notes the drawbacks of this mode, and hence advocates native > transport were possible! > > e.g. > No currently defined support for ECN > No currently defined support for shared PMTUD > Restricted support for partial coverage > > - The pros would seem to outweigh the cons, but there are disadvantages. > > Gorry > > P.S. I also believe this should be discussed at TSVWG, since there is > already a proposal for an SCTP encapsulation.
