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
--------------------------------------------------------------------
