Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4340

Datagram Congestion Control Protocol (DCCP)

Pages: 129
Proposed Standard
Errata
Updated by:  5595559663356773
Part 5 of 5 – Pages 101 to 129
First   Prev   None

Top   ToC   RFC4340 - Page 101   prevText

14. Maximum Packet Size

A DCCP implementation MUST maintain the maximum packet size (MPS) allowed for each active DCCP session. The MPS is influenced by the maximum packet size allowed by the current congestion control mechanism (CCMPS), the maximum packet size supported by the path's links (PMTU, the Path Maximum Transmission Unit) [RFC1191], and the lengths of the IP and DCCP headers.
Top   ToC   RFC4340 - Page 102
   A DCCP application interface SHOULD let the application discover
   DCCP's current MPS.  Generally, the DCCP implementation will refuse
   to send any packet bigger than the MPS, returning an appropriate
   error to the application.  A DCCP interface MAY allow applications to
   request fragmentation for packets larger than PMTU, but not larger
   than CCMPS.  (Packets larger than CCMPS MUST be rejected in any
   case.)  Fragmentation SHOULD NOT be the default, since it decreases
   robustness: an entire packet is discarded if even one of its
   fragments is lost.  Applications can usually get better error
   tolerance by producing packets smaller than the PMTU.

   The MPS reported to the application SHOULD be influenced by the size
   expected to be required for DCCP headers and options.  If the
   application provides data that, when combined with the options the
   DCCP implementation would like to include, would exceed the MPS, the
   implementation should either send the options on a separate packet
   (such as a DCCP-Ack) or lower the MPS, drop the data, and return an
   appropriate error to the application.

14.1. Measuring PMTU

Each DCCP endpoint MUST keep track of the current PMTU for each connection, except that this is not required for IPv4 connections whose applications have requested fragmentation. The PMTU SHOULD be initialized from the interface MTU that will be used to send packets. The MPS will be initialized with the minimum of the PMTU and the CCMPS, if any. Classical PMTU discovery uses unfragmentable packets. In IPv4, these packets have the IP Don't Fragment (DF) bit set; in IPv6, all packets are unfragmentable once emitted by an end host. As specified in [RFC1191], when a router receives a packet with DF set that is larger than the next link's MTU, it sends an ICMP Destination Unreachable message back to the source whose Code indicates that an unfragmentable packet was too large to forward (a "Datagram Too Big" message). When a DCCP implementation receives a Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU value given in the ICMP message. If the MTU given in the message is zero, the sender chooses a value for PMTU using the algorithm described in [RFC1191], Section 7. If the MTU given in the message is greater than the current PMTU, the Datagram Too Big message is ignored, as described in [RFC1191]. (We are aware that this may cause problems for DCCP endpoints behind certain firewalls.) A DCCP implementation may allow the application occasionally to request that PMTU discovery be performed again. This will reset the PMTU to the outgoing interface's MTU. Such requests SHOULD be rate limited, to one per two seconds, for example.
Top   ToC   RFC4340 - Page 103
   A DCCP sender MAY treat the reception of an ICMP Datagram Too Big
   message as an indication that the packet being reported was not lost
   due to congestion, and so for the purposes of congestion control it
   MAY ignore the DCCP receiver's indication that this packet did not
   arrive.  However, if this is done, then the DCCP sender MUST check
   the ECN bits of the IP header echoed in the ICMP message and only
   perform this optimization if these ECN bits indicate that the packet
   did not experience congestion prior to reaching the router whose link
   MTU it exceeded.

   A DCCP implementation SHOULD ensure, as far as possible, that ICMP
   Datagram Too Big messages were actually generated by routers, so that
   attackers cannot drive the PMTU down to a falsely small value.  The
   simplest way to do this is to verify that the Sequence Number on the
   ICMP error's encapsulated header corresponds to a Sequence Number
   that the implementation recently sent.  (According to current
   specifications, routers should return the full DCCP header and
   payload up to a maximum of 576 bytes [RFC1812] or the minimum IPv6
   MTU [RFC2463], although they are not required to return more than 64
   bits [RFC792].  Any amount greater than 128 bits will include the
   Sequence Number.)  ICMP Datagram Too Big messages with incorrect or
   missing Sequence Numbers may be ignored, or the DCCP implementation
   may lower the PMTU only temporarily in response.  If more than three
   odd Datagram Too Big messages are received and the other DCCP
   endpoint reports more than three lost packets, however, the DCCP
   implementation SHOULD assume the presence of a confused router and
   either obey the ICMP messages' PMTU or (on IPv4 networks) switch to
   allowing fragmentation.

   DCCP also allows upward probing of the PMTU [PMTUD], where the DCCP
   endpoint begins by sending small packets with DF set and then
   gradually increases the packet size until a packet is lost.  This
   mechanism does not require any ICMP error processing.  DCCP-Sync
   packets are the best choice for upward probing, since DCCP-Sync
   probes do not risk application data loss.  The DCCP implementation
   inserts arbitrary data into the DCCP-Sync application area, padding
   the packet to the right length.  Since every valid DCCP-Sync
   generates an immediate DCCP-SyncAck in response, the endpoint will
   have a pretty good idea of when a probe is lost.

14.2. Sender Behavior

A DCCP sender SHOULD send every packet as unfragmentable, as described above, with the following exceptions. o On IPv4 connections whose applications have requested fragmentation, the sender SHOULD send packets with the DF bit not set.
Top   ToC   RFC4340 - Page 104
   o  On IPv6 connections whose applications have requested
      fragmentation, the sender SHOULD use fragmentation extension
      headers to fragment packets larger than PMTU into suitably-sized
      chunks.  (Those chunks are, of course, unfragmentable.)

   o  It is undesirable for PMTU discovery to occur on the initial
      connection setup handshake, as the connection setup process may
      not be representative of packet sizes used during the connection,
      and performing MTU discovery on the initial handshake might
      unnecessarily delay connection establishment.  Thus, DCCP-Request
      and DCCP-Response packets SHOULD be sent as fragmentable.  In
      addition, DCCP-Reset packets SHOULD be sent as fragmentable,
      although typically these would be small enough to not be a
      problem.  For IPv4 connections, these packets SHOULD be sent with
      the DF bit not set; for IPv6 connections, they SHOULD be
      preemptively fragmented to a size not larger than the relevant
      interface MTU.

   If the DCCP implementation has decreased the PMTU, the sending
   application has not requested fragmentation, and the sending
   application attempts to send a packet larger than the new MPS, the
   API MUST refuse to send the packet and return an appropriate error to
   the application.  The application should then use the API to query
   the new value of MPS.  The kernel might have some packets buffered
   for transmission that are smaller than the old MPS but larger than
   the new MPS.  It MAY send these packets as fragmentable, or it MAY
   discard these packets; it MUST NOT send them as unfragmentable.

15. Forward Compatibility

Future versions of DCCP may add new options and features. A few simple guidelines will let extended DCCPs interoperate with normal DCCPs. o DCCP processors MUST NOT act punitively towards options and features they do not understand. For example, DCCP processors MUST NOT reset the connection if some field marked Reserved in this specification is non-zero; if some unknown option is present; or if some feature negotiation option mentions an unknown feature. Instead, DCCP processors MUST ignore these events. The Mandatory option is the single exception: if Mandatory precedes some unknown option or feature, the connection MUST be reset. o DCCP processors MUST anticipate the possibility of unknown feature values, which might occur as part of a negotiation for a known feature. For server-priority features, unknown values are handled as a matter of course: since the non-extended DCCP's priority list will not contain unknown values, the result of the negotiation
Top   ToC   RFC4340 - Page 105
      cannot be an unknown value.  A DCCP MUST respond with an empty
      Confirm option if it is assigned an unacceptable value for some
      non-negotiable feature.

   o  Each DCCP extension SHOULD be controlled by some feature.  The
      default value of this feature SHOULD correspond to "extension not
      available".  If an extended DCCP wants to use the extension, it
      SHOULD attempt to change the feature's value using a Change L or
      Change R option.  Any non-extended DCCP will ignore the option,
      thus leaving the feature value at its default, "extension not
      available".

   Section 19 lists DCCP assigned numbers reserved for experimental and
   testing purposes.

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
Top   ToC   RFC4340 - Page 106
   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.

17. Relations to Other Specifications

17.1. RTP

The Real-Time Transport Protocol, RTP [RFC3550], is currently used over UDP by many of DCCP's target applications (for instance, streaming media). Therefore, it is important to examine the relationship between DCCP and RTP and, in particular, the question of whether any changes in RTP are necessary or desirable when it is layered over DCCP instead of UDP. There are two potential sources of overhead in the RTP-over-DCCP combination: duplicated acknowledgement information and duplicated sequence numbers. Together, these sources of overhead add slightly more than 4 bytes per packet relative to RTP-over-UDP, and eliminating the redundancy would not reduce the overhead. First, consider acknowledgements. Both RTP and DCCP report feedback about loss rates to data senders, via RTP Control Protocol Sender and Receiver Reports (RTCP SR/RR packets) and via DCCP acknowledgement
Top   ToC   RFC4340 - Page 107
   options.  These feedback mechanisms are potentially redundant.
   However, RTCP SR/RR packets contain information not present in DCCP
   acknowledgements, such as "interarrival jitter", and DCCP's
   acknowledgements contain information not transmitted by RTCP, such as
   the ECN Nonce Echo.  Neither feedback mechanism makes the other
   redundant.

   Sending both types of feedback need not be particularly costly
   either.  RTCP reports may be sent relatively infrequently: once every
   5 seconds on average, for low-bandwidth flows.  In DCCP, some
   feedback mechanisms are expensive -- Ack Vector, for example, is
   frequent and verbose -- but others are relatively cheap: CCID 3
   (TFRC) acknowledgements take between 16 and 32 bytes of options sent
   once per round-trip time.  (Reporting less frequently than once per
   RTT would make congestion control less responsive to loss.)  We
   therefore conclude that acknowledgement overhead in RTP-over-DCCP
   need not be significantly higher than for RTP-over-UDP, at least for
   CCID 3.

   One clear redundancy can be addressed at the application level.  The
   verbose packet-by-packet loss reports sent in RTCP Extended Reports
   Loss RLE Blocks [RFC3611] can be derived from DCCP's Ack Vector
   options.  (The converse is not true, since Loss RLE Blocks contain no
   ECN information.)  Since DCCP implementations should provide an API
   for application access to Ack Vector information, RTP-over-DCCP
   applications might request either DCCP Ack Vectors or RTCP Extended
   Report Loss RLE Blocks, but not both.

   Now consider sequence number redundancy on data packets.  The
   embedded RTP header contains a 16-bit RTP sequence number.  Most data
   packets will use the DCCP-Data type; DCCP-DataAck and DCCP-Ack
   packets need not usually be sent.  The DCCP-Data header is 12 bytes
   long without options, including a 24-bit sequence number.  This is 4
   bytes more than a UDP header.  Any options required on data packets
   would add further overhead, although many CCIDs (for instance, CCID
   3, TFRC) don't require options on most data packets.

   The DCCP sequence number cannot be inferred from the RTP sequence
   number since it increments on non-data packets as well as data
   packets.  The RTP sequence number cannot be inferred from the DCCP
   sequence number either [RFC3550].  Furthermore, removing RTP's
   sequence number would not save any header space because of alignment
   issues.  We therefore recommend that RTP transmitted over DCCP use
   the same headers currently defined.  The 4 byte header cost is a
   reasonable tradeoff for DCCP's congestion control features and access
   to ECN.  Truly bandwidth-starved endpoints should use some header
   compression scheme.
Top   ToC   RFC4340 - Page 108

17.2. Congestion Manager and Multiplexing

Since DCCP doesn't provide reliable, ordered delivery, multiple application sub-flows may be multiplexed over a single DCCP connection with no inherent performance penalty. Thus, there is no need for DCCP to provide built-in support for multiple sub-flows. This differs from SCTP [RFC2960]. Some applications might want to share congestion control state among multiple DCCP flows that share the same source and destination addresses. This functionality could be provided by the Congestion Manager [RFC3124], a generic multiplexing facility. However, the CM would not fully support DCCP without change; it does not gracefully handle multiple congestion control mechanisms, for example.

18. Security Considerations

DCCP does not provide cryptographic security guarantees. Applications desiring cryptographic security services (integrity, authentication, confidentiality, access control, and anti-replay protection) should use IPsec or end-to-end security of some kind; Secure RTP is one candidate protocol [RFC3711]. Nevertheless, DCCP is intended to protect against some classes of attackers: Attackers cannot hijack a DCCP connection (close the connection unexpectedly, or cause attacker data to be accepted by an endpoint as if it came from the sender) unless they can guess valid sequence numbers. Thus, as long as endpoints choose initial sequence numbers well, a DCCP attacker must snoop on data packets to get any reasonable probability of success. Sequence number validity checks provide this guarantee. Section 7.5.5 describes sequence number security further. This security property only holds assuming that DCCP's random numbers are chosen according to the guidelines in [RFC4086]. DCCP also provides mechanisms to limit the potential impact of some denial-of-service attacks. These mechanisms include Init Cookie (Section 8.1.4), the DCCP-CloseReq packet (Section 5.5), the Application Not Listening Drop Code (Section 11.7.2), limitations on the processing of options that might cause connection reset (Section 7.5.5), limitations on the processing of some ICMP messages (Section 14.1), and various rate limits, which let servers avoid extensive computation or packet generation (Sections 7.5.3, 8.1.3, and others). DCCP provides no protection against attackers that can snoop on data packets.
Top   ToC   RFC4340 - Page 109

18.1. Security Considerations for Partial Checksums

The partial checksum facility has a separate security impact, particularly in its interaction with authentication and encryption mechanisms. The impact is the same in DCCP as in the UDP-Lite protocol, and what follows was adapted from the corresponding text in the UDP-Lite specification [RFC3828]. When a DCCP packet's Checksum Coverage field is not zero, the uncovered portion of a packet may change in transit. This is contrary to the idea behind most authentication mechanisms: authentication succeeds if the packet has not changed in transit. Unless authentication mechanisms that operate only on the sensitive part of packets are developed and used, authentication will always fail for partially-checksummed DCCP packets whose uncovered part has been damaged. The IPsec integrity check (Encapsulation Security Protocol, ESP, or Authentication Header, AH) is applied (at least) to the entire IP packet payload. Corruption of any bit within that area will then result in the IP receiver's discarding a DCCP packet, even if the corruption happened in an uncovered part of the DCCP application data. When IPsec is used with ESP payload encryption, a link can not determine the specific transport protocol of a packet being forwarded by inspecting the IP packet payload. In this case, the link MUST provide a standard integrity check covering the entire IP packet and payload. DCCP partial checksums provide no benefit in this case. Encryption (e.g., at the transport or application levels) may be used. Note that omitting an integrity check can, under certain circumstances, compromise confidentiality [B98]. If a few bits of an encrypted packet are damaged, the decryption transform will typically spread errors so that the packet becomes too damaged to be of use. Many encryption transforms today exhibit this behavior. There exist encryption transforms, stream ciphers, that do not cause error propagation. Proper use of stream ciphers can be quite difficult, especially when authentication checking is omitted [BB01]. In particular, an attacker can cause predictable changes to the ultimate plaintext, even without being able to decrypt the ciphertext.
Top   ToC   RFC4340 - Page 110

19. IANA Considerations

IANA has assigned IP Protocol Number 33 to DCCP. DCCP introduces eight sets of numbers whose values should be allocated by IANA. We refer to allocation policies, such as Standards Action, outlined in [RFC2434], and most registries reserve some values for experimental and testing use [RFC3692]. In addition, DCCP requires that the IANA Port Numbers registry be opened for DCCP port registrations; Section 19.9 describes how. The IANA should feel free to contact the DCCP Expert Reviewer with questions on any registry, regardless of the registry policy, for clarification or if there is a problem with a request.

19.1. Packet Types Registry

Each entry in the DCCP Packet Types registry contains a packet type, which is a number in the range 0-15; a packet type name, such as DCCP-Request; and a reference to the RFC defining the packet type. The registry is initially populated using the values in Table 1 (Section 5.1). This document allocates packet types 0-9, and packet type 14 is permanently reserved for experimental and testing use. Packet types 10-13 and 15 are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.

19.2. Reset Codes Registry

Each entry in the DCCP Reset Codes registry contains a Reset Code, which is a number in the range 0-255; a short description of the Reset Code, such as "No Connection"; and a reference to the RFC defining the Reset Code. The registry is initially populated using the values in Table 2 (Section 5.6). This document allocates Reset Codes 0-11, and Reset Codes 120-126 are permanently reserved for experimental and testing use. Reset Codes 12-119 and 127 are currently reserved and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards track or not) with IESG review and approval. Reset Codes 128-255 are permanently reserved for CCID-specific registries; each CCID Profile document describes how the corresponding registry is managed.

19.3. Option Types Registry

Each entry in the DCCP option types registry contains an option type, which is a number in the range 0-255; the name of the option, such as "Slow Receiver"; and a reference to the RFC defining the option type. The registry is initially populated using the values in Table 3 (Section 5.8). This document allocates option types 0-2 and 32-44,
Top   ToC   RFC4340 - Page 111
   and option types 31 and 120-126 are permanently reserved for
   experimental and testing use.  Option types 3-30, 45-119, and 127 are
   currently reserved and should be allocated with the IETF Consensus
   policy, requiring an IETF RFC publication (standards track or not)
   with IESG review and approval.  Option types 128-255 are permanently
   reserved for CCID-specific registries; each CCID Profile document
   describes how the corresponding registry is managed.

19.4. Feature Numbers Registry

Each entry in the DCCP feature numbers registry contains a feature number, which is a number in the range 0-255; the name of the feature, such as "ECN Incapable"; and a reference to the RFC defining the feature number. The registry is initially populated using the values in Table 4 (Section 6). This document allocates feature numbers 0-9, and feature numbers 120-126 are permanently reserved for experimental and testing use. Feature numbers 10-119 and 127 are currently reserved and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards track or not) with IESG review and approval. Feature numbers 128-255 are permanently reserved for CCID-specific registries; each CCID Profile document describes how the corresponding registry is managed.

19.5. Congestion Control Identifiers Registry

Each entry in the DCCP Congestion Control Identifiers (CCIDs) registry contains a CCID, which is a number in the range 0-255; the name of the CCID, such as "TCP-like Congestion Control"; and a reference to the RFC defining the CCID. The registry is initially populated using the values in Table 5 (Section 10). CCIDs 2 and 3 are allocated by concurrently published profiles, and CCIDs 248-254 are permanently reserved for experimental and testing use. CCIDs 0, 1, 4-247, and 255 are currently reserved and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards track or not) with IESG review and approval.

19.6. Ack Vector States Registry

Each entry in the DCCP Ack Vector States registry contains an Ack Vector State, which is a number in the range 0-3; the name of the State, such as "Received ECN Marked"; and a reference to the RFC defining the State. The registry is initially populated using the values in Table 6 (Section 11.4). This document allocates States 0, 1, and 3. State 2 is currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
Top   ToC   RFC4340 - Page 112

19.7. Drop Codes Registry

Each entry in the DCCP Drop Codes registry contains a Data Dropped Drop Code, which is a number in the range 0-7; the name of the Drop Code, such as "Application Not Listening"; and a reference to the RFC defining the Drop Code. The registry is initially populated using the values in Table 7 (Section 11.7). This document allocates Drop Codes 0-3 and 7. Drop Codes 4-6 are currently reserved, and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.

19.8. Service Codes Registry

Each entry in the Service Codes registry contains a Service Code, which is a number in the range 0-4294967294; a short English description of the intended service; and an optional reference to an RFC or other publicly available specification defining the Service Code. The registry should list the Service Code's numeric value as a decimal number. When the Service Code may be represented in "SC:" format according to the rules in Section 8.1.2, the registry should also show the corresponding ASCII interpretation of the Service Code minus the "SC:" prefix. Thus, the number 1717858426 would additionally appear as "fdpz". Service Codes are not DCCP-specific. Service Code 0 is permanently reserved (it represents the absence of a meaningful Service Code), and Service Codes 1056964608-1073741823 (high byte ASCII "?") are reserved for Private Use. Note that 4294967295 is not a valid Service Code. Most of the remaining Service Codes are allocated First Come First Served, with no RFC publication required; exceptions are listed in Section 8.1.2. This document allocates a single Service Code, 1145656131 ("DISC"). This corresponds to the discard service, which discards all data sent to the service and sends no data in reply.

19.9. Port Numbers Registry

DCCP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for DCCP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged
Top   ToC   RFC4340 - Page 113
   users, while Registered Ports can be used by ordinary user processes
   or programs executed by ordinary users.  Dynamic and/or Private Ports
   are intended for temporary use, including client-side ports, out-of-
   band negotiated ports, and application testing prior to registration
   of a dedicated port; they MUST NOT be registered.

   The Port Numbers registry should accept registrations for DCCP ports
   in the Well Known Ports and Registered Ports ranges.  Well Known and
   Registered Ports SHOULD NOT be used without registration.  Although
   in some cases -- such as porting an application from UDP to DCCP --
   it may seem natural to use a DCCP port before registration completes,
   we emphasize that IANA will not guarantee registration of particular
   Well Known and Registered Ports.  Registrations should be requested
   as early as possible.

   Each port registration SHALL include the following information:

   o  A short port name, consisting entirely of letters (A-Z and a-z),
      digits (0-9), and punctuation characters from "-_+./*" (not
      including the quotes).

   o  The port number that is requested to be registered.

   o  A short English phrase describing the port's purpose.  This MUST
      include one or more space-separated textual Service Code
      descriptors naming the port's corresponding Service Codes (see
      Section 8.1.2).

   o  Name and contact information for the person or entity performing
      the registration, and possibly a reference to a document defining
      the port's use.  Registrations coming from IETF working groups
      need only name the working group, but indicating a contact person
      is recommended.

   Registrants are encouraged to follow these guidelines when submitting
   a registration.

   o  A port name SHOULD NOT be registered for more than one DCCP port
      number.

   o  A port name registered for UDP MAY be registered for DCCP as well.
      Any such registration SHOULD use the same port number as the
      existing UDP registration.

   o  Concrete intent to use a port SHOULD precede port registration.
      For example, existing UDP ports SHOULD NOT be registered in
      advance of any intent to use those ports for DCCP.
Top   ToC   RFC4340 - Page 114
   o  A port name generally associated with TCP and/or SCTP SHOULD NOT
      be registered for DCCP, since that port name implies reliable
      transport.  For example, we discourage registration of any "http"
      port for DCCP.  However, if such a registration makes sense (that
      is, if there is concrete intent to use such a port), the DCCP
      registration SHOULD use the same port number as the existing
      registration.

   o  Multiple DCCP registrations for the same port number are allowed
      as long as the registrations' Service Codes do not overlap.

   This document registers the following port.  (This should be
   considered a model registration.)

   discard    9/dccp    Discard SC:DISC
   # IETF dccp WG, Eddie Kohler <kohler@cs.ucla.edu>, [RFC4340]

   The discard service, which accepts DCCP connections on port 9,
   discards all incoming application data and sends no data in response.
   Thus, DCCP's discard port is analogous to TCP's discard port, and
   might be used to check the health of a DCCP stack.

20. Thanks

Thanks to Jitendra Padhye for his help with early versions of this specification. Thanks to Junwen Lai and Arun Venkataramani, who, as interns at ICIR, built a prototype DCCP implementation. In particular, Junwen Lai recommended that the old feature negotiation mechanism be scrapped and co-designed the current mechanism. Arun Venkataramani's feedback improved Appendix A. We thank the staff and interns of ICIR and, formerly, ACIRI, the members of the End-to-End Research Group, and the members of the Transport Area Working Group for their feedback on DCCP. We especially thank the DCCP expert reviewers Greg Minshall, Eric Rescorla, and Magnus Westerlund for detailed written comments and problem spotting, and Rob Austein and Steve Bellovin for verbal comments and written notes. We also especially thank Aaron Falk, the working group chair during the development of this specification. We also thank those who provided comments and suggestions via the DCCP BOF, Working Group, and mailing lists, including Damon Lanphear, Patrick McManus, Colin Perkins, Sara Karlberg, Kevin Lai, Bernard Aboba, Youngsoo Choi, Pengfei Di, Dan Duchamp, Lars Eggert, Gorry Fairhurst, Derek Fawcus, David Timothy Fleeman, John Loughney, Ghyslain Pelletier, Hagen Paul Pfeifer, Tom Phelan, Stanislav
Top   ToC   RFC4340 - Page 115
   Shalunov, Somsak Vanit-Anunchai, David Vos, Yufei Wang, and Michael
   Welzl.  In particular, Colin Perkins provided extensive, detailed
   feedback, Michael Welzl suggested the Data Checksum option, Gorry
   Fairhurst provided extensive feedback on various checksum issues, and
   Somsak Vanit-Anunchai, Jonathan Billington, and Tul Kongprakaiwoot's
   Colored Petri Net model [VBK05] discovered several problems with
   message exchange.
Top   ToC   RFC4340 - Page 116

A. Appendix: Ack Vector Implementation Notes

This appendix discusses particulars of DCCP acknowledgement handling in the context of an abstract implementation for Ack Vector. It is informative and not normative. The first part of our implementation runs at the HC-Receiver, and therefore acknowledges data packets. It generates Ack Vector options. The implementation has the following characteristics: o At most one byte of state per acknowledged packet. o O(1) time to update that state when a new packet arrives (normal case). o Cumulative acknowledgements. o Quick removal of old state. The basic data structure is a circular buffer containing information about acknowledged packets. Each byte in this buffer contains a state and run length; the state can be 0 (packet received), 1 (packet ECN marked), or 3 (packet not yet received). The buffer grows from right to left. The implementation maintains five variables, aside from the buffer contents: o "buf_head" and "buf_tail", which mark the live portion of the buffer. o "buf_ackno", the Acknowledgement Number of the most recent packet acknowledged in the buffer. This corresponds to the "head" pointer. o "buf_nonce", the one-bit sum (exclusive-or, or parity) of the ECN Nonces received on all packets acknowledged by the buffer with State 0. We draw acknowledgement buffers like this: +---------------------------------------------------------------+ |S,L|S,L|S,L|S,L| | | | |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| +---------------------------------------------------------------+ ^ ^ buf_tail buf_head, buf_ackno = A buf_nonce = E <=== buf_head and buf_tail move this way <===
Top   ToC   RFC4340 - Page 117
   Each "S,L" represents a State/Run length byte.  We will draw these
   buffers showing only their live portion and will add an annotation
   showing the Acknowledgement Number for the last live byte in the
   buffer.  For example:

        +-----------------------------------------------+
      A |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| T    BN[E]
        +-----------------------------------------------+

   Here, buf_nonce equals E and buf_ackno equals A.

   We will use this buffer as a running example.

         +---------------------------+
      10 |0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0    BN[1]   [Example Buffer]
         +---------------------------+

   In concrete terms, its meaning is as follows:

      Packet 10 was received.  (The head of the buffer has sequence
      number 10, state 0, and run length 0.)

      Packets 9, 8, and 7 have not yet been received.  (The three bytes
      preceding the head each have state 3 and run length 0.)

      Packets 6, 5, 4, 3, and 2 were received.

      Packet 1 was ECN marked.

      Packet 0 was received.

      The one-bit sum of the ECN Nonces on packets 10, 6, 5, 4, 3, 2,
      and 0 equals 1.

   Additionally, the HC-Receiver must keep some information about the
   Ack Vectors it has recently sent.  For each packet sent carrying an
   Ack Vector, it remembers four variables:

   o  "ack_seqno", the Sequence Number used for the packet.  This is an
      HC-Receiver sequence number.

   o  "ack_ptr", the value of buf_head at the time of acknowledgement.

   o  "ack_runlen", the run length stored in the byte of buffer data at
      buf_head at the time of acknowledgement.
Top   ToC   RFC4340 - Page 118
   o  "ack_ackno", the Acknowledgement Number used for the packet.  This
      is an HC-Sender sequence number.  Since acknowledgements are
      cumulative, this single number completely specifies all necessary
      information about the packets acknowledged by this Ack Vector.

   o  "ack_nonce", the one-bit sum of the ECN Nonces for all State 0
      packets in the buffer from buf_head to ack_ackno, inclusive.
      Initially, this equals the Nonce Echo of the acknowledgement's Ack
      Vector (or, if the ack packet contained more than one Ack Vector,
      the exclusive-or of all the acknowledgement's Ack Vectors).  It
      changes as information about old acknowledgements is removed (so
      ack_ptr and buf_head diverge) and as old packets arrive (so they
      change from State 3 or State 1 to State 0).

A.1. Packet Arrival

This section describes how the HC-Receiver updates its acknowledgement buffer as packets arrive from the HC-Sender.

A.1.1. New Packets

When a packet with Sequence Number greater than buf_ackno arrives, the HC-Receiver updates buf_head (by moving it to the left appropriately), buf_ackno (which is set to the new packet's Sequence Number), and possibly buf_nonce (if the packet arrived unmarked with ECN Nonce 1), in addition to the buffer itself. For example, if HC-Sender packet 11 arrived ECN marked, the Example Buffer above would enter this new state (changes are marked with stars): ** +***----------------------------+ 11 |1,0|0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] ** +***----------------------------+ If the packet's state equals the state at the head of the buffer, the HC-Receiver may choose to increment its run length (up to the maximum). For example, if HC-Sender packet 11 arrived without ECN marking and with ECN Nonce 0, the Example Buffer might enter this state instead: ** +--*------------------------+ 11 |0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] ** +--*------------------------+
Top   ToC   RFC4340 - Page 119
   Of course, the new packet's sequence number might not equal the
   expected sequence number.  In this case, the HC-Receiver will enter
   the intervening packets as State 3.  If several packets are missing,
   the HC-Receiver may prefer to enter multiple bytes with run length 0,
   rather than a single byte with a larger run length; this simplifies
   table updates if one of the missing packets arrives.  For example, if
   HC-Sender packet 12 arrived with ECN Nonce 1, the Example Buffer
   would enter this state:

      ** +*******----------------------------+         *
      12 |0,0|3,0|0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0    BN[0]
      ** +*******----------------------------+         *

   Of course, the circular buffer may overflow when the HC-Sender is
   sending data at a very high rate, when the HC-Receiver's
   acknowledgements are not reaching the HC-Sender, or when the
   HC-Sender is forgetting to acknowledge those acks (so the HC-Receiver
   is unable to clean up old state).  In this case, the HC-Receiver
   should either compress the buffer (by increasing run lengths when
   possible), transfer its state to a larger buffer, or, as a last
   resort, drop all received packets, without processing them at all,
   until its buffer shrinks again.

A.1.2. Old Packets

When a packet with Sequence Number S <= buf_ackno arrives, the HC-Receiver will scan the table for the byte corresponding to S. (Indexing structures could reduce the complexity of this scan.) If S was previously lost (State 3), and it was stored in a byte with run length 0, the HC-Receiver can simply change the byte's state. For example, if HC-Sender packet 8 was received with ECN Nonce 0, the Example Buffer would enter this state: +--------*------------------+ 10 |0,0|3,0|0,0|3,0|0,4|1,0|0,0| 0 BN[1] +--------*------------------+ If S was not marked as lost, or if it was not contained in the table, the packet is probably a duplicate and should be ignored. (The new packet's ECN marking state might differ from the state in the buffer; Section 11.4.1 describes what is allowed then.) If S's buffer byte has a non-zero run length, then the buffer might need to be reshuffled to make space for one or two new bytes. The ack_nonce fields may also need manipulation when old packets arrive. In particular, when S transitions from State 3 or State 1 to State 0, and S had ECN Nonce 1, then the implementation should flip the value of ack_nonce for every acknowledgement with ack_ackno >= S.
Top   ToC   RFC4340 - Page 120
   It is impossible with this data structure to shift packets from State
   0 to State 1, since the buffer doesn't store individual packets' ECN
   Nonces.

A.2. Sending Acknowledgements

Whenever the HC-Receiver needs to generate an acknowledgement, the buffer's contents can simply be copied into one or more Ack Vector options. Copied Ack Vectors might not be maximally compressed; for example, the Example Buffer above contains three adjacent 3,0 bytes that could be combined into a single 3,2 byte. The HC-Receiver might, therefore, choose to compress the buffer in place before sending the option, or to compress the buffer while copying it; either operation is simple. Every acknowledgement sent by the HC-Receiver SHOULD include the entire state of the buffer. That is, acknowledgements are cumulative. If the acknowledgement fits in one Ack Vector, that Ack Vector's Nonce Echo simply equals buf_nonce. For multiple Ack Vectors, more care is required. The Ack Vectors should be split at points corresponding to previous acknowledgements, since the stored ack_nonce fields provide enough information to calculate correct Nonce Echoes. The implementation should therefore acknowledge data at least once per 253 bytes of buffer state. (Otherwise, there'd be no way to calculate a Nonce Echo.) For each acknowledgement it sends, the HC-Receiver will add an acknowledgement record. ack_seqno will equal the HC-Receiver sequence number it used for the ack packet; ack_ptr will equal buf_head; ack_runlen will equal the run length stored in the buffer's buf_head byte; ack_ackno will equal buf_ackno; and ack_nonce will equal buf_nonce.

A.3. Clearing State

Some of the HC-Sender's packets will include acknowledgement numbers, which ack the HC-Receiver's acknowledgements. When such an ack is received, the HC-Receiver finds the acknowledgement record R with the appropriate ack_seqno and then does the following: o If the run length in the buffer's R.ack_ptr byte is greater than R.ack_runlen, then it decrements that run length by R.ack_runlen + 1 and sets buf_tail to R.ack_ptr. Otherwise, it sets buf_tail to R.ack_ptr + 1.
Top   ToC   RFC4340 - Page 121
   o  If R.ack_nonce is 1, it flips buf_nonce, and the value of
      ack_nonce for every later ack record.

   o  It throws away R and every preceding ack record.

   (The HC-Receiver may choose to keep some older information, in case a
   lost packet shows up late.)  For example, say that the HC-Receiver
   storing the Example Buffer had sent two acknowledgements already:

   1. ack_seqno = 59, ack_runlen = 1, ack_ackno = 3, ack_nonce = 1.

   2. ack_seqno = 60, ack_runlen = 0, ack_ackno = 10, ack_nonce = 0.

   Say the HC-Receiver then received a DCCP-DataAck packet with
   Acknowledgement Number 59 from the HC-Sender.  This informs the
   HC-Receiver that the HC-Sender received, and processed, all the
   information in HC-Receiver packet 59.  This packet acknowledged
   HC-Sender packet 3, so the HC-Sender has now received HC-Receiver's
   acknowledgements for packets 0, 1, 2, and 3.  The Example Buffer
   should enter this state:

               +------------------*+ *       *
            10 |0,0|3,0|3,0|3,0|0,2| 4    BN[0]
               +------------------*+ *       *

   The tail byte's run length was adjusted, since packet 3 was in the
   middle of that byte.  Since R.ack_nonce was 1, the buf_nonce field
   was flipped, as were the ack_nonce fields for later acknowledgements
   (here, the HC-Receiver Ack 60 record, not shown, has its ack_nonce
   flipped to 1).  The HC-Receiver can also throw away stored
   information about HC-Receiver Ack 59 and any earlier
   acknowledgements.

   A careful implementation might try to ensure reasonable robustness to
   reordering.  Suppose that the Example Buffer is as before, but that
   packet 9 now arrives, out of sequence.  The buffer would enter this
   state:

                +----*----------------------+
             10 |0,0|0,0|3,0|3,0|0,4|1,0|0,0| 0     BN[1]
                +----*----------------------+

   The danger is that the HC-Sender might acknowledge the HC-Receiver's
   previous acknowledgement (with sequence number 60), which says that
   Packet 9 was not received, before the HC-Receiver has a chance to
   send a new acknowledgement saying that Packet 9 actually was
   received.  Therefore, when packet 9 arrived, the HC-Receiver might
   modify its acknowledgement record as follows:
Top   ToC   RFC4340 - Page 122
   1. ack_seqno = 59, ack_ackno = 3, ack_nonce = 1.

   2. ack_seqno = 60, ack_ackno = 3, ack_nonce = 1.

   That is, Ack 60 is now treated like a duplicate of Ack 59.  This
   would prevent the Tail pointer from moving past packet 9 until the
   HC-Receiver knows that the HC-Sender has seen an Ack Vector
   indicating that packet's arrival.

A.4. Processing Acknowledgements

When the HC-Sender receives an acknowledgement, it generally cares about the number of packets that were dropped and/or ECN marked. It simply reads this off the Ack Vector. Additionally, it should check the ECN Nonce for correctness. (As described in Section 11.4.1, it may want to keep more detailed information about acknowledged packets in case packets change states between acknowledgements, or in case the application queries whether a packet arrived.) The HC-Sender must also acknowledge the HC-Receiver's acknowledgements so that the HC-Receiver can free old Ack Vector state. (Since Ack Vector acknowledgements are reliable, the HC-Receiver must maintain and resend Ack Vector information until it is sure that the HC-Sender has received that information.) A simple algorithm suffices: since Ack Vector acknowledgements are cumulative, a single acknowledgement number tells HC-Receiver how much ack information has arrived. Assuming that the HC-Receiver sends no data, the HC-Sender can ensure that at least once a round-trip time, it sends a DCCP-DataAck packet acknowledging the latest DCCP-Ack packet it has received. Of course, the HC-Sender only needs to acknowledge the HC-Receiver's acknowledgements if the HC-Sender is also sending data. If the HC-Sender is not sending data, then the HC-Receiver's Ack Vector state is stable, and there is no need to shrink it. The HC-Sender must watch for drops and ECN marks on received DCCP-Ack packets so that it can adjust the HC-Receiver's ack-sending rate in response to congestion, for example, with Ack Ratio. If the other half-connection is not quiescent -- that is, the HC-Receiver is sending data to the HC-Sender, possibly using another CCID -- then the acknowledgements on that half-connection are sufficient for the HC-Receiver to free its state.
Top   ToC   RFC4340 - Page 123

B. Appendix: Partial Checksumming Design Motivation

A great deal of discussion has taken place regarding the utility of allowing a DCCP sender to restrict the checksum so that it does not cover the complete packet. This section attempts to capture some of the rationale behind specific details of DCCP design. Many of the applications that we envisage using DCCP are resilient to some degree of data loss, or they would typically have chosen a reliable transport. Some of these applications may also be resilient to data corruption -- some audio payloads, for example. These resilient applications might rather receive corrupted data than have DCCP drop corrupted packets. This is particularly because of congestion control: DCCP cannot tell the difference between packets dropped due to corruption and packets dropped due to congestion, and so it must reduce the transmission rate accordingly. This response may cause the connection to receive less bandwidth than it is due; corruption in some networking technologies is independent of, or at least not always correlated to, congestion. Therefore, corrupted packets do not need to cause as strong a reduction in transmission rate as the congestion response would dictate (as long as the DCCP header and options are not corrupt). Thus DCCP allows the checksum to cover all of the packet, just the DCCP header, or both the DCCP header and some number of bytes from the application data. If the application cannot tolerate any data corruption, then the checksum must cover the whole packet. If the application would prefer to tolerate some corruption rather than have the packet dropped, then it can set the checksum to cover only part of the packet (but always the DCCP header). In addition, if the application wishes to decouple checksumming of the DCCP header from checksumming of the application data, it may do so by including the Data Checksum option. This would allow DCCP to discard corrupted application data without mistaking the corruption for network congestion. Thus, from the application point of view, partial checksums seem to be a desirable feature. However, the usefulness of partial checksums depends on partially corrupted packets being delivered to the receiver. If the link-layer CRC always discards corrupted packets, then this will not happen, and so the usefulness of partial checksums would be restricted to corruption that occurred in routers and other places not covered by link CRCs. There does not appear to be consensus on how likely it is that future network links that suffer significant corruption will not cover the entire packet with a single strong CRC. DCCP makes it possible to tailor such links to the application, but it is difficult to predict if this will be compelling for future link technologies.
Top   ToC   RFC4340 - Page 124
   In addition, partial checksums do not co-exist well with IP-level
   authentication mechanisms such as IPsec AH, which cover the entire
   packet with a cryptographic hash.  Thus, if cryptographic
   authentication mechanisms are required to co-exist with partial
   checksums, the authentication must be carried in the application
   data.  A possible mode of usage would appear to be similar to that of
   Secure RTP.  However, such "application-level" authentication does
   not protect the DCCP option negotiation and state machine from forged
   packets.  An alternative would be to use IPsec ESP, and to use
   encryption to protect the DCCP headers against attack, while using
   the DCCP header validity checks to authenticate that the header is
   from someone who possessed the correct key.  While this is resistant
   to replay (due to the DCCP sequence number), it is not by itself
   resistant to some forms of man-in-the-middle attacks because the
   application data is not tightly coupled to the packet header.  Thus,
   an application-level authentication probably needs to be coupled with
   IPsec ESP or a similar mechanism to provide a reasonably complete
   security solution.  The overhead of such a solution might be
   unacceptable for some applications that would otherwise wish to use
   partial checksums.

   On balance, the authors believe that DCCP partial checksums have the
   potential to enable some future uses that would otherwise be
   difficult.  As the cost and complexity of supporting them is small,
   it seems worth including them at this time.  It remains to be seen
   whether they are useful in practice.

Normative References

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
Top   ToC   RFC4340 - Page 125
   [RFC3309]      Stone, J., Stewart, R., and D. Otis, "Stream Control
                  Transmission Protocol (SCTP) Checksum Change", RFC
                  3309, September 2002.

   [RFC3692]      Narten, T., "Assigning Experimental and Testing
                  Numbers Considered Useful", BCP 82, RFC 3692, January
                  2004.

   [RFC3775]      Johnson, D., Perkins, C., and J. Arkko, "Mobility
                  Support in IPv6", RFC 3775, June 2004.

   [RFC3828]      Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
                  and G. Fairhurst, "The Lightweight User Datagram
                  Protocol (UDP-Lite)", RFC 3828, July 2004.

Informative References

[B98] Bellovin, S.M., "Cryptography and the Internet", CRYPTO '98 (LNCS 1462), pp 46-55, August 1988. [BB01] Bellovin, S.M. and M. Blaze, "Cryptographic Modes of Operation for the Internet", 2nd NIST Workshop on Modes of Operation, August 2001. [M85] Morris, R.T., "A Weakness in the 4.2BSD Unix TCP/IP Software", Computer Science Technical Report 117, AT&T Bell Laboratories, Murray Hill, NJ, February 1985. [PMTUD] Mathis, M. and J. Heffner, "Path MTU Discovery", Work in Progress, March 2006. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
Top   ToC   RFC4340 - Page 126
   [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [RFC2463]      Conta, A. and S. Deering, "Internet Control Message
                  Protocol (ICMPv6) for the Internet Protocol Version 6
                  (IPv6) Specification", RFC 2463, December 1998.

   [RFC2581]      Allman, M., Paxson, V., and W. Stevens, "TCP
                  Congestion Control", RFC 2581, April 1999.

   [RFC2960]      Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
                  Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
                  Zhang, L., and V. Paxson, "Stream Control Transmission
                  Protocol", RFC 2960, October 2000.

   [RFC3124]      Balakrishnan, H. and S. Seshan, "The Congestion
                  Manager", RFC 3124, June 2001.

   [RFC3360]      Floyd, S., "Inappropriate TCP Resets Considered
                  Harmful", BCP 60, RFC 3360, August 2002.

   [RFC3448]      Handley, M., Floyd, S., Padhye, J., and J. Widmer,
                  "TCP Friendly Rate Control (TFRC): Protocol
                  Specification", RFC 3448, January 2003.

   [RFC3540]      Spring, N., Wetherall, D., and D. Ely, "Robust
                  Explicit Congestion Notification (ECN) Signaling with
                  Nonces", RFC 3540, June 2003.

   [RFC3550]      Schulzrinne, H., Casner, S., Frederick, R., and V.
                  Jacobson, "RTP: A Transport Protocol for Real-Time
                  Applications", STD 64, RFC 3550, July 2003.

   [RFC3611]      Friedman, T., Caceres, R., and A. Clark, "RTP Control
                  Protocol Extended Reports (RTCP XR)", RFC 3611,
                  November 2003.

   [RFC3711]      Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                  K. Norrman, "The Secure Real-time Transport Protocol
                  (SRTP)", RFC 3711, March 2004.

   [RFC3819]      Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
                  Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
                  and L. Wood, "Advice for Internet Subnetwork
                  Designers", BCP 89, RFC 3819, July 2004.
Top   ToC   RFC4340 - Page 127
   [RFC4086]      Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                  "Randomness Requirements for Security", BCP 106, RFC
                  4086, June 2005.

   [RFC4341]      Floyd, S. and E. Kohler, "Profile for Datagram
                  Congestion Control Protocol (DCCP) Congestion Control
                  ID 2: TCP-like Congestion Control", RFC 4341, March
                  2006.

   [RFC4342]      Floyd, S., Kohler, E., and J. Padhye, "Profile for
                  Datagram Congestion Control Protocol (DCCP) Congestion
                  Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC
                  4342, March 2006.

   [SHHP00]       Spatscheck, O., Hansen, J.S., Hartman, J.H., and L.L.
                  Peterson, "Optimizing TCP Forwarder Performance",
                  IEEE/ACM Transactions on Networking 8(2):146-157,
                  April 2000.

   [SYNCOOKIES]   Bernstein, D.J., "SYN Cookies",
                  http://cr.yp.to/syncookies.html, as of March 2006.

   [VBK05]        Vanit-Anunchai, S., Billington, J., and T.
                  Kongprakaiwoot, "Discovering Chatter and
                  Incompleteness in the Datagram Congestion Control
                  Protocol", FORTE 2005, pp 143-158, October 2005.
Top   ToC   RFC4340 - Page 128

Authors' Addresses

Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA EMail: kohler@cs.ucla.edu Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA EMail: floyd@icir.org
Top   ToC   RFC4340 - Page 129
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).