Our messages crossed, Simon. > - IPv6 stack interacting with the adaptation layer
I'm not sure I agree with that (see my other mail), but if you're correct I really what to dig that and fix it. Please read the other email I just sent and if you still see that the mapping is not there then please refine what the issue is exactly. > - No one-to-one mapping between a RH3-6LoRH and a RH3 We can reconstruct an RH0 form from RH3 and from RH3-6LoRH, and recompress an RH0 into both as well. I fail to see what the problem is though I do hope that implementations never need to play that game. When the packet goes up the stack, the RH3-6LoRH should be gone, removed by the last router (which may be collocated). Would you be willing to participate to the next 6TiSCH interim? We'll discuss that topic since it impacts the plugtest. Cheers, Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Simon Duquennoy > Sent: mercredi 20 janvier 2016 08:44 > To: Michael Richardson <[email protected]> > Cc: Pascal Thubert (pthubert) <[email protected]>; [email protected]; > Routing Over Low power and Lossy networks <[email protected]>; Tengfei Chang > <[email protected]>; [email protected] > Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH > > 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
