Hello Thomas :
I agree it is non-obvious. Here’s why I ended up with that recommendation:
1) The IP in IP 6LoRH in RFC8138 was designed for the minimal
encapsulation as opposed to a generic one, basically a place holder for the
outer addresses to be added and removed easily, and meltdown avoidance with a
hop limit; everything else is defaulted. This was just an artifact to pass the
6MAN logo. Seems that since then, the law has been bended but that’s another
story. Its format is as follows:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 14: The IP-in-IP-6LoRH
As you see, there is not provision to transport traffic class in that encoding.
To transport the TC in outer IP in IP, we’d need to specify a new 6LoRH type
for richer IP in IP. Can be done, but quite a bit of hassle. When you asked, I
translated “with a minimum changes in mind” and answered accordingly.
2) In the particular case of the join packet from the join proxy upwards,
there is probably no IP in IP, unless an extra encapsulator finds a reason to
do so
(https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-19#page-17);
in the general case of IP in IP, the encapsulator may or may not be the source
of the packet; for an encapsulated join, it would not be. So for the generic
case of a packet that has to be encapsulated, we’d have to set rules on whether
the encapsulator echoes the inned TC in the outer TC. Again, hassle, hassle.
Not having an outer TC gives back the control to the source, the JP in our
case. At the expense of extra complexity in a node that care whether there is a
TC, and which has to dig down to IPHC. Not that hard though.
Makes sense?
Pascal
From: 6tisch [mailto:[email protected]] On Behalf Of Thomas Watteyne
Sent: mardi 14 novembre 2017 14:44
To: [email protected]
Subject: [6tisch] tagging join traffic wih DSCP: why inside IP header?
Pascal,
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.
Thomas
--
_______________________________________
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
