Right, I'm using the wrong wording, I counted RFC6554 as RPL, sorry for the confusion.
What I don't like: - IPv6 stack interacting with the adaptation layer - No one-to-one mapping between a RH3-6LoRH and a RH3 If I'm not mistaken, everything else in 6lowpan offers this one-to-one mapping, and that allows the IPv6 stack to work independently of 6lowpan (i.e. the same stack runs both in 6lowpan environment or not). I also find this property nice, conceptually, as one can produce any IPv6 packet and easily derive its compressed form, and back. One header maps to one compressed header with all its fields compressed, etc. If I'm the only one to think this is an issue, I'm ready to close the issue. Thanks, Simon On Tue, Jan 19, 2016 at 11:06 PM, Michael Richardson <[email protected]> wrote: > > Simon Duquennoy <[email protected]> wrote: > > Not really. It was rather my view of the architecture that differs a > > bit from what you describe in your previous mail. > > okay. > > > 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. > > RPL is the thing in RFC6550, a routing protocol, that runs over ICMP ND > messages. > > I think the thing you are describing is the IPv6 stack, and you don't like > that the IPv6 stack has to interact with the link adaptation layer. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
