In your previous mail you wrote:
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.
=> yes but this bit is not used today (this is not a proposal to remove it,
I believe it is a very useful feature).
RFC 2460 also specifies the recommended Extension Header Order as:
IPv6|HbH|DO1|RH|FH|AH|ESP|DO2|TCP/UDP/etc
=> this recommendation has three problems:
- DO1 makes sense only when there is a routing header. This is not clear
enough!
- an IPComp (RFC 2393) header should be between ESP and DO2
- there are two kinds of DO (DO1 and DO2) which makes implementations hairy
and the recommendation unclear (see first point). As the third placement
(between RH and FH) for DO header seems to be very useful for home address
(cf mobile IP discussion) and tunnel encapsulation limit (DO2 makes it
near useless) options the whole DO placement stuff should be redone.
I've proposed a solution but I *never* get an answer (even negative :-).
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.
=> I agree that mutable options in DO2 should be forbidden (just because
they don't make sense).
Unfortunately, this requirement that mutable options not appear after the
Routing Header is not explicitly stated in the spec anywhere.
=> I don't believe we need to state this now. It should be done only
if/when someone proposes a mutable option which is not hop-by-hop
(I don't think DO1 is still useful but there were some (rejected) proposals
for mutable hop-by-hop options).
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.
=> this is a different point because "after AH" is not the same thing than
"before RH". You can apply your ESP argument too here...
Perhaps you should support my DO header cleanup, I'll add a mutable-forbidden
statement for DO2 (:-)...
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.
=> if nobody has an usage for DO1 I think we should phase it out and
simplify your proposal in mutable implies hop-by-hop.
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.
=> I agree, in DO1 and DO2 are too many choices. I believe for the new
header you want a new type?
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.
=> we agree at least on the necessary cleanup for DO headers.
Regards
[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]
--------------------------------------------------------------------
