[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK-6q+hRz-M0hy611rDZhiF7CVUSD1FmPGMLGNBhVJ-CjSFqtg@mail.gmail.com>
Date: Wed, 26 Jun 2024 09:48:30 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Mathis Marion <mathis.marion@...abs.com>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, alex.aring@...il.com, davem@...emloft.net,
dsahern@...nel.org, edumazet@...gle.com, jerome.pouiller@...abs.com,
kuba@...nel.org, kylian.balan@...abs.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, pabeni@...hat.com,
Michael Richardson <mcr@...delman.ca>
Subject: Re: [PATCH v1 2/2] ipv6: always accept routing headers with 0
segments left
Hi,
On Wed, Jun 26, 2024 at 6:10 AM Mathis Marion <mathis.marion@...abs.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@...zon.com> wrote:
> >>
> >> From: Mathis Marion <Mathis.Marion@...abs.com>
> >> Date: Mon, 24 Jun 2024 16:15:33 +0200
> >>> From: Mathis Marion <mathis.marion@...abs.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
Powered by blists - more mailing lists