Date: Mon, 07 Jan 2002 15:13:51 -0500
From: Alex Conta <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| One of the comments pro "immutability" was that you cannot trust the
| flow label if it is not "immutable".
I didn't ever see that argument. What I saw was that you can't rely upon
it if it isn't - but not from the point of view of the recipient, from the
point of view of the sender. That is, if the value might be changed to
any random thing, what's the point of setting it all, ever? It would just
be meaningless bits (imagine a router forwarding a packet through an
encrypting tunnel, and seeing some mutable bits - ones it is allowed to
alter - and filling them with a random value in order to make cryptanalysis
more difficult).
| Current or future flow setup and flow processing mechanisms, do now, or
| will, in the future,
| KNOW BEST the micro-details of the flow label usage. Therefore
| responsibility of the immutability/mutability of the flow label value
| should stay ALONE with those mechanisms.
I think in this case, you really favour making the field immutable, but
unverified. If it were truly mutable, it would never be able to be used
for any of those uses, as no-one could ever rely upon any value they set
remaining intact to the point where it was supposed to be used (the "router"
in my previous paragraph might be a link level bridge type object - even
imagine a NIC that sees this mutable field and uses it to send to the
destination a count of the number of times it deferred because of a busy
link before sending the packet...)
If some future spec wants to make the field mutable, then as long as we
have not done anything silly (like modify the current AH rules) to prevent
it, then that spec will be able to do that - and with a good chance of
being able to rely upon the value only being changed as the future new spec
actually says should happen.
| By leaving mutability alone, possible issues with checksum, and AH
| calculation can be really forgotten, or ignored.
This amounts to "make it immutable, don't change AH, and explain in the
doc that AH explicitly doesn't include the flow label, to leave open the
possibility that some later spec might specify conditions under which the
field can be changed". Until this later spec appears though, I don't think
we need to anticipate its requirements, and waste time here debating
whether or not those unknown future requirements are a good thing or a
bad thing.
All we need to do now is avoid doing something truly silly like revising
AH to have it include the flow label.
The only plausible "mutable" argument I can see remaining for now is to have
a case where the source host says "I don't care what is in this field, I
am not setting it to anything". I haven't yet even seen an argument as
to why that value has to be immutable (by definition it has no meaning to
anyone). So, I'm still in favour of allowing that. But not so much as to
object to a doc that doesn't include it - after all, no-one will ever care if
that value is changed, so if anyone wants to do so, they can, regardless of
what this new spec on the flow label claims.
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]
--------------------------------------------------------------------
