Wes, Let me focus on one phrase of yours:
> because no implementer in their right mind is going to try > to use this for an application that needs the label to be immutable in all > cases. Correct, and that has always been the case, even for any hypothetical implementers of RFC 3697. The difference is that we're trying to say it more clearly in 3697bis, and obviously haven't quite succeeded yet. Nodes MUST NOT change the flow label. But since you can't detect whether it's been changed, mechanisms using the flow label for some purpose must be robust against unanticipated changes. What that means in the stateless load-balancing model is that the impact of a changed value needs to be limited to sub-optimal load balancing. What it means in other, hypothetical, models for using the flow label I cannot say. It's for the designer of such a model to figure out. Maybe it's just the use of the word "immutable" that is causing the problem here, because it implies something that physically isn't true. Regards Brian On 2011-05-06 01:48, George, Wes E [NTK] wrote: > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian > E Carpenter > Sent: Tuesday, May 03, 2011 5:58 PM > Subject: Re: Flow label drafts updated > >> and also the apparent decision to write these documents in a manner >> intended to legislate reasonable security measures (if applicable only >> in selected deployments) out of existence. > > I don't understand this comment. The flow label has always been defined as > immutable; the consensus in the WG is to keep that > property. So a firewall that overwrites it is unambiguously breaking the > standard. > > [WEG] now it's my turn to be confused by your comment, Brian. I missed this > detail of interpretation when reviewing the draft for > LC, and I apologize, but I think it's pretty important... >>From the 3697bis draft: > "There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, no > Internet-wide mechanism can depend mathematically on immutable and > uniformly distributed flow labels; they have a "best effort" quality." > But it goes on to say: > " This specification defines the flow label as immutable once it has > been set to a non-zero value. However, implementers are advised that > forwarding nodes, especially those acting as domain border devices, > might nevertheless be configured to change the flow label value in > packets. This is undetectable." > My interpretation of the above is that it functionally renders the flow label > mutable. If one cannot assume that the flow label will > arrive at its destination with the original value intact, nor detect when it > has been changed, it is by definition mutable and it's > nonsensical to have this discussed in such an ambiguous way in the draft, > because no implementer in their right mind is going to try > to use this for an application that needs the label to be immutable in all > cases. This draft should be correcting the fundamentally > flawed assumption that an unprotected field can be immutable. I don't see how > Ran's comments would be a different case and > (apparently) a different interpretation of the above. > > I don't recall consensus forming around this idea of immutable, but with > asterisks instead of simply acknowledging that regardless > of what the standard said before, the label has always been mutable since > it's unprotected. However, I've had a couple of gaps where > $day_job has taken precedence over IETF lists, so I might have missed a part > of that discussion. Apologies if I'm rehashing. Perhaps > the chairs would like to offer an interpretation? > > Wes George -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
