Not really. It was rather my view of the architecture that differs a bit from what you describe in your previous mail. For me RPL produces the RH3 and then passes the packet down the stack for compression. Or for incoming packets, first there is decompression, then the IPv6 packet with its headers and extension headers are passed up to RPL etc. If find it odd to force upper layers to work on 6lowpan compressed formats.
On Tue, Jan 19, 2016 at 10:42 PM, Michael Richardson <[email protected]> wrote: > > Pascal Thubert (pthubert) <[email protected]> wrote: > > destination does not have the same reference as 6554 either. And the > final > > destination may have a different prefix than the core of the mesh, so > using > > addresses in the mesh like RFC 6554 and the new proposal do seems a > better > > idea. RFC 6554 is emulated in the current draft by representing the > first > > address in full, since that is the end of the current segment in the > 6LoRH > > format. But to compress it, we need a reference, thus the idea to use > the > > root as opposed to the final destination. > > Simon, is it the fact that the root is present here that makes you feel that > it's linked? > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
