[PATCH v1 0/2] ipv6: always accept routing headers with 0 segments left

[PATCH v1 0/2] ipv6: always accept routing headers with 0 segments left

[Mathis Marion]

From: Mathis Marion <mathis.marion@silabs.com>

Hello maintainers,

Here is a bit of context for this series: Silicon Labs is working
on implementing a Wi-SUN[1] routing daemon for Linux[2]. Wi-SUN uses
RPL[3] for routing, which uses a specialized IPv6 routing header[4],
supported by a kernel module[5]. Currently, our border router daemon
does not rely on that kernel module and instead inserts the Source
Routing Header (SRH) in userspace after reading the IPv6 packet from a
TUN device.

Future development is now geared towards a router implementation (as
opposed to a border router), which does not insert the SRH but instead
processes it. The first step was to implement a leaf node, which always
receive a SRH with 0 segments left. Even without having the RPL kernel
module enabled, I was expecting the kernel to properly receive these
packets, but they were instead being dropped. Looking at the kernel
code, it seems that the SRH would have been accepted before
8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr").

[1]: https://wi-sun.org/
[2]: https://github.com/SiliconLabs/wisun-br-linux
[3]: https://www.rfc-editor.org/rfc/rfc6550.html
[4]: https://www.rfc-editor.org/rfc/rfc6554.html
[5]: https://elixir.bootlin.com/linux/v6.9/source/net/ipv6/Kconfig#L322

Mathis Marion (2):
  ipv6: introduce ipv6_rthdr_rcv_last()
  ipv6: always accept routing headers with 0 segments left

 net/ipv6/exthdrs.c | 124 ++++++++++++++++++---------------------------
 1 file changed, 48 insertions(+), 76 deletions(-)

-- 
2.43.0

[PATCH v1 1/2] ipv6: introduce ipv6_rthdr_rcv_last()

[Mathis Marion]

From: Mathis Marion <mathis.marion@silabs.com>

This factorizes some code between ipv6_srh_rcv(), ipv6_rpl_srh_rcv()
and ipv6_rthdr_rcv().

Note that:
  - IPv4-in-IPv6 was previously only supported by ipv6_srh_rcv().
  - IPv6-in-IPv6 was previously not supported in ipv6_rthdr_rcv().

Signed-off-by: Mathis Marion <mathis.marion@silabs.com>
---
 net/ipv6/exthdrs.c | 107 ++++++++++++++++++---------------------------
 1 file changed, 42 insertions(+), 65 deletions(-)

diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 6789623b2b0d..083dbbafb166 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -366,9 +366,45 @@ static void seg6_update_csum(struct sk_buff *skb)
 			   (__be32 *)addr);
 }
 
-static int ipv6_srh_rcv(struct sk_buff *skb)
+static int ipv6_rthdr_rcv_last(struct sk_buff *skb)
 {
 	struct inet6_skb_parm *opt = IP6CB(skb);
+	struct net *net = dev_net(skb->dev);
+	const struct ipv6_rt_hdr *hdr;
+
+	hdr = (struct ipv6_rt_hdr *)skb_transport_header(skb);
+
+	if (hdr->nexthdr == NEXTHDR_IPV6 || hdr->nexthdr == NEXTHDR_IPV4) {
+		int offset = (hdr->hdrlen + 1) << 3;
+
+		skb_postpull_rcsum(skb, skb_network_header(skb),
+				   skb_network_header_len(skb));
+		skb_pull(skb, offset);
+		skb_postpull_rcsum(skb, skb_transport_header(skb), offset);
+
+		skb_reset_network_header(skb);
+		skb_reset_transport_header(skb);
+		skb->encapsulation = 0;
+		if (hdr->nexthdr == NEXTHDR_IPV4)
+			skb->protocol = htons(ETH_P_IP);
+		__skb_tunnel_rx(skb, skb->dev, net);
+
+		netif_rx(skb);
+		return -1;
+	}
+
+	opt->srcrt = skb_network_header_len(skb);
+	opt->lastopt = opt->srcrt;
+	skb->transport_header += (hdr->hdrlen + 1) << 3;
+	opt->dst0 = opt->dst1;
+	opt->dst1 = 0;
+	opt->nhoff = (&hdr->nexthdr) - skb_network_header(skb);
+
+	return 1;
+}
+
+static int ipv6_srh_rcv(struct sk_buff *skb)
+{
 	struct net *net = dev_net(skb->dev);
 	struct ipv6_sr_hdr *hdr;
 	struct inet6_dev *idev;
@@ -395,34 +431,8 @@ static int ipv6_srh_rcv(struct sk_buff *skb)
 #endif
 
 looped_back:
-	if (hdr->segments_left == 0) {
-		if (hdr->nexthdr == NEXTHDR_IPV6 || hdr->nexthdr == NEXTHDR_IPV4) {
-			int offset = (hdr->hdrlen + 1) << 3;
-
-			skb_postpull_rcsum(skb, skb_network_header(skb),
-					   skb_network_header_len(skb));
-			skb_pull(skb, offset);
-			skb_postpull_rcsum(skb, skb_transport_header(skb),
-					   offset);
-
-			skb_reset_network_header(skb);
-			skb_reset_transport_header(skb);
-			skb->encapsulation = 0;
-			if (hdr->nexthdr == NEXTHDR_IPV4)
-				skb->protocol = htons(ETH_P_IP);
-			__skb_tunnel_rx(skb, skb->dev, net);
-
-			netif_rx(skb);
-			return -1;
-		}
-
-		opt->srcrt = skb_network_header_len(skb);
-		opt->lastopt = opt->srcrt;
-		skb->transport_header += (hdr->hdrlen + 1) << 3;
-		opt->nhoff = (&hdr->nexthdr) - skb_network_header(skb);
-
-		return 1;
-	}
+	if (hdr->segments_left == 0)
+		return ipv6_rthdr_rcv_last(skb);
 
 	if (hdr->segments_left >= (hdr->hdrlen >> 1)) {
 		__IP6_INC_STATS(net, idev, IPSTATS_MIB_INHDRERRORS);
@@ -482,7 +492,6 @@ static int ipv6_srh_rcv(struct sk_buff *skb)
 static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
 {
 	struct ipv6_rpl_sr_hdr *hdr, *ohdr, *chdr;
-	struct inet6_skb_parm *opt = IP6CB(skb);
 	struct net *net = dev_net(skb->dev);
 	struct inet6_dev *idev;
 	struct ipv6hdr *oldhdr;
@@ -506,33 +515,8 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
 looped_back:
 	hdr = (struct ipv6_rpl_sr_hdr *)skb_transport_header(skb);
 
-	if (hdr->segments_left == 0) {
-		if (hdr->nexthdr == NEXTHDR_IPV6) {
-			int offset = (hdr->hdrlen + 1) << 3;
-
-			skb_postpull_rcsum(skb, skb_network_header(skb),
-					   skb_network_header_len(skb));
-			skb_pull(skb, offset);
-			skb_postpull_rcsum(skb, skb_transport_header(skb),
-					   offset);
-
-			skb_reset_network_header(skb);
-			skb_reset_transport_header(skb);
-			skb->encapsulation = 0;
-
-			__skb_tunnel_rx(skb, skb->dev, net);
-
-			netif_rx(skb);
-			return -1;
-		}
-
-		opt->srcrt = skb_network_header_len(skb);
-		opt->lastopt = opt->srcrt;
-		skb->transport_header += (hdr->hdrlen + 1) << 3;
-		opt->nhoff = (&hdr->nexthdr) - skb_network_header(skb);
-
-		return 1;
-	}
+	if (hdr->segments_left == 0)
+		return ipv6_rthdr_rcv_last(skb);
 
 	n = (hdr->hdrlen << 3) - hdr->pad - (16 - hdr->cmpre);
 	r = do_div(n, (16 - hdr->cmpri));
@@ -648,7 +632,6 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
 static int ipv6_rthdr_rcv(struct sk_buff *skb)
 {
 	struct inet6_dev *idev = __in6_dev_get(skb->dev);
-	struct inet6_skb_parm *opt = IP6CB(skb);
 	struct in6_addr *addr = NULL;
 	int n, i;
 	struct ipv6_rt_hdr *hdr;
@@ -709,13 +692,7 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
 		default:
 			break;
 		}
-
-		opt->lastopt = opt->srcrt = skb_network_header_len(skb);
-		skb->transport_header += (hdr->hdrlen + 1) << 3;
-		opt->dst0 = opt->dst1;
-		opt->dst1 = 0;
-		opt->nhoff = (&hdr->nexthdr) - skb_network_header(skb);
-		return 1;
+		return ipv6_rthdr_rcv_last(skb);
 	}
 
 	switch (hdr->type) {
-- 
2.43.0

[PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left

[Mathis Marion]

From: Mathis Marion <mathis.marion@silabs.com>

Routing headers of type 3 and 4 would be rejected even if segments left
was 0, in the case that they were disabled through system configuration.

RFC 8200 section 4.4 specifies:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

Signed-off-by: Mathis Marion <mathis.marion@silabs.com>
---
 net/ipv6/exthdrs.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 083dbbafb166..913160b0fe13 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -662,17 +662,6 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
 		return -1;
 	}
 
-	switch (hdr->type) {
-	case IPV6_SRCRT_TYPE_4:
-		/* segment routing */
-		return ipv6_srh_rcv(skb);
-	case IPV6_SRCRT_TYPE_3:
-		/* rpl segment routing */
-		return ipv6_rpl_srh_rcv(skb);
-	default:
-		break;
-	}
-
 looped_back:
 	if (hdr->segments_left == 0) {
 		switch (hdr->type) {
@@ -708,6 +697,12 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
 		}
 		break;
 #endif
+	case IPV6_SRCRT_TYPE_3:
+		/* rpl segment routing */
+		return ipv6_rpl_srh_rcv(skb);
+	case IPV6_SRCRT_TYPE_4:
+		/* segment routing */
+		return ipv6_srh_rcv(skb);
 	default:
 		goto unknown_rh;
 	}
-- 
2.43.0

Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left

[Kuniyuki Iwashima]

From: Mathis Marion <Mathis.Marion@silabs.com>
Date: Mon, 24 Jun 2024 16:15:33 +0200
> From: Mathis Marion <mathis.marion@silabs.com>
> 
> Routing headers of type 3 and 4 would be rejected even if segments left
> was 0, in the case that they were disabled through system configuration.
> 
> RFC 8200 section 4.4 specifies:
> 
>       If Segments Left is zero, the node must ignore the Routing header
>       and proceed to process the next header in the packet, whose type
>       is identified by the Next Header field in the Routing header.

I think this part is only applied to an unrecognized Routing Type,
so only applied when the network stack does not know the type.

   https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4

   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.

But now the kernel recognizes RPL and it's intentionally disabled
by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.

And SRv6 has been rejected since 1ababeba4a21f for the same reason.


> 
> Signed-off-by: Mathis Marion <mathis.marion@silabs.com>
> ---
>  net/ipv6/exthdrs.c | 17 ++++++-----------
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> index 083dbbafb166..913160b0fe13 100644
> --- a/net/ipv6/exthdrs.c
> +++ b/net/ipv6/exthdrs.c
> @@ -662,17 +662,6 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
>  		return -1;
>  	}
>  
> -	switch (hdr->type) {
> -	case IPV6_SRCRT_TYPE_4:
> -		/* segment routing */
> -		return ipv6_srh_rcv(skb);
> -	case IPV6_SRCRT_TYPE_3:
> -		/* rpl segment routing */
> -		return ipv6_rpl_srh_rcv(skb);
> -	default:
> -		break;
> -	}
> -
>  looped_back:
>  	if (hdr->segments_left == 0) {
>  		switch (hdr->type) {
> @@ -708,6 +697,12 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
>  		}
>  		break;
>  #endif
> +	case IPV6_SRCRT_TYPE_3:
> +		/* rpl segment routing */
> +		return ipv6_rpl_srh_rcv(skb);
> +	case IPV6_SRCRT_TYPE_4:
> +		/* segment routing */
> +		return ipv6_srh_rcv(skb);
>  	default:
>  		goto unknown_rh;
>  	}
> -- 
> 2.43.0

Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left

[Alexander Aring]

Hi,

On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> From: Mathis Marion <Mathis.Marion@silabs.com>
> Date: Mon, 24 Jun 2024 16:15:33 +0200
> > From: Mathis Marion <mathis.marion@silabs.com>
> >
> > Routing headers of type 3 and 4 would be rejected even if segments left
> > was 0, in the case that they were disabled through system configuration.
> >
> > RFC 8200 section 4.4 specifies:
> >
> >       If Segments Left is zero, the node must ignore the Routing header
> >       and proceed to process the next header in the packet, whose type
> >       is identified by the Next Header field in the Routing header.
>
> I think this part is only applied to an unrecognized Routing Type,
> so only applied when the network stack does not know the type.
>
>    https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
>
>    If, while processing a received packet, a node encounters a Routing
>    header with an unrecognized Routing Type value, the required behavior
>    of the node depends on the value of the Segments Left field, as
>    follows:
>
>       If Segments Left is zero, the node must ignore the Routing header
>       and proceed to process the next header in the packet, whose type
>       is identified by the Next Header field in the Routing header.
>
> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
>
> But now the kernel recognizes RPL and it's intentionally disabled
> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
>
> And SRv6 has been rejected since 1ababeba4a21f for the same reason.

so there might be a need to have an opt-in knob to actually tell the
kernel ipv6 stack to recognize or not recognize a next header field
for users wanting to bypass certain next header fields to the user
space?

- Alex

Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left

[Mathis Marion]

On 26/06/2024 3:45 AM, Alexander Aring wrote:
> Hi,
> 
> On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>>
>> From: Mathis Marion <Mathis.Marion@silabs.com>
>> Date: Mon, 24 Jun 2024 16:15:33 +0200
>>> From: Mathis Marion <mathis.marion@silabs.com>
>>>
>>> Routing headers of type 3 and 4 would be rejected even if segments left
>>> was 0, in the case that they were disabled through system configuration.
>>>
>>> RFC 8200 section 4.4 specifies:
>>>
>>>        If Segments Left is zero, the node must ignore the Routing header
>>>        and proceed to process the next header in the packet, whose type
>>>        is identified by the Next Header field in the Routing header.
>>
>> I think this part is only applied to an unrecognized Routing Type,
>> so only applied when the network stack does not know the type.
>>
>>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
>>
>>     If, while processing a received packet, a node encounters a Routing
>>     header with an unrecognized Routing Type value, the required behavior
>>     of the node depends on the value of the Segments Left field, as
>>     follows:
>>
>>        If Segments Left is zero, the node must ignore the Routing header
>>        and proceed to process the next header in the packet, whose type
>>        is identified by the Next Header field in the Routing header.
>>
>> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
>>
>> But now the kernel recognizes RPL and it's intentionally disabled
>> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
>>
>> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> 
> so there might be a need to have an opt-in knob to actually tell the
> kernel ipv6 stack to recognize or not recognize a next header field
> for users wanting to bypass certain next header fields to the user
> space?
> 
> - Alex
> 

My point is that if a particular routing header support is disabled
through system configuration, it should be treated as any unrecognized
header. From my perspective, doing otherwise causes a regression every
time a new routing header is supported.

Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left

[Alexander Aring]

Hi,

On Wed, Jun 26, 2024 at 6:10 AM Mathis Marion <mathis.marion@silabs.com> wrote:
>
> On 26/06/2024 3:45 AM, Alexander Aring wrote:
> > Hi,
> >
> > On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >>
> >> From: Mathis Marion <Mathis.Marion@silabs.com>
> >> Date: Mon, 24 Jun 2024 16:15:33 +0200
> >>> From: Mathis Marion <mathis.marion@silabs.com>
> >>>
> >>> Routing headers of type 3 and 4 would be rejected even if segments left
> >>> was 0, in the case that they were disabled through system configuration.
> >>>
> >>> RFC 8200 section 4.4 specifies:
> >>>
> >>>        If Segments Left is zero, the node must ignore the Routing header
> >>>        and proceed to process the next header in the packet, whose type
> >>>        is identified by the Next Header field in the Routing header.
> >>
> >> I think this part is only applied to an unrecognized Routing Type,
> >> so only applied when the network stack does not know the type.
> >>
> >>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
> >>
> >>     If, while processing a received packet, a node encounters a Routing
> >>     header with an unrecognized Routing Type value, the required behavior
> >>     of the node depends on the value of the Segments Left field, as
> >>     follows:
> >>
> >>        If Segments Left is zero, the node must ignore the Routing header
> >>        and proceed to process the next header in the packet, whose type
> >>        is identified by the Next Header field in the Routing header.
> >>
> >> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
> >>
> >> But now the kernel recognizes RPL and it's intentionally disabled
> >> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
> >>
> >> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> >
> > so there might be a need to have an opt-in knob to actually tell the
> > kernel ipv6 stack to recognize or not recognize a next header field
> > for users wanting to bypass certain next header fields to the user
> > space?
> >
> > - Alex
> >
>
> My point is that if a particular routing header support is disabled
> through system configuration, it should be treated as any unrecognized
> header. From my perspective, doing otherwise causes a regression every
> time a new routing header is supported.
>

makes sense to me. I am asking myself what the exact reason is to have
the difference between "recognized" and "unrecognized" to judge more
about such change and what we may miss here to consider?

- Alex

Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left

[Alexander Aring]

Hi,

On Wed, Jun 26, 2024 at 6:10 AM Mathis Marion <mathis.marion@silabs.com> wrote:
>
> On 26/06/2024 3:45 AM, Alexander Aring wrote:
> > Hi,
> >
> > On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >>
> >> From: Mathis Marion <Mathis.Marion@silabs.com>
> >> Date: Mon, 24 Jun 2024 16:15:33 +0200
> >>> From: Mathis Marion <mathis.marion@silabs.com>
> >>>
> >>> Routing headers of type 3 and 4 would be rejected even if segments left
> >>> was 0, in the case that they were disabled through system configuration.
> >>>
> >>> RFC 8200 section 4.4 specifies:
> >>>
> >>>        If Segments Left is zero, the node must ignore the Routing header
> >>>        and proceed to process the next header in the packet, whose type
> >>>        is identified by the Next Header field in the Routing header.
> >>
> >> I think this part is only applied to an unrecognized Routing Type,
> >> so only applied when the network stack does not know the type.
> >>
> >>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
> >>
> >>     If, while processing a received packet, a node encounters a Routing
> >>     header with an unrecognized Routing Type value, the required behavior
> >>     of the node depends on the value of the Segments Left field, as
> >>     follows:
> >>
> >>        If Segments Left is zero, the node must ignore the Routing header
> >>        and proceed to process the next header in the packet, whose type
> >>        is identified by the Next Header field in the Routing header.
> >>
> >> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
> >>
> >> But now the kernel recognizes RPL and it's intentionally disabled
> >> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
> >>
> >> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> >
> > so there might be a need to have an opt-in knob to actually tell the
> > kernel ipv6 stack to recognize or not recognize a next header field
> > for users wanting to bypass certain next header fields to the user
> > space?
> >
> > - Alex
> >
>
> My point is that if a particular routing header support is disabled
> through system configuration, it should be treated as any unrecognized
> header. From my perspective, doing otherwise causes a regression every
> time a new routing header is supported.
>

coming back to this. I think you need to add another switch to do that
and turn it by default in whatever the current default situation is,
otherwise this patch will break the next person's behaviour.

- Alex