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

Re: [udp-encap rev2] discussion/comments

Hi Gerrit,

See inline...

Tom P.

> -----Original Message-----
> From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf
> Gerrit Renker
> Sent: Friday, September 03, 2010 6:52 AM
> To: dccp@xxxxxxxx
> Subject:  [udp-encap rev2] discussion/comments
> Please find below the transcript of a discussion I sent to Gorry
> revision 2 of the udp-encap draft.
> As per Gorry's comments, I may have missed parts of the discussion, so
> please
> ignore or correct where I am erring.
> The main point I did not understand is whether the aim is to
>  * encapsulate DCCP as a user-space protocol or
>  * encapsulate DCCP as an in-kernel protocol?
[TomP] The main point is neither, or rather the main point is orthogonal
to these issues.  The main point is to allow DCCP to pass through
existing NAT devices.

> If the latter is the main aim, then it would be great not to make
> to
> the encapsulated data (DCCP header + DCCP payload), since this would
> require
> a separate implementation for generating the DCCP-UDP payload data.
> Even if the DCCP checksum should break as a result of NAT-ing some of
> IP adresses - the DCCP checksum can easily be recomputed at the UDP
> endpoint.
[TomP] I am very against doing the checksum calculation twice, once for
UDP and then again for DCCP.  In my opinion, implementations should know
which encapsulation is being used.

> General questions and remarks
> =============================
>   a. It would be good to specify how UDP ICMP errors are translated
>      semantics, in particular the "administratively prohibited"
> of
>      Destination Unreachable (RFC 1122,, and how these
> are
>      to be passed on to UDP.
> GF>  Agree, something is needed to specify at the sender to say the
> procedure for generating errors
> and processing then at the receiver.
[TomP] I'll look into this for the next version.

>   b. Are network-layer options (e.g. setting TOS) which may be set
>      simply to be transferred to DCCP-UDP (same question for PMTUD -
> the
>      DCCP-UDP MTU the same the UDP_MTU - 8 ?).
[TomP] I believe this is already covered in the draft (sections 3.4 and
3.5).  As to how implementations will choose to do this (as you suggest
or some other mechanism), I don't thinks that's the business of this

>   c. Why does there need to be an IANA-assigned default port for DCCP
>      encapsulation? The benefit of a well-known for current-generation
> boxes
>      is not clear (it would not help NAT traversal). For
>      boxes might give the wrong impression to implementors that
> is the
>      only feasible way of supporting DCCP.
>      For out-of-band signalling SDP has already been specified by the
> document.
[TomP] For applications that don't use a rendezvous protocol such as
SDP, a default port is very useful.  That it might be changed along the
way doesn't change the initial need.

> GF>  This is debatable - I can see pros and cons, at the moment I'd
> using
> a well known port. The document should say WHY the method is chosen.
[TomP] I think that such as statement is not necessary.

>   d. The document specifies that both endpoints shall be listening on
> given
>      UDP port, while DCCP distinguishes active and passive
> parts
>      of the connection. I wonder whether it is necessary or would be
> to
>      inform about which side is the active one in the SDP protocol,
> how
>      shall the endpoint otherwise know what to do with the UDP tunnel?
> both
>      endpoints listen, nothing happens, if both connect there is
> simultaneous
>      open (discussed in RFC 5596).
[TomP] You seem to be confusing the UDP aspects with the DCCP aspects
here.  The DCCP server listens, and the DCCP client initiates on DCCP
ports, but both server and client listen on UDP ports.

> GF>  This, to me, refers to both stacks at the hosts, rather than per-
> socket connection
> endpoints. I agree the wording should better.
[TomP] The wording where?
>   e. I can see no point for the extra rule that DCCP packets contained
>      encapsulation should not have their own checksums. First it
> and
>      restricts the use of DCCP so that encapsulated DCCP behaves
> differently
>      from unencapsulated DCCP. Second, it makes the specification more
> complicated,
>      by adding exceptions. Furthermore, the Internet checksum is cheap
> compute,
>      the other endpoint is known (and hence pseudo-header is already
> implicit).
>      The restriction of not being able to use partial checksums limits
> usability
>      if e.g. DCCP-UDP is employed on a path where on the "last mile"
> partial
>      checksums are of interest (e.g. wireless links). It is also
> conceivable
>      that there may be a "tunneling server" which transparently wraps
> in UDP;
>      for such mode of operation it could simply just prepend the 8
> of header,
>      checksum the resulting packet, no need to alter its payload. The
> peering
>      endpoint would strip off the UDP header and could forward the
> enclosed DCCP
>      datagram without having to peek into the packet in order to
> the
>      checksum. Hence the recommendation is to keep DCCP as originally
> specified
>      in DCCP, and to not introduce extra checksumming rules.
[TomP] I don't agree.  Introducing an in-the-network tunneling server
complicates things (how do you ensure it's on the path?  Build it into
the NAT?  But then why not build in real DCCP support?), and therefore
will never be built.

Maybe someone might choose to implement DCCP-UDP as a bump-in-the-stack
model.  Well, then that implementation can zero the DCCP checksum on the
outbound side and recomputed it on the inbound side, instead of forcing
more integrated implementations to calculate the checksum twice.

> GF>  This comes from the NAT behaviour where the module modifies the
> (and port
> values for NAPT) of the outer headers. The encaps document doesn't say
> this works, and I expect a NAPT would re-write the "emphemeral" port
> anyway.
> So, I am guessing the encaps receiver should bind to ANY src port and
> standard DCCP_UDP dst port by default. The document should say WHY the
> method was chosen.
[TomP] I'm not seeing the relationship of this to what's immediately

> Abstract
> --------
>   * the term 'alternative' encapsulation is a bit misleading, since
> is
>     alternative, both DCCP-STD and DCCP-UDP are encapsulated in IPv4/6
> headers;
>   * it would be clearer to refer to the technique as something like
> in-UDP"
>   * "without modification of those middleboxes"
>     =>  suggest e.g. 'modification of their software stacks' since
> "middleboxes"
>        otherwise is repeated in the same sentence
[TomP] I think the abstract is pretty clear.

> 1. Introduction
> ---------------
>   * 'According to [RFC 4340], DCCP packets are directly encapsulated
>     =>  this is clear from the definition of transport protocol, could
> omitted
> GF>  I disagree: This was instead in the last review, to make clear
> behaviour was standard RFC 4340 encaps.
[TomP] I agree with Gorry.

>   * 'For convenience, the [RFC 4340] encapsulation (updated by [RFC
> 5596])'
>     =>  as above, perhaps one could refer to RFC 4340 as "native
> packetization of
>        DCCP within IP" or something similar;
[TomP] I find that very clumsy.

>     =>  the remark that RFC 4340 is updated by RFC 5596 is not
> referencing
>        it would only make sense if there were discussion comparing the
> pros and cons
>        of the two approaches, which does not seem to be the aim of
> specification.
>        Since this document introduces a fix for current-generation NAT
> devices, it
>        could e.g. be said that current generation NAT devices also do
> support
>        RFC 5596 (hopefully Linux will soon), or the RFC reference
could be
> dropped.
> >  I recommended adding this: The rationale was we need to be able to
> transition
> firewalls AND NATs and the same behaviour can not be expected at all
> middleboxes.
> Therefore, I argued that the encaps MUST support both RFC 4340 and the
> extension
> in 5596 to allow it to operate in the wild, especially with multiple
> NATs/Firewalls.
[TomP] I think that this should be kept.  The capabilities of 5596 are
supported by DCCP-UDP.

>   * "The DCCP-UDP encapsulation specified here supports all of the
> features
>     contained in DCCP-STD except for partial checksums."
>     =>  Please see (e) above, it would be best not to introduce new
> assumptions
>        about DCCP and support the checksum by treating the
> packet
>        as opaque payload data of UDP. This would not restrict
> scenarios
>        ("sorry you can't use partial checksums because we are
> you").
> GF>  The intention was to allow applications to use the same partial-
> checksum code,
> but they wouldn't get benefit with UDP encaps. If they were to use
> Lite encaps
> they would, but that is a corner case...
[TomP] DCCP-UDP supports the semantics of partial checksums, but not the
function, as the UDP checksum covers the whole packet.  I think the
statement stands.
> -----------
>   * "(default port awaiting IANA action)"
>     sorry I don't understand why it is necessary to define a default
>   * "The basic format of a DCCP-UDP packet is"
>     =>  Drawing could perhaps be simplified by referring from 'DCCP
> Generic
>        Header' downwards simply as "DCCP packet, possibly with header
> options,
>        as specified in RFC 4340, section 5".
[TomP] Possibly, but I like the resemblance to the drawing in 4340.

>   * section 3.1, "(normally both are the default port to be assigned
> IANA)"
>     =>  meaning that 'Source Port' == 'Dest Port'?
>     =>  again, please, I don't understand why a default port is
[TomP] We've covered why the default port.  I suggest changing
"(normally both are the" to "(often both are initially the".

>   * Checksum:
>     - the specification (reference) of the UDP pseudo-header is
[TomP] RFC 0768 has already been referred to.  I can add another
reference here.

>     - as per (e) above it is better not to introduce assumptions about
>       contained payload, which would also simplify the specification,
>       * checksums are to be used and computed as specified in RFC
>       * the DCCP pseudo-header uses the DCCP port numbers and the UDP
>         endpoint IP addresses (i.e. from the point of DCCP the
> encapsulating
>         UDP header does not exist);
>       * the DCCP-UDPv4 checksum computation then proceeds according to
>         RFC 768 with the UDP checksum field set to zero and using as
>         UDP length the length of the contained DCCP packet including
>         DCCP header and DCCP header options;
>       * the DCCP-UDPv6 checksum computation uses the pseudo-header
>         from RFC 2460, 8.1 with the Upper-Layer packet length set to
>         length of the contained DCCP packet including the DCCP header
>         options.
[TomP] I don't agree with this (as covered before).

>   * section 3.2 could be omitted, since this is already specified in
>     RFC 4340 and as far as I understand the inner DCCP packet
>     are opaque for the purpose of NAT traversal;
[TomP] We still the paragraph of text that's in the section.  I think it
doesn't hurt to repeat the diagrams and set the context for that

>   * section 3.3, checksum computation
>     - as per (e) above, this section could be omitted
>     - with regard to checksum validity it could be simplified by
>       referring validate DCCP-UDP packets according to RFC 768, with
>       the restriction that the checksum MUST NOT be disabled (zero
>     - (The term 'DCCP-NAT' has not been introduced in this document.)
[TomP] I disagree.

>   * section 3.3.1
>     - s/Chesksums/Checksums/
[TomP] I'll fix the typo.

>     - same comment as per (e), section could be omitted
[TomP] I disagree.

>   * section 3.5
>     - would be good to clarify the use of UDP fragmentation:
>       UDP implementations support fragmentation, UDPv6 in addition
> supports
>       jumbograms (RFC 2675), hence need clarification whether to
>       a) bump the maximum inner MTU of DCCP to exploit the limits of
> or
>       b) completely disallow fragmentation of DCCP-UDP packets (since
> possibly
>          not supported by hardware)
>     - how shall section 14 of RFC 4340 be interpreted in this context:
>       * is DCCP's MPS simply the UDP PMTU minus 8?
>       * apply RFC 5405 for UDP MTU fallback values?
[TomP] I think that 4340 section 14 (including 14.2) covers these

>   * section 3.6
>     I don't understand the purpose of specifying the service code of
>     encapsulated protocol. Service code and encapsulation seem not
> related,
>     a connection could have any service-code value and still need UDP
>     encapsulation, but why not leaving this transparent to DCCP?
>     In particular, if assuming a "DCCP tunnelling service" or a type
>     overlay network, it would be difficult to alter the contained
>     code. Also, like the checksums, this again introduces new
>     into DCCP and complicates the specification. My personal view is
>     allow DCCP to pick whatever service code is appropriate for the
>     of service used, and not to add additional rules restricting this
>     because the protocol ends up being "tunneled".
[TomP] I think you mean section 3.7.  I believe the section says pretty
much what you say above.

> 5. Signaling the Use of DCCP-UDP
> --------------------------------
>   * "listening for DCCP-UDP connections on the indicated UDP port (if
>     udp-port-num is included)
>     -->  suggest to make the use of `udp-port-num' mandatory ('MUST')
>         not to require an IANA-assigned well-known port
[TomP] I disagree.

> GF>  Don't agree.
> 7. IANA Considerations
> ----------------------
>   * same comment as earlier, perhaps I am missing something, but I
>     to see the need for a default well-known port for DCCP

[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