Date: Tue, 14 Nov 2000 21:10:22 -0800
From: Brian Zill <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
It certainly makes no sense to have to allow specially for
the possibility of mutable options, which cannot in fact mutate.
I kind of like Steve's suggestion ...
> Alternatively, we could specify that any mutable options that appear
> after the AH header are treated as if they were immutable
except we can generalise that - anything that is internal to any header
(part of the payload of that header) must be able to be treated as immutable
for the purposes of the header.
There can never be (rationally) a need to peel back the onion and look inside
the payload to attempt to interpret any particular header.
The mutable/immutable stuff is needed only because we need to have the
security headers apply to data that is strictly outside their scope
(data from headers in which they're wrapped), and for that, allowance
that things might sometimes change is unavoidable. Some of that is
just handled by rules "the hop count field varies", but where data yet
to be invented exists (options) the method to make clear which is
mutable, and which is not is clear - but only in headers that come outside
the header which cares.
But...
| 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.
Please, no - the double use of the DO header is a thing of beauty.
It, just by being there, makes clear the way the IPv6 header structure
is to work, it makes clear that headers can appear more than once,
it makes clear that the interpretation of a header depends upon where
in the sequence of headers it is found, it makes clear the onion
peeling parsing technique that is defined to apply to IPv6 headers,
and is a very clean architectural design.
Please don't mess with this just because it seems easier to fix everything
in concrete (this follows this follows this...) and pretend that variations
are never going to be possible. (Aside from that it would be a waste
of one of the 256 header type codes for no reason whatever).
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
