-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>> "Philip" == Philip Levis <[email protected]> writes: Philip> I feel like we're running in circles, in part due to Philip> different expectations of how RPL will be used. Philip> It's clear that in proprietary or vertically integrated Philip> networks running RPL, it's possible to state how Philip> controllers/other nodes set the flow label in order to play Philip> nice with RPL. E.g., if my home automation network receives Philip> commands from a special device (which itself might have a Philip> web/SOAP/etc. interface), then that special device can set Philip> the flow label. This isn't the problem case. Philip> The problem case for the use of the flow label is when Philip> arbitrary Internet hosts (e.g., my laptop) want to Philip> communicate with devices running RPL. E.g., I have a home Philip> RPL network and want to directly talk to a RPL device from Philip> my laptop. Requiring the packet source to be aware of flow Philip> labels and how to set them breaks the whole idea of Internet Philip> connectivity: suddenly an end host needs to be aware of what Philip> routing protocol is used to reach the other host, as well as Philip> configuration parameters of that host. I need to be able to Philip> SSH to the RPL-connected device without requiring a new ssh Philip> program that uses ioctls to set flow labels. We can't say Philip> that only OSes which set the flow label to 0 (or some other Philip> value) can be used. Nor can we expect to change how OSes set Philip> the flow label. I guess I don't see the problem to be as big a deal as you suggest. I'm happy if flow label 0 gets some default RPLinstanceID. It would be convenient if the rules were relaxed such that on ingress, the RPL edge router could *set* the FL if it were zero, and it appears that this matches up well with what the load balancing people want to do. Today, if you ssh or HTTP or what-not, without doing anything special, you will get a flow label of zero, which with the above rule, means you get connectivity. Only if some intermediate node sets the FL=0 would it be a problem today, and that's illegal so far. BTW: the flowlabel is not in an ioctl, it's right in the sockaddr_in6. Too bad that inet_ntop(3)/RFC2373/4291 was not specified to include the flow label, as then it would be just a matter of user education... Maybe there is some way to use the %ifname notation used for ifindex mapping. (okay, it falls apart once you want to use DNS) It seems to me that within RPL, if we use RPLinstanceID, we need to decide what to do when we get a flow label from an untrusted source that is non-zero. Inserting an end-host option, with the unstrusted FL seems like the right thing to do to me. This facility might be generally useful to entire Internet. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTGGx4oCLcPvd0N1lAQIuhgf/Z6e/vJKj9K+6+N3djKdLx7nut2iJ+K1X JaKs/TsKJdNJ59520x9m5pcYo+r9oXrGVG2mohIHu0WktY/XkJMdBSncgkiKvSmh VEZlFAzw+eJYZdiNlWvIFxD13REOyc4S+jJhx6ECONFSq2csHdbt8q7O1jIsDuar hEhLS7v0a61T7rbM7aP95q+aYBr2ofWX5g596I/lYgSwZ7+fhuySm7DhckBWf/yC pPdEw4xAMA4/jnHZzp3iTKcFhbGQWvdBvsUKPM/EJLQWwExzFS3WmEP3ltDyXkiZ zo5oEj7Xdir2mN18cvyysa/8izgQ8sD3TSYUu+feNHO2hRdbNRoX3w== =kE6H -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
