=> I agree with nealry everything you said except for one point I'd like to clarify below.
> In general, Tony Hain's arguments are pretty persuasive to > me ... but I > am not sure that I would go as far as to prohibit all changes to the > label - though the only ones I would allow are where the source has > explicitly said that changes are OK (which an initial label of 0, or > we could reserve FFFFF for the purpose, could be defined to > do, and some > flow state setup mechanism could also do). => Fully agree with this and all of Tony's comments on this thread. One point I'd like to clarify here is my suggestion that some other part of the stack (other than the application). can set the flow label. The reason I suggested that (and I do think it's different from having it set by the router) is that I've been looking at some mobility scenarios in which a multihomed IPv6 MN can direct it's inbound traffic to certain interfaces based on some internal policies (QoS, cost, BW ...etc on each interface) using MIPv6 signalling. 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. So to be very clear, I was suggesting that for cases where the applications have not set the flow label, AND the host requires an e2e immutable value. > > Also, everyone please note, just in case it isn't already > clear. When > anyone says the field needs to be immutable (in this case > anyway), it > isn't (really) because anyone cares what value is delivered to the > recipient node - it is that we want to know what value will > be observed as > the packet passes through each routing domain along the > path. That's > important. It just happens that this is equivalent to > saying that the > field must not be modified (perhaps with some specific exceptions). => 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. This is an addition to what you say and doesn't contradict it. Without some sort of semi secured flow label, the mutability requirement seems like a gentlemen's agreement :) The problem is that this is not verifiable, which is why I see a benefit in using some hash function to generate it. Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
