kre is correct IMHO, and we won't get any further by repeating this loop again.
However there is one qualification on kre's final comment: > ...if someone decides to alter the field, no-one > would notice - and there's no reason to go and add a mechanism just to detect > something that no-one cares about anyway. The field could theoretically be abused as a signalling channel by malicious people - detecting this might be of value in some circumstances. Brian Robert Elz wrote: > > Date: Tue, 8 Jan 2002 21:28:11 -0800 > From: "Dr. Subrata Goswami" <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | 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. > > Yes, though we perhaps aren't using it in quite that sense, more > in the "must not be changed" rather than "can not be changed". > > | With an IPv6 > | packet that is not possible unless every router vendor > | and IP stack vendor is some how forced to do that. > > But that's certainly not true. We don't have to force them, we just > need to tell them what is right. That's all the IETF ever really does. > > | Even the IP address fields are mutable as any intervening router > | can change (and they do in case of NAT). > > Yes, exactly. Yes and (NAT set aside for a minute) the IP address fields > have just the properties that we are really aiming for here. That is, > they aren't changed by random routers along the path - packets get delivered > with the same addresses in them that they had when they left the source > (or did, pre NAT). And that was achieved without AH existing yet to > validate things - the routers simply didn't alter the fields. > > That's what is desirable here. > > But then, along came the need for NAT (as evil as it is, there must be > a pretty strong case for it, given its widespread use). Implementing that > meant that the address field, which previously had never been altered, > now needed to be changed by routers. Had there been any enforcement of > the immutability of the addresses, then there would have been no way to > add NAT to the net (which might have been good, or bad, but for sure the > net now would be nothing like it is if not for it). > > | 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. > > If there was any reason to enforce it, that would be correct. But there > isn't - so we don't need this. > > And if we did, then there'd be no possibility later to come up with some > new use which requires the field to be mutable (and argue about it a lot > in the IETF and perhaps eventually agree to it). At this stage in the > evolution of the flow label, completely cutting off that possibility is > unreasonable. > > In practice, if actual immutability is required by applications that use the > flow label, then what will "enforce" the immutability is the screams of the > users at the router vendors/operators if they start playing about with the > data. Just as would happen if (aside from the explicitly configured NAT, > and even that generates plenty of screaming) routers started randomly > changing IP addresses. > > If there's never an application actually deployed that cares, then why would > anyone else? In that case, if someone decides to alter the field, no-one > would notice - and there's no reason to go and add a mechanism just to detect > something that no-one cares about anyway. > > 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] --------------------------------------------------------------------
