Hi, What is the worst thing that could happen if the DCCP-over-UDP connection was identified as DCCP/IP four-tuple? Obviously, there is a risk that connections from two hosts behind a NAPT get the same DCCP four-tuple. Is there any worse effect than the latter connection being rejected? There is ongoing connection state from the first connection, and for the latter the first packet should be DCCP-Request, which should then fail. I'd assume that there could be a small module listening at a well-known UDP port that strips out the UDP header and forwards the DCCP packet to the DCCP implementation. Such module should remember the active UDP sources per each DCCP connection, to be able to route the responses back to the right source. Then it should be possible for the module to identify for an incoming packet, that a given DCCP four-tuple is already in use by a different UDP source, and discard packets from the latter connection. If the rejected connection is later retried, it would probably use a different random DCCP source port, right? Getting connections rejected is not an ideal situation, but few things are when NATs are involved. And the DCCP source port should be usually selected by random, so this should be fairly rare situation, anyway. - Pasi On Jan 1, 2011, at 1:50 PM, Gorry Fairhurst wrote: > It's approaching a time when we need to decide as a WG what goes into the next rev. of the draft: > > ~ Could the procedure for DCCP checksums be further simplified by requiring (MUST) this to be set to zero when encapsulated within a (DCCP-)UDP header? - this would reduce the checksum processing overhead to that of only UDP. > > ~ 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. > > ~ If we adopt the above, there has also been a proposal to remove the DCCP ports prior to encaps. This is a topic we have visited as a WG in the past. I've seen recent comments supporting this and comments against this. Is it viable to remove the DCCP ports field, and is this desirable or not - comments welcome? (see also note on DCCP Checksum being zero) - How far do people wish to go (if at all) in removing unused fields? > > ~ If we allow the the well-known UDP-assigned port for DCCP (as currently proposed), then it seems this would rely on out-of-band information or the SC to identify the intended DCCP service. This has less utility (i.e. there are only specific cases where this is useful, and it wouldn't work in some NAPT scenarios), but it currently seems to me to be mostly harmless - can someone supply suggested text?. > > --- > > ~ Known NiTs (to be corrected in next version - thanks to all who noted these): > > Header: s/Engineeeing/Engineering/ > Abstract: s/This documents also updates/The document also updates/ > > Section 1: "[...] that is compatible with this installed base of NAT/NAPT > devices that supports [RFC4787], but do not support [RFC5597]." > Change to 'devices that support' > Section 1: "The document also provides an updated SDP specification for DCCP, > and, in this respect only, it updates the method in [RFC5762]." > Insert text 'updated SDP specification for DCCP to convey the > encapsulation type and, in this respect only, ...' > > Section 3: "Devices offering or using DCCP services [...] listens on a UDP port" > ^ - Change to /A device that offers or uses ... > > Section 3.1: "Length: 16 bits > [...] (for DCCP-UDP, the payload is a DCCP-UDP datagram)" > See if this is clearer to say that the payload is a DCCP datagram. > > Section 3.3: s/encapuslated/encapsulated/ > Section 3.3: "Use of UDP-checksum is mandated" => of UDP checksums > > Section 3.4: Typo "teh" > Section 3.4: Typo "A DCCP-UDP implementations" change to implementation > Section 3.4: Typo s/susbequent/subsequent/ > > Section 3.8: Typo "DCP-UDP client" > Section 3.8: "If the DCCP-UDP server binds to this default port" > Repeat "binds to the default port reserved for DCCP-UDP service"? > > Section 3.9: Check: "This section clarifies the usage of DCCP Service Codes or the registration of > server ports by DCCP-UDP." ==> should this be 'Service Codes and the [...]"? > > Section 4: There is no clear motivation for using a different encapsulation for higher-layer protocols in DCCP-NAT than in DCCP-STD. Change: The different encapsulations MUST be the same. > > Section 4: Clarify "If a document does not specify [...] the specified encapsulation SHALL apply [...]" ==> does this mean that 'DCCP-UDP encapsulation applies as specified by this document'? > > Section 5.1: Add some words to explain the applicability of the new SDP attribute. Specifically, it's likely only useful if the offering party is on the public Internet, or in the same private addressing realm as the answering party, since otherwise the port advertised is unlikely to be reachable due to the NAT. > > Section 5.1: the "a=dccp-in-udp:" attribute can be used in a declarative SDP file, in addition to in offer/answer mode. > Section 5.1: procedures for handling DCCP-STD and/or DCCP-NAT with ICE may need to be developed, but are left for further work. > > Section 5: Ed Note: There is only one subsection, 'SDP Support for DCCP-UDP'. Would it make > sense to collapse the single subsection so that there is only a section 5? > > Section 6: s/swent/sent/, s/encapsualted/encapsulated/, s/conenctions/connections/ > > Section 7: s/occurances/occurrences/ > > Section 8: s/Collin/Colin/, s/Lenvorski/Lentvorski/ > --- > > Gorry > > > On 20/12/2010 15:30, Eddie Kohler wrote: >> If the parsing change were dramatic or expensive I'd be less happy about eliding the DCCP ports. But the DCCP ports are just the first 4 bytes of the DCCP header, making it very easy to pop ports on for parsing and pop them off for encapsulating. >> >> E >> >> >> On 12/20/10 1:50 AM, Pasi Sarolahti wrote: >>> On Dec 15, 2010, at 11:20 PM, Colin Perkins wrote: >>> >>>>> No, they would not. Just as the encapsulated DCCP header checksum is ignored, the encapsulated DCCP PORTS would be ignored. The receiver would use the ports from UDP. >>>> >>>> In that case, we should just elide the ports from the encapsulated DCCP header to avoid the confusion, if we're going to do this. >>> >>> I'm also supportive of using UDP ports in the 4-tuple, and ignore the DCCP ports. I wouldn't so much like the idea of defining a different DCCP header for UDP encapsulation, even if it saved a few bytes (just to avoid separate packet parsers). >>> >>> With a shared UDP port at the server, this would mean that the service codes come to good use (which might be worth emphasizing in the text). >>> >>> - Pasi >>> >> >> >
