Roland Bless <[email protected]> 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 <[email protected]> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
