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) < [email protected]> 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 <[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]> > 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
