Hello Mališa The all-0 destination is tricky, not done anymore that I know off. Trying that may get us through hell at 6MAN and/or IESG.
I think that as an RFC you must described the clean way and then the optimizations when the LLs are based on EUI 64. IMHO, the spec should say that: - That the pledge sends an RS to all-JPs at l3, L2 dest = unicast MAC of the JP. - That the pledge registers its LL using ND EARO. With that we are clean from the standards perspective. And then, to address your concern, the spec would then indicate that if the pledge or the JP LL are derived from EUI 64 then some optimizations are possible. If the JP LL derives from EUI 64 you may: - Have a bit in the beacon that indicates so. If the pledge LL derives from EUI 64 you may: - Skip the ND EARO to register the LL to the JP - Indicate in the join message that the LL derives from the MAC - Use it on the way back to skip the look up Notes: - The JP just needs to have a threshold of unsecured NCE, and a sensible lifetime for these, but that’s not that difficult. - If the NCE for the pledge is no more there when the join response comes in then the JP needs to do a NS look up. Also, I do not necessarily agree that the ND phase is that expensive. It is just a one-hop exchange. Cheers, Pascal From: Mališa Vučinić <malisa.vuci...@inria.fr> Sent: jeudi 19 avril 2018 15:32 To: Pascal Thubert (pthubert) <pthub...@cisco.com> Cc: Michael Richardson <mcr+i...@sandelman.ca>; 6tisch@ietf.org Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process Pascal, If we were to use the unspecified address, would the following be OK: - Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2 source: pledge EUI; L3 destination: JP EUI from the Beacon - Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2 source: JP EUI; L2 destination: Pledge EUI (Join Request and Join Response refer to packets exchanged between the pledge and the JP.) This seems to: - resolve Michael's concern about CoAP libraries expecting the response to come from the same IPv6 address where it was sent to - not introduce any additional packet overhead - avoid an ND exchange doubling communication overhead - avoid the need to keep a separate insecure cache at JP. How this would be implemented is implementation specific, one example is an ephemeral cache entry discussed in previous emails. Let me know if you see any pitfalls, to me it looks quite appealing as an option. Mališa On Thu, Apr 19, 2018 at 2:41 PM Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>> wrote: 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 <6tisch-boun...@ietf.org<mailto:6tisch-boun...@ietf.org>> On Behalf Of Mališa Vucinic Sent: mercredi 18 avril 2018 19:37 To: Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> Cc: 6tisch@ietf.org<mailto:6tisch@ietf.org> Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process On Wed, 18 Apr 2018 at 19:17, Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
