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 protected]] 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? 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: > > 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 > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
