On Jul 29, 2010, at 15:11, Michael Richardson wrote: > What's the FLOW LABEL FOR then?
Wrong question, at least if taken the way you meant to ask it. Let me try to give an answer to the question "why is it there" from the view of a somewhat cynical protocol designer and see who of the original players would like to oppose my analysis. The flow label is an unused space of 20 (was: 28) bits in the IPv6 header. It is there to round the size of this header up to a multiple of 8 bytes. However, marking all these 20 bits as reserved appears to have caused too much cognitive dissonance to the IPv6 designers (or they feared such dissonance during reception of their proposal; I wasn't there). Instead, the 20 bits were given an ostensible purpose to remove that cognitive dissonance. Since intserv, a technology that is about flows, was modern just at the time when IPv6 was finally nailed down, the spare bits were given an ostensible purpose in the area of distinguishing flows. Intserv never took really off, and it was too difficult to make the flow label idea useful in a mixed v4/v6 world, so that assignment was never specified out well enough to make it concrete. Instead, in order to keep it usable for its ostensible purpose, we managed to accumulate various prohibitions on its proper use that appear to have made sure it is not used at all. In effect, the flow label is still a collection of reserved bits in the IPv6 header. I'm not saying this development is bad or even that the players that caused this development acted in a devious way. It is a relatively rational result of the cognitive and political processes that govern protocol design in a consensus environment. We can learn a lot for future protocol designs from examining these kinds of cases from the past. Now my contribution to the discussion. Since the cognitive dissonance of 20 unused bits per packet is no longer likely to damage IPv6, we might now want to recognize the flow label as what it is. 20 bits that are waiting for a purpose. With the nice property that they can be changed in the network without upsetting checksums/integrity checks. Allocating all of them right now at once, early in the lifetime of the protocol, doesn't strike me as particularly prudent. Being able to use them as a short MPLS label, as was envisioned in RPL, might be a good experimental use, if this does not mean they get lost for any and all future use in the general Internet. A policy of MBZ, overwrite at will on ingress, clear at egress, might be good enough to enable that experimental use. Gruesse, Carsten -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
