I agree with Alex's comments. I think that flow label field in IPv6 header is IPv6 design's soft underbelly. I can understand and appreciate Brian Carpenter's efforts on trying to resolve this issue.
My suggestion for Mext (and Netext) usage is to assign the first 16 bits of the flow label as FID. Regards, Behcet ----- Original Message ---- > From: Alexandru Petrescu <[email protected]> > To: 6MAN <[email protected]> > Sent: Thu, April 15, 2010 5:14:52 AM > Subject: Comments on draft-carpenter-6man-flow-update-02 > > Hello Authors of draft-carpenter-6man-flow-update-02 > at http://tools.ietf.org/html/draft-carpenter-6man-flow-update-02 I > have some comments. "a. "The Flow Label value set by the > source MUST be delivered unchanged... b. > "IPv6 nodes MUST NOT assume any mathematical or other > properties... c. "Router performance SHOULD NOT be dependent on > the distribution of the Flow Label values... The > second two rules appear to forbid a usage in which... However, both before > and after these rules were laid down, a considerable number of proposals for > use of the flow label have been published... Examples... These authors > propose use cases in which some combination of the following options apply: > o The flow label may be changed by intermediate > systems..." Er? The logic sounds flawed. You seem to be > saying that earlier Authors complained about "b" and "c". But then you > say they suggested a solution where "a" is addressed too. So actually > they complained about "a" too? Not sure I understand what they > wanted. > The purpose of the proposed change is that the flow label > should be > available for domain-specific use, with locally defined > semantics, > without preventing uses that are compatible with RFC > 3697. Ok, but then make sure one considers coherently a Host being _in_ > xor _out_ of that domain. Sometimes these usages can be mixed. If > we say a Host _within_ the domain will _not_ set the Flow Label then we can't > say that the intermediary Routers within that domain will change it: > because it's hard to imagine a Router is not a Host at the same > time. > 1. If and only if the flow label in an IPv6 packet has > the default > value of zero, then a router MAY set it to a value between > between 1 > and 0xFFFFF. This option modifies the rule that > the flow label must > be delivered unchanged, by allowing exactly > one router to set it if > the source host did not set it. I > believe this may pose problems. The case is when the sending Host1 does > not set the Flow Label and the receiving Host2 knows somehow (e.g. the app > protocol is older than new Flow Labels) that H1 doesn't implement Flow Labels > and so expects "0" zero from it. When H2 sees a flow label set then it > deduces something is wrong, because it knows H1 couldn't set it. In > RPL there's talk proposing "restoration" of the Flow Label at the exit point, > but I don't agree with that either. > packets leaving the local domain > may contain flow label values that > are not pseudo-random For some > reason I have difficulty understanding "not pseudo-radom": does it mean > actually "random", interpreted as a double negation? Does it mean "not > random but can't talk random because true random doesn't exist"? The > implications of this clarification are wide I believe. > The flow > label is not protected in any way and can be forged by an > on-path > attacker. On the other hand, a pseudo-random flow label > cannot be > readily guessed by an off-path attacker. That "OTOH" makes think that > because pseudo-random flow labels cannot be guessed then the Flow Label is > protected against on-path attackers. I don't think much protection is > afforded by the use of visible be them random numbers. Were it > public-private-keys then yes but here we don't talk Flow Labels as security > keys, at least because of the obvious performance > requirements. Alex -------------------------------------------------------------------- IETF > IPv6 working group mailing list > href="mailto:[email protected]";>[email protected] Administrative Requests: > href="https://www.ietf.org/mailman/listinfo/ipv6"; target=_blank > >https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
