Hi John, First off, forget what the Appendix of RFC 2460 says. It's not normative.
So, the current rules are in RFC 3697. They certainly don't allow any kind of semantics in the bits of the flow label (in the absence of a signalling mechanism): > IPv6 nodes MUST NOT assume any mathematical or other properties of > the Flow Label values assigned by source nodes. Then: >> reserving several bits that could be changed by ConEx-aware >> routers Changing any bits is forbidden by RFC 3697. We are discussing draft-ietf-6man-flow-3697bis-00.txt, which will (if approved) replace RFC 3697. It doesn't allow encoding any kind of semantics either, or mutability, but of course it's open for debate in the WG. I suggest reading that draft as the next step. Regards Brian Carpenter On 2011-02-08 01:33, John Leslie wrote: > Roland Bless <roland.bl...@kit.edu> wrote: >> Am 04.02.2011 18:53, schrieb Vishwas Manral: >> >>> If we want to process connex or some particular option, we could >>> process it. However there may need to be some assumptions like, the >>> option is the first in the list of options or any such thing. >> Personally, I'm not looking for a new option, but I was wondering >> about Conex trying to redefine/claim common IPv6 header bits for >> their purpose, which is IMHO worse than using some HbH option... > > Disclaimer: I am a co-author of one of the ConEx drafts; but I make no > claim to speak for anyone else -- least of all my co-authors! > > I _think_ we're looking at the Flow Label field. Let me outline my > understanding of that field -- > > RFC 2460 states that the Flow Label field is to be set by the source: > ] > ] 6. Flow Labels > ] > ] The 20-bit Flow Label field in the IPv6 header may be used by a > ] source to label sequences of packets for which it requests special > ] handling by the IPv6 routers, such as non-default quality of service > ] or "real-time" service. This aspect of IPv6 is, at the time of > ] writing, still experimental and subject to change as the requirements > ] for flow support in the Internet become clearer. Hosts or routers > ] that do not support the functions of the Flow Label field are > ] required to set the field to zero when originating a packet, pass the > ] field on unchanged when forwarding a packet, and ignore the field > ] when receiving a packet. > ] > ] Appendix A describes the current intended semantics and usage of the > ] Flow Label field. > > Note Appendix A is "current intended semantics" and is clearly subject > to change. > > Appendix A "currently" calls for: > ] > ] A flow label is assigned to a flow by the flow's source node. New > ] flow labels must be chosen (pseudo-)randomly and uniformly from the > ] range 1 to FFFFF hex. The purpose of the random allocation is to > ] make any set of bits within the Flow Label field suitable for use as > ] a hash key by routers, for looking up the state associated with the > ] flow. > > Since Appendix A calls for "pseudo-random" and section 6 insists that > "most" routers must ignore the field and pass it unchanged, at first blush > ConEx-aware senders could put something there and expect it to survive > the trip through a number of not-ConEx-aware routers. ;^) > > Note that RFC 1883, which suggested that routers "opportunistically" > "set up flow handling state" is now quite obsolete (the field doesn't > even match!); and even 1883 made no suggestion that a router might > legitimately _change_ the flow label. > > (I suppose technically a NAT might play with flow-label, since the > definition calls for a flow to be > ] > ] uniquely identified by the combination of a source address and a > ] non-zero flow label > > but I have no reason to believe any existing IPv6 NAT does such a thing.) > > IMHO, Appendix A of RFC 2460 was pining-for-the-fjords when RFC 2460 > was published in 1998. However, we need to consider RFC 3697, published > in 2004. (It is standards-track, but I don't know of any implementations.) > > RFC 3697 specifies: > > - The Flow Label value set by the source MUST be delivered unchanged > to the destination node(s) > > - IPv6 nodes MUST NOT assume any mathematical or other properties of > the Flow Label values assigned by source nodes. > > - Router performance SHOULD NOT be dependent on the distribution of the > Flow Label values. Especially, the Flow Label bits alone make poor > material for a hash key. > > ==== > > Thus it would seem that ConEx-aware senders could put a value in > Flow label, reserving several bits that could be changed by ConEx-aware > routers (and more importantly by ConEx policers) without changing the > flow _identity_ as seen by ConEx-aware devices. > > I'd like to see some discussion of this. IMHO, 6man is a better place > for the discussion than ConEx, since ConEx is concerned with the meaning > of bits more than transport of them. > > -- > John Leslie <j...@jlc.net> > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
