| Age | Commit message (Collapse) | Author |
|---|
|
Router Discovery is a core part of IPv6, which by default is handled by the kernel.
However, the kernel implementation is meant as a fall-back, and to fully support
the protocol a userspace implementation is desired.
The protocol essentially listens for Router Advertisement packets from routers
on the local link and use these to configure the client automatically. The four
main pieces of information are: what kind (if any) of DHCPv6 configuration should
be performed; a default gateway; the prefixes that should be considered to be on
the local link; and the prefixes with which we can preform SLAAC in order to pick
a global IPv6 address.
A lot of additional information is also available, which we do not yet fully
support, but which will eventually allow us to avoid the need for DHCPv6 in the
common case.
Short-term, the reason for wanting this is in userspace was the desire to fully
track all the addresses on links we manage, and that is not possible for addresses
managed by the kernel (as the kernel does not expose to us the fact that it
manages these addresses). Moreover, we would like to support stable privacy
addresses, which will soon be mandated and the legacy MAC-based global addresses
deprecated, to do this well we need to handle the generation in userspace. Lastly,
more long-term we wish to support more RA options than what the kernel exposes.
|
|
The previous behavior:
When DHCPv6 was enabled, router discover was performed first, and then DHCPv6 was
enabled only if the relevant flags were passed in the Router Advertisement message.
Moreover, router discovery was performed even if AcceptRouterAdvertisements=false,
moreover, even if router advertisements were accepted (by the kernel) the flags
indicating that DHCPv6 should be performed were ignored.
New behavior:
If RouterAdvertisements are accepted, and either no routers are found, or an
advertisement is received indicating DHCPv6 should be performed, the DHCPv6
client is started. Moreover, the DHCP option now truly enables the DHCPv6
client regardless of router discovery (though it will probably not be
very useful to get a lease withotu any routes, this seems the more consistent
approach).
The recommended default setting should be to set DHCP=ipv4 and to leave
IPv6AcceptRouterAdvertisements unset.
|
|
Enabling address acquisition, configuring the client and starting the client are now
split out. This to better handle the client being repeatedly enabled due to router
advertisements.
|
|
As the data passed is very different, we introduce four different callbacks:
- Generic - router discovery timed out or state machine stopped
- Router - router and link configuration received
- Prefix onlink - configuration for an onlink prefix received
- Prefix autonomous - configuration for to configure a SLAAC address for a prefix received
|
|
Also, stop the state machine when we get into a broken state, rather than just notify the user.
|
|
Instead instantiate the kernel flags to TENTATIVE until the kernel
updates us with the real value.
|
|
|
|
|
|
|
|
This patch adds support to configure IPV6 hop limit.
For example:
/proc/sys/net/ipv6/conf/wlp3s0/hop_limit
|
|
networkd: vxlan add option to set FDB entries
|
|
|
|
|
|
networkd: (de)serialize more state and support expiring routes
|
|
Add support to configures maximum number of FDB entries.
|
|
We have enough places where we parse an ifindex, hence introduce a
proper parsing function for it, that verifies all parameters.
|
|
|
|
This should really live in the kernel, but the netlink API currently
does not support it. Until support has been added, expire the route
from userspace.
|
|
|
|
This initializes the clients to try rebinding the preexisting
addresses before doing anything else.
|
|
For now only deserialize some basic state and the applied addresses.
When a link is added, try to deserialize it's state from /run. This
is relevant only when networkd is restarted at runtime.
|
|
|
|
|
|
|
|
The operstate may change based on address properties, so make a change of
address trigger an operstate update.
|
|
Different tools use different terms for the same concept, let's try
to stick with 'priority', as that is what the netlink API uses.
|
|
|
|
Freeing a link removes it both from addresses and addresses_foreign,
causing SIGSEGV if one of the sets is freed.
|
|
|
|
|
|
capability-util.[ch]
The files are named too generically, so that they might conflict with
the upstream project headers. Hence, let's add a "-util" suffix, to
clarify that this are just our utility headers and not any official
upstream headers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networkd: fix asserts
|
|
There are more than enough to deserve their own .c file, hence move them
over.
|
|
|
|
|
|
|
|
|
|
|
|
Exported header files should not include internal headers. Fix that.
Exported header files should not use the bool type. So far we opted to
stick to C89 for exported headers, and hence use "int" for bools in
them. Continue to do so.
Exported header files should have #include lines for everything they use
including inttypes.h and sys/types.h, so that they may be included in
any order.
Exported header files should have C++ guards, hence add them.
Exported header files should not use gcc extensions like #pragma once,
get rid of it.
|
|
string-util.[ch]
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.
|
|
The caller should push any lifetime information into the kernel and let the kernel handle
prefix expiration.
|
|
This ressurects 47d45d3cde45d6545367570264e4e3636bc9e345. We now always use /128 prefixes,
so there is no need for the DHCPv6 code to know about prefixes expiring.
|
|
The routing information should be configured separately by ND, there is no need to
indicate the prefix again in the DHCPv6 addresses.
See discussion and related links at issue #1520.
|
|
|
