[bugzilla-daemon@xxxxxxxxxxxxx]

boaz.brickner@gmail.com changed bug 10561

What	Removed	Added
Status	RESOLVED	CONFIRMED
Resolution	FIXED	---

Comment # 4 on bug 10561 from boaz.brickner@gmail.com

Hi Alexis, thanks for your response.

This field indeed indicates the length of the Compartment Bitmap but *in 32-bit
words*, which means that the value of 12 means the compartment bitmap is 48
bytes long.


>From RFC 5770:

5.1.3.  Compartment Length Field

   This field contains an unsigned 8-bit integer.  The field specifies
   the size of the Compartment Bitmap field in 32-bit words.  The
   minimum value is zero, which is used only when the information in
   this packet is not in any compartment.  (In that situation, the
   CALIPSO Sensitivity Label has no need for a Compartment Bitmap).
   Note that measuring the Compartment Bitmap field length in 32-bit
   words permits the header to be 64-bit aligned, following IPv6
   guidelines, without wasting 32 bits.  Using 64-bit words for the size
   of the Compartment Bitmap field length would force 32 bits of padding
   with every option in order to maintain 64-bit alignment; wasting
   those bits in every CALIPSO option is undesirable.

   Because this specification represents Releasabilities on the wire as
   inverted Compartments, the size of the Compartment Bitmap field needs
   to be large enough to hold not only the set of logical Compartments,
   but instead to hold both the set of logical Compartments and the set
   of logical Releasabilities.

   Recall that the overall length of this option MUST follow IPv6
   optional header rules, including the word alignment rules.  This has
   implications for the valid values for this field.  In some cases, the
   length of the Compartment Bitmap field might need to exceed the
   number of bits required to hold the sum of the logical Compartments
   and the logical Releasabilities, in order to comply with IPv6
   alignment rules.

---

      You are receiving this mail because:

• You are watching all bug changes.