> => It would be good if yu could point out > a link perhaps to help me understand the reasons. > > => there are tons of mails in the archive of this list about that.
=> OK thanks. > > > If we want to make it > > more sophisticated then we can add another number > > to the hash input (e.g P1 || P2 || x). > > Where x can be something specific to this flow. > > > > => so why not just x (:-)... > > => Well because not all applications have that > luxury of knowing an 'x' beforehand. > Also you would have to define for each application > what 'x' means. Or define some behaviour in the > IPv6 stack based on some shared secret, which again > is not always available. > > => I still don't understand what is the difference between > x and hash(P1 || P2 || x) where x can be something specific > to this flow. => Well it doesn't have to be flow specific. If you're trying to avoid exposing the encryption key, you can use x, where x is any number that both nodes are aware of. If ESP is not being used, you simply use P1 || P2 || x (x = 0) , unless you get a duplication (1 in a thousand probability, that is if the two nodes have a thousand connections between them). Anyhow, if you get a duplicate flow id then you can increment x by 1. This is a brief explanation obviously. > PS: I can read between the lines that an end-to-end usage of > the flow label is proposed. => It wasn't meant to be between the lines :) IMHO this is only a waste of bits, > the flow label is in the header in order to be available to > intermediate nodes. For end-to-end options, a destination header > fits better. => But doesn't that waste even more bits ? Cheers, 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] --------------------------------------------------------------------
