On Apr 15, 2010, at 05:52, Brian E Carpenter wrote: >> the flow-label MUST or, at >> least, SHOULD be reset to 0 upon /leaving/ that domain, >> otherwise the next domain may (or, will?) misinterpret the >> meaning of the incoming "locally-defined" flow-label. The > > I'm personally quite attracted by this. It does further damage > to the sacred principle that the flow label is immutable, > but maybe that is the inevitable result anyway.
It may be useful to discuss this in the context of a more general question: How does a domain stash temporary information (meaningful only in that domain) into an IPv6 packet, with the intention of removing it again at domain egress? See also: "RPL Option for Carrying RPL Information in Data-Plane Datagrams", Jonathan Hui, JP Vasseur, 10-Mar-10, <draft-hui-6man-rpl-option-00.txt> The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL option for use within a RPL domain. This work was originally trying to use the flow label in a similar way, and has moved to proposing to insert a hop-hy-hop option. Note that hop-by-hop options *inserted* on the way destroy AH, so in this case they *must* be removed at egress (including at final delivery; and the fun part about "removing" is then how to reconstitute any padding in the original hbh option, if there was one). I'm not saying the flow label does not pose an attractive nuisance for addressing some of these problems. But if it is already taken in a packet (by the sending host or by an encapsulating domain), how does the domain derive the benefit? We can either stipulate that everyone (end-to-end, encapsulating domain) please use it in a similar way (i.e., 5-tuple), or we can provide for a way to stash it on ingress and reconstruct it on egress (the only way that would be useful for RPL, as its use would not be about the 5-tuple). None of this makes me particularly happy right now. (I'm not even saying the flow label work *must* consider this problem. It just appears it's getting awfully close to it.) Gruesse, Carsten -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------