Hey, not so Thomas. The 6MAN rules have been bended in more than one way since the times when the IP in IP discussions took place.
1) RFC8200 allows routers to ignore HbH options so sending the RPI outside the RPL domain is OK. We actually made it ignorable in https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-19#section-3.2 2) Header insertion is not as Tabu as it was, with segment routing inserting them anyway. So I expect that removing the RPI is OK. Good news, with 6LoRH, it just means ignore the 6LoRH headers, start by decompressing the IPHC and forward just that. It was a design goal for 6LoRH to make the header insertion/deletion, the routing header operations easy to code and debug. The packet starting at the IPHC is exactly what should be decompressed and forwarded, and there is no RPL artifact to it. DPI means a layer violation. Looking at the IPHC is not. So conceptually, yes that was very far off ☺ Take care, Pascal From: Thomas Watteyne [mailto:[email protected]] Sent: mercredi 15 novembre 2017 16:55 To: Pascal Thubert (pthubert) <[email protected]> Cc: Michael Richardson <[email protected]>; [email protected] Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header? Pascal, Michael, If there is no IPIP, then everything is easy. But, AFAICT, we want the JRC to be able to live on the Internet, i.e. not per se co-located with the DAGroot. In that case, the Join Request looks like any data packet sent by the JP to an IPv6 address outside the mesh, which triggers IPIP because the outer IP header contains the RPI. So AFAICT, IPIP is needed unless we mandate that JRC and DAGroot are collocated. So with IPIP, if we want to play by the rules, forwarding routers (nodes in the mesh) only look at the outer IP header, and treat the inner IP header as opaque. So if we use RFC6282 for that header with TF=b10 so ECN+DSCP are carried inline, it doesn't matter. AFAICT, you recommend to "dig down to IPHC". Looks more and more like my initial recommendation of using DPI wasn't that far off :-) Thomas On Wed, Nov 15, 2017 at 2:37 AM, Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Hello Michael: > I thought that in 8138, that if we didn't need an outer IPIP, that we just > used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1) This is correct. The RPL artifact for the join request is only the RPI, and the packet (going up) looks as follows in both storing and non-storing, assuming the join is a UDP/CoAP packet. The format in Figure 16 is logically equivalent to the uncompressed format illustrated in Figure 17: +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | IPv6 Header | Hop-by-Hop | RPI in | ICMP message ... | NH = 58 | Header | RPL Option | +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Figure 17: Uncompressed ICMP Packet with RPI For a UDP packet, the transport header can be compressed with 6LoWPAN HC [RFC6282<https://tools.ietf.org/html/rfc6282>] as illustrated in Figure 18: +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+... |11110001| RPI- | NH=1 |11110CPP| Compressed | UDP |Page 1 | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payload +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+... <- RFC 6282<https://tools.ietf.org/html/rfc6282> -> No RPL artifact Figure 18: Uncompressed ICMP Packet with RPI RFC 8138 places the artifact in front so it is easy to manipulate. After that, you find the IPHC, which encodes the traffic class. Nothing really complex. A simpler side question is whether the rest of the join flow (response etc…) should trigger allocation of timeslots by the SF or not. If the response only comes for valid requests then I supposed it should. Take care, Pascal -----Original Message----- From: 6tisch [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Michael Richardson Sent: mercredi 15 novembre 2017 03:29 To: [email protected]<mailto:[email protected]> Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header? Michael Richardson <[email protected]<mailto:[email protected]>> wrote: >> During the WG meeting yesterday, we discussed using DSCP bits as a way >> to identify join request/reply messages. We talked about mapping, in >> the minimal-security spec, the different DSCP values to scheduling >> behavior. >> But you indicated the DSCP bits would be in the inside IPv6 header. >> That doesn't make sense to me, can you please provide more info? The >> outside IPv6 header looks to me like the right place to put the bits. > I thought it was a typo, and I passed it by. > Why in this non-storing, RPL-aware situation is there even an IPIP outer > header for traffic from the proxy to the DODAG root? Since I re-read Pascal's answer (in the light of my "day"), I now see why it can not go into to the outer IP header, because we didn't not plan for it. I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... <https://tools.ietf.org/html/rfc6282#section-3.2.1> ) If we can agree that this is the way, then I think we also need to agree that certain AFxx would be assigned to available bandwidth, and not cause 6top to allocate any additional bandwidth. This does not really fit "AF" Diffserv in some ways (which in some ways to buffer/delay rather than drop...). -- Michael Richardson <[email protected]<mailto:[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com<http://www.thomaswatteyne.com> _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
