| Age | Commit message (Collapse) | Author |
|---|
|
Start sending Renew and Rebind DHCPv6 messages when respective timers T1
and T2 expire. Rebind messages do not include a Server ID option and the
Rebind procedure ends when the last IPv6 address valid lifetime expires,
whereafter the client restarts the address acquisition procedure by
Soliciting for available servers.
See RFC 3315, sections 18.1.3. and 18.1.4. for details.
|
|
Provide a function to request more options from the DHCPv6 server.
Provide a sensible default set at startup and add test basic test
cases for the intended usage.
Define DNS and NTP related option codes and add comments for the
unassigned codes.
|
|
In order to keep the refcounting working, a DONT_DESTROY macro similar
to the one in sd-bus has been added also to DHCPv6.
|
|
|
|
|
|
client_initialize name is misleading, since the function is actually
useful at the *end*, to reinitialize the object. But reset is shorter,
so rename it to client_reset.
|
|
Receive and parse a Reply from the server. Set up T1 and T2 timers and
notify the library user of an acquired DHCPv6 lease.
|
|
As described in RFC 3315, Section 17.1.2, a client has to wait until the
first timeout has elapsed before it is allowed to request IPv6 addresses
from the DHCPv6 server. This is indicated by a non-NULL lease and a
non-zero resend count. Should the Advertisement contain a preference
value of 255 or be received after the first timeout, IPv6 address
requesting is started immediately.
In response to these events, create a Request message and set up proper
resend timers to send the message to the server.
|
|
Update the start function so that the client state can be conveniently
changed with the previous message resend timers cleared. On initial
startup also create and bind to the UDP socket.
|
|
Add support functions for accessing the current client lease as well
as iterating over the addresses and get their preferred and valid
lifetimes.
|
|
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.
|
|
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 the core of DHCPv6 client message retransmission and upper bound
timer and message count handling according to RFC 3315 Secions 7.1.2
and 14. Omit the DHCPv6 initial delay; for now it is assumed that
systemd-networkd will provide decent startup randomization that will
desynchronize the clients.
When reinitializing the client, clear all timers.
|
|
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.]
|
|
Initialize DHCP Unique Identifier when creating the client. The
DUID is generated based on the machine-id, which satisfies all the
requirements of what an DUID should be. The DUID type is DUID-EN.
Based on patch by Patrik Flykt.
|
|
Add initial structure definition and functions for setting index, MAC
address, callback and event loop. Define protocol values and states.
|
