Hello Micheal: > > 1) What L2 address would the JP use in the Enhanced Beacon? > Could we mandate that whatever it uses there, that it also configure as > a valid l3 LL address? It doesn't have to use that address by default > for any other traffic. > > 2) we could include the lower-64-bits of the LL address for the JP in the > Enhanced Beacon. > [PT>] Which is much better IMHO. This can be expressed as a compressed IPv6 address; any compression works for like 6LoWPAN, including one single bit that says that it is derived from the MAC. Looks very close to the above, but in principle quite different.
> > To resolve the address of the device at the JP you could > > > - 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>] [PT>] Well no one likes duplicate addresses, either, but the issue will arise if the pledge wants privacy. Note that the ND exchange is one hop Q&A so it does not 'double' the cost of anything. The point is that we must document the proper way and then explain optimizations; if we only have an optimization and that optimization depends on EUI 64 then we're in for privacy-related issues. > > > - 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. > > > - There is such thing as traffic source set to unspecified address > > (all zeroes) though. If that’s enough for you, you may use that. > > ugh. > I can live with a source of ::, but I would rather not. [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. If this is a consequence of an implementation as opposed to a standard then that implementation could be corrected, too. Take care, [PT>] Pascal _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
