2019-05-19 13:07:45 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-07-11 21:13:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-13 23:30:47 -07:00
|
|
|
|
2005-07-11 21:13:56 -07:00
|
|
|
|
2015-07-13 08:48:00 -07:00
|
|
|
|
2022-07-09 14:18:49 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-07-13 08:48:00 -07:00
|
|
|
|
2005-07-11 21:13:56 -07:00
|
|
|
|
|
|
|
|
|
2013-02-21 16:43:05 -08:00
|
|
|
|
2015-07-13 08:48:00 -07:00
|
|
|
|
2020-04-28 00:01:50 +02:00
|
|
|
|
2020-07-06 19:38:50 +02:00
|
|
|
|
2005-07-11 21:13:56 -07:00
|
|
|
|
2018-07-24 12:29:18 -07:00
|
|
|
|
2005-07-11 21:13:56 -07:00
|
|
|
|
|
|
|
|
|
2008-04-13 23:30:47 -07:00
|
|
|
|
|
|
|
|
|
2006-03-20 17:04:53 -08:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2006-03-20 17:04:53 -08:00
|
|
|
|
2009-01-26 11:12:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 17:04:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 17:06:24 -08:00
|
|
|
|
2012-10-02 11:19:49 -07:00
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2018-05-07 14:03:18 +02:00
|
|
|
|
2006-03-20 17:06:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
2012-10-02 11:19:49 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2018-05-07 14:03:18 +02:00
|
|
|
|
|
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2020-06-10 09:14:35 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2020-06-10 09:14:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-10 09:14:35 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2020-06-10 09:14:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-15 09:40:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2017-02-15 09:40:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-27 17:59:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-28 01:12:13 -08:00
|
|
|
|
2008-07-25 02:54:40 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-23 19:13:46 -07:00
|
|
|
|
2012-10-02 11:19:49 -07:00
|
|
|
|
2006-08-23 19:13:46 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2006-08-23 19:13:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 13:42:27 -07:00
|
|
|
|
|
|
|
|
|
2015-12-18 15:37:37 +01:00
|
|
|
|
2018-07-18 10:48:56 +02:00
|
|
|
|
2015-08-17 13:42:27 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-08-17 13:42:27 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 01:12:13 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-28 01:12:13 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-08-19 08:07:34 +02:00
|
|
|
|
2023-08-16 13:26:06 +05:30
|
|
|
|
2013-08-19 08:07:34 +02:00
|
|
|
|
2014-02-19 13:33:23 +01:00
|
|
|
|
2019-03-29 21:16:31 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2013-08-19 08:07:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-10 14:47:44 -07:00
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2013-03-25 14:50:00 +00:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2006-10-10 14:47:44 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2006-10-10 14:47:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-26 22:50:57 -07:00
|
|
|
|
2006-10-10 14:47:44 -07:00
|
|
|
|
|
|
|
|
|
2009-06-05 00:44:53 +02:00
|
|
|
|
2006-10-10 14:47:44 -07:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
2012-10-02 11:19:49 -07:00
|
|
|
|
|
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-20 16:13:58 -07:00
|
|
|
|
2006-03-28 01:12:13 -08:00
|
|
|
|
2016-02-12 15:43:54 +01:00
|
|
|
|
2017-02-07 15:37:15 -08:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-03-20 16:13:58 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-10 00:51:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 14:50:00 +00:00
|
|
|
|
2016-05-03 17:19:57 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2012-08-10 00:51:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fou: add Kconfig options for IPv6 support
A previous patch added the fou6.ko module, but that failed to link
in a couple of configurations:
net/built-in.o: In function `ip6_tnl_encap_add_fou_ops':
net/ipv6/fou6.c:88: undefined reference to `ip6_tnl_encap_add_ops'
net/ipv6/fou6.c:94: undefined reference to `ip6_tnl_encap_add_ops'
net/ipv6/fou6.c:97: undefined reference to `ip6_tnl_encap_del_ops'
net/built-in.o: In function `ip6_tnl_encap_del_fou_ops':
net/ipv6/fou6.c:106: undefined reference to `ip6_tnl_encap_del_ops'
net/ipv6/fou6.c:107: undefined reference to `ip6_tnl_encap_del_ops'
If CONFIG_IPV6=m, ip6_tnl_encap_add_ops/ip6_tnl_encap_del_ops
are in a module, but fou6.c can still be built-in, and that
obviously fails to link.
Also, if CONFIG_IPV6=y, but CONFIG_IPV6_TUNNEL=m or
CONFIG_IPV6_TUNNEL=n, the same problem happens for a different
reason.
This adds two new silent Kconfig symbols to work around both
problems:
- CONFIG_IPV6_FOU is now always set to 'm' if either CONFIG_NET_FOU=m
or CONFIG_IPV6=m
- CONFIG_IPV6_FOU_TUNNEL is set implicitly when IPV6_FOU is enabled
and NET_FOU_IP_TUNNELS is also turned out, and it will ensure
that CONFIG_IPV6_TUNNEL is also available.
The options could be made user-visible as well, to give additional
room for configuration, but it seems easier not to bother users
with more choice here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: aa3463d65e7b ("fou: Add encap ops for IPv6 tunnels")
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-25 16:50:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fou: fix IPv6 Kconfig options
The Kconfig options I added to work around broken compilation ended
up screwing up things more, as I used the wrong symbol to control
compilation of the file, resulting in IPv6 fou support to never be built
into the kernel.
Changing CONFIG_NET_FOU_IPV6_TUNNELS to CONFIG_IPV6_FOU fixes that
problem, I had renamed the symbol in one location but not the other,
and as the file is never being used by other kernel code, this did not
lead to a build failure that I would have caught.
After that fix, another issue with the same patch becomes obvious, as we
'select INET6_TUNNEL', which is related to IPV6_TUNNEL, but not the same,
and this can still cause the original build failure when IPV6_TUNNEL is
not built-in but IPV6_FOU is. The fix is equally trivial, we just need
to select the right symbol.
I have successfully build 350 randconfig kernels with this patch
and verified that the driver is now being built.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Valentin Rothberg <valentinrothberg@gmail.com>
Fixes: fabb13db448e ("fou: add Kconfig options for IPv6 support")
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-31 22:42:11 +02:00
|
|
|
|
fou: add Kconfig options for IPv6 support
A previous patch added the fou6.ko module, but that failed to link
in a couple of configurations:
net/built-in.o: In function `ip6_tnl_encap_add_fou_ops':
net/ipv6/fou6.c:88: undefined reference to `ip6_tnl_encap_add_ops'
net/ipv6/fou6.c:94: undefined reference to `ip6_tnl_encap_add_ops'
net/ipv6/fou6.c:97: undefined reference to `ip6_tnl_encap_del_ops'
net/built-in.o: In function `ip6_tnl_encap_del_fou_ops':
net/ipv6/fou6.c:106: undefined reference to `ip6_tnl_encap_del_ops'
net/ipv6/fou6.c:107: undefined reference to `ip6_tnl_encap_del_ops'
If CONFIG_IPV6=m, ip6_tnl_encap_add_ops/ip6_tnl_encap_del_ops
are in a module, but fou6.c can still be built-in, and that
obviously fails to link.
Also, if CONFIG_IPV6=y, but CONFIG_IPV6_TUNNEL=m or
CONFIG_IPV6_TUNNEL=n, the same problem happens for a different
reason.
This adds two new silent Kconfig symbols to work around both
problems:
- CONFIG_IPV6_FOU is now always set to 'm' if either CONFIG_NET_FOU=m
or CONFIG_IPV6=m
- CONFIG_IPV6_FOU_TUNNEL is set implicitly when IPV6_FOU is enabled
and NET_FOU_IP_TUNNELS is also turned out, and it will ensure
that CONFIG_IPV6_TUNNEL is also available.
The options could be made user-visible as well, to give additional
room for configuration, but it seems easier not to bother users
with more choice here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: aa3463d65e7b ("fou: Add encap ops for IPv6 tunnels")
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-25 16:50:46 +02:00
|
|
|
|
2006-10-16 22:12:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2006-10-16 22:12:21 -07:00
|
|
|
|
|
|
|
|
|
2006-08-23 17:23:39 -07:00
|
|
|
|
|
|
|
|
|
2006-10-16 22:12:21 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2006-08-23 17:23:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-03 09:22:53 +09:00
|
|
|
|
2012-10-02 11:19:49 -07:00
|
|
|
|
|
|
|
|
|
2018-02-28 23:29:29 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2018-05-07 14:03:18 +02:00
|
|
|
|
2008-04-03 09:22:53 +09:00
|
|
|
|
|
|
|
|
|
ipv6: ip6mr: support multiple tables
This patch adds support for multiple independant multicast routing instances,
named "tables".
Userspace multicast routing daemons can bind to a specific table instance by
issuing a setsockopt call using a new option MRT6_TABLE. The table number is
stored in the raw socket data and affects all following ip6mr setsockopt(),
getsockopt() and ioctl() calls. By default, a single table (RT6_TABLE_DFLT)
is created with a default routing rule pointing to it. Newly created pim6reg
devices have the table number appended ("pim6regX"), with the exception of
devices created in the default table, which are named just "pim6reg" for
compatibility reasons.
Packets are directed to a specific table instance using routing rules,
similar to how regular routing rules work. Currently iif, oif and mark
are supported as keys, source and destination addresses could be supported
additionally.
Example usage:
- bind pimd/xorp/... to a specific table:
uint32_t table = 123;
setsockopt(fd, SOL_IPV6, MRT6_TABLE, &table, sizeof(table));
- create routing rules directing packets to the new table:
# ip -6 mrule add iif eth0 lookup 123
# ip -6 mrule add oif eth0 lookup 123
Signed-off-by: Patrick McHardy <kaber@trash.net>
2010-05-11 14:40:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-03 09:22:54 +09:00
|
|
|
|
2012-10-02 11:19:49 -07:00
|
|
|
|
2008-04-03 09:22:54 +09:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-04-03 09:22:54 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-15 16:14:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-27 11:43:59 +02:00
|
|
|
|
2017-08-25 09:56:47 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-11-15 16:14:04 +01:00
|
|
|
|
|
|
|
|
|
2017-08-05 12:38:26 +02:00
|
|
|
|
|
|
|
|
|
2016-11-15 16:14:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-08 14:57:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-23 21:36:43 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-11-08 14:57:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bpf: Add IPv6 Segment Routing helpers
The BPF seg6local hook should be powerful enough to enable users to
implement most of the use-cases one could think of. After some thinking,
we figured out that the following actions should be possible on a SRv6
packet, requiring 3 specific helpers :
- bpf_lwt_seg6_store_bytes: Modify non-sensitive fields of the SRH
- bpf_lwt_seg6_adjust_srh: Allow to grow or shrink a SRH
(to add/delete TLVs)
- bpf_lwt_seg6_action: Apply some SRv6 network programming actions
(specifically End.X, End.T, End.B6 and
End.B6.Encap)
The specifications of these helpers are provided in the patch (see
include/uapi/linux/bpf.h).
The non-sensitive fields of the SRH are the following : flags, tag and
TLVs. The other fields can not be modified, to maintain the SRH
integrity. Flags, tag and TLVs can easily be modified as their validity
can be checked afterwards via seg6_validate_srh. It is not allowed to
modify the segments directly. If one wants to add segments on the path,
he should stack a new SRH using the End.B6 action via
bpf_lwt_seg6_action.
Growing, shrinking or editing TLVs via the helpers will flag the SRH as
invalid, and it will have to be re-validated before re-entering the IPv6
layer. This flag is stored in a per-CPU buffer, along with the current
header length in bytes.
Storing the SRH len in bytes in the control block is mandatory when using
bpf_lwt_seg6_adjust_srh. The Header Ext. Length field contains the SRH
len rounded to 8 bytes (a padding TLV can be inserted to ensure the 8-bytes
boundary). When adding/deleting TLVs within the BPF program, the SRH may
temporary be in an invalid state where its length cannot be rounded to 8
bytes without remainder, hence the need to store the length in bytes
separately. The caller of the BPF program can then ensure that the SRH's
final length is valid using this value. Again, a final SRH modified by a
BPF program which doesn’t respect the 8-bytes boundary will be discarded
as it will be considered as invalid.
Finally, a fourth helper is provided, bpf_lwt_push_encap, which is
available from the LWT BPF IN hook, but not from the seg6local BPF one.
This helper allows to encapsulate a Segment Routing Header (either with
a new outer IPv6 header, or by inlining it directly in the existing IPv6
header) into a non-SRv6 packet. This helper is required if we want to
offer the possibility to dynamically encapsulate a SRH for non-SRv6 packet,
as the BPF seg6local hook only works on traffic already containing a SRH.
This is the BPF equivalent of the seg6 LWT infrastructure, which achieves
the same purpose but with a static SRH per route.
These helpers require CONFIG_IPV6=y (and not =m).
Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
Acked-by: David Lebrun <dlebrun@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-20 14:58:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 18:00:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-16 20:57:13 +02:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2020-03-27 18:00:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 21:42:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-03 20:45:38 +02:00
|
|
|
|
2021-07-20 21:42:59 +02:00
|
|
|
|
2021-10-03 20:45:38 +02:00
|
|
|
|
|
|
|
|
|
2021-07-20 21:42:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-13 23:30:47 -07:00
|
|
|
|