Colin,
We cannot keep the port spaces separate. The IP-addresses-plus-DCCP-ports
4-tuple cannot be used for unambiguous demultiplexing in the presence of a NAT.
The NAT might change the UDP ports to ensure uniqueness, but will not change
the DCCP ports. So the IP-addresses-plus-DCCP-ports 4-tuple might not be
unique, if two hosts behind the same NAT happen to choose the same IP
destination, DCCP source port, and DCCP destination port.
Hopefully this is enough to jog your memory, there is a worked out example in
the mail that started all this.
Eddie
On 02/07/2011 07:45 AM, Colin Perkins wrote:
On 7 Feb 2011, at 15:24, Eddie Kohler wrote:
Colin,
The problem solved by the 6-tuple is that the receiver CANNOT simply throw away
the UDP ports. The UDP ports are a critical component of flow demultiplexing.
Do I misunderstand you?
Yes, you misunderstand.
Obviously the receiver uses the UDP header to direct incoming packets to the
DCCP decapsulation service. However, after that, a receiver that has a native
DCCP stack can remove the UDP header and reconstruct the native DCCP packet,
which can be injected into its DCCP stack. There's no need to couple the two
port spaces: the UDP port chosen by the encapsulation service is entirely
separate from the DCCP ports. Keep the layers separate as much as possible.
Colin
Eddie
On 2/7/11 3:54 AM, Colin Perkins wrote:
On 1 Feb 2011, at 09:02, Pasi Sarolahti wrote:
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?
My preference is for the 6-tuple, since this is conceptually simplest: the
receiver operation is just to remove the UDP header, and treat the encapsulated
DCCP packet as any other native DCCP packet received. I'd expect this also to
be simple to implement as a user-space daemon.
