If Gateway=_dhcp4/_ra, the route will be anyway configured with
NETWORK_CONFIG_SOURCE_DHCP4/_NDISC. See dhcp4_request_route() and
ndisc_route_prepare().
This is mostly for avoiding link_drop_routes(), which drops unnecessary static
and/or foreign routes, unexpectedly filtering an existing route with the
route specified with Gateway=_dhcp4/_ra.
Fixes IPv6 Core Conformance test failures reported at #33468.
https://www.ipv6ready.org/docs/Core_Conformance.pdf
Test v6LC.2.2.23 h and j: Processing Router Advertisement with Route
Information Option (Host Only)
When a RA contains route option with ::/0 prefix, then previously that
may contradict with the default route requested with the RA header.
If the route option has zero lifetime, the existing default route should
be removed, and a new route based on the RA header should be configured.
If the route option has non-zero lifetime, the RA header should be
ignored.
So, we first need to process options with zero lifetime (not only
route option, as the similar reasons), then configure the default route
based on the RA, finally process options with non-zero lifetime.
Previously, when multiple routers send RAs with the same preference,
then the kernel merges routes with the same gateway address:
===
default proto ra metric 1024 expires 595sec pref medium
nexthop via fe80::200:10ff:fe10:1060 dev enp0s9 weight 1
nexthop via fe80::200:10ff:fe10:1061 dev enp0s9 weight 1
===
This causes IPv6 Conformance Test v6LC.2.2.11 failure, as reported in #33470.
To avoid the coalescing issue, we can use nexthop, as suggested by Ido Schimmel:
https://lore.kernel.org/netdev/ZytjEINNRmtpadr_@shredder/
> BTW, you can avoid the coalescing problem by using the nexthop API.
> # ip nexthop add id 1 via fe80::200:10ff:fe10:1060 dev enp0s9
> # ip -6 route add default nhid 1 expires 600 proto ra
> # ip nexthop add id 2 via fe80::200:10ff:fe10:1061 dev enp0s9
> # ip -6 route append default nhid 2 expires 600 proto ra
> # ip -6 route
> fe80::/64 dev enp0s9 proto kernel metric 256 pref medium
> default nhid 1 via fe80::200:10ff:fe10:1060 dev enp0s9 proto ra metric 1024 expires 563sec pref medium
> default nhid 2 via fe80::200:10ff:fe10:1061 dev enp0s9 proto ra metric 1024 expires 594sec pref medium
Fixes#33470.
Suggested-by: Ido Schimmel <idosch@idosch.org>
Follow-up for 972f1d17ab.
This fixes the logic of removing unnecessary routes configured by the
previously received RAs. Previously, we wrongly handled existing routes
could be updated, and unexpected routes would be kept.
- drop unnecessary call of ndisc_set_route_priority() at the beginning,
as it is called later in the loop below,
- use RET_GATHER() and remove all possible routes even if failed.
Previously, even if KeepConfiguration=dhcp or yes is specified in the
new .network file, dynamic configurations like DHCP address and routes
were dropped when 'networkctl reconfigure INTERFACE' is invoked.
If the setting is specified, let's gracefully handle the dynamic
configurations. Then, 'networkctl reconfigure' can be also used for
an interface that has critical connections.
E.g. when a .network file is updated, but DHCP setting is unchanged, it
is not necessary to drop acquired DHCP lease.
So, let's not stop DHCP client and friends in link_reconfigure_impl(),
but stop them later when we know they are not necessary anymore.
Still DHCP clients and friends are stopped and leases are dropped when
the explicit reconfiguration is requested
We need a sensible limit on the number of Encrypted DNS options allowed
so that the set of resolvers per link does not grow without bound.
Fixes: 0c90d1d2f2 ("ndisc: Parse RFC9463 encrypted DNS (DNR) option")
This reverts commit ffef01acdd.
Similar to 2d393b1b6d ("network: IPv6 Compliance: Router Advertisement
Processing, Reachable Time [v6LC.2.2.15]"),
Extract from: https://www.ietf.org/rfc/rfc4861.html#section-4.2, p.21,
first paragraph:
The Router Lifetime applies only to
the router's usefulness as a default router; it
does not apply to information contained in other
message fields or options.
So it does not make sense to prevent DHCPv6 when Router Lifetime is 0.
Fixes#33357.
As all callers do not care if the address has peer address.
This also drops prefixlen argument as it is always zero.
Fixes a bug introduced by 42f8b6a808.
Fixes#31950.
Similar to the previous commit, but for preventing from removing static
routes on receiving RA with zero lifetime.
Fixes a regresson caused by 479d3e1994.
Fixes#33346.
We have already ignored conflicting address configurations requested by
NDisc protocol. See ndisc_request_address().
Let's follow the same rule for routes. That is, if there are conflicting
static routes configured or requested, do not override them by NDisc.
Also, swap the order of checking existing route and existing request.
Fixes a regression caused by 972f1d17ab.
Prompted by #33346.
Previously, we did not set lifetime for redirect route, and redirect
routes were removed only when received a RA from the target address.
Thus, routes that redirect on-link addresses were never removed.
RFCs mention nothing about the lifetime of redirection. But the previous
implementation does not pass the IPv6 Core Conformance Tests.
This makes
- remember all received RAs and manage them by the sender address
(previously, remembered only one with the highest preference),
- then use the router lifetime as one for redirect route,
- remove redirect route also when the router corresponds to the sender
address is dropped (previously, considered only target address).
Note, even if we recieve a new RA, we do not update existing redirect
routes. The lifetime of the redirect route is updated only when a new
Redirect message is received.
Closes#32527.
RFC 4862 Section 5.5.3, bullet e, sub-bullet 3 applies to existing
addresses, i.e. when address_get() returns success. If the address is
new (i.e. address_get() fails), then we should not be adding 2 hours to
the lifetime_valid_usec. Instead, use the valid_lifetime from the RA's
Prefix Information Option.
This change allows v6LC.3.2.2 to pass. Also verified all v6LC3.2.* tests
pass. This covers all the v6LC tests from Group2: Router Advertisement
Processing and Address Lifetime.
Fixes#32652.
Previously, RA option fields were being ignored when the Router Lifetime
value was zero. Remove this logic to be compliant with RFC4861.
Extract from: https://www.ietf.org/rfc/rfc4861.html#section-4.2, p.21,
first paragraph:
The Router Lifetime applies only to
the router's usefulness as a default router; it
does not apply to information contained in other
message fields or options.
This affected IPv6 Conformance test:
v6LC.2.2.15: Router Advertisement Processing, Reachable Time.
Fixes#31842.
Co-authored-by: Matt Muggeridge <Matt.Muggeridge@hpe.com>
Running both sd-ndisc and sd-radv should be mostly a misconfiguration,
but may not. So, let's only disable sd-ndisc by default when sd-radv is
enabled, but allow when both are explicitly requested.
This effectively reverts commit 155d7a2c04.
From RFC 4861 section 6.3.4:
> Note, however, that a Prefix Information option with the on-link flag
> set to zero conveys no information concerning on-link determination and
> MUST NOT be interpreted to mean that addresses covered by the prefix
> are off-link.
So, we should not drop previously configured routes when receieved a RA
with Prefix Information option without on-link flag.
Closes#28435.
The sender must be the first-hop router of the destination. Previously,
we only accepted Redirect messages whose sender is the current default
router with the highest priority.
See RFC 4861 section 8.1 for more details.
Fixes#31981.
It is now called by only ndisc_redirect_handler(), and the check in
ndisc_request_redirect_route() is redundant and already done by
ndisc_redirect_verify_sender().
No functional change, just refactoring.
Hence, ndisc_router_update_redirect() does nothing. Let's remove it.
Also, ndisc_request_route() does not set lifetime for the route, it is
not necessary to set the third argument.
Then, make ndisc_request_route() generic and usable for configuring
routes based on both Router Advertisement and Redirect messages.
Note, ndisc_request_router() never set lifetime, so the dropped comment
in ndisc_request_redirect_route() is wrong.
No functional change, just refactoring.
Setting MTU announced in RA message to routes is problematic, as the
value may be larger than the device MTU (IFLA_MTU), and in such case the
route cannot be used.
These two properties are now set per-interface, and gracefully handled
such invalid cases. Hence not necessary to set them to each route.
Follow-up for #32195.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Ronan Pigott
Lennart Poettering
Matteo Croce
Ivan Shapovalov
Luca Boccassi
Matt Muggeridge
Matt MuggeridgeandMatt Muggeridge