> 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. > I can see how this might work, but I find no immediate benefit in it. It shifts the complexity from memory (4 instead of 6) to algorithm. IMHO this all shows a tendency to go from an initially simple tunneling-like service (which could declare DCCP-UDP connections dead after some timeout of inactivity) to a stateful DCCP middle-box, which is more difficult to specify and implement.
