On Nov 20, 2009, at 8:07 PM, Phelan, Tom wrote: > 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. We use IP Header/UDP/SCTP when encapsulating SCTP in UDP. Please note that SCTP does NOT use a pseudoheader for checksum computation. The SCTP checksum (actually a CRC32c) is computed only over the SCTP packet, not taking into account anything from the IP header. > > 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. SCTP works, we also use the UDP checksum. Since it is computed normally by the NIC it is not that much of a performance issue. And I thought it is better to do the same for IPv4 and IPv6. > > 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... We also need SCTP specific rules for dealing with multihoming and NAT traversal... But that is specific. > > 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. The does NOT work for SCTP, since the UDP ports on different paths might be different, due to independent NAT boxes on different paths. SCTP, however, does require one port for all paths. So for SCTP we really need the IP Header/UDP Header/SCTP Packet approach... Best regards Michael > > 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. > >
