>>>>> On Wed, 29 Nov 2006 14:48:40 -0500,
>>>>> Ralph Droms <[EMAIL PROTECTED]> said:
>>> How, exactly, is this padding encoded? And, why bother?
>>
>> See the length field:
>>
>> Length 8-bit unsigned integer. The length of the option
>> (including the type and length fields) in units of
>> 8 octets. The value 0 is invalid. Nodes MUST
>> silently discard an ND packet that contains an
>> option with length zero.
>>
>> You have to pad options to fill them out to 8 octets.
> Oh, of course...
> OK, so "natural 64-bit boundaries" is a little unclear. And, shouldn't it
> be a MUST? Does each option describe how to pad; i.e., suppose an option
> carries a single variable length value? Is it the responsibility of the
> text defining the option to describe the format of the option so the option
> is always a multiple of 8 octets?
I don't know the original intent, but RFC2497 defines an ND option
with a 5-byte option field. This may indicate it was expected that
documents that specify options were responsible for specifying
necessary padding as well.
> Backtracking...I reviewed the options defined in this spec, and all except
> the Redirected-header option are defined to be an integer multiple of 8
> octets in length. So, is the "padded when necessary" advice for the
> definition of future options?
Good point...I recently found the following comment lines in the
KAME/BSD implementation of sending a Redirect message:
/*
* Redirected header option spec (RFC2461 4.6.3) talks nothing
* about padding/truncate rule for the original IP packet.
* From the discussion on IPv6imp in Feb 1999,
* the consensus was:
* - "attach as much as possible" is the goal
* - pad if not aligned (original size can be guessed by
* original ip6 header)
[...]
I don't remember "the discussion on IPv6imp", but this comment shows
the implementor community found the spec unclear on this and reached a
"consensus" that there should be a padding if the length of the
enclosed packet is not a multiple of 8 octets.
I'm not sure if we want to clarify this point in 2461bis, though. I
personally think the clarification (whatever it is) is basically
compatible with existing implementations, but it may affect some
existing implementations, and it may look an "incompatible change" for
some implementors...
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
