mcr> 1) What L2 address would the JP use in the Enhanced Beacon?
mcr> Could we mandate that whatever it uses there, that it also configure as
mcr> a valid l3 LL address? It doesn't have to use that address by default
mcr> for any other traffic.
mcr>
mcr> 2) we could include the lower-64-bits of the LL address for the JP in
the
mcr> Enhanced Beacon.Pascal Thubert (pthubert) <[email protected]> wrote: PT> Which is much better IMHO. This can be expressed as a compressed PT> IPv6 address; any compression works for like 6LoWPAN, including PT> one single bit that says that it is derived from the MAC. Looks PT> very close to the above, but in principle quite different. So I think that you are saying that the Enhanced Beacon needs to include the full IPv6 (LL) of the Join Proxy, but that it could say that is in fact compressed using 6LoWPAN mechanisms. So, something like RFC6282, section 3.1.1, but only the second byte, with CID probably forced to 0? Is this what you had in mind? >> > - Piggy back an ARO in the join request, implicitly associated with >> > the link local of the device. The JP may store it or not, I guess it >> > could have a bounded amount of NCE for this use. At least, it could >> > immediately reject the Join if the LL is a duplicate with another >> > node, in which case a NA (status/=0) would work. Otherwise duplicate >> > LL may be an issue for a non-EUI64-based LL. >> I don't like this. pt> Well no one likes duplicate addresses, either, but the issue pt> will arise if the pledge wants privacy. I don't like trying to stuff the ARO into the join request. It violates too many layers in most systems. Even a flat-code space contiki,RIOT or OpenWSN, it will be convoluted. Any OS with more layers will find it impossible. pt> Note that the ND exchange is one hop Q&A so it does not 'double' the cost of anything. pt> The point is that we must document the proper way and then pt> explain optimizations; if we only have an optimization and that pt> optimization depends on EUI 64 then we're in for privacy-related pt> issues. I feel that I disagree for two reasons. a) Regardless of what we do at L3, if one uses a manufacturer derived EUI-64 for the 8-byte layer-2 address, then one discloses. And this occurs even when encrypted. In the industrial IoT space assumed by 6tisch, the devices do not visit coffee shops. Even if attached to one's person (a true "PAN"), the devices do not talk to the coffee shop network. Nor do they join the coffee shop network. If you still need privacy beyond tracking the device between coffee shops, then you need a randomized L2. Doing things at L3 won't get you any additional privacy. b) The "prohibition" against deriving L3 addresses from L2 ones is predicated upon the concept that L2 addresses are constant. Since a major point of the join process is to get a "randomized" (not linked to manufacturer) 2-byte address... I'd call our process privacy enhancing. c) I think that we would prefer, for security purposes, to have a strong link between something we can print on the outside of the device and the L2 address used. That doesn't have to be manufacturer EUI-64 4-byte prefix + serial number. So I just gotta push back on the privacy argument. We aren't building protocols for *Internet*, we are building *internet* protocols. >> > - If the prefix is known, we can define an anycast address “any JP on >> > this prefix” similar to the home agent anycast address in RFC 3775. >> >> Yes, but can we sanely reply from that address? >> Are anycast addresses allowed in source addresses? > [PT>] for all I know, they are not. So no you cannot use that in > the reply. Then we shouldn't address traffic to it if we expect a reply :-) But, it must be allowed in replies, or UDP to anycast couldn't ever work. > [PT>] And I have never seen it used in the reply. > If we really need to enforce that the response come to the same > address as the source of the request we are in a tight corner. Yeah, because operating systems want to associate the packet with the right socket. > If this is a consequence of an implementation as opposed to a > standard then that implementation could be corrected, too. It's how sockets work. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
