DCCP'ers,
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.
Before we choose, can I suggest a version of the 4-tuple demux that also
uses the encaps DCCP information. This assumes a 4-tuple
{ip-src,ip-dst,udp-src,udp-dst} is expected per DCCP connection.
Here is my suggestion:
We demux incoming UDP encapsulated DCCP datagrams using only the UDP and
IP information. However, if a flow is active (i.e. DCCP connection)
using a particular 4-tuple, we then check the DCCP ports are the same as
the cached value for the session that initiated the connection, if the
cached info is different, the encaps returns a DCCP-Reset(Connection
Refused) to abort the "additional conflicting" connection.
For an established flow, this requires a cache of the DCCP ports (32
bits). In most cases, a second flow that maps to the same UDP ports
would start an initiation of a new DCCP session, and therefore the reset
would will simply abort this, and provide a high probability that this
would not disrupt any existing flow.
Others may immediately see a flaw, in which case do speak-up. Is
something else better?
Gorry
