Section 16. Middlebox Considerations

This section describes properties of DCCP that firewalls, network
   address translators, and other middleboxes should consider, including
   parts of the packet that middleboxes should not change.  The intent
   is to draw attention to aspects of DCCP that may be useful, or
   dangerous, for middleboxes, or that differ significantly from TCP.
   The Service Code field in DCCP-Request packets provides information
   that may be useful for stateful middleboxes.  With Service Code, a
   middlebox can tell what protocol a connection will use without
   relying on port numbers.  Middleboxes can disallow connections that
   attempt to access unexpected services by sending a DCCP-Reset with
   Reset Code 8, "Bad Service Code".  Middleboxes should not modify the
   Service Code unless they are really changing the service a connection
   is accessing.
   The Source and Destination Port fields are in the same packet
   locations as the corresponding fields in TCP and UDP, which may
   simplify some middlebox implementations.
   The forward compatibility considerations in Section 15 apply to
   middleboxes as well.  In particular, middleboxes generally shouldn't
   act punitively towards options and features they do not understand.
   Modifying DCCP Sequence Numbers and Acknowledgement Numbers is more
   tedious and dangerous than modifying TCP sequence numbers.  A
   middlebox that added packets to or removed packets from a DCCP
   connection would have to modify acknowledgement options, such as Ack
   Vector, and CCID-specific options, such as TFRC's Loss Intervals, at
   minimum.  On ECN-capable connections, the middlebox would have to
   keep track of ECN Nonce information for packets it introduced or
   removed, so that the relevant acknowledgement options continued to
   have correct ECN Nonce Echoes, or risk the connection being reset for
   "Aggression Penalty".  We therefore recommend that middleboxes not
   modify packet streams by adding or removing packets.
   Note that there is less need to modify DCCP's per-packet sequence
   numbers than to modify TCP's per-byte sequence numbers; for example,
   a middlebox can change the contents of a packet without changing its
   sequence number.  (In TCP, sequence number modification is required
   to support protocols like FTP that carry variable-length addresses in
   the data stream.  If such an application were deployed over DCCP,
   middleboxes would simply grow or shrink the relevant packets as
   necessary without changing their sequence numbers.  This might
   involve fragmenting the packet.)
   Middleboxes may, of course, reset connections in progress.  Clearly,
   this requires inserting a packet into one or both packet streams, but
   the difficult issues do not arise.
   DCCP is somewhat unfriendly to "connection splicing" [SHHP00], in
   which clients' connection attempts are intercepted, but possibly
   later "spliced in" to external server connections via sequence number
   manipulations.  A connection splicer at minimum would have to ensure
   that the spliced connections agreed on all relevant feature values,
   which might take some renegotiation.
   The contents of this section should not be interpreted as a wholesale
   endorsement of stateful middleboxes.