[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: dccp-udpencap discussed in TSVWG



> -----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






[Kernel List]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]     [Linux Resources]

Powered by Linux