summaryrefslogtreecommitdiff
path: root/src/network/networkd-dhcp6.c
Commit message (Collapse)AuthorAgeFilesLines
* send dhcpv6 release when stoppingchris2023-01-171-0/+6
|
* network: manage addresses in the way the kernel doesYu Watanabe2022-12-071-2/+1
| | | | | | | | | | | | | This effectively reverts 5d0030310c134a016321ad8cf0b4ede8b1800d84. With the commit 5d0030310c134a016321ad8cf0b4ede8b1800d84, networkd manages addresses with the detailed hash and compare functions. But that causes networkd cannot detect address update by the kernel or an external tool. See issue https://github.com/systemd/systemd/issues/481#issuecomment-1328132401. With this commit, networkd (again) manages addresses in the way that the kernel does. Hence, we can correctly detect address update.
* network: attach device to DHCP clientsYu Watanabe2022-10-261-0/+4
| | | | The attached sd_device object will be used later.
* 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-4/+2
|
* 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: check link state with link_is_ready_to_configure() before ↵Yu Watanabe2022-08-051-1/+1
| | | | | | | configuring DHCP client or friends Otherwise, DHCP client or friends may started before link-layer properties, e.g. MAC address, being configured or the link being activated.
* network: dhcp6: re-introduce RapidCommit= settingYu Watanabe2022-07-221-0/+6
| | | | | | | | | | | Previous implementation of disabling rapid commit was broken, and dropped by 308d01f3c4decf3240ca0c6c7f91049953df7299. Let's re-introduce the option in the correct way, as some servers seem to return borked message when the solicit message contain the rapid commit option. Closes #24065.
* Merge pull request #24001 from yuwata/network-lifetime-fixLuca Boccassi2022-07-181-2/+2
|\ | | | | network: fixes for lifetime handling
| * network: fix infinite lifetime handlingYu Watanabe2022-07-141-2/+2
| |
* | Revert "network: configure DHCP clients after MAC address is assigned"Yu Watanabe2022-07-141-5/+0
|/ | | | | | | | | This reverts commit f42d41cc5f9cd8cac538a1c30fda04d346b5bae2. DHCPv6 client does not require MAC address. DHCPv4 client will be handled in a different way in a later commit. Partially fixes #23546.
* basic/in-addr-util: add IN_ADDR_TO_STRINGZbigniew Jędrzejewski-Szmek2022-06-061-12/+7
| | | | | | | | | | | | | | | Since we don't need the error value, and the buffer is allocated with a fixed size, the whole logic provided by in_addr_to_string() becomes unnecessary, so it's enough to wrap inet_ntop() directly. inet_ntop() can only fail with ENOSPC. But we specify a buffer that is supposed to be large enough, so this should never fail. A bunch of tests of this are added. This allows all the wrappers like strna(), strnull(), strempty() to be dropped. The guard of 'if (DEBUG_LOGGING)' can be dropped from around log_debug(), because log_debug() implements the check outside of the function call. But log_link_debug() does not, so it we need it to avoid unnecessary evaluation of the formatting.
* network: clarify the relationship between RA flags and DHCPv6 modesAlex Henrie2022-05-061-2/+2
| | | | | | | | | | | | | | | | | | In the documentation, using the term "managed" for both the RA flag and the DHCPv6 mode is confusing because the mode is referred to as "solicit" both in the official DHCPv6 documentation (see RFC 8415) and in the WithoutRA option. Furthermore, calling the other RA flag "other information" or "other address configuration" is confusing because its official name is simply "other configuration" (see RFC 4861 and RFC 5175) and it isn't used to assign IP addresses. Rewrite the documentation for DHCPv6Client and WithoutRA to make it clear that getting the "managed" RA flag triggers the same kind of DHCP request as WithoutRA=solicit, whereas getting the "other configuration" RA flag triggers the same kind of DHCP request as WithoutRA=information-request.
* network: dhcp6: request DNS servers or friends only when they will be usedYu Watanabe2022-04-031-0/+23
|
* time-util: assume CLOCK_BOOTTIME always existsLennart Poettering2022-03-281-1/+1
| | | | | | | | 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.
* network: re-design request queueYu Watanabe2022-03-111-2/+2
| | | | | | | | This makes Request object takes hash, compare, free, and process functions. With this change, the logic in networkd-queue.c can be mostly independent of the type of the request or the object (e.g. Address) assigned to the request, and it becomes simpler.
* network: introduce request_call_netlink_async()Yu Watanabe2022-03-111-4/+1
| | | | | | | | | | | | | | | | | | | | | 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: make request_process_address() and friends take Link and ↵Yu Watanabe2022-03-111-8/+2
| | | | | | | | | | | | | | | | | corresponding object This also renames e.g. request_process_address() -> address_process_request(). Also, this drops type checks such as `assert(req->type == REQUEST_TYPE_ADDRESS)`, as in the later commits, the function of processing request, e.g. `address_process_request()`, will be assigned to the Request object when it is created. And the request type will be used to distinguish and to avoid deduplicating requests which do not have any assigned objects, like REQUEST_TYPE_DHCP4_CLIENT. Hence, the type checks in process functions are mostly not necessary and redundant. This is mostly cleanups and preparation for later commits, and should not change any behavior.
* network: compare addresses more strictlyYu Watanabe2022-02-241-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | This re-introduce the full hash and compre functions for Address, which was reverted 1d30fc5cb64ecba2f03fe42aa0d8c65c3decad82 (#17851). The issue #17831, which is fixed by #17851, is handled in a different way; simply ignore to configure the conflicted DHCPv6 address. Previously, we warn about the conflict, but continue to configure the address anyway, and the kernel ignores the request. So, it is not necessary to request the conflicted address in networkd side. This fixes the following issues: - when a link has an address, and corresponding .network file has the address with different prefix length, then the prefix length specified in the .network file will not be applied, - we cannot specify multiple IPv4 addresses with different prefix length, e.g. ---- Address=10.10.10.10/24 Address=10.10.10.10/16 ---- This is spurious setup, but the kernel allows it. Fixes #22515.
* network: do not restart DHCPv6 client when it is already running in managed modeYu Watanabe2022-02-141-0/+12
| | | | | | | Otherwise, if a network has two router and one provides M flag and the other provides O flag, then the DHCPv6 client switches the running mode repeatedly. That makes the IPv6 network configuration of the host unstable.
* network: configure DHCP clients after MAC address is assignedYu Watanabe2022-01-311-0/+5
| | | | Prompted by #20090.
* network: dhcp6: do not request address if UseAddress=noYu Watanabe2022-01-111-1/+7
| | | | Fixes #22068.
* network: dhcp-pd: rename [DHCPv6PrefixDelegation] -> [DHCPPrefixDelegation]Yu Watanabe2021-12-071-3/+3
| | | | | | | This just changes the names of settings, variables, functions, files, and so on. No functionality is changed. Preparation for supporting 6rd.
* network: route: make route_cancel_request() take Link*Yu Watanabe2021-12-061-1/+1
| | | | As the Route object may be managed by Manager.
* network: split networkd-dhcp6.cYu Watanabe2021-12-061-1040/+2
| | | | | This moves DHCPv6 prefix delegation related functions to networkd-dhcp-prefix-delegation.c.
* network: dhcp6-pd: exclude all explicitly specified subnet IDs when ↵Yu Watanabe2021-12-011-18/+11
| | | | | | | | | | | | | | | searching free IDs When the upstream link gained a lease, then several downstream links may not appear yet. Previously, the explicitly specified subnet ID for a downstream link which appears later may be already assigned to an interface which does not request specific subnet ID. To avoid such situation, this makes all specified IDs are excluded when searching free IDs. As a side effect, we can avoid the second call of dhcp6_pd_distribute_prefix().
* network: dhcp6-pd: introduce dhcp6_pd_is_uplink()Yu Watanabe2021-12-011-37/+37
| | | | This also merges dhcp6_pd_resolve_uplink() with dhcp6_pd_find_uplink()
* network: dhcp6: make UplinkInterface=:self take effect only when ↵Yu Watanabe2021-12-011-0/+3
| | | | DHCPv6PrefixDelegation= is enabled
* network: radv: use the uplink interface used in DHCPv6-PDYu Watanabe2021-12-011-1/+1
|
* tree-wide: fix typoYu Watanabe2021-11-301-1/+1
|
* network: save server address to DHCPv6 addressesYu Watanabe2021-11-011-1/+8
| | | | The server address will be used in later commits.
* network: dhcp6: make UplinkInterface=:self imply WithoutRA=solicitYu Watanabe2021-10-271-5/+26
|
* network: do not restart DHCPv6 client when WithoutRA= is setYu Watanabe2021-10-271-10/+25
| | | | | Previously, even if WithoutRA= is specified, the DHCPv6 client may be restarted in undesired mode when a RA is received.
* network: deprecate ForceDHCPv6PDOtherInformation= settingYu Watanabe2021-10-271-15/+1
| | | | | | The setting is completely meaningless, as WithoutRA= and UseDelegatedPrefix= in [DHCPv6] section, and DHCPv6Client= in [IPv6AcceptRA] section control the behavior.
* network: dhcp6: introduce UplinkInterface= for DHCP6 prefix delegationYu Watanabe2021-10-261-0/+35
|
* network: dhcp6pd: do not trigger prefix reassignment for all downstreams ↵Yu Watanabe2021-10-261-9/+55
| | | | | | when a new downstream appears It is not necessary to reconfigure other interfaces.
* network: dhcp6: do not reconfigure/restart DHCPv6 clients when a new ↵Yu Watanabe2021-10-261-52/+43
| | | | | | | | | | | downstream appears Previously, when a downstream appears which requests delegated prefix to be assigned, then possibly restart all DHCPv6 clients for another interfaces. This makes networkd always honor the UseDelegatedPrefix= setting, and not restart DHCPv6 clients.
* network: dhcp6: introduce UseDelegatedPrefix= setting and enable by defaultYu Watanabe2021-10-261-24/+4
| | | | | | | | | | | | | | | Previously, the prefix delegation is enabled when at least one downstream interfaces request it. But, when the DHCPv6 client on the upstream interface is configured, some downstream interfaces may not exist yet, nor have .network file assigned. Also, if a system has thousands of interfaces, then the previous logic introduce O(n^2) search. This makes the prefix delegation is always enabled, except when it is explicitly disabled. Hopefully, that should not break anything, as the DHCPv6 server should ignore the prefix delegation request if the server do not have any prefix to delegate.
* network: dhcp6pd: do not assign downstream prefix when RADV is requested but ↵Yu Watanabe2021-10-261-0/+9
| | | | not configured yet
* network: dhcp6: rename variablesYu Watanabe2021-10-261-8/+10
|
* network: dhcp6pd: move logic of acquiring subnet prefix into ↵Yu Watanabe2021-10-261-43/+55
| | | | | | dhcp6_pd_assign_prefix() Preparation for later commits.
* network: dhcp6pd: introduce a simplified and unified method to calculate ↵Yu Watanabe2021-10-261-33/+42
| | | | subnet prefix
* network: dhcp6pd: check link state earlier before assigning prefixes to ↵Yu Watanabe2021-10-221-5/+5
| | | | | | downstream Also, narrow the acceptable range of the states.
* network: dhcp6pd: also call dhcp6_pd_prepare() and dhcp6_pd_finalize() for ↵Yu Watanabe2021-10-221-8/+14
| | | | | | upstream interface As now the subnet prefix may be assigned to the upstream interface.
* network: dhcp6pd: not necessary to drop routes when Assign=yesYu Watanabe2021-10-221-30/+34
|
* Merge pull request #21072 from yuwata/network-address-lifetimeYu Watanabe2021-10-221-42/+49
|\ | | | | network: address: use usec_t for handling lifetime
| * network: address: use usec_t for handling lifetimeYu Watanabe2021-10-211-42/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This drops stuct ifa_cacheinfo from Address, and store lifetime with usec_t. Why? Now, all requests of address configurations are once stored in the request queue, and will be processed when it is ready. So, the timestamp value passed to the kernel must be evaluated on configure. This also fixes the following two issues. - Time values in struct ifa_cacheinfo are stored in uint32_t. So, the validity check of the address configured by NDisc may fail on long running systems. - If a system uses DHCPv6PD, when an interface may appear or be reconfigured later, then the lifetime value may be inappropriate. We need to adjust the lifetime with the current time and the timestamp of the lease.
| * network: route: rename lifetime -> lifetime_usecYu Watanabe2021-10-211-2/+2
| |
* | network: drop unnecessary header inclusionYu Watanabe2021-10-211-1/+0
|/
* network: dhcp6: explicitly specify metric for unreachable routeYu Watanabe2021-10-201-0/+1
| | | | | | | For static IPv6 routes without metric is specified, then we use 1024. But such an adjustment is not performed to dynamic routes. So, let's specify the metric explicitly. Otherwise, configured routes will be handled as foreign.
View Lorry Controller Status