Pascal Thubert (pthubert) <pthub...@cisco.com> wrote:
> 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.
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.
> 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.
> - 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?
> - 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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
