Ken Powell wrote:
RJ Atkinson wrote:
On 11 Feb 2009, at 18:46, Suresh Krishnan wrote:
Section 5.1 : Option format
The alignment requirement for this option should be 4n+2 and not 4n as
mentioned in the document. This is required to align the CALIPSO DOI on
its natural 32 bit boundary.
First, please let me note that I am not religious about this.
Users are concerned about throughput lost due to overhead.[1] This
option is already potentially large (example: when the bitmap field
is large). Packets with this option are known to be used routinely
over lower bandwidth links (e.g. IP over 2.4 Kbps HF radio) where
2 bytes might matter. Ordinary IPv6 is already operationally
challenging on such links (even with header compression), but
those link types are not going away (in fact, HF radio deployment
reportedly is growing these days, after a reported decline in
IP/HF deployments in the late 1990s).
So I can better understand your inputs, it would help to have
a bit of context:
- Are you implementing this option ?
- Do you have a MLS network deployment ?
Given the above, do you view the alignment question as a
show-stopper ?
Or can you live with the current alignment given the
very limited use of this option ?
The "Option Data" reference in the following text from the top
of draft-stjohns-sipso-07.txt page 27 may have caused some
confusion here.
Following the nomenclature of RFC-2460, Section 4.2, the Option
Data field of this option must have 4n alignment.[RFC-2460]
RFC 2460 describes option alignment requirements based on the
location of the Option Type field, not the Option Data field.
Let me rephrase,
I've learned to expect alignment to be specified in terms of the
Option Type field per RFC 2460 page 10:
The alignment requirement of an option is
specified using the notation xn+y, meaning the Option Type must
appear at an integer multiple of x octets from the start of the
header, plus y octets.
I read your draft last week and thought there was a problem with
the "4n" alignment as well. I didn't realize you had specified
alignment in terms of "Option Data" until this morning.
Perhaps it would help if the text at the top of
draft-stjohns-sipso-07.txt page 27 said:
Following the nomenclature of RFC-2460, Section 4.2, the Option
Type field of this option must have 4n+2 alignment.[RFC-2460]
Ken
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
