When a prefix is delegated to an interface that is already sending
RAs, send an RA immediately to inform clients of the new prefix.
This allows them to start using it immediately instead of waiting
up to nearly 10 minutes (depending on when the last timed RA was
sent). This type of situation might occur if, for example, an
outage of the WAN connection caused the addresses and prefixes to
be lost and later regained after service was restored. The
condition for the number of RAs sent being above 0 simultaneously
ensures that RADV is already running and that this code doesn't
send any RAs before the timed RAs have started when the interface
first comes up.
To make Driver= in [Match] section work in containers.
Note that ID_NET_DRIVER= property in udev database is set with the
result of the ethtool. So, this should not change anything for
non-container cases.
Closes#15678.
This is an attempt to clean-up the DHCP lease server type code a bit. We
now strictly use the same enum everywhere, and store server info in an
array. Moreover, we use the same nomenclature everywhere.
This only makes the changes in the sd-dhcp code. The networkd code is
untouched so far (but should be fixed up like this too. But it's more
complicated since this would then touch actual settings in .network
files).
Note that this also changes some field names in serialized lease files.
But given that these field names have not been part of a released
version of systemd yet, such a change should be ok.
This is pure renaming/refactoring, shouldn't actually change any
behaviour.
RFC: 8415
21.17. Vendor-specific Information Option
This option is used by clients and servers to exchange vendor-
specific information.
The format of the Vendor-specific Information option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Vendor-specific Information Option Format
option-code OPTION_VENDOR_OPTS (17).
option-len 4 + length of vendor-option-data field.
enterprise-number The vendor's registered Enterprise Number as
maintained by IANA [IANA-PEN]. A 4-octet
field containing an unsigned integer.
vendor-option-data Vendor options, interpreted by
vendor-specific code on the clients and
servers. A variable-length field (4 octets
less than the value in the option-len field).
The definition of the information carried in this option is vendor
specific. The vendor is indicated in the enterprise-number field.
Use of vendor-specific information allows enhanced operation,
utilizing additional features in a vendor's DHCP implementation. A
DHCP client that does not receive requested vendor-specific
information will still configure the node's IPv6 stack to be
functional.
The vendor-option-data field MUST be encoded as a sequence of
code/length/value fields of format identical to the DHCP options (see
Section 21.1). The sub-option codes are defined by the vendor
identified in the enterprise-number field and are not managed by
IANA. Each of the sub-options is formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt-code | sub-option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: Vendor-specific Options Format
sub-opt-code The code for the sub-option. A 2-octet
field.
sub-option-len An unsigned integer giving the length of the
sub-option-data field in this sub-option in
octets. A 2-octet field.
sub-option-data The data area for the sub-option. The
length, in octets, is specified by
sub-option-len.
Multiple instances of the Vendor-specific Information option may
appear in a DHCP message. Each instance of the option is interpreted
according to the option codes defined by the vendor identified by the
Enterprise Number in that option. Servers and clients MUST NOT send
more than one instance of the Vendor-specific Information option with
the same Enterprise Number. Each instance of the Vendor-specific
Information option MAY contain multiple sub-options.
A client that is interested in receiving a Vendor-specific
Information option:
- MUST specify the Vendor-specific Information option in an Option
Request option.
- MAY specify an associated Vendor Class option (see Section 21.16).
- MAY specify the Vendor-specific Information option with
appropriate data.
Servers only return the Vendor-specific Information options if
specified in Option Request options from clients and:
- MAY use the Enterprise Numbers in the associated Vendor Class
options to restrict the set of Enterprise Numbers in the
Vendor-specific Information options returned.
- MAY return all configured Vendor-specific Information options.
- MAY use other information in the packet or in its configuration to
determine which set of Enterprise Numbers in the Vendor-specific
Information options to return.
We need to fix RCC 2215 behaviour with rfc7550 errata
and https://tools.ietf.org/html/rfc8415.
[RFC3315] specifies that a client must ignore an Advertise message if
a server will not assign any addresses to a client, and [RFC3633]
specifies that a client must ignore an Advertise message if a server
returns the NoPrefixAvail status to a requesting router. Thus, a
client requesting both IA_NA and IA_PD, with a server that only
offers either addresses or delegated prefixes, is not supported by
the current protocol specifications.
Solution: a client SHOULD accept Advertise messages, even when not
all IA option types are being offered. And, in this case, the client
SHOULD include the not offered IA option types in its Request. A
client SHOULD only ignore an Advertise message when none of the
requested IA options include offered addresses or delegated prefixes.
Note that ignored messages MUST still be processed for SOL_MAX_RT and
INF_MAX_RT options as specified in [RFC7083].
Replace Section 17.1.3 of RFC 3315: (existing errata)
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message(s) to the
user.
With the following text (which addresses the existing erratum
[Err2471] and includes the changes made by [RFC7083]):
The client MUST ignore any Advertise message that contains no
addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
options; see RFC 3633) with the exception that the client:
- MUST process an included SOL_MAX_RT option (RFC 7083) and
- MUST process an included INF_MAX_RT option (RFC 7083).
A client can display any associated status message(s) to the user
or activity log.
The client ignoring this Advertise message MUST NOT restart the
Solicit retransmission timer.
Instead of -EBUSY, return 0 from sd_ipv4ll_start() if it's already started,
and change successful start return value to 1.
This matches sd_ndisc_start() behavior; 1 indicates successful start, and
0 indicates already started.
```
21.16. Vendor Class Option
This option is used by a client to identify the vendor that
manufactured the hardware on which the client is running. The
information contained in the data area of this option is contained in
one or more opaque fields that identify details of the hardware
configuration. The format of the Vendor Class option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Vendor Class Option Format
option-code OPTION_VENDOR_CLASS (16).
option-len 4 + length of vendor-class-data field.
enterprise-number The vendor's registered Enterprise Number as
maintained by IANA [IANA-PEN]. A 4-octet
field containing an unsigned integer.
vendor-class-data The hardware configuration of the node on
which the client is running. A
variable-length field (4 octets less than the
value in the option-len field).
The vendor-class-data field is composed of a series of separate
items, each of which describes some characteristic of the client's
hardware configuration. Examples of vendor-class-data instances
might include the version of the operating system the client is
running or the amount of memory installed on the client.
Each instance of vendor-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Figure 29: Format of vendor-class-data Field
The vendor-class-len field is 2 octets long and specifies the length
of the opaque vendor-class-data in network byte order.
Servers and clients MUST NOT include more than one instance of
OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance
of OPTION_VENDOR_CLASS can carry multiple vendor-class-data
instances.
```
sd-network: DHCPv6 - add support to send userclass option
21.15. User Class Option
The User Class option is used by a client to identify the type or
category of users or applications it represents.
The format of the User Class option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. user-class-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: User Class Option Format
option-code OPTION_USER_CLASS (15).
option-len Length of user-class-data field.
user-class-data The user classes carried by the client. The
length, in octets, is specified by
option-len.
The information contained in the data area of this option is
contained in one or more opaque fields that represent the user class
or classes of which the client is a member. A server selects
configuration information for the client based on the classes
identified in this option. For example, the User Class option can be
used to configure all clients of people in the accounting department
with a different printer than clients of people in the marketing
department. The user class information carried in this option MUST
be configurable on the client.
The data area of the User Class option MUST contain one or more
instances of user-class-data information. Each instance of
user-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
Figure 27: Format of user-class-data Field
Let's use size_t for numbers of entries in memory.
Let's use const wherever appropriate.
Drop `_server` suffix from function name where we don't have it for
similar other cases.
We always need to make them unions with a "struct cmsghdr" in them, so
that things properly aligned. Otherwise we might end up at an unaligned
address and the counting goes all wrong, possibly making the kernel
refuse our buffers.
Also, let's make sure we initialize the control buffers to zero when
sending, but leave them uninitialized when reading.
Both the alignment and the initialization thing is mentioned in the
cmsg(3) man page.
We need to use the CMSG_SPACE() macro to size the control buffers, not
CMSG_LEN(). The former is rounded up to next alignment boundary, the
latter is not. The former should be used for allocations, the latter for
encoding how much of it is actually initialized. See cmsg(3) man page
for details about this.
Given how confusing this is, I guess we don't have to be too ashamed
here, in most cases we actually did get this right.
Split out of #15457, let's see if this is the culprit of the CI failure.
(also setting green label here, since @keszybz already greenlit it in that other PR)
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
When specifying `DHCPv4.SendOption=`, it is used by systemd-networkd to
set the value of that option within the DHCP request that is sent out.
This differs to setting `DHCPServer.SendOption=`, which will place all
the options together as suboptions into the vendor-specific information
(code 43) option.
This commit adds two new config options, `DHCPv4.SendVendorOption=` and
`DHCPServer.SendVendorOption=`. These both have the behaviour of the old
`DHCPServer.SendOption=` flag, and set the value of the suboption in the
vendor-specific information option.
The behaviour of `DHCPServer.SendOption=` is then changed to reflect
that of `DHCPv4.SendOption=`. It will set the value of the corresponding
option in the DHCP request.
Don't reset the conflict counter when trying a new pseudo random
address, so that after trying 10 addresses the londer timeout is used in
accordance with the RFC
Fixes#14299.
