linux-kernel - Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d458b4c0-963e-d9bc-c4bb-ab689edd7686@gmail.com>
Date:   Mon, 9 Mar 2020 09:36:48 -0600
From:   David Ahern <dsahern@...il.com>
To:     Ahmed Abdelsalam <ahmed.abdelsalam@...i.it>,
        Carmine Scarpitta <carmine.scarpitta@...roma2.it>
Cc:     davem@...emloft.net, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, dav.lebrun@...il.com,
        andrea.mayer@...roma2.it, paolo.lungaroni@...t.it,
        hiroki.shirokura@...ecorp.com
Subject: Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

On 3/6/20 9:45 AM, Ahmed Abdelsalam wrote:
> 
> However, in the SRv6 we don’t really need a VRF device. The SRv6
> functions (the already supported ones as well as the End.DT4 submitted
> here) resides in the IPv6 FIB table.
> 
> The way it works is as follows:
> 1) create a table for the tenant
> $ echo 100 tenant1 >> /etc/iproute2/rt_tables
> 
> You instantiate an SRv6 End.DT4 function at the Egress PE to decapsulate
> the SRv6 encapsulation and lookup the inner packet in the tenant1 table.
> The example iproute2 command to do so is as below.
> 
> $ ip -6 route add A::B encap seg6local action End.DT4 table tenant1 dev
> enp0s8
> 
> This installs an IPv6 FIB entry as shown below.
> $ ip -6 r
> a::b  encap seg6local action End.DT4 table 100 dev enp0s8 metric 1024
> pref medium
> 
> Then the BGP routing daemon at the Egress PE is used to advertise this
> VPN service. The BGP sub-TLV to support SRv6 IPv4 L3VPN is defined in [2].
> 
> The SRv6 BGP extensions to support IPv4/IPv6 L3VPN are now merged in in
> FRRouting/frr [3][4][5][6].
> 
> There is also a pull request for the CLI to configure SRv6-locator on
> zebra [7].
> 
> The BGP daemon at the Ingress PE receives the BGP update and installs an
> a FIB entry that this bound to SRv6 encapsulation.
> 
> $ ip r
> 30.0.0.0/24  encap seg6 mode encap segs 1 [ a::b ] dev enp0s9
> 
> Traffic destined to that tenant will get encapsulated at the ingress
> node and forwarded to the egress node on the IPv6 fabric.
> 
> The encapsulation is in the form of outer IPv6 header that has the
> destination address equal to the VPN service A::B instantiated at the
> Egress PE.
> 
> When the packet arrives at the Egress PE, the destination address
> matches the FIB entry associated with the End.DT4 function which does
> the decapsulation and the lookup inside the tenant table associated with
> it (tenant1).

And that is exactly how MPLS works. At ingress, a label is pushed to the
front of the packet encapping the original packet at the network header.
It traverses the label switched path and at egress the label is popped
and tenant table can be consulted.

IPv6 SR is not special with any of these steps. If you used a VRF device
and used syntax that mirrors MPLS, you would not need a kernel change.
The infrastructure to do what you need already exists, you are just
trying to go around and special case the code.

SR for IPv6 packets really should have been done this way already; the
implementation is leveraging a code path that should not exist.

> 
> Everything I explained is in the Linux kernel since a while. End.DT4 was
> missing and this the reason we submitted this patch.
> 
> In this multi-tenant DC fabric we leverage the IPv6 forwarding. No need
> for MPLS dataplane in the fabric.

My MPLS comment was only point out that MPLS encap and IPv6 SR encap is
doing the exact same thing.