Hi all, got a question about mutable options.
As described in RFC 2460, Option Type identifiers have an encoded bit (aka
the mutable option bit) indicating "whether or not the Option Data of that
option can change en-route to the packet's final destination". This allows
new IPv6 options to be defined with contents that may be changed by either
routers or intermediate destinations along the way to the final destination,
without breaking IPsec authentication.
RFC 2460 also specifies the recommended Extension Header Order as:
IPv6|HbH|DO1|RH|FH|AH|ESP|DO2|TCP/UDP/etc
where DO1 is "for options to be processed by the first destination that
appears in the IPv6 Destination Address field plus subsequent destinations
listed in the Routing header", and DO2 is "for options to be processed only
by the final destination of the packet". The exact order is only a
recommendation, but the distinction between Destination Options headers that
appear before the Routing Header versus those that appear after it is the
important part here.
>From the above, one could reasonably conclude that mutable options should
only appear in Hop-by-Hop and Destination Options 1, and not in Destination
Options 2. Options that appear in DO2 have no need to be mutable since this
header is never examined until after the packet has arrived at the final
destination. And in fact, if they were mutable and mutated in-flight, they
would break things like ESP in null-encryption authentication-only mode.
Unfortunately, this requirement that mutable options not appear after the
Routing Header is not explicitly stated in the spec anywhere. And it
matters for how one calculates the ICV when processing AH headers (since the
calculation treats mutable options as zeroed fields in all cases). If one
allows mutable options to appear anywhere, then the AH ICV calculation needs
to parse past the AH header through to the end of the packet, instead of
being able to treat everything inside of the AH header as an opaque blob.
This would needlessly complicate the AH ICV calculation for no practical
reason.
Therefore, I'd like to propose that the spec is clarified to limit mutable
options to where they make sense, i.e. in Hop-by-Hop and Destination Options
headers that appear before the Routing Header.
Comments?
Thanks,
--Brian
P.S. As an aside, it occurs to me that it might be clearer to define a new
"Intermediate Destination Options" header to take the place of DO1. Then it
could be declared that this new header (if present) MUST appear before the
Routing Header, and that mutable options (if present) MUST appear in either
this new header or a Hop-by-Hop header. Or to put it another way, mutable
options wouldn't be allowed any more in a Destination Options header. This
would also make the spec cleaner - it could get rid of the special case
notations explaining the difference between DO1 and DO2.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
