Tim, On Sep 9, 2010, at 05:05 MDT, Tim Chown wrote: > On 9 Sep 2010, at 06:49, Mikael Abrahamsson wrote: >> >> In real life, ISPs consider DSCP as one thing they have the right to change >> (along with TTL) in transit. I can imagine the flow label being considered >> the same thing regardless of what the standard says. > > The interesting thing in the academic networks through Europe and I believe > Internet2 as well is that - the last time I checked - there is agreement > between the NRENs (national academic ISPs) to pass DSCP values unaltered > between networks. > > In general in those academic networks the only rewriting that may occur is at > site exit routers where site policy may either determine the DSCP value a > packet is marked with, or trump the DSCP value set by a user/application. > I believe where policing detects excess traffic of a certain DSCP value, that > traffic is dropped rather than being remarked. > > There are agreed semantics for DSCP values between multiple NRENs, e.g. for > Premium, BE and LBE, who also agree to not alter the DSCP in transit, even > though there's nothing stopping them doing so per se. > > I don't see why the Flow Label should be treated differently. If > cooperating ISPs agree to pass it unaltered, that's fine. As the spec > stands, it's hard to see how we could say otherwise.
One counter-point worth considering. If there is a desire "raise the bar" higher than BCP 38, in terms of preventing/minimizing off-path attacks in IPv6[1], then IMHO it would be best to discourage ISP's from changing a non-zero flow-label[2] of plain/vanilla (non-tunneled) IPv6 packets mid-flight (i.e.: leave it unchanged). This would allow end-hosts/receivers, perhaps even middleboxes (e.g.: firewalls if they wanted to keep track of that much state), some ability to "inexpensively" sort out the good, from bad, packets as described in [1]. Assuming that folks generally agree the above is a good (primary?) goal, the question may then become can (or, should?) we make the flow-label compatible as an input-key for flow-based load-balancing across LAG & ECMP paths? At least as I understand them now, the two drafts [1] are compatible with using the input-key for flow-based load-balancing decisions (more or less), which IMO is a great thing: two uses for the price of one! ;-) -shane [1] draft-gont-6man-flowlabel-security-00 or draft-blake-ipv6-flow-label-nonce-02 [2] I am slightly concerned about, for example, first-hop routers over-writing a non-zero flow-label in plain/vanilla IPv6 (non-tunneled) packets, because the sending host hasn't set one. More specifically: a) Would routers be capable of implementing something like draft-gont or draft-blake (in HW) or is there too much state (i.e.: ensuring that previous flow-labels aren't re-used within a certain [time] window)? b) Assuming that, e.g., first-hop routers couldn't implement either draft, then they would like revert to implementing a stateless hash of various IPv6 header fields with no (?) crypto/authentication properties. If that is the case, then it seems the "security value" of a received flow-label at a remote host is virtually nil and we're not much better off than BCP 38 ... -shane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------