Hi Brian: > On 2010-08-09 22:17, Pascal Thubert (pthubert) wrote: > > Hi Michael: > > > > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I > > tried to stay within the lines of RFC 3697 as you also defend in your > > mail. > > > > I think the question we have now is not whether that proposal is > > lawful but whether the new law being defined at 6MAN would prevent it > > in the future. > > If the updated rules allow, then I'll be glad to work on an FL-based > > alternate to the IPinIP/HbH. > > So I understand that ROLL would definitely need the ability to define explicit > semantics on the label. Would it also need the label to be mutable? >
[Pascal] The FL based proposal for RPL uses 12 mutable bits. They are used as an in-band control plane that checks the consistency of routing states along a path. Those states can easily get out of sync due to the nature of the links, but the maintenance can be costly. We want to accelerate the repairs on those links that are actually used when an inconsistency is detected that will impact the delivery. RPL also builds multiple topologies (virtual networks identified by an instanceID) to address various constraints, in terms that can be such as metrics but also administrative. E.g. a power utility Command & Control network at home will have a specific ID that's different from the default general purpose one, so the power related traffic ends up at the power utility GW along a specific graph. An opaque instanceID for the topology can be known by the end points. The instanceID is not necessarily related to QoS and does not map to a per hop behavior, but in our case, to acts more like L3 .1Q tag. The Flow Label is the only field available for an application to pass such information to the network. Thus the non-mutable 8 bits in the proposal. > > > > It appeared at the 6MAN WG meeting that 12 bits mutable was exactly > > what the core network was asking for to do its load balancing. > > A first question to the group could be whether 12 mutable bits are > > enough for the sensible usages envisioned so far? > > To me it seems that 12 bits could contain enough randomness to drive a load > balancing mechanism, but there's no need for those bits to be mutable that I > can see. On the other hand, 12 bits seems very small for any kind of nonce or > for a flow identification scheme, so it seems that draft-blake and > draft-donley > would be knocked out. I'm unsure why draft_donley does not copy the IPv4 TOS Byte in the IPv6 Traffic Class Octet, if differentiated service is what the draft is after. In any case, it appears that the need is not really for a flow but for a flow type, in which case 8 non mutable bits are enough. I'm also unsure why draft blake can be preferred over syn cookies, but if it is, then, obviously the more bits the better. Still, this nonce is not used by the network, so the network header should not be encumbered by it. If you look at it, a similar problem appears when a node receives a packet back in an ICMP error, in which case it would be safe to make sure that the node really issued that packet in the first place, otherwise actions taken upon the ICMP could be misused by an attacker from anywhere in the Internet.. If we take the path of a nonce, I'd favor a new "source option" with semantics by which the network is not concerned with the header and that would enable the source to place its own information such as this nonce. Thanks a bunch for your help, Pascal > Brian > > > > >> -----Original Message----- > >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf > > Of > >> Michael Richardson > >> Sent: Wednesday, August 04, 2010 4:05 AM > >> To: r...@ietf.org; Carsten Bormann > >> Cc: Pascal Thubert (pthubert); ipv6@ietf.org > >> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable > >> > >> > >> {there is a thread which started on r...@ietf.org, and ipv6@ietf.org, > > and then > >> seemed to have dropped r...@ietf.org. I'm not on ipv6@ietf.org, so > > there likely > >> are message there I've missed} > >> > >> okay, so I've read Carsen's opinion. > >> I read RFC 3697 (which I didn't know about). > >> > >> draft-hu-flow-label-cases-00 is a very good read. I pull out > > something from > >> section 4 (Discussion); > >> > >> The other choice, for designers who wish to use the flow label to > >> control switching or QoS directly, is to bypass the rules within a > >> given domain (a set of cooperating nodes) in a way that nodes > > outside > >> the domain cannot detect. In this case, any deviation from > > [RFC3697] > >> has no possible effect outside the domain in question. > >> > >> I don't know where this subject line is from: 12 bits/8bits. > >> Is there a draft that explains that idea that I've missed? > >> > >> My claim is that ROLL's RPL is a set of cooperating nodes. > >> > >> But, it's better than that --- it's a set of routers which are tuned > > to support > >> specific applications, and the applications want in this case to be > > given > >> information like, "what flow label" to use. RPL's RPLinstanceID has > > all the > >> properties required of a flow label (or, rather, it has no > > requirements presently, > >> and therefore can have the flow label requirements imposed upon it, > >> specifically: > >> 2. "Nodes MUST NOT assume any mathematical or other properties of > >> the Flow Label" > >> ) > >> > >> The non-mutability of the label isn't a problem either --- the > > applications *AT > >> EACH END*, even if one end of the application is several AS's away (a > > very > >> unusual case for 95% of RPL's target use), that application still > > needs to know > >> something about what label to use. > >> > >> There are three cases to consider: > >> a) traffic between two RPL nodes > >> b) traffic exiting an RPL > >> c) traffic entering an RPL > >> > >> case (a) -- is the "set of cooperating nodes", and therefore is no > > problem. > >> case (b) -- the flow label is set to get through the RPL/LLN, and out > > to > >> the network, and the flow label has done it's job, and > >> the RPL/LLN network could care less what happens to the > > flow > >> label at that point. The rest of the network might have > > a > >> problem (i.e. a bug) when RPL networks start sending > >> non-zero flow labels, but that's the rest of the > > network's > >> problem. > >> > >> case (c) - flow labels of zero are not a problem. There is either a > >> default RPLinstanceID to use (and traffic flows, perhaps not > >> optimally), or there isn't (and ICMP Host unreachable > > occurs). > >> - non-zero flow labels which do not map to an RPLinstanceID, > >> are simply considered zero, see above. > >> - non-zero flow labels which map to RPLinstanceIDs are used. > >> *If* it is a problem for outsiders to invoke that LLN's > >> DODAG, then there are bigger issues, which the flow label > > can neither > >> help nor hinder --- the flowlabel is not a magic security > > cookie. > >> A firewall may still be required. > >> > >> The only real problem I can see is when a packet needs to do (b) and > >> (c). e.g. use label A to exit LLN alpha, and label B to enter LLN > > beta. > >> I don't have a solution to this. Some have suggested IPIP tunnels, > > which sound > >> nice in theory, but in practice do not work in the wilderness found > > behind the > >> walls of walled gardens. > >> > >> -- > >> ] He who is tired of Weird Al is tired of life! | > > firewalls [ > >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > >> architect[ > >> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ > > |device > >> driver[ > >> Kyoto Plus: watch the video > >> <http://www.youtube.com/watch?v=kzx1ycLXQSE> > >> then sign the petition. > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
