I'm well aware of the example. It's one of the reasons why I'm arguing for the 6-tuple.
Colin On 7 Feb 2011, at 16:18, Eddie Kohler wrote: > 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. >>>> >> >> >> -- Colin Perkins http://csperkins.org/
