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 <idsubmission@xxxxxxxx> >> To: gorry@xxxxxxxxxxxxxx >> CC: tphelan@xxxxxxxxxxxx >> >> >> 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/
