-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Joel" == Joel M Halpern <j...@joelhalpern.com> writes:
Joel> Off-list, although you may decide that my confusion is wider, and
take it
Joel> back to the list:
okay, I think it's worthwhile.
Joel> When a ROLL network is talking to the rest of the world, using IPv6,
it would
Joel> seem that packets can arrive with
Joel> a) a non-zero flow label
Joel> b) which happened to be an extant RPLinstanceID
Joel> c) and apparently the sender, since it is outside of ROLL, is not
permitted
Joel> to use that instanceID
Joel> d) but we clearly want the traffic to continue
Joel> WHhy is this at all unlikely? Are you counting on not having
Joel> collisions between values in a 20 bit field? It simply isn't
Joel> big enough for that to be a safe assumption.
I think that (d) is unlikely.
That is, random nodes on the network, not only will not have a reason to
talk to the light bulb in my living room, but also won't be permitted to
do so.
(If it's actually me at the random IP, then likely I'll come through an
IPsec tunnel...)
I'm not saying that this will apply to *ALL* ROLL deployments, but to
the majority of them that are envisaged today. (In fact, the things I
want to deploy likely will suffer from this more than the average will)
In particular, the commodity situation where some node on my network
decides to do an HTTP request to commodity site FOO, and the packets in
question here are replies to my request.
I do not know how the reply flow labels will be set, but if it will be
simply echoed by TCP passive opens, then in fact, (c) might not apply.
That is, the node will have permission to use that instanceID.
It's not because the node is outside of the ROLL that it can not use
the instanceID. It's just that nodes outside the ROLL won't know much
about the instanceIDs, if the applications running on them have not been
configured properly.
That is, my network device used instanceID XYZ to send the request out,
and it is appropriate for replies to also use XYZ. There might even be a
stateful firewall opening a pinhole on the ACL for instanceID XYZ.
If it should come that it is accepable for an intermediate node to reset
the FL to zero, that would solve the problem for incoming packets.
I guess, I'd rather we allocate well known FL=1 (or 0b1111...) to
indicate, "has been reset" rather than "was never set", I'd be happier.
If it is permissible for a "firewall" to drop packets with non-zero FLs,
then that might also solve the problem. I'd hate to see that in any
kind of commodity system: I've had it with "secure" banks that can not
speak ECN, or that have broken PMTU.
- --
] 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBTGFuZ4CLcPvd0N1lAQKZHQf/dEAJLQkwFLXDUAaDPLU0bzw4GoMb6xzw
ILymBmJKBLUJ88LwGDLCC5XNwn2ayY9EB/wE/N6yt5l6e9mijDhiHAaNQAVMMlxs
ktqEx048ANVbG6QtRYsCmJyjWmoutG5jYBYfIuDJBle5vHsKApb7msH+I24C3jRs
AyaTJfom7isFTLo/Eua0a5t7OORdbNB61aRmqqDwJ4g0gCjJlxOaPJhAglm/j3lV
W24SshuJy+M0Zglzu7XbYqobcaA0//jJBe3nMpLTUJyVuT8+vdQ9m7lbblUI2YKZ
YHfWIkVzbWGxBoe7J9SiFu0vR56g88pCEBXuYiXkkTeiWMQpHDiL8g==
=0kD/
-----END PGP SIGNATURE-----
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
