On Thu, 22 Apr 2010 15:23:27 -0500 "Manfredi, Albert E" <albert.e.manfr...@boeing.com> wrote:
> > -----Original Message----- > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > > Behalf Of Shane Amante > > > c) Declare the flow-label is _immutable_ and must be set by > > all hosts and must only contain a 3- or 5-tuple hash of the > > appropriate IPv6 headers. Further use cases for the > > flow-label would be restricted. IMHO, this would be by far > > the easiest from an implementation and operational > > point-of-view, however this is unlikely to appeal to > > proponents of domain-specific special-uses of flow-labels, > > unfortunately. > > Count me in. In following this thread, I've come to believe that this is the > best course of action. And it keeps the flow label immutable, as originally > prescribed. > There's the interesting question. If it was supposed to be end-to-end immutable, then it should have been covered by an end-to-end checksum, which in the case of IPv6 means a transport layer checksum, via a transport layer IPv6 pseudo-header. Even further, as the IPsec AH header doesn't cover it, then that means that not only isn't it protected against network faults, it also means it's integrity isn't ever assured from a 'proper' security perspective. Since it wasn't end-to-end protected, then I think that fundamentally indicates that it is mutable as it traverses the network. I think that therefore means that you can only trust it's value across a domain upon which you can trust the network's integrity, and I think that domain only corresponds to a network which you control and operate, or one that you are paying to use, with error-free service level agreements. And there's the interesting quandary. The attractive value of the flow label is that the only checksum that protects it is the layer 2 checksum (should there be one). Conversely, the fundamental problem with the flow label is that it isn't protected by a checksum, other than a layer 2 one. So it's not protected end-to-end, it isn't protected against layer 2 errors when layer 2 doesn't implement checksums, and it isn't protected against memory errors in routers, even when layer 2 has a checksum that protects it. In other words, similar to IPv6 packets themselves, the flow label fields is only a 'best effort' field, and can only be trusted within a domain that can be controlled, or one that the flow label serves the purpose of a hint, not a value to be absolutely relied upon. I think there is a fair amount value in the field (verses new extension headers that could be used for the same purpose), and I think there are a number of uses for it. We just need to be careful about uses which place absolute trust in it, outside domains where the trust in it's integrity can be assumed and assured. Regards, Mark. > > Therefore, if a legitimate use of flow-labels has not been > > found in the last 15 years of IPv6 development, it's time to > > move on and use the flow-label for something useful and > > practical in production networks, (i.e.: a hash of the 3- or > > 5-tuple of L3 + L4 headers for LAG + ECMP load-balancing). > > Indeed. This becomes doable easily in IPv6, no matter the extension headers. > What better purpose could there be for this field? And it's certainly NOT a > stretch to think that the traditional 5-tuple was, in fact, used to define > what some might call a "flow." > > Bert > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
