From: Mathis Marion <mathis.marion@silabs.com>
To: linux-wpan@vger.kernel.org
Cc: "Jérôme Pouiller" <jerome.pouiller@silabs.com>
Subject: RPL lwtunnel encapsulation
Date: Tue, 24 Oct 2023 20:35:07 +0200 [thread overview]
Message-ID: <d25926f8-84bd-4eef-9e44-86fb1e3e5932@silabs.com> (raw)
Hello linux-wpan devs,
I have been experimenting with the RPL SRH support implemented by
Alexander Aring. I hope related questions fit into this mailing list,
otherwise feel free to redirect me elsewhere.
In the original merge commit (96376cad3508) for this feature, the log
indicates that IPv6-in-IPv6 encapsulation is implemented:
In receive handling I add handling for IPIP encapsulation as RFC6554
describes it as possible.
However, my observations suggest that it is actually not the case when
forwarding packets. Instead, the IPv6 header of the packet is modified
in a way which violates the IPv6 specification (RFC 8200 section 4):
Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted by any node along a packet's delivery
path, until the packet reaches the node (or each of the set of nodes,
in the case of multicast) identified in the Destination Address field
of the IPv6 header.
In the appendix I describe more precisely the steps I took to come to
this conclusion. A couple questions follow from my observations:
- First of all, is my analysis flawed?
- Then, was this behavior implemented knowingly?
- Finally, should it be changed?
########################################################################
Appendix: my experiment
I have 2 TUN devices setup and a couple simple routes to do testing.
$ ip -6 route
[...]
2001:db8::1 dev tun1 proto kernel metric 256 pref medium
2001:db8::2 dev tun2 proto kernel metric 256 pref medium
2001:db8::3 dev tun2 metric 1024 pref medium
2001:db8::4 encap rpl segs 1 [ 2001:db8::3 ] dev tun2 metric 1024
pref medium
[...]
I am then generating a packet at tun1, destined to 2001:db8::4, and
observing what goes through both interfaces using tshark.
$ tshark -i tun1 -i tun2 -V
Capturing on 'tun1' and 'tun2'
Frame 1: 48 bytes on wire (384 bits), 48 bytes captured (384 bits)
on interface tun1, id 0
[...]
Internet Protocol Version 6, Src: 2001:db8::1, Dst: 2001:db8::4
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00
(DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated
Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit
Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 8
Next Header: UDP (17)
Hop Limit: 255
Source Address: 2001:db8::1
Destination Address: 2001:db8::4
User Datagram Protocol, Src Port: 5000, Dst Port: 5000
Source Port: 5000
Destination Port: 5000
Length: 8
Checksum: 0x7d57 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Frame 2: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
on interface tun2, id 1
[...]
Internet Protocol Version 6, Src: 2001:db8::1, Dst: 2001:db8::3
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00
(DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated
Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit
Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 24
Next Header: Routing Header for IPv6 (43)
Hop Limit: 254
Source Address: 2001:db8::1
Destination Address: 2001:db8::3
Routing Header for IPv6 (RPL Source Route)
Next Header: UDP (17)
Length: 1
[Length: 16 bytes]
Type: RPL Source Route (3)
Segments Left: 1
1111 .... .... .... .... .... .... .... = Compressed
Internal Octets (CmprI): 15
.... 1111 .... .... .... .... .... .... = Compressed Final
Octets (CmprE): 15
.... .... 0111 .... .... .... .... .... = Padding Bytes: 7
.... .... .... 0000 0000 0000 0000 0000 = Reserved: 0
[Total Address Count: 1]
Address: 04
[Address[1]: 2001:db8::4]
User Datagram Protocol, Src Port: 5000, Dst Port: 5000
Source Port: 5000
Destination Port: 5000
Length: 8
Checksum: 0x7d57 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
We can then see that the original packet header was modified, with
destination address changed, and a routing extension header added. If
IPv6-in-IPv6 encapsulation was at play, the original header would have
been copied unchanged (except the hop limit I suppose), and an
additional IPv6 header accompanied with the SRH would have been added as
an outer header.
next reply other threads:[~2023-10-24 18:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 18:35 Mathis Marion [this message]
2023-10-25 15:35 ` RPL lwtunnel encapsulation Michael Richardson
2023-10-26 1:03 ` Alexander Aring
2023-10-26 12:39 ` Alexander Aring
2023-10-26 13:56 ` Michael Richardson
2023-10-26 16:44 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d25926f8-84bd-4eef-9e44-86fb1e3e5932@silabs.com \
--to=mathis.marion@silabs.com \
--cc=jerome.pouiller@silabs.com \
--cc=linux-wpan@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).