{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
--------------------------------------------------------------------
