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.
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.
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
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
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
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
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
cannot be an unknown value. A DCCP MUST respond with an empty
Confirm option if it is assigned an unacceptable value for some
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
Section 19 lists DCCP assigned numbers reserved for experimental and
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
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.
17. Relations to Other Specifications
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
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
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
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
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
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 (Section14.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
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
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
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
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,
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.
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
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
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
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
Registrants are encouraged to follow these guidelines when submitting
o A port name SHOULD NOT be registered for more than one DCCP port
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.
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
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 <firstname.lastname@example.org>, [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.
Thanks to Jitendra Padhye for his help with early versions of this
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
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
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
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
o "buf_ackno", the Acknowledgement Number of the most recent packet
acknowledged in the buffer. This corresponds to the "head"
o "buf_nonce", the one-bit sum (exclusive-or, or parity) of the ECN
Nonces received on all packets acknowledged by the buffer with
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 <===
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 [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.
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
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
11 |0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN
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
** +*******----------------------------+ *
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
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.
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
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
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
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.
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
+------------------*+ * *
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
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
10 |0,0|0,0|3,0|3,0|0,4|1,0|0,0| 0 BN
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:
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
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.
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
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.
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
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.
[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.
[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
[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.
[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,
[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,
[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.
[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
[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,
[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.
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
Department of Computer Science
University College London
London WC1E 6BT
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704
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.
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
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-
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).