Subject: [Seamoby] issue-#49: Length indicator for Router Certificate sub-option

From: "James Kempf" <[email-masked]>
Date: Wed, 5 May 2004 15:32:09 -0700

All the length fields in CARD are 8 bits, which means restricts the size of
messages to 254 bytes. This length is insufficient for certificates.

An additional concern is that if the length field of the entire
Request/Reply mesage is the same as the sub-option length field, the
sub-option generator may want generate an option longer than would fit into
the message, since this would be allowed by the field length. The solution
for this in any case is for the sub-option generator code to respect the
overall limits on the message length, in addition to the sub-option length.

Proposal 1: Keep the length field size at 8 bits and make the units of
length be 8 octets, for a maximum 1634 bits  or 2048 bytes.

Proposal 2: Change the length field size to 16 bits, for a total of 65535
bits or 8192 bytes.

Suggested resolution: Proposal 2

Reason: Proposal 1 could result in a maximum of up to 7 padding bytes of
null data in an option or sub-option which is an extra overhead that is
unnecessary and unwanted over the air.

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 11 May 2004 18:42:26 +0200

>unnecessary and unwanted over the air.
Well, this is only my opinion, but if we transmit certs of size > 1kbyte 
over the air with
a CARD Reply, who cares about 7 bytes padding... What bothers me with 
the 16-bit proposal is
that potentially the length of this sub-option can be much larger than 
the length of the option it
is encapsulated with, which is max 256 x 8bytes long. And even when 
having resolution of
1 byte with 16-bit length identifier, requirement for all sub-options is 
to take care about 32-bit
boundary alignment.
Hence, max overhead with proposal 1 is 4 bytes, right?

What do others think?

marco

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 May 2004 10:18:43 -0700

> Hence, max overhead with proposal 1 is 4 bytes, right?

So how about changing the size of the option to 16 bits as well?

BTW, if we do change the size to 16 bits, then I think the units should be
bytes and not bits. So the max size would be 65536 bytes.

            jak