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."
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.
