I agree with Joel, in great part because of the IPSEC issue that Thomas mentions. Final payload and ports can be easily obfuscated behind chains of headers, or encrypted in IPSEC. Specifying that the flow label SHOULD be set to hash of specified values would lead to greater inter-operability.
-----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, May 07, 2010 6:29 AM To: Brian E Carpenter Cc: 6man Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-03.txt] The more I think about "encouraging" locally defined use of the flow label, the less I like it. The basic problem is that in the context we are discussing, is for use by routers. If you have locally defined flow label usage, then 1) Any vendor selling to an operator has to somehow manage to support their locally defined behavior. 2) Operators MUST configure all their routers to properly understand their flow label meaning. 2') Given that it can not be counted on, even the global interpretation such as the use of non-zero flow-labels for ECMP/LAG balancing would be to be off by default, since there would be no default expect ability to match that use. 3) This is quite fragile. Given that there is no indication in the packet of what meaning of flow-label was intended, there is nothing that will alert an operator if (as seems periodically inevitable some of the routers are attempting to apply a different interpretation than the operator intends. Basically, from a vendor's perspective, a multiplicity of local interpretations of flow label is a serious impediment to implementing any usage of flow label at all. One could argue that as long as the routers are all from one vendor, they will support the same local interpretation. I hope we are not going there! Hence, to be clear and specific, I support approach 1, and oppose approach 2. Yours, Joel Brian E Carpenter wrote: > Hi, > > This is revised again according to discussion on the list, and some > off-list discussion with Shane Amante in particular. > > Firstly, since there seemed to be a feeling that a full update > of RFC 3697 is better than publishing a set of changes, this is > now just informational, although written using normative language. > The major next step would be a 3697bis draft. > > Secondly, it offers the WG a binary choice as the main decision: > > "There appear to be two viable approaches: > 1. Definitively forbid locally defined use of the flow label. > Strengthen RFC 3697 to say that hosts SHOULD set a pseudo-random > label value, which would clarify and limit its possible uses. In > particular, its use for load balancing and possibly as a nonce > would be encouraged. > 2. Encourage locally defined use of the flow label. This approach > would make the flow label mutable and would exclude any use case > depending on end-to-end immutability. It would encourage > applications of a pseudo-random flow label, such as load > balancing, on a local basis, but it would exclude end-to-end > applications such as [I-D.blake-ipv6-flow-label-nonce]." > > Please, can we focus on this choice rather than the fine details, > initially? Also, please read the draft as a whole; looking at diffs > would be quite confusing. > > Brian + Sheng > > -------- Original Message -------- > Subject: I-D Action:draft-carpenter-6man-flow-update-03.txt > Date: Thu, 6 May 2010 18:00:01 -0700 (PDT) > From: internet-dra...@ietf.org > Reply-To: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Update to the IPv6 flow label specification > Author(s) : B. Carpenter, S. Jiang > Filename : draft-carpenter-6man-flow-update-03.txt > Pages : 11 > Date : 2010-05-06 > > Various published proposals for use of the IPv6 flow label are > incompatible with its existing specification in RFC 3697. This > document proposes changes to the specification that permit additional > use cases. The concept of flow label domains is introduced, with the > label possibly being rewritten at domain boundaries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-03.txt > > > -------------------------------------------------------------------- > 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
