Date: Fri, 21 Dec 2001 17:18:24 +0100
From: "Hesham Soliman (ERA)" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| So in this case, if you end up with an application that
| doesn't support the flow label or simply doesn't
| care, it might still be a good idea to set the flow
| by another function in the IPv6 stack to be able
| to identify the flow when signalling to the CN
| or HA.
Sure.
| => Agreed. But some of the cases I've looked into would
| require the end node (as well as routers along the
| path) to verify the validity of the flow label.
That is going to be an interesting challenge. Good luck.
| Without some sort of semi secured flow label, the
| mutability requirement seems like a gentlemen's
| agreement :)
Yes. As Glenn Morrow said in a recent message, if it can be altered
and there's a business imperative, it will be altered.
However, what counts is "can be altered" - that happens only if things
don't break when it is altered. If packets get rejected because it is
being authenticated, and the alteration is detected - that's breaking,
so anyone who tried to fiddle such a field would find themselves with
no customers. But that's not the only way for things to break, and
any breakage has the same effect.
The reason that people got away with altering the IPv4 TOS field was
simply that no-one cared - it was used for nothing in practice. Had
there been applications that actually used it, or routing schemes that
depended upon it, it wouldn't have been able to be altered without the
s**t hitting the fan.
We don't need cryptographic type protection to avoid that kind of
manipulation - we just need to actually care what the value is.
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]
--------------------------------------------------------------------
