I like 4-tuple IP/UDP.
- Look up IP+UDP 4-tuple
- If flow exists and DCCP ports conflict, send Reset; otherwise continue
This seems no more complex than a straight-up 6-tuple.
The draft could introduce a new Reset Reason for "encapsulated port reuse" so
a tunneled endpoint could immediately try again.
*
The IP/UDP 4-tuple would become SUFFICIENT, as well as necessary -- and we
would avoid the need for Resets -- if we could guarantee that each separate
DCCP flow would have its own UDP flow, even given NATs.
It's also clean for network accounting when a flow is a flow is a flow.
This is not true with the current draft because of default port numbers for
UDP SOURCE ports -- a feature I've never much liked. A user-space daemon
could just as easily assign different UDP source ports to different DCCP
flows; source UDP ports are by default chosen at random from the dynamic port
range. A kernel implementation could too.
So what about: "An endpoint MUST ensure that UDP-based flow identifiers differ
whenever DCCP-based flow identifiers differ. Specifically, two connections
with different <source address, source DCCP port, destination address,
destination DCCP port> 4-tuples MUST have different <source address, source
UDP port, destination address, destination UDP port> 4-tuples. This can be
ensured, for example, by choosing distinct source UDP ports for distinct DCCP
connections."
*
Gerrit suggested that we leave this up to the implementer. I initially
disagreed. However, on reflection, this could work well. If the above
suggestion about distinct UDP 4-tuples is not adopted, I would prefer allowing
implementations to EITHER send Reset(encapsulated port reuse) OR demultiplex
using a 6-tuple.
*
To summarize, my strong preference is IP/UDP 4-tuple, plus language about
ensuring distinct IP/UDP 4-tuples.
Eddie
On 02/02/2011 12:09 AM, Gorry Fairhurst wrote:
On 01/02/2011 09:02, Pasi Sarolahti wrote:
Hi,
On Jan 19, 2011, at 9:40 PM, Gorry Fairhurst wrote:
I have now implemented all the corrections in the UDP encaps draft, except
for the issue of how we implement transport demultiplexing, where there
seems to be multiple ideas. We clearly need to choose either
the 4-tuple demux or the 6-tuple demux.
Indeed. I think there are three choices
* 6-tuple
* 4-tuple IP/UDP (with checks against conflicting DCCP connections)
* 4-tuple IP/DCCP (with checks against conflicting UDP ports at UDP
decapsulation point)
There have been arguments suspecting kernel implementation feasibility of
6-tuple. People have also wanted to see UDP tunneling work with unmodified
DCCP implementation. If I understand correctly this would be difficult with
the first two option. Would there be something wrong with the last option?
I think this is the only remaining open issue (right?). So let's try to
reach a conclusion. If you don't have clear favorite, is some of the options
out of question?
- Pasi
I vote for:
* 4-tuple IP/UDP (with checks against conflicting DCCP connections)
Gorry
