| ~ 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. On re-reading rev03 of the draft, to me the design seems to go from simple tunneling to more complex scenarios for NAT. I like Tom's initial concept for it is simple.
The text still reads as providing a tunnelling service where by default on either side is a UDP endpoint listening on a default port (i.e. on both firewalls only 1 UDP port is needed for both directions). And for this scenario, both Colin and Eddie are right - it requires using the 6-tuple (when using the default IANA UDP port for src/dst UDP ports, it quasi reduces to a 4-tuple). Hence unless a different purpose is desired, the design requires what Eddie posted on 13 Dec, > 6-tuples are MUST, not SHOULD A naive implementation concept: ------------------------------- UDP tunnelling endpoint is a userspace application (not sure if Lloyd's posting meant this), connected to a tun/tap virtual interface, just like the OpenVPN tunnelling daemon. The application takes care of connection state, strips UDP headers from incoming datagrams, recomputes the checksum according to CsCov, and outputs the datagram to the virtual interface, from where it is routed inside the host to listening DCCP applications. Such an application would not become more complex by using 6-tuples instead of 4-tuples. The UDP header of outgoing DCCP packets is filled in from the 6-tuple. The DCCP session is still described by the contained 4-tuple, while the additional two UDP ports (which both may actually be set to the IANA default port) add the information needed for the outer packet.
