On 13 Dec 2010, at 17:19, Eddie Kohler wrote: > Hi Gorry, > > The text is close; I've put a revision below. I have other comments on that > section too; also below. As for the 6-tuple, WG FEEDBACK would be good. > > > 1) Does the text capture the problem? > > Reasonably well, could be better. 6-tuples are MUST, not SHOULD. > > > 2) Do you think this is the right method to handle this? > > - my concern is whether this adds significant extra complexity to the > > DCCP stack/module. > > Unfortunately the current design needs the 6-tuple for correctness. > > The only way to avoid a 6-tuple is to REQUIRE (with a MUST) that the UDP > ports equal the DCCP ports. In that case, the DCCP ports would be ignored on > packet receipt; the UDP ports would be used for the DCCP ports as well. You > can then use a 4-tuple to distinguish flows. But you cannot support a > "default UDP port."
NATs that rewrite the UDP ports but leave the UDP payload untouched would break this, no? Colin > It is up to the working group whether this is a good tradeoff. Now is the > time to decide. > > 4-tuple PRO: Simpler model. Every DCCP flow appears to middleboxes like a > different UDP flow (rather than the current design, in which a UDP "flow" > might multiplex several DCCP "flows", possibly causing oddities around ECN > marking and accounting). Some implementation scenarios simplified. > > 4-tuple CON: Effectively combines DCCP's port space with UDP's. If an > application wants to listen for both UDP and DCCP traffic, it must use > different port numbers for UDP and DCCP, even if the "service" is the same. > RFC4340 says "A port name registered for UDP MAY be registered for DCCP as > well. Any such registration SHOULD use the same port number as the existing > UDP registration." -- This would look like a bad decision. Of course DCCP > has a very small installed base. > > Having thought about it, I think a 4-tuple is a GOOD tradeoff. I would > recommend dropping the default UDP port, and requiring that the UDP ports > equal the DCCP ports. > > What do others think? > > (I note that the Linux kernel's flow cache uses 16 bit port numbers. It > could be changed to 32 bit port numbers at relatively low code complexity > cost; but the flow cache would get larger and lookups a bit more expensive. > More complex code could avoid this -- that is the tradeoff. FWIW the chance > 32-bit port #s would be accepted into Linux seems vanishingly small. A > userlevel DCCP-UDP implementation would be less constrained of course; there > I consider the complexity cost of a 6-tuple minimal; we know how to write > hash tables with arbitrary keys.) > > > Comments: > > A DCCP-UDP endpoint MAY use any UDP port number, providing the active > endpoint knows a valid UDP Destination Port on the passive endpoint. > > => This reads as though a DCCP-UDP endpoint MAY use different UDP port > numbers over the course of a single connection, which is not what you mean. > You are also using "endpoint" differently from RFC4340. > > By default, the DCP-UDP client sets the source and destination ports > to the default port number. UDP port number XXX IANA PORT XXX has > been registered with IANA for this purpose. > > => I am not a fan of this use of "default". I think what is really intended > here is a bit different. > > As for the text, please consider and use this: > > A DCCP-UDP connection involves two addresses and two sets of ports, one for > UDP and one for DCCP. The flow identifier for a DCCP-UDP connection is > therefore the 6-tuple <source address, source UDP port, source DCCP port, > destination address, destination UDP port, and destination UDP port>. > > A DCCP-UDP implementation SHOULD offer an interface by which applications > specify both server ports when opening a passive connection, and all four > ports when opening an active connection. However, implementations MAY also > offer a mode in which the UDP ports are not specified. In this mode, the > server UDP port SHOULD be set to XXX IANA PORT XXX; this has been registered > with IANA as the default DCCP-UDP server UDP port (i.e., the destination UDP > port of an actively-opened connection and the listening UDP port of a > passively-opened connection). In this mode, a client's DCCP-UDP > implementation MAY choose its client UDP port from the ephemeral ports, or it > MAY set the client UDP port to XXX IANA PORT XXX as well. > > A DCCP-UDP endpoint MUST use the entire 6-tuple as a flow identifier, rather > than the 4-tuple <source address, source DCCP port, destination address, > destination DCCP port> specified in [RFC4340]. This is because a NAT between > the endpoints may change the UDP ports to ensure flow uniqueness, but will > not examine or modify UDP packet payloads; as a result, the combination of > addresses and DCCP ports might be the same for two distinct flows. In > practice, this means that a DCCP-UDP implementation must use the 6-tuple as > key for its flow hash table (e.g., in step 2 of [RFC4340, Section 8.5]). > > > Eddie > > > On 12/9/10 12:48 AM, Gorry Fairhurst wrote: >> Eddie, >> >> I tried to create text on the topics you raised during WGLC. >> >> Specifically, you introduced a 6-tuple, which actually I don't yet fully >> understand: I see the need to handle cases where two clients are behind >> a NAPT and appear to tunnel from the same "host" using different UDP >> ports, resulting in them using the same DCCP 4-tuple, but I'm not sure >> exactly what a DCCP-UDP server should do. >> >> 1) Does the text capture the problem? >> >> 2) Do you think this is the right method to handle this? >> - my concern is whether this adds significant extra complexity to the >> DCCP stack/module. >> >> Gorry >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-dccp-udpencap-03 >> Date: Wed, 8 Dec 2010 05:03:31 -0800 (PST) >> From: IETF I-D Submission Tool <[email protected]> >> To: [email protected] >> CC: [email protected] >> >> >> A new version of I-D, draft-ietf-dccp-udpencap-03.txt has been >> successfully submitted by Gorry Fairhurst and posted to the IETF >> repository. >> >> Filename: draft-ietf-dccp-udpencap >> Revision: 03 >> Title: Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT >> Traversal (DCCP-UDP) >> Creation_date: 2010-12-08 >> WG ID: dccp >> Number_of_pages: 12 >> >> Abstract: >> This document specifies an alternative encapsulation of the Datagram >> Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This >> encapsulation allows DCCP to be carried through the current >> generation of Network Address Translation (NAT) middleboxes without >> modification of those middleboxes. This documents also updates the >> SDP information for DCCP defined in RFC 5762. >> >> >> >> >> The IETF Secretariat. >> >> >> -- Colin Perkins http://csperkins.org/
