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.
