Well I would not recommend settling something with screams. Making the Flow Label immutable would infact need more than screams.
I can not see how by just saying something is immutable going to help. It would infact be the ground for more confusion, uncertainty, doubt and vendor specific interpretations. I would also recommend adopting the semantics of immutability from the AH RFC 2402 - I guess that is where the word immutable first appears. Also, as you know AH is completely broken by NAT. Why has NAT become popular ? I can only guess: a quick and dirty fix for IPv4 address scarcity; some firewall benefits. The -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Elz Sent: Tuesday, January 08, 2002 10:45 PM To: Dr. Subrata Goswami Cc: [EMAIL PROTECTED] Subject: Re: Flow Label 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
