Re: draft-ietf-dccp-udpencap-03 - 6-tuple

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux