Subject: [Roll] Sub-option Alignment

From: Dario Tedeschi <[email-masked]>
Date: Fri, 09 Apr 2010 17:03:02 -0700

The [length] field in the first sub-option in a DIO message will not be 
aligned properly (as per IPv6 convention), unless a PAD1 is inserted 
after DAGID. Was this the original intention or an oversight?

One alternative to this, would be to change the DIO base header format 
to always include the OCP as a one byte field instead of having OCP as a 
sub-option. Of coarse, this won't fix alignment in subsequent options 
(due to [type] plus [length] being 3 bytes long), but at least we 
replace some padding with useful information.

I apologize if this has already been discussed. I've only found one 
archived thread on the matter, and it appears unresolved.
http://www.ietf.org/mail-archive/web/roll/current/msg02769.html

Regards
Dario Tedeschi

---

From: Matteo Paris <[email-masked]>
Date: Fri, 9 Apr 2010 20:29:18 -0400

I believe it has been observed before that the length field should be 
one byte, which would address your alignment concerns.  If RPL 
requires suboptions longer than 255 bytes, we are in trouble.  Does 
anybody object to changing this in the next rpl draft?

Matteo

At 5:03 PM -0700 4/9/10, Dario Tedeschi wrote:
>The [length] field in the first sub-option in a DIO message will not 
>be aligned properly (as per IPv6 convention), unless a PAD1 is 
>inserted after DAGID. Was this the original intention or an 
>oversight?
>
>One alternative to this, would be to change the DIO base header 
>format to always include the OCP as a one byte field instead of 
>having OCP as a sub-option. Of coarse, this won't fix alignment in 
>subsequent options (due to [type] plus [length] being 3 bytes long), 
>but at least we replace some padding with useful information.
>
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 13:38:08 +0200

Le 10/04/2010 02:29, Matteo Paris a écrit :
> one byte, which would address your alignment concerns. If RPL requires
> suboptions longer than 255 bytes, we are in trouble. Does anybody object
> to changing this in the next rpl draft?

I strongly support using padding as usual is used for IPv6 - it helps 
implementer a lot.

Alex

>> inserted after DAGID. Was this the original intention or an oversight?
>>
>> to always include the OCP as a one byte field instead of having OCP as
>> a sub-option. Of coarse, this won't fix alignment in subsequent
>> options (due to [type] plus [length] being 3 bytes long), but at least
>> we replace some padding with useful information.
>>