Chronological Thread 

< Chronological >      < Thread >

---

Background Information:

On Page 19 of RFC2960, the following is stated regarding Chunk Length:

Chunk Length: 16 bits (unsigned integer)

This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
padding.

On Page 20, the following is stated for the TLV:

Chunk Parameter Length: 16 bits (unsigned integer)

The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes.


By looking at all the Chunk formats, I can see that if there is no TLV
present, then the Chunks will always be a multiple of 4 by design. So the
only time a chunk will follow on a non-4 byte boundary is when a TLV is
present.

It appears to me that the statement on page 20 under "Chunk Parameter
Length" is the only one that applies. Shouldn't the Chunk Length then
contain the padded bytes in the TLV? If it is not then how will the receive
verify the Adler-32 checksum. The checksum of the packet is calculated for
the whole packet including the padded bytes.

Sal

---

• [SCTP-Discussion] Chunk Length and Padding, S. Faizi, 03/23/2002
  • Re: [SCTP-Discussion] Chunk Length and Padding, Michael Tuexen, 03/23/2002

---

Archive powered by MHonArc 2.6.19+.