Hello all : Guessing the Link Local of the JP looks like a very bad idea. Because the JP may not form a link local from EUI. This is being discouraged for privacy reasons. Guessing is really unclean any way.
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. - Lookup the Link Local of the device on the way back, if there is no NCE, but that’s a multicast from the JP to locate the JN To reverse resolve the IP - 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. - Else you can define a multicast all-JPs and use the multicast IP over unicast MAC trick by extension to RFC 6085. - Early implementations / pre standards can ship with FF02::2 instead of all-JPs, but the standard should be correct otherwise we’ll pay it at the IESG. For the mail below: - There is no such thing as traffic from all-routers. With RFC 6085 we are tricking “all” at L3 with a unicast L2 to make the L3 multicast become a sort of anycast and where we get to choose which JP. - There is such thing as traffic source set to unspecified address (all zeroes) though. If that’s enough for you, you may use that. - With RFC 6775 update, ND registration for a link local is a one hop thing, does not fly to the root or what, so the cost is really limited Take care, Pascal From: 6tisch <[email protected]> On Behalf Of Mališa Vucinic Sent: mercredi 18 avril 2018 19:37 To: Michael Richardson <[email protected]> Cc: [email protected] Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process On Wed, 18 Apr 2018 at 19:17, Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: > Yes, I guess you could call it an ephemeral cache entry > constructed by CoAP at JP when the join response is received, > before being forwarded to the pledge. As soon as the packet is > passed to L2, the cache entry is removed. Can we do this? I think that we can do this. It might be better if the traffic came from ff02::2, but I'm not sure that would be acceptable for IPv6 reasons. I am concerned that a reply from a different L3 address will not be acceptable to some coap libraries. Indeed, good point about a different adress in the response. @Pascal, would it be possible for JP to use all-routers as the source IPv6 address? If not, does it help if we define our own well-known address?
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
