Re: draft-ietf-dccp-udpencap-03 - 6-tuple

On 1 Jan 2011, at 11:50, Gorry Fairhurst wrote:
> It's approaching a time when we need to decide as a WG what goes into the next rev. of the draft:
> 
> ~ Could the procedure for DCCP checksums be further simplified by requiring (MUST) this to be set to zero
when encapsulated within a (DCCP-)UDP header? - this would reduce the checksum processing overhead to
that of only UDP.
> 
> ~ Following the WGLC there was debate on the 4/6-Tuple and how this would work with different UDP and DCCP
port values. As I see it, the current proposal is to eliminate the 6-Tuple text and use only the outer UDP
ports for demultiplexing.

If I understand what's proposed correctly, I don't think this would be a good idea. The ability to have a
well-known UDP port on which tunnelled DCCP connections can be accepted seems important to me; as does the
ability to run a server accessible via UDP and native DCCP listening on the same port, also accessible via
tunnelled DCCP. Neither of these are possible if we use only the outer UDP ports. 

> ~ If we adopt the above, there has also been a proposal to remove the DCCP ports prior to encaps. This is a
topic we have visited as a WG in the past. I've seen recent comments supporting this and comments against
this. Is it viable to remove the DCCP ports field, and is this desirable or not - comments welcome? (see also
note on DCCP Checksum being zero) - How far do people wish to go (if at all) in removing unused fields?

See above. I don't think this is desirable.

> ~ If we allow the the well-known UDP-assigned port for DCCP (as currently proposed), then it seems this
would rely on out-of-band information or the SC to identify the intended DCCP service. This has less
utility (i.e. there are only specific cases where this is useful, and it wouldn't work in some NAPT
scenarios), but it currently seems to me to be mostly harmless - can someone supply suggested text?.

Or use the inner DCCP port.