public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed

* [PATCH v1 0/2] ipv6: always accept routing headers with 0 segments left
@ 2024-06-24 14:15 Mathis Marion
  2024-06-24 14:15 ` [PATCH v1 1/2] ipv6: introduce ipv6_rthdr_rcv_last() Mathis Marion
  2024-06-24 14:15 ` [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left Mathis Marion
  0 siblings, 2 replies; 8+ messages in thread
From: Mathis Marion @ 2024-06-24 14:15 UTC (permalink / raw)
  To: David S. Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni
  Cc: netdev, linux-kernel, Jérôme Pouiller, Kylian Balan,
	Alexander Aring, 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


^ permalink raw reply	[flat|nested] 8+ messages in thread

• * [PATCH v1 1/2] ipv6: introduce ipv6_rthdr_rcv_last()
    2024-06-24 14:15 [PATCH v1 0/2] ipv6: always accept routing headers with 0 segments left Mathis Marion
  @ 2024-06-24 14:15 ` Mathis Marion
    2024-06-24 14:15 ` [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left Mathis Marion
    1 sibling, 0 replies; 8+ messages in thread
  From: Mathis Marion @ 2024-06-24 14:15 UTC (permalink / raw)
    To: David S. Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
  	Paolo Abeni
    Cc: netdev, linux-kernel, Jérôme Pouiller, Kylian Balan,
  	Alexander Aring, 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
  
  
  ^ permalink raw reply related	[flat|nested] 8+ messages in thread

• * [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left
    2024-06-24 14:15 [PATCH v1 0/2] ipv6: always accept routing headers with 0 segments left Mathis Marion
    2024-06-24 14:15 ` [PATCH v1 1/2] ipv6: introduce ipv6_rthdr_rcv_last() Mathis Marion
  @ 2024-06-24 14:15 ` Mathis Marion
    2024-06-25 21:38   ` Kuniyuki Iwashima
    1 sibling, 1 reply; 8+ messages in thread
  From: Mathis Marion @ 2024-06-24 14:15 UTC (permalink / raw)
    To: David S. Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
  	Paolo Abeni
    Cc: netdev, linux-kernel, Jérôme Pouiller, Kylian Balan,
  	Alexander Aring, 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
  
  
  ^ permalink raw reply related	[flat|nested] 8+ messages in thread

• • * Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left
      2024-06-24 14:15 ` [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left Mathis Marion
    @ 2024-06-25 21:38   ` Kuniyuki Iwashima
      2024-06-26  1:45     ` Alexander Aring
      0 siblings, 1 reply; 8+ messages in thread
    From: Kuniyuki Iwashima @ 2024-06-25 21:38 UTC (permalink / raw)
      To: mathis.marion
      Cc: alex.aring, davem, dsahern, edumazet, jerome.pouiller, kuba,
    	kylian.balan, linux-kernel, netdev, pabeni, kuniyu
    
    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
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

  • • * Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left
        2024-06-25 21:38   ` Kuniyuki Iwashima
      @ 2024-06-26  1:45     ` Alexander Aring
        2024-06-26 10:10       ` Mathis Marion
        0 siblings, 1 reply; 8+ messages in thread
      From: Alexander Aring @ 2024-06-26  1:45 UTC (permalink / raw)
        To: Kuniyuki Iwashima
        Cc: mathis.marion, alex.aring, davem, dsahern, edumazet,
      	jerome.pouiller, kuba, kylian.balan, linux-kernel, netdev, pabeni,
      	Michael Richardson
      
      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
      
      
      ^ permalink raw reply	[flat|nested] 8+ messages in thread

    • • * Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left
          2024-06-26  1:45     ` Alexander Aring
        @ 2024-06-26 10:10       ` Mathis Marion
          2024-06-26 13:48         ` Alexander Aring
          2024-07-16 21:27         ` Alexander Aring
          0 siblings, 2 replies; 8+ messages in thread
        From: Mathis Marion @ 2024-06-26 10:10 UTC (permalink / raw)
          To: Alexander Aring, Kuniyuki Iwashima
          Cc: alex.aring, davem, dsahern, edumazet, jerome.pouiller, kuba,
        	kylian.balan, linux-kernel, netdev, pabeni, Michael Richardson
        
        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.
        
        
        ^ permalink raw reply	[flat|nested] 8+ messages in thread

      • • * Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left
            2024-06-26 10:10       ` Mathis Marion
          @ 2024-06-26 13:48         ` Alexander Aring
            2024-07-16 21:27         ` Alexander Aring
            1 sibling, 0 replies; 8+ messages in thread
          From: Alexander Aring @ 2024-06-26 13:48 UTC (permalink / raw)
            To: Mathis Marion
            Cc: Kuniyuki Iwashima, alex.aring, davem, dsahern, edumazet,
          	jerome.pouiller, kuba, kylian.balan, linux-kernel, netdev, pabeni,
          	Michael Richardson
          
          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
          
          
          ^ permalink raw reply	[flat|nested] 8+ messages in thread

        • * Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left
            2024-06-26 10:10       ` Mathis Marion
            2024-06-26 13:48         ` Alexander Aring
          @ 2024-07-16 21:27         ` Alexander Aring
            1 sibling, 0 replies; 8+ messages in thread
          From: Alexander Aring @ 2024-07-16 21:27 UTC (permalink / raw)
            To: Mathis Marion
            Cc: Kuniyuki Iwashima, alex.aring, davem, dsahern, edumazet,
          	jerome.pouiller, kuba, kylian.balan, linux-kernel, netdev, pabeni,
          	Michael Richardson
          
          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
          
          
          ^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-07-16 21:27 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-24 14:15 [PATCH v1 0/2] ipv6: always accept routing headers with 0 segments left Mathis Marion
2024-06-24 14:15 ` [PATCH v1 1/2] ipv6: introduce ipv6_rthdr_rcv_last() Mathis Marion
2024-06-24 14:15 ` [PATCH v1 2/2] ipv6: always accept routing headers with 0 segments left Mathis Marion
2024-06-25 21:38   ` Kuniyuki Iwashima
2024-06-26  1:45     ` Alexander Aring
2024-06-26 10:10       ` Mathis Marion
2024-06-26 13:48         ` Alexander Aring
2024-07-16 21:27         ` Alexander Aring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox