Hello Michael
Regards, Pascal > Le 24 avr. 2018 à 20:21, Michael Richardson <[email protected]> a écrit : > > > 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. > I’m Addressing the join response coming back. At that point the JP has the MAC of the pledge but not its LL. The bit in the request to the JRC is echoed and the JP knows without a lookup that the ll address derived from EUI 64... Take care, Pascal > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works | network architect > [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
