Here we go again, I guess first we need to make sure what immutability really is. The proper semantic of something immutable is that it can not be changed - as when you ship a CD that is only readable. With an IPv6 packet that is not possible unless every router vendor and IP stack vendor is some how forced to do that. Even the IP address fields are mutable as any intervening router can change (and they do in case of NAT). So the only way to enforce immutability is to add something like the AH so that anyone who is concerned with the Flow Label can be sure that no router in the middle has tempered it.
Subrata -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Elz Sent: Tuesday, January 08, 2002 7:08 PM To: Alex Conta Cc: Subrata Goswami; Brian E Carpenter; [EMAIL PROTECTED] Subject: Re: Flow Label 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
