summaryrefslogtreecommitdiffstats
path: root/src/network/networkd-dhcp-prefix-delegation.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* network/route: introduce ref/unref functions for Route objectYu Watanabe2024-01-251-3/+3
| | | | | | | Then, Route object can live if it is detached from the owner (Manager, Network, or Wireguard object). This is the one for routes of ebd96906477aac2bbc6b9de0d6e9bd0f39db5581.
* network/route: introduce route_remove_and_cancel()Yu Watanabe2024-01-251-5/+2
| | | | | | | | | | | | Then, replace route_remove_and_drop() with it. If a route is requested, and the request is already called, we may not received its reply and notification from the kernel, and the corresponding Route object may not be remembered. Even in such case, we need to remove the route, otherwise the route will come later after the function called. This is the version for route of f22b586a215962416bdbd692aabb89b1ac2999d0.
* network/route: manage all routes by Manager objectYu Watanabe2024-01-241-6/+15
| | | | | | | | | | | | | | | | | | Previously, a Route object is owned by a Link object corresponding to the outgoing interface of the route, and a Route object that does not have outgoing interface is owned by the Manager object. However, there were several issues: - if a route has a nexthop ID, then the corresponding nexthop may be changed to use another interface, hence the outgoing interface of the route may be changed. - if a route requested with MultiPathRoute=, then the link who requests the route is different from the outgoing interface of the configured route. So, we need to find routes on other interfaces on reconfiguring or so. By this change, the limit of the number of routes per-interface is tentatively dropped. Let's re-introduce the limit later in a nicer way.
* network/route: convert route before requestingYu Watanabe2024-01-191-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, 1. use the passed Route object as is when a route is requested, 2. when the route becomes ready to configure, convert the Route object if necessary, to resolve outgoing interface name, and split multipath routes, and save them to the associated interfaces, 3. configure the route with the passed Route object. However, there are several inconsistencies with what kernel does: - The kernel does not merge nor split IPv4 multipath routes. However, we unconditionally split multipath routes to manage. - The kernel does not set gateway or so to a route if it has nexthop ID. Fortunately, I do not find any issues caused by the inconsistencies. But for safety, let's manage routes in a consistent way with the kernel. This makes, 1. when a route is requested, split IPv6 multipath routes, but keep IPv4 multipath routes as is, and queue (possibly multiple) requests for the route. 2. when the route becomes ready to configure, resolve nexthop and interface name, and requeue request if necessary. 3. configure the (possibly split) route. By using the logic, - Now we manage routes in a mostly consistent way with the kernel. - We can drop ConvertedRoutes object. - Hopefully the code becomes much simpler.
* network: adjust nexthops of dynamic routes before requestingYu Watanabe2024-01-191-0/+12
| | | | No effective functionality is changed. Preparation for later commits.
* network/route: also use RouteNextHop for managing gatewayYu Watanabe2024-01-151-2/+2
| | | | No functional change, just refactoring.
* network/route: update expiration timer only when we know the route existsYu Watanabe2024-01-121-3/+3
|
* network/address: introduce ref/unref functions for Address objectYu Watanabe2024-01-031-1/+1
| | | | | Then, Address object can live if it is detached from the owner (Link or Network object).
* network/address: introduce address_remove_and_cancel()Yu Watanabe2024-01-021-1/+1
| | | | | | | | | | Then, replace address_remove_and_drop() with it. If an address is requested, and the request is already called, we may not received its reply and notification from the kernel, and the corresponding address object may not be remmbered. Even in such case, we need to remove the address, otherwise the address will come later after the function called.
* network: use RET_GATHER() macroYu Watanabe2023-12-251-9/+4
|
* network/dhcp-pd: use correct flag when DHCPv4 6rd is enabledYu Watanabe2023-11-101-4/+8
| | | | | | | | Previously, Link.dhcp6_configured flag was unconditionally used even if the route is configured based on the DHCPv4 protocol. Follow-up for a27588d4e7f780243a1828e2af56562f9d779412 and e49bad0179cb670edeac12ef062887af0ac4c8c5.
* sd-dhcp6-client: rework IA_NA or IA_PD gettersYu Watanabe2023-09-201-26/+21
| | | | | | | | | This splits sd_dhcp6_lease_get_address() into small pieces, and introduce FOREACH_DHCP6_ADDRESS() macro. Also, the lifetimes provided by _get_address_lifetime() are now in usec, and _get_address_lifetime_timestamp() provides timestamp. The same change is also applied for IA_PD.
* sd-dhcp6-client: introduce sd_dhcp6_lease_has_pd_prefix() and friendYu Watanabe2023-09-201-17/+1
| | | | No functional change, just refactoring.
* sd-dhcp-client: introduce sd_dhcp_lease_has_6rd() helper functionYu Watanabe2023-09-051-11/+1
| | | | No functional change, just refactoring.
* dhcp: introduce sd_dhcp_lease_get_timestamp()Yu Watanabe2023-09-051-10/+4
| | | | | | | | And drop sd_dhcp_client_get_lease_timestamp(). Also, this introduce sd_dhcp_lease_get_lifetime_timestamp() and friends, which provides timestamp of the lifetime and so on, while sd_dhcp_lease_get_lifetime() provides timestamp.
* sd-dhcp-client: store lifetime and friends in usec_tYu Watanabe2023-09-051-6/+4
|
* network/address: introduce address_get_harder() and use it where appropriateYu Watanabe2023-07-301-1/+1
| | | | | | With the previous change, now Address objects under requesting are not owned by Link object, hence we need to also search corresponding Address object in the request queue.
* network: use address_remove_and_drop()Yu Watanabe2023-07-291-3/+1
|
* network/address: free Address object by caller that passed to ↵Yu Watanabe2023-07-291-1/+1
| | | | | | | | | link_request_address() Follow-up for 9684a8ded083dd427f843b0c40aa0292e6c7ae06. Now, the input Address object is always copied, hence it is not necessary to free it in link_request_address().
* network: don't forget old RAs when a new one arrivesThomas Hebb2022-10-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IPv6 Neighbor Discovery lets us autoconfigure a link's IPv6 addresses, routes, DNS servers, and DNS search domains by listening for Router Advertisement (RA) packets broadcast by one or more routers on the link. Each RA can contain zero or more "options," each describing one piece of configuration (e.g. a single route). Currently, when we receive an RA from a router, we delete any addresses, routes, etc. that originated from that router's previous RAs unless they're also present as options in the new RA. That behavior is a violation of RFC 4861[1]. In Section 9, the RFC states that Senders MAY send a subset of options in different packets. ... Thus, a receiver MUST NOT associate any action with the absence of an option in a particular packet. This protocol specifies that receivers should only act on the expiration of timers and on the information that is received in the packets. Several other passages in the RFC reiterate this. Section 6.2.3: A router MAY choose not to include some or all options when sending unsolicited Router Advertisements. Section 6.3.4: Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. At least one consumer router in production today, the Google Nest Wifi, often sends RAs that omit its global IPv6 prefix. When current versions of systemd-networkd receive those RAs, they immediately delete the interface's global IPv6 address, which breaks IPv6 connectivity. Fix the issue by removing the invalidation logic entirely. It's not needed at all, since we already invalidate addresses, routes, and DNS configuration when the interface goes down or their lifetimes expire. This fix does have the side effect of preventing changes to the .network file (e.g. denylisted prefixes, whether to add routes from RAs) from taking effect as soon as a new RA arrives. Instead, a full interface reconfiguration is needed. But triggering those changes on RA receipt was already rather arbitrary and out of the administrator's control, so I think this change is fine. commit 69203fba700e ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready") introduced this behavior. commit 50550722e3ba fixed it partially, by preventing one router's RAs from invalidating another router's configuration. [1] https://www.rfc-editor.org/rfc/rfc4861 Fixes: 69203fba700e ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready")
* tree-wide: use ASSERT_PTR moreDavid Tardon2022-09-131-2/+1
|
* tree-wide: Use correct format specifiersJan Janssen2022-08-301-1/+1
| | | | gcc will complain about all these with -Wformat-signedness.
* network: NetLabel integrationTopi Miettinen2022-08-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New directive `NetLabel=` provides a method for integrating static and dynamic network configuration into Linux NetLabel subsystem rules, used by Linux Security Modules (LSMs) for network access control. The label, with suitable LSM rules, can be used to control connectivity of (for example) a service with peers in the local network. At least with SELinux, only the ingress can be controlled but not egress. The benefit of using this setting is that it may be possible to apply interface independent part of NetLabel configuration at very early stage of system boot sequence, at the time when the network interfaces are not available yet, with netlabelctl(8), and the per-interface configuration with systemd-networkd once the interfaces appear later. Currently this feature is only implemented for SELinux. The option expects a single NetLabel label. The label must conform to lexical restrictions of LSM labels. When an interface is configured with IP addresses, the addresses and subnetwork masks will be appended to the NetLabel Fallback Peer Labeling rules. They will be removed when the interface is deconfigured. Failures to manage the labels will be ignored. Example: ``` [DHCPv4] NetLabel=system_u:object_r:localnet_peer_t:s0 ``` With the above rules for interface `eth0`, when the interface is configured with an IPv4 address of 10.0.0.123/8, `systemd-networkd` performs the equivalent of `netlabelctl` operation ``` $ sudo netlabelctl unlbl add interface eth0 address:10.0.0.0/8 label:system_u:object_r:localnet_peer_t:s0 ``` Result: ``` $ sudo netlabelctl -p unlbl list ... interface: eth0 address: 10.0.0.0/8 label: "system_u:object_r:localnet_peer_t:s0" ... ```
* network: fix infinite lifetime handlingYu Watanabe2022-07-141-11/+7
|
* network: use sd_event_now()Yu Watanabe2022-07-141-4/+8
|
* basic/in-addr-util: add IN_ADDR_PREFIX_TO_STRINGZbigniew Jędrzejewski-Szmek2022-06-061-39/+20
|
* time-util: assume CLOCK_BOOTTIME always existsLennart Poettering2022-03-281-4/+4
| | | | | | | | Let's raise our supported baseline a bit: CLOCK_BOOTTIME started to work with timerfd in kernel 3.15 (i.e. back in 2014), let's require support for it now. This will raise our baseline only modestly from 3.13 → 3.15.
* sd-radv: voidify sd_radv_remove_prefix()Yu Watanabe2022-03-171-2/+2
| | | | | | | If the prefix is only referenced by sd_radv, then the returned pointer is already freed. networkd does not uses the returned value. Let's voidify the function.
* network: introduce request_call_netlink_async()Yu Watanabe2022-03-111-17/+5
| | | | | | | | | | | | | | | | | | | | | In most netlink handlers, we do the following, 1. decrease the message counter, 2. check the link state, 3. error handling, 4. update link state via e.g. link_check_ready(). The first two steps are mostly common, hence let's extract it. Moreover, this is not only extracting the common logic, but provide a strong advantage; `request_call_netlink_async()` assigns the relevant Request object to the userdata of the netlink slot, and the request object has full information about the message we sent. Hence, in the future, netlink handler can print more detailed error message. E.g. when an address is failed to configure, then currently we only show an address is failed to configure, but with this commit, potentially we can show which address is failed explicitly. This does not change such error handling yet. But let's do that later.
* network: dhcp-pd: allow to assign the same subnet prefix to multiple interfacesYu Watanabe2022-02-221-23/+15
| | | | | | | | There is no reason networkd refuses that. Especially, when multiple downstream interfaces are connected to the same network, it is natural to assign the same subnet prefix to them. Prompted by #22571.
* network: dhcp-pd: fix prefix length of address assigned to upstream interfaceYu Watanabe2022-02-221-62/+25
| | | | | | | | This effectively revert ab0c82d9f749cc397a6b7e0327ddb2c08cd7d7e0. I have no idea why I did that... Fixes #22559.
* network: dhcp-pd: fix condition in dhcp_pd_prefix_lost()Yu Watanabe2021-12-181-1/+1
|
* network: dhcp: logs received 6rd optionYu Watanabe2021-12-171-9/+18
| | | | Addresses https://github.com/systemd/systemd/pull/21625#issuecomment-996109051.
* network: dhcp-pd: add 6rd supportYu Watanabe2021-12-071-12/+325
| | | | Closes #19152.
* network: dhcp-pd: rename [DHCPv6PrefixDelegation] -> [DHCPPrefixDelegation]Yu Watanabe2021-12-071-168/+185
| | | | | | | This just changes the names of settings, variables, functions, files, and so on. No functionality is changed. Preparation for supporting 6rd.
* Merge pull request #21653 from yuwata/network-dhcp6pd-unreachable-route-cleanupsYu Watanabe2021-12-071-12/+28
|\ | | | | network: dhcp6pd: cleanups for unreachable route
| * network: dhcp6pd: use the kernel's default value for priority of unreachable ↵Yu Watanabe2021-12-071-1/+3
| | | | | | | | | | | | route This should not change any behavior, as both values are equivalent.
| * network: dhcp6pd: always use main route table for unreachable routeYu Watanabe2021-12-071-1/+0
| | | | | | | | This mostly reverts e47bcb7d0b2cb07c5c594e374baeb061bb7f88ba.
| * network: dhcp6pd: set server address for unreachable routeYu Watanabe2021-12-071-2/+15
| | | | | | | | This is just for json output.
| * network: dhcp6pd: gracefully handle delegated prefix whose prefixlen is ↵Yu Watanabe2021-12-071-8/+10
| | | | | | | | larger than 64
* | network: dhcp6pd: assign addresses in the delegated prefix instead of a ↵Yu Watanabe2021-12-071-8/+48
| | | | | | | | subnet prefix /64 on upstream interface
* | network: dhcp6pd: do not check Announce= setting when the link does not ↵Yu Watanabe2021-12-071-2/+2
| | | | | | | | support RADV
* | network: dhcp6pd: drop link_has_preferred_subnet_id() and inline conditionYu Watanabe2021-12-071-8/+2
|/
* Merge pull request #21639 from ↵Luca Boccassi2021-12-071-143/+55
|\ | | | | | | | | yuwata/network-dhcp6pd-use-dhcp6_pd_prefix_acquired network: dhcp6pd: use dhcp6 pd prefix acquired() and drop dhcp6_pd_distribute_prefix()
| * network: dhcp6pd: make dhcp6_pd_assign_prefixes() used also by ↵Yu Watanabe2021-12-061-97/+16
| | | | | | | | dhcp6_pd_prefix_acquired()
| * network: dhcp6pd: first check prefixes, then calculate lifetimeYu Watanabe2021-12-061-3/+3
| |
| * network: dhcp6pd: shorten code a bitYu Watanabe2021-12-061-5/+1
| |
| * network: dhcp6pd: skip to assign prefixes to a downstream link if it is not ↵Yu Watanabe2021-12-061-4/+4
| | | | | | | | ready
| * network: dhcp6pd: move dhcp6_pd_assign_prefixes()Yu Watanabe2021-12-061-53/+53
| | | | | | | | Preparation for the later commits.
| * network: dhcp6pd: also allow to only assign prefix route for delegated ↵Yu Watanabe2021-12-061-3/+0
| | | | | | | | prefix to upstream interface
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 08:53:37 +0100