On 31 Jan 2011 at 09:17:47 -0500, Joel Halpern wrote: > Several of these comments have a common theme of requiring domains > to remark flow-labels on ingress. While we have agreed to allow > remarking of packets with 0 values in their flow label, expecting > repeated remarking seems to me a very bad idea. Basically, if we do that, > then I expect that most routers will simply assume that the flow label > is useless, since we can not expect peering scale routers to remark > the flow label of packets based on deep packet inspection. Also, > in many cases, as described in other documents, such re-marking > is effectively impossible.
Joel's comments are well put. That noted, everyone interested in the Flow Label issue needs to keep in mind that various operational domains (e.g. sites, organisations, providers) have various domain-specific and site-specific security policies that preclude end-to-end Flow Label values. In particular, a number of domains connected to the public Internet, including a number of commercial firms, are concerned about use of "covert channels" by their adversaries (e.g. to steal IPR, to probe interior network segments). While most (all ?) useful communications protocols have at least some low-bandwidth covert channels, the IPv6 Flow Label stands out as a relatively high-bandwidth covert channel -- due to its size. Packets entering or leaving a domain with such a security policy very likely will have their IPv6 Flow Label either zeroed or otherwise overwritten with new values upon ingress or egress. I understand that such capabilities commonly exist in currently deployed commercially available firewall products. I'm further told that the larger sized commercial firewalls have hardware (e.g. ASICs) that can zero or remark IPv6 Flow Label values at interestingly high speeds (e.g. at least wire-speed for a 1 GigE interface, possibly faster). Similarly, organisations operating such domains do NOT want their end systems putting non-zero bits into the IPv6 Flow Label during packet origination, as that is a particularly interesting high speed way to covertly export data from such end systems. One imagines that sysctl() or similar knobs might be used by some system administrators to disable generation of non-zero IPv6 Flow Labels within the originating nodes of a given domain. Kindly note that I'm merely reporting what I understand to be the case in an interesting number of cases. I'm not advocating any particular behaviour on the part of any enterprise/ISP/other network operator. Also note that the IETF normally levies requirements upon device/protocol implementers, but does not normally levy requirements upon enterprise/ISP/other network operators. In any event, one imagines the local security policy will de facto take precedence over what any RFC says, within a given domain, should an RFC contradict local security policy. When one intersects Joel's comments above and my observations above, it is not obvious to me that an arbitrary router somewhere in the global Internet reasonably could expect that the IPv6 Flow Label of an arbitrary IPv6 packet will contain values useful for LAG, SLB, etc. Yours, Ran Atkinson -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
