Aleksi, On Aug 3, 2010, at 16:25 MDT, Aleksi Suhonen wrote: >> On Aug 3, 2010, at 02:53 MDT, Rémi Després wrote: >>> What about this combination (not documented yet, it seems) >>> - Hosts that send non 0 FLs, MUST do it with a value that: >>> . is common to all packets of their flow >>> . generally is different from one flow to another >>> - non 0 FLs MUST be preserved e2e. >>> - 0 FLs may be changed anywhere, but with the same constraints as in hosts. > > Earlier I suggested that a modified "0 FL" should be reset back to zero at > the egress of the network that modified it. Someone said this is impossible, > which I don't believe at all. However, all I really care about is that "0 FL" > should be mutable and others shouldn't. Whether it is or should be reset on > egress doesn't matter to me.
I believe I made the point during the 6MAN meeting that while it's technically possible to change the flow-label back to 0 upon exit of a "flow-label domain", it's likely to be operationally challenging to do so. IOW, SP's would have to ensure systems/processes are in place to properly configure each of their interfaces appropriately (i.e.: reset the FL to 0 at exit). Likewise, if my network is downstream from yours ... I have to trust that you've properly configured your interfaces and that your router SW/HW is working properly so that I will always receive a 0 in the FL. That's asking a lot, IMHO. :-/ So, while I wouldn't call that "impossible", I would say it's highly unlikely, particularly in [very] large networks. Of course, that's just my opinion and YMMV. >>> In addition, >>> - A flow is specified by its 5-tuple, if it exists, or its 3-tuple >>> otherwise. >>> - The FL value assigned to a flow MAY be EITHER: >>> . a hash of the flow identification (simple because stateless), OR >>> . a pseudo random number (more complex because stateful, but providing an >>> utmost privacy protection >>> The choice between hash or randomness is made where the FL is set. Other >>> nodes don't need to know what has been chosen. > > On 08/03/10 17:20, Shane Amante wrote: >> Because of your last two bullets I have to ask the following. How would a >> receiving host deterministically distinguish (1) flow-labels that were >> created by network devices (just a 5-tuple was put into a flow-label) vs. >> (2) flow-labels that were created by a source-host w/ a pseudo-random number >> + 5-tuple[1]? (Please read on before answering :-) > > Why does a receiving host care about the flow label at all? It exists to make > sure that all intermediate nodes give correct treatment to the flow, but once > it reaches its destination it's "safe", right? It depends on your worldview. I think Brian Carpenter (?) may have said it best in a private e-mail -- let me paraphrase (and, Brian, please correct me if I'm wrong). The flow-label can belong either to the network -or- to the host(s): pick one[1]. If you believe the flow-label belongs to the network, then you're statement above is correct ... hosts must ignore (or, not care about) the received flow-label. OTOH, if you believe the flow-label belongs to hosts and you potentially want to enable applications like draft-blake-ipv6-flow-label-nonce-02, which could prevent off-path attacks, then you (likely) can't have routers messing around with the flow-label. Routers may read a flow-label, but they can't attempt to change it. -shane [1] If you put aside the debate about whether or not locally-defined flow-labels are a good idea, this is likely what the choice about what to do with the flow-label field boils down to: it's either a field that belongs to the network or a field that belongs to the hosts. Once that is decided, legitimate uses of the flow-label (including, potentially, locally-defined flow-labels) likely fall out from that. > What have I missed? > > -- > Aleksi Suhonen > Department of Communications Engineering > Tampere University of Technology > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
