Subject: curious about 64-bit alignment for Nonce Option by SEND?

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Oct 2011 12:25:16 -0500

Jari and other SEND authors,

I am curious why SEND proposed to align the Nonce Option on a 64-bit
boundary?   Was it due to a specific hardware reason?

Thanks,

Hemant

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Oct 2011 00:03:12 +0300

These options are ND options as specified in RFC 4861, which states:

    Neighbor Discovery messages include zero or more options, some of
    which may appear multiple times in the same message.  Options should
    be padded when necessary to ensure that they end on their natural
    64-bit boundaries.  All options are of the form:

There are no other alignment rules on RFC 3971 options IIRC. The Nonce option section in RFC 3971 does say:

       The length of the random number MUST be at
       least 6 bytes.  The length of the random number MUST be selected
       so that the length of the nonce option is a multiple of 8 octets.

But this is just to satisfy RFC 4861 criteria and simplify the length field option processing, as the basic ND option length field is counted in units of 8 octets. So the possible actual random number sizes are 6, 14, 22, etc. If this is inconvenient to implementations, they could of course select a suitable random number size (e.g., 8 octets) and pad the rest to a constant value or copy some random number bytes to the option multiple times.

Jari

On 17.10.2011 20:25, Hemant Singh (shemant) wrote:
> I am curious why SEND proposed to align the Nonce Option on a 64-bit boundary?   Was it due to a specific hardware reason?
>
> Thanks,
>
> Hemant
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Oct 2011 17:29:46 -0500

Jari,

Ah, I forgot to check the ND RFC 4861 for option recommendations -
appreciate the quick reply!  I suspected all along to align data on the
64-bit boundary would be to use newer 64-bit processors.  Good work on
the SEND document because the Nonce Option is defined very well and we
could use this option to catch reflected DAD messages.  While I have you
here, if you could review the section 4 related to mixed-SEND (secured
and un-secured nodes) environments, it would be great.  

http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01

Regards,

Hemant

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, October 17, 2011 5:03 PM
To: Hemant Singh (shemant)
Cc: IPv6 WG Mailing List
Subject: Re: curious about 64-bit alignment for Nonce Option by SEND?

There are no other alignment rules on RFC 3971 options IIRC. The Nonce
option section in RFC 3971 does say:

But this is just to satisfy RFC 4861 criteria and simplify the length
field option processing, as the basic ND option length field is counted
in units of 8 octets. So the possible actual random number sizes are 6,
14, 22, etc. If this is inconvenient to implementations, they could of
course select a suitable random number size (e.g., 8 octets) and pad the
rest to a constant value or copy some random number bytes to the option
multiple times.

Jari