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]
--------------------------------------------------------------------
