> -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On > Behalf Of Pasi Sarolahti > Sent: Thursday, March 18, 2010 11:01 AM > To: DCCP working group > Subject: dccp-udpencap discussed in TSVWG > > Hi, > > Even though we do not have a DCCP session in the Anaheim > meeting, the > dccp-udpencap draft will be discussed in the TSVWG session. > TSVWG will > meet on Monday, March 22 at 13:00, so if you are interested in this > draft, please consider attending that session. > > Now might also be a good time to read the draft, if you haven't done > so yet. The draft is available at > http://tools.ietf.org/html/draft-ietf-dccp-udpencap-00 Introduction: The introduction should more clearly indicate if DCCP-NAT is intended to work with NAPT (as defined in Section 4.1.2 of RFC2663) or not. I believe that is the intent; please make the document clearer on that point. OLD: In order for the [RFC4340] encapsulation to pass through Network Address Translation (NAT) devices, these devices must be updated to recognize and properly modify DCCP. This is the long-term objective for DCCP, and work is underway to specify the necessary operations. NEW: In order for the [RFC4340] encapsulation to pass through Network Address Translation (NAT) devices, these devices must be updated to recognize and properly modify DCCP, as described in [RFC5597]. .....................................^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 3.1, "UDP Header" "Source and Dest(ination) Ports: 16 bits each These fields identify the UDP ports on which the source and destination (respectively) of the packet are listening for incoming DCCP-NAT packets (normally both are the default port to be assigned by IANA). Note that they do not identify the DCCP source and destination ports." With a NAPT, due to the UDP port being used by another host, or another DCCP-NAT instance running on the same host, it is not true that "normally" the source and destination ports will be whatever IANA assigns. If anything, the parenthetical statement should be almost reversed and say something like "implementations should be aware that a NAPT may, for various reasons, assign a different source UDP port than used by the host sourcing the DCCP-NAT packets". "Length: 16 bits This field is the length of the portion of the UDP datagram, including the UDP header and the payload (which for DCCP-NAT is the DCCP-NAT datagram) that is covered by the UDP Checksum." Is the "DCCP-NAT datagram" the same as the "Application Data Area" from the diagram in section 3? If they are the same, please pick one term; if they are different, the I-D needs to explain the difference. I believe it encompasses the DCCP-NAT Generic Header, Additional Fields, DCCP Options, and [DCCP?] Application Data Area. The I-D does not say if the UDP source/destination ports need to agree with the DCCP source/destination ports, or what it means if they disagree (nothing?). Is there a reason there are ports in both places? I presume it is so that one DCCP-NAT "tunnel" can be run between two DCCP-NAT hosts, carrying various different DCCP flows? Section 3.3: "If the UDP Checksum field, computed using standard UDP methods except including only UDP Length bytes of the UDP packet, is invalid, the packet MUST be dropped." I don't understand the phrase "except including only UDP Length bytes of the UDP packet". Can that be clarified? Section 3.5: DCCP-NAT implementations should follow DCCP-STD section 14 with ^^^^^^ SHOULD regard to maximum packet size and Path Maximum Transmission Unit Discovery (PMTUD). Section 4: In general, the encapsulation of a higher-layer protocol within DCCP SHOULD be the same in both DCCP-STD and DCCP-NAT. At this time, encapsulations of DTLS over DCCP, defined in [RFC5238] and RTP over DCCP, defined in [I-D.ietf-dccp-rtp], have been already defined. The encapsulations of those protocols in DCCP-NAT SHALL be the same as specified in those documents. Except that, for native DCCP, the encapsulation allows short sequence numbers -- but that isn't allowed with DCCP-NAT. That should be made clearer Section 5.1: [I-D.ietf-dccp-rtp] defines SDP extensions for signaling RTP over DCCP connections. Since it predates this document, it does not define a method for determining the DCCP encapsulation type. ^^^^^^^^^^^ signaling Section 5.1: This document updates [I-D.ietf-dccp-rtp] to add a method for determining the DCCP encapsulation type. Then it needs "Updates: ietf-dccp-rtp" in the document header. Which makes me notice that DCCP-NAT is Experimental, whereas draft-ietf-dccp-rtp is standards-track. So, I think you cannot 'update' the standards-track document. Rather, the extension to SDP needs to, itself, be experiemental. This is Experimental, so the a=dccp-in-udp is probably okay. If it wasn't experimental, it would probably be better to use the SDP Capabilities Negotiation stuff from MMUSIC (draft-ietf-mmusic-sdp-capability-negotiation). I would encourage the I-D require the UDP port *always* be provided in the signaling, and not allow it optionally as currently in the spec. Havoc will ensue if the port is not signaled, as implementations will expect/require the NAPT to not change port numbers (relying on the NAPT keeping the port the same), which will break outside of a quiescent lab environment. We had a similar problem with RTCP port numbers not being signaled (assumed to be the RTP port number + 1) which has not worked out well in practice. Section 5.1: What happens if the offerer supports DCCP-over-UDP, but the answerer only supports native DCCP? Also, what happens if both offerer and answerer support DCCP-over-UDP, but there isn't a NAT between them (and they could have used DCCP for more efficient communication)? It seems adding a 'for future study' reference to ICE might be helpful if someone decides they want to optimize that situation. -d
