Previous

Content

Next 

4.0.- Packet Format  

Generic Packet Header
 All DCCP packets begin with a generic DCCP packet header:

Source and Destination Ports: 16 bits each
 
  These fields identify the connection, similar to the corresponding fields in TCP and UDP. The Source Port represents the relevant port on the endpoint that sent this packet, the Destination Port the relevant port on the other endpoint.  
 Type: 4 bits
 
  The type field specifies the type of the DCCP message. The following values are defined:
 
0 DCCP-Request packet.
1 DCCP-Response packet.
2 DCCP-Data packet.
3 DCCP-Ack packet.
4 DCCP-DataAck packet.
5 DCCP-CloseReq packet.
6 DCCP-Close packet.
7 DCCP-Reset packet.
8 DCCP-Move packet.
 
 CCval: 4 bits
 
  This field is reserved for use by the sending CCID. In particular, the A-to-B CCID's sender, which is active at DCCP A, MAY send information to the receiver at DCCP B by encoding that information in CCval. DCCP proper MUST ignore the field. If the relevant CCID does not specify its value, it SHOULD be set to zero.  
 Sequence Number: 24 bits
 
  The sequence number field is initialized by a DCCP-Request or DCCP-Response packet, and increases by one (modulo 16777216) with every packet sent. The receiver uses this information to determine whether packet losses have occurred. Even packets containing no data update the sequence number. Sequence numbers also provide some protection against old and malicious packets.
 		  
  Very-high-rate DCCPs may need protection against wrapped sequence numbers. For example, a 10 Gb/s flow of 1500-byte DCCP packets will send 2^24 packets in about 20 seconds. This is a long time, in terms of likely round-trip times that could possibly achieve such a sustained rate, but it is not without risk. In particular, if it is decided that very large packet sizes are better than very large congestion windows for very-high-bandwidth flows, then 24 bits may be enough.
 		  
  The two subflows' initial sequence numbers are set by the first DCCP-Request and DCCP-Response packets sent, and SHOULD be chosen as for TCP. In particular, initial sequence number choice MUST include a random or pseudorandom component to make it harder for attackers to complete sequence number attacks. The initial sequence number chosen for a given connection identifier (source address and port plus destination address and port) SHOULD increase over time, as TCP suggests to prevent inappropriate delivery of old packets.  
 Data Offset: 8 bits
 
  The offset from the start of the DCCP header to the beginning of the packet's payload, measured in 32-bit words.  
Number of Non-Data Packets (# NDP): 4 bits
 
  DCCP sets this field to the number of non-data packets it has sent so far on its sequence, modulo 16. A non-data packet is simply any packet not containing user data; DCCP-Ack, DCCP-Close, DCCP-CloseReq, and DCCP-Reset are always non-data packets, while DCCP-Request, DCCP-Response, and DCCP-Move might or might not be. When sending a non-data packet, DCCP increments the # NDP counter before storing its value in the packet header.
 		  
  This field can help the receiving DCCP decide whether a lost packet contained any user data. For example, say that packet 10 had # NDP set to 5; packet 11 was lost; and packet 12 had # NDP set to 5. Then the receiving DCCP could deduce that packet 11 contained data, since # NDP did not change. Likewise, if # NDP had gone up to 6 (and packet 12 contained user data), then packet 11 must not have contained any data.  
 Checksum Length (Cslen): 4 bits
 
  The checksum length field specifies what parts of the packet are covered by the checksum field. The checksum always covers at least the DCCP header, DCCP options, and a pseudoheader taken from the network-layer header. If the checksum length field is zero, that is all the checksum covers. If the field is 15, the checksum covers the packet's payload as well, possibly with 8 bits of zero padding on the right to pad the payload to an even number of bytes. Values between 1 and 14, inclusive, indicate that the checksum additionally covers that number of initial 32-bit words of the packet's payload, padded on the right with zeros as necessary.
 		  
  Values other than 15 specify that corruption is acceptable in some or all of the DCCP packet's payload. In fact, DCCP cannot even detect corruption there, unless the Payload Checksum option is used. The meaning of values other than 0 and 15 should be considered experimental.  
 Checksum: 16 bits
 
  DCCP uses the TCP/IP checksum algorithm. The checksum field equals the 16 bit one's complement of the one's complement sum of all 16 bit words in the DCCP header, DCCP options, a pseudoheader taken from the network-layer header, and, depending on the value of the checksum length field, some or all of the payload.
 		  
  The pseudoheader is calculated as for TCP. For IPv4, it is 96 bits 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).
 		  
  Packets with invalid checksums MUST be ignored. In particular, their options MUST NOT be processed.  
Sequence Number Validity
DCCP endpoints SHOULD ignore packets with invalid sequence numbers, which may arise if the network delivers a very old packet or an attacker attempts to hijack a connection. In DCCP, sequence numbers change with each packet sent, even pure acknowledgements. Thus, a loss event that dropped many consecutive packets could cause two DCCPs to get out of sync relative to any window.
  DCCP uses Loss Window and Identification mechanisms to determine whether a given packet's sequence number is valid. Each HC-Sender gives the corresponding HC-Receiver a loss window width W. This reflects how many packets the sender expects to be in flight. Only the sender can anticipate this number. One good guideline is to set it to about 3 or 4 times the maximum number of packets the sender expects to send in any round-trip time. Too-small values increase the risk of the endpoints getting out sync after bursts of loss; too-large values increase the risk of connection hijacking. W defaults to 1000. The Identification mechanism is used to get back into sync when more than W consecutive packets are lost.
The HC-Receiver sets up a loss window of W consecutive sequence numbers containing GSN, the Greatest Sequence Number it has received on any valid packet from the sender. ("Consecutive" and "greatest" are measured in circular sequence space. The receiver may center the loss window on GSN, or arrange it asymmetrically.) Sequence numbers outside this loss window are invalid. Packets with invalid sequence numbers are themselves invalid, unless both of the following conditions are true:
 
 
  1. No valid packet has been received recently (for instance, within at least one round-trip time).
     
  2. The packet includes a correct Identification or Challenge option, and a valid Acknowledgement Number (meaning the Acknowledgement Number is within the corresponding Loss Window).
  
The receiving DCCP SHOULD ignore invalid packets. However, the receiving DCCP MAY send a DCCP-Ack packet to the sender, as allowed by the congestion control mechanism in use. This packet SHOULD acknowledge the last received valid sequence number and contain a Challenge option. The other DCCP will send an Identification option to resync.
A DCCP endpoint MAY implement rate limits to reduce the likelihood of denial-of-service attack. In particular, it MAY ignore all packets with bad sequence numbers, even those containing Identification or Challenge options, for some amount of time, on the order of one round-trip time, after receiving a packet with an invalid Identification or Challenge option; and it MAY rate-limit the Challenge options it sends.
Previous

Content

Next