Hi Ryoga, please, see my answers below. On Fri, 9 Jul 2021 05:52:45 +0900 Ryoga Saito <proelbtn@xxxxxxxxx> wrote: > Dear Andrea > Thanks for your reviews and comments. > You're welcome, always happy to help if I can. > > > > the problem is that in SRv6 a packet to be processed by a node with an > > SRv6 End Behavior does not follow the INPUT path and its processing is > > different from the UDP tunnel example that you have in mind (more info > > below) > > > > Note that I'm referring to the SRv6 Behaviors as implemented in seg6_local.c > > I thought SRv6 processing to be the same as encapsulation/decapsulation > processing and I implemented patch this way intentionally. > Segment routing is *not* just another protocol to carry encapsulated traffic and, thus, to perform *only* encap/decap operations. Directly quoting the abstract of the RFC 8986: --- The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. --- In principle, each instruction can lead to a different processing than the other. > > I considered srv6 Behaviors (e.g. T.Encaps) to be the same as the encapsulation > in other tunneling protocols, and srv6local Behaviors (e.g. End, End.DT4, > End.DT6, ...) to be the same as the decapsulation in other tunneling protocols > even if decapsulation isn't happened. This is the point: SRv6 End, End.T, End.X with their flavors are *not* encap/ decap operations. As SRv6 is not a protocol meant only for encap/decap, we cannot apply to this the same logic found in other protocols that perform encap/decap operations. > I'm intended that SRv6 packets whose > destination address is SRv6 End Behavior go through INPUT path. > No, it does not work this way and this was an important design choice in the SRv6 implementation in Linux. Basically, the SIDs corresponding to End behaviors (srv6local) are *not* considered local addresses bound to a local interface. This has important advantages in terms of the forwarding performance of SRv6. We cannot change this design choice without causing a strong performance impact on SRv6 forwarding. > I think it works correctly on your situation with the following rule: > > ip6tables -A INPUT --dst fc01::2 -j ACCEPT > > To say more generally, SRv6 locator blocks should be allowed with ip6tables if > you want to change default policy of INPUT chain to DROP/REJECT. > No, this is a way to fix the problem that you introduce by changing the current srv6local forwarding model. If you have 100 End SIDs should you add 100 accept rules? The root problem is that SRv6 (srv6local) traffic should not go through the INPUT path. Have you set the traffic to flow through INPUT to confirm a connection (for conntrack)? If this is the only reason, before changing the srv6local processing model in such a disruptive way, you can investigate different ways to do connection confirmation without going directly through nfhook with INPUT. I can help with some hints if you are interested. Andrea
