Since we now have the possibility to request prefixes to be delegated
without corresponding IPv6 addresses, it does not make sense to store
lease T1 and T2 timeouts in the otherwise unused IA_NA structure.
Therefore lease timeouts T1 and T2 are moved to the DHCPv6 client
structure, as there will be only one set of stateful timeouts required
by RFC 7550, Section 4.3.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
Parse IA PD options and the prefixes in one or more PD Prefix
options. As the PD option contains identical data as the IA NA
option, re-use the same general data structures and sub-option
parsing logic. Similar to IA NA addresses, PD and associated
prefixes are stored in the address list of the IA PD lease.
An IA sub-option Status code will affect the IA NA and IA PD
option in question and cause those options to be ignored. A
Status code option in an IA Address or IA PD Prefix option
affects only that IA Address or Prefix.
Factor out IA Address option parsing and fix it so that all conditions
are checked before a new address is allocated and added to the address
list. Note also that the IA Address option can contain a nested Status
option. If the status in anything else than zero, the DHCPv6 server is
communicating an error condition and the address cannot be used.
Status option nesting is clarified in RFC 7550, Section 4.1.
The IA Address option is included as a typedef so that the lifetimes
can be inspected before allocating a new address and the option length
needed is easily available.
Sanitize code for parsing DHCPv6 IA NA and TA options and their
nested Status options so that the options can be fully and
properly ignored should they not be conformant to the specification.
Do this by defining a proper DHCP6Option structure and sending that
structure to the parsing function. The parsing function will then
not manipulate either any option data pointers or their lengths in
order to iterate over the current option. Needless to say, this
affects a few files including the test program.
Implement DHCPv6 option to exchange information about the Fully
Qualified Domain Name (FQDN) according to RFC 4704.
The RFC 4704 describes two models of operations in section 3,
currently only the second model is supported (DHCPv6 server
updates both the AAAA and the PTR RRs).
The existing DHCP Section Options SendHostname and Hostname are
sent as FQDN to the server. According to section 4.2 sending
only parts of its FQDN is allowed.
Fixes#4682.
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
Add a helper function containing a modified version of dns_packet_read_name()
that does not use DnsPacket to extract a string array of domain names from
the provided option data. The domain names are stored uncompressed as defined
in Section 8. of RFC 3315.
- Rename log_meta() → log_internal(), to follow naming scheme of most
other log functions that are usually invoked through macros, but never
directly.
- Rename log_info_object() to log_object_info(), simply because the
object should be before any other parameters, to follow OO-style
programming style.
This change has two benefits:
- The format string %m will now resolve to the specified error (or to
errno if the specified error is 0. This allows getting rid of a ton of
strerror() invocations, a function that is not thread-safe.
- The specified error can be passed to the journal in the ERRNO= field.
Now of course, we just need somebody to convert all cases of this:
log_error("Something happened: %s", strerror(-r));
into thus:
log_error_errno(-r, "Something happened: %m");
With this change the DHCP6_OPTION_IAADDR_LEN define can be removed in
favor of using sizeof(). Using the name of the struct and sizeof()
makes it clearer how much and what data is being copied from the
DHCPv6 message.
When receiving DHCPv6 messages, discard the ones that are not meant
for DHCPv6 clients and verify the transaction id. Once that is done,
process the Advertise message and select the Advertise with the
highest preference.
Create a separate function for lease information parsing so that it
can be reused in other parts of the protocol. Verify both DUID and
IAID in the received message and store other necessary information
with the lease structure.
Add functionality to parse DHCPv6 Identity Association for
Non-temporary (IA_NA) and Temporary Addresses (IA_TA) options.
Both of them contain one or more IA Address (IAADDR) options
and optinally a status code option. Only the IA_NA option
contains lease lifetimes. See RFC 3315, sections 22.4., 22.5.,
22.6., 22.13. and appendix B. for details. If the lease
timeouts are not set, use the ones recommended for servers in
section 22.4.
Factor out common code in the form of an option header parsing
helper function.
Implement the initial functionality used for creating a DHCPv6 Solicit
message containing the needed options and send it to the DHCPv6
broadcast address. Increase the sent message count and ensure that
the Solicit Initial Retransmission Time is strictly greater than
the Solicitation IRT as described in RFC 3315, section 17.1.2.
Add a function that creates a UDP socket bound to the given interface
and optionally to an IPv6 address. Add another function that will
send the DHCPv6 UDP packet to its destination.
Using IPV6_PKTINFO in setsockopt to bind the IPv6 socket to an
interface is documented in section 4. of RFC 3542, "Advanced Sockets
Application Program Interface (API) for IPv6"
Add a define for DHCPv6 Relay Agents and Servers multicast address as
its not available elsewhere.
Add option appending and parsing. DHCPv6 options are not aligned, thus
the option handling code must be able to handle options starting at
any byte boundary.
Add a test case for the basic option handling.
Create structures describing Identity Association IDentifiers and
IPv6 lease addresses.
[tomegun: initialize the IAID when client is started. Base this off of the
predictable udev names, if available, as these satisfy the requirement of
the IAID, and base it off the mac addres otherwise, as that is the best we
have.]
Provide functions to bind the ICMPv6 socket to the approriate interface
and set multicast sending and receiving according to RFC 3493, section
5.2. and RFC 3542, sections 3. and 3.3. Filter out all ICMPv6 messages
except Router Advertisements for the socket in question according to
RFC 3542, section 3.2.
Send Router Solicitations to the all routers multicast group as
described in RFC 4861, section 6. and act on the received Router
Advertisments according to section 6.3.7.
Implement a similar API for ICMPv6 handling as is done for DHCPv4 and
DHCPv6.
