I have the impression that a lot of the complexity in these chained
extension headers is caused by the way Source Routing is specified.
If Source Routing would be a hop-by-hop extension and the IPv6
destination was always the final destination the header mess wouldn't be
that big (the disadvantage being that Loose Source Routed packets need
additional procesing in non-fixed hops, but who is using Source Routing
anyhow?).
dirk
Brian Zill wrote:
>
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
