Pascal Thubert (pthubert) <[email protected]> wrote: > Maybe we can just have one bit. On, the 64bits suffix is inline, > Off, the suffix is derived from the MAC address; semi quoting:
> 1: 64 bits. The first 64-bits of the address are elided.
> The value of those bits is the link-local prefix padded with
> zeros. The remaining 64 bits are carried in-line.
> 0: 0 bits. The address is fully elided. The first 64 bits
> of the address are the link-local prefix padded with zeros.
> The remaining 64 bits are computed from the encapsulating
> header (e.g., 802.15.4 or IPv6 destination address) as
> specified in Section 3.2.2.
I like this very much, but I'm not certain I understand where it goes.
I thought into the Enhanced Beacon, but other words below make me think
you want to put it into the join request
> Don't you think that forcing an implicit relation between the MAC
> and the IP is going to cause knee-jerks in the review process?
Maybe.
> The idea of signaling it at the cost of one bit leaves the future
> open and allows us to do what we do today.
I'm open to signaling it. More options means more bugs.
> My suggestion is to transport that bit in the join and in the
> response back, same as the beacon one.
I'm confused here.
We are putting the IPv6LL of the joining node into the join request
as context. Are you saying that a bit here would say if the L2 address
is the same? I think that the best way to do that is to have two
different dictionary keys. Let me think about the best way to do this.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
