Thanks for your reply. >> 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. Okay, I understood. >> 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. No, you only need to add single rule for accepting these SIDs. Here is the quote of RFC 8986. --- This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). L, the locator length, is flexible, and an operator is free to use the locator length of their choice. F and A may be any value as long as L+F+A <= 128. When L+F+A is less than 128, then the remaining bits of the SID MUST be zero. A locator may be represented as B:N where B is the SRv6 SID block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID. When the LOC part of the SRv6 SIDs is routable, it leads to the node, which instantiates the SID. --- If there are 100 SIDs, but these SIDs are for the same node, the locators of these SIDs also should be same. so, you can allow SRv6 flows by adding only single rule. > 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. You stated this patch isn't acceptable because NF_HOOK is called even when End behavior is processing, aren't you? So, do you think it’s natural that NF_HOOK is called *only* when SRv6 behavior is encap/decap operation. The problem I stated first is that netfilter couldn't track inner flows of SRv6-encapsulated packets regardless of the status of IPv6 conntrack. If yes, I will fix and resubmit patch. Ryoga
