@@ Page 9 @@ connections. o Congestion control incorporating Explicit Congestion Notification - (ECN) and the ECN Nonce, as per [RFC 3168] and [RFC 3540]. + (ECN) [RFC 3168] and the ECN Nonce [RFC 3540]. o Acknowledgement mechanisms communicating packet loss and ECN information. Acks are transmitted as reliably as the relevant @@ Page 9 @@ those packets were ECN marked, corrupted, or dropped in the receive buffer. - o Path Maximum Transmission Unit (PMTU) discovery, as per [RFC - 1191]. + o Path Maximum Transmission Unit (PMTU) discovery [RFC 1191]. o A choice of modular congestion control mechanisms. Two mechanisms are currently specified, TCP-like Congestion Control @@ Page 10 @@ TCP. Applications using this congestion control mechanism will respond quickly to changes in available bandwidth, but must tolerate the abrupt changes in congestion window typical of TCP. A second - alternative, TCP-Friendly Rate Control (TFRC, [RFC 3448]), a form of + alternative, TCP-Friendly Rate Control (TFRC) [RFC 3448], a form of equation-based congestion control, minimizes abrupt changes in the sending rate while maintaining longer-term fairness with TCP. Other alternatives can be added as future congestion control mechanisms @@ Page 11 @@ this document, to suit any application desiring unicast congestion- controlled streams of unreliable datagrams. The congestion control mechanisms currently approved for use with DCCP, which are described - in separate Congestion Control ID Profiles [CCID 2 PROFILE] [CCID 3 + in separate Congestion Control ID Profiles [CCID 2 PROFILE, CCID 3 PROFILE], may, however, cause problems for some applications, including high-bandwidth interactive video. These applications should be able to use DCCP once suitable Congestion Control ID @@ Page 11 @@ 3. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in [RFC 2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. 3.1. Numbers and Fields @@ Page 11 @@ means towards the least significant bit. Random numbers in DCCP are used for their security properties, and - SHOULD be chosen according to the guidelines in [RFC 1750]. + SHOULD be chosen according to the guidelines in RFC 1750. All operations on DCCP sequence numbers, and comparisons such as "greater" and "greatest", use circular arithmetic modulo 2**48. @@ Page 11 @@ technique for implementing circular comparison using two's- complement arithmetic, whereby A < B using circular arithmetic if and only if (A - B) < 0 using conventional two's-complement - arithmetic, may be used for DCCP sequence numbers, providing they - are stored in the most significant 48 bits of 64-bit integers. + arithmetic, may be used for DCCP sequence numbers, provided they are + stored in the most significant 48 bits of 64-bit integers. Reserved bitfields in DCCP packet headers MUST be set to zero by senders, and MUST be ignored by receivers, unless otherwise @@ Page 18 @@ Section 10 describes DCCP's CCIDs in more detail. The behaviors of CCIDs 2 and 3 are fully defined in separate profile documents [CCID - 2 PROFILE] [CCID 3 PROFILE]. + 2 PROFILE, CCID 3 PROFILE]. 4.5. Features @@ Page 34 @@ Options are processed sequentially, starting at the first option in - the packet header. Options with unknown types, and options with - invalid lengths (length byte less than two or more than the - remaining space in the options portion of the header), MUST be - ignored. + the packet header. Options with unknown types MUST be ignored. + Also, options with nonsensical lengths (length byte less than two or + more than the remaining space in the options portion of the header) + MUST be ignored, and any option space following an option with + nonsensical length MUST likewise be ignored. The following options are currently defined: @@ Page 34 @@ when received on a DCCP-Data packet. (Section 7.5.5 describes why such options are ignored as opposed to, say, causing a reset.) + Options with invalid values MUST be ignored unless otherwise + specified. For example, any Data Checksum option with option length + 4 MUST be ignored, since all valid Data Checksum options have option + + + + + + length 6. This section describes two generic options, Padding and Mandatory. Other options are described later. @@ Page 35 @@ Padding is a single-byte "no-operation" option used to pad between or after options. If the length of a packet's other options is not - a multiple of 4, then Padding options are REQUIRED to pad out the - options area to the length implied by Data Offset. Padding may also - be used between options -- for example, to align the beginning of a - subsequent option on a word boundary. There is no guarantee that - senders will use this option, so receivers must be prepared to + a multiple of 32 bits, then Padding options are REQUIRED to pad out + the options area to the length implied by Data Offset. Padding may + also be used between options -- for example, to align the beginning + of a subsequent option on a 32-bit boundary. There is no guarantee + that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary. 5.8.2. Mandatory Option @@ Page 35 @@ +--------+ Type=1 - Mandatory is a single byte option that marks the immediately + Mandatory is a single-byte option that marks the immediately following option as mandatory. Say that the immediately following option is O. Then the Mandatory option has no effect if the receiving DCCP endpoint understands and processes O. If the @@ Page 40 @@ priority feature); DCCP A's preferred values are 2 and 3, in that preference order. - Change L(Sequence Window, 1024) = 32,6,3,0,4,0 + Change L(Sequence Window, 1024) = 32,9,3,0,0,0,0,4,0 DCCP B should change Sequence Window/A's value (feature number - 3, a non-negotiable feature) to the 3-byte string 0,4,0 (the - value 1024). + 3, a non-negotiable feature) to the 6-byte string 0,0,0,0,4,0 + (the value 1024). Confirm L(CCID, 2, 2 3) = 33,6,1,2,2,3 DCCP A has changed CCID/A's value to 2; its preferred values are @@ Page 41 @@ were 3 and 2, in that preference order. - Confirm R(Sequence Window, 1024) = 35,6,3,0,4,0 - DCCP A has changed Sequence Window/B's value to the 3-byte - string 0,4,0 (the value 1024). + Confirm R(Sequence Window, 1024) = 35,9,3,0,0,0,0,4,0 + DCCP A has changed Sequence Window/B's value to the 6-byte + string 0,0,0,0,4,0 (the value 1024). Empty Confirm R(126) = 35,3,126 DCCP A doesn't implement feature number 126, or DCCP B's @@ Page 42 @@ reordered Change option MUST result in a corresponding Confirm option, and any packet including a Confirm option MUST carry an - Acknowledgement Number. Generated Confirm options may be attached - to packets that would have been sent anyway (such as DCCP-Response - or DCCP-SyncAck), or to new feature negotiation packets, as - described above. + Acknowledgement Number. (Section 6.6.4 describes how Change + reordering is detected and handled.) Generated Confirm options may + be attached to packets that would have been sent anyway (such as + DCCP-Response or DCCP-SyncAck), or to new feature negotiation + packets, as described above. The Change-sending endpoint MUST wait to receive a corresponding Confirm option before changing its stored feature value. The @@ Page 47 @@ such options are invalid, depending on the relevant reconciliation rule (Section 6.3). For instance: - o All features have length limitiations, and options with invalid + o All features have length limitations, and options with invalid lengths are invalid. For example, the Ack Ratio feature takes 16-bit values, so valid "Confirm R(Ack Ratio)" options have option length 5. @@ Page 49 @@ numbers that a future connection would use [M85]. These problems are the same as problems faced by TCP, and DCCP - implementations SHOULD use TCP's strategies to avoid them [RFC 793] - [RFC 1948]. The rest of this section explains these strategies in + implementations SHOULD use TCP's strategies to avoid them [RFC 793, + RFC 1948]. The rest of this section explains these strategies in more detail. To address the first problem, an implementation MUST ensure that the @@ Page 52 @@ Sequence Window/A value is W. Sequence Window has feature number 3, and is non-negotiable. It - takes 48-bit (6-byte) integer values, like DCCP sequence numbers, - but 1- to 5-byte values are also allowed in options; the receiver - will pad on the left with zero bytes as necessary to total 48 bits. - Change and Confirm options for Sequence Window are therefore between - 4 and 9 bytes long. New connections start with Sequence Window 100 - for both endpoints. The minimum valid Sequence Window value is - Wmin = 32. The maximum valid Sequence Window value is Wmax = - 2^46 - 1 = 70368744177663; circular sequence number comparisons - would stop working absent this constraint. Change options - suggesting Sequence Window values out of this range are invalid and - MUST be handled accordingly. + takes 48-bit (6-byte) integer values, like DCCP sequence numbers. + + + + + + Change and Confirm options for Sequence Window are therefore 9 bytes + long. New connections start with Sequence Window 100 for both + endpoints. The minimum valid Sequence Window value is Wmin = 32. + The maximum valid Sequence Window value is Wmax = 2^46 - 1 = + 70368744177663; circular sequence number comparisons would stop + working absent this constraint. Change options suggesting Sequence + Window values out of this range are invalid and MUST be handled + accordingly. A proper Sequence Window/A value must reflect the number of packets DCCP A expects to be in flight. Only DCCP A can anticipate this @@ Page 62 @@ also carry application data, but the client should be aware that the server may not accept such data. - A client in the REQUEST state SHOULD send use an exponential-backoff + A client in the REQUEST state SHOULD use an exponential-backoff timer to send new DCCP-Request packets if no response is received. The first retransmission should occur after approximately one second, backing off to not less than one packet every 64 seconds; or @@ Page 63 @@ response to packets whose Service Code is considered unsuitable. Service Codes are not intended to be DCCP-specific, and are - allocated by IANA. Following the policies outlined in [RFC 2434], + allocated by IANA. Following the policies outlined in RFC 2434, most Service Codes are allocated First Come First Served, subject to the following guidelines. @@ Page 64 @@ reserved for Private Use. o Service Code 0 represents the absence of a meaningful Service - Code, and MUST never be allocated. + Code, and MUST NOT be allocated. This design for Service Code allocation is based on the allocation of 4-byte identifiers for Macintosh resources, PNG chunks, and @@ Page 75 @@ long, and consists of the IPv4 source and destination addresses, the IP protocol number for DCCP (padded on the left with 8 zero bits), and the DCCP length as a 16-bit quantity (the length of the DCCP - header with options, plus the length of any data); see Section 3.1 - of [RFC 793]. For IPv6, it is 320 bits long, and consists of the + header with options, plus the length of any data); see RFC 793 + (Section 3.1). For IPv6, it is 320 bits long, and consists of the IPv6 source and destination addresses, the DCCP length as a 32-bit quantity, and the IP protocol number for DCCP (padded on the left - with 24 zero bits); see Section 8.1 of [RFC 2460]. + with 24 zero bits); see RFC 2460 (Section 8.1). Packets with invalid header checksums MUST be ignored. In particular, their options MUST NOT be processed. @@ Page 78 @@ 9.3.2. Usage Notes Internet links must normally apply strong integrity checks to the - packets they transmit [RFC 3828] [RFC 3819]. This is the default + packets they transmit [RFC 3828, RFC 3819]. This is the default case when the DCCP header's Checksum Coverage value equals zero (full coverage). However, the DCCP Checksum Coverage value might not be zero. By setting partial Checksum Coverage, the application @@ Page 80 @@ relatively smooth sending rate is of importance. CCID 3 is further described in [CCID 3 PROFILE]. The TFRC - congestion control algorithms were initially described in [RFC - 3448]. + congestion control algorithms were initially described in RFC 3448. 10.3. CCID-Specific Options, Features, and Reset Codes @@ Page 84 @@ Update message [RFC 3775] SHOULD reset its congestion state for any corresponding DCCP connections. + A DCCP implementation MAY also reset its congestion state when a + CCID changes (that is, a negotiation for the CCID feature completes + successfully, and the new feature value differs from the old value). + Thus, a connection in a heavily congested environment might evade + end-to-end congestion control by frequently renegotiating a CCID, + just as it could evade end-to-end congestion control by opening new + connections for the same session. This behavior is prohibited. To + prevent it, DCCP implementations MAY limit the rate at which CCID + can be changed -- for instance, by refusing to change a CCID feature + value more than once per minute. 11. Acknowledgements @@ Page 96 @@ packet, or that disagree with Ack Vector or equivalent options (by reporting a "not yet received" packet as "dropped in the receive buffer", for example), SHOULD be considered invalid. The receiving - DCCP SHOULD either such options, or respond by resetting the + DCCP SHOULD either ignore such options, or respond by resetting the connection with Reset Code 5, "Option Error". A DCCP application interface should let receiving applications @@ Page 98 @@ state for the packet by that time, so the Data Dropped report will have no effect.) Every packet newly acknowledged as Drop Code 2 SHOULD reduce the sender's instantaneous rate by one packet per - round-trip time. Each CCID profile defines the CCID-specific - mechanism by which this is accomplished. + round-trip time, unless the sender is already sending one packet per + RTT or less. Each CCID profile defines the CCID-specific mechanism + by which this is accomplished. Currently, the other Drop Codes, namely Drop Code 3, Corrupt, Drop Code 7, Delivered Corrupt, and reserved Drop Codes 4-6, MUST cause @@ Page 100 @@ sender may react punitively to an ECN Nonce mismatch, possibly up to dropping the connection. The ECN Nonce Echo field need not be an integer; one bit is enough to catch 50% of infractions, and the - probability of success drops exponentially as more bits are sent + probability of success drops exponentially as more packets are sent [RFC 3540]. In DCCP, the ECN Nonce Echo field is encoded in acknowledgement @@ Page 102 @@ The option data, Elapsed Time, represents an estimated upper bound on the amount of time elapsed since the packet being acknowledged - was received, with units of tenths of milliseconds. If Elapsed Time - is less than a half-second, the first, smaller form of the option - SHOULD be used. Elapsed Times of more than 0.65535 seconds MUST be - sent using the second form of the option. The special Elapsed Time - value 4294967295, which corresponds to approximately 11.9 hours, is - used to represent any Elapsed Time greater than 42949.67294 seconds. - DCCP endpoints MUST NOT report Elapsed Times that are significantly - larger than the true elapsed times. A connection MAY be reset with - Reset Code 11, "Aggression Penalty", if one endpoint determines that - the other is reporting a much-too-large Elapsed Time. + was received, with units of hundredths of milliseconds. If Elapsed + Time is less than a half-second, the first, smaller form of the + option SHOULD be used. Elapsed Times of more than 0.65535 seconds + MUST be sent using the second form of the option. The special + Elapsed Time value 4294967295, which corresponds to approximately + 11.9 hours, is used to represent any Elapsed Time greater than + 42949.67294 seconds. DCCP endpoints MUST NOT report Elapsed Times + that are significantly larger than the true elapsed times. A + connection MAY be reset with Reset Code 11, "Aggression Penalty", if + one endpoint determines that the other is reporting a much-too-large + Elapsed Time. @@ Page 104 @@ 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. As specified in [RFC 1191], 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 Section 7 of [RFC 1191]. If - the MTU given in the message is greater than the current PMTU, the - Datagram Too Big message is ignored, as described in [RFC 1191]. - (We are aware that this may cause problems for DCCP endpoints behind - certain firewalls.) + packets are unfragmentable once emitted by an end host. As + specified in RFC 1191, 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 RFC 1191 (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 RFC 1191. (We are aware that this may + cause problems for DCCP endpoints behind certain firewalls.) A DCCP implementation may allow the application to occasionally request that PMTU discovery be performed again. This will reset the @@ Page 105 @@ 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. (Routers are not - required to return more than 64 bits of the DCCP header [RFC 792], - but most modern routers will return far more, including 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. + 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 [RFC 1812] or the minimum IPv6 + MTU [RFC 2463], although they are not required to return more than + 64 bits [RFC 792]. 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, then gradually @@ Page 110 @@ 18. Security Considerations DCCP does not provide cryptographic security guarantees. - Applications desiring hard security should use IPsec or end-to-end - security of some kind. + 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 [RFC 3711]. @@ Page 111 @@ 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 [RFC 1750]. + number security further. This security property only holds assuming + that DCCP's random numbers are chosen according to the guidelines in + RFC 1750. + + 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. @@ Page 112 @@ too damaged to be of use. Many encryption transforms today exhibit this behavior. There exist encryption transforms, stream ciphers, which do not cause error propagation. Proper use of stream ciphers - can be quite difficult, especially when authentication-checking is + 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. @@ Page 112 @@ DCCP introduces eight sets of numbers whose values should be allocated by IANA. We refer to allocation policies, such as - Standards Action, outlined in [RFC 2434], and most registries - reserve some values for experimental and testing use [RFC 3692]. In + Standards Action, outlined in RFC 2434, and most registries reserve + some values for experimental and testing use [RFC 3692]. In addition, DCCP requires a Protocol Number to be added to the registry of Assigned Internet Protocol Numbers. IANA is requested to assign IP Protocol Number 33 to DCCP; this number has already @@ Page 112 @@ (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 IETF - working group review and standards-track RFC publication. + allocated with the Standards Action policy, which requires IESG + review and approval and standards-track IETF RFC publication. 19.2. Reset Codes @@ Page 113 @@ 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, which requires RFC publication (not necessarily standards- - track). Reset Codes 128-255 are permanently reserved for CCID- - specific registries; each CCID Profile document describes how the - corresponding registry is managed. + 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 @@ Page 113 @@ 32-44, 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, which requires RFC publication (not necessarily - standards-track). Option types 128-255 are permanently reserved for - CCID-specific registries; each CCID Profile document describes how - the corresponding registry is managed. + 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 @@ Page 113 @@ 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, which requires RFC publication (not - necessarily standards-track). Feature numbers 128-255 are - permanently reserved for CCID-specific registries; each CCID Profile - document describes how the corresponding registry is managed. + 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 @@ Page 114 @@ 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, which requires RFC publication (not - necessarily standards-track). + the IETF Consensus policy, requiring an IETF RFC publication + (standards-track or not) with IESG review and approval. 19.6. Ack Vector States @@ Page 114 @@ 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 IETF working group - review and standards-track RFC publication. + with the Standards Action policy, which requires IESG review and + approval and standards-track IETF RFC publication. 19.7. Drop Codes @@ Page 114 @@ 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 - IETF working group review and standards-track RFC publication. + IESG review and approval and standards-track IETF RFC publication. 19.8. Service Codes @@ Page 115 @@ 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 codesigned the current mechanism. Arun Venkataramani's - feedback improved Appendix A. + 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 @@ Page 125 @@ [RFC 1750] D. Eastlake, S. Crocker, and J. Schiller. Randomness Recommendations for Security. RFC 1750. + [RFC 1812] F. Baker, editor. Requirements for IP Version 4 Routers. + RFC 1812. [RFC 1948] S. Bellovin. Defending Against Sequence Number Attacks. RFC 1948. @@ Page 125 @@ [RFC 2401] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401. + [RFC 2463] A. Conta and S. Deering. Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) + Specification. RFC 2463. [RFC 2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control. RFC 2581. @@ Page 126 @@ [RFC 3611] T. Friedman, R. Caceres, and A. Clark, editors. RTP Control Protocol Extended Reports (RTCP XR). RFC 3611. + [RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. + Norrman. The Secure Real-time Transport Protocol (SRTP). + RFC 3711. [RFC 3819] P. Karn, editor, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, and L. Wood.