|
@@ -1841,26 +1841,26 @@ should include options from the isc option space:
|
|
<section id="mac-in-dhcpv6">
|
|
<section id="mac-in-dhcpv6">
|
|
<title>MAC/Hardware addresses in DHCPv6</title>
|
|
<title>MAC/Hardware addresses in DHCPv6</title>
|
|
<para>MAC/hardware addesses are available in DHCPv4 messages
|
|
<para>MAC/hardware addesses are available in DHCPv4 messages
|
|
- from the client and administrators
|
|
|
|
|
|
+ from the clients and administrators
|
|
frequently use that information to perform certain tasks, like per host
|
|
frequently use that information to perform certain tasks, like per host
|
|
configuration, address reserveration for specific MAC addresses and other.
|
|
configuration, address reserveration for specific MAC addresses and other.
|
|
Unfortunately, DHCPv6 protocol does not provide any completely reliable way
|
|
Unfortunately, DHCPv6 protocol does not provide any completely reliable way
|
|
to retrieve that information. To mitigate that issue a number of mechanisms
|
|
to retrieve that information. To mitigate that issue a number of mechanisms
|
|
- has been implemented in Kea that attempts to gather that information. Each
|
|
|
|
- of those mechanisms works in certain cases, but may fail in others. There
|
|
|
|
- is no single best mechanism as they are somewhat dependent on the network
|
|
|
|
- topology and the technologies used.</para>
|
|
|
|
|
|
+ have been implemented in Kea that attempt to gather that information. Each
|
|
|
|
+ of those mechanisms works in certain cases, but may fail in other cases.
|
|
|
|
+ Whether the mechanism works or not in the particular deployment is
|
|
|
|
+ somewhat dependent on the network topology and the technologies used.</para>
|
|
|
|
|
|
- <para>Kea allows configuration which of the supported methods should be
|
|
|
|
|
|
+ <para>Kea allows for configuration which of the supported methods should be
|
|
used and in which order. This configuration may be considered a fine tuning
|
|
used and in which order. This configuration may be considered a fine tuning
|
|
of the DHCP deployment. In a typical deployment the default
|
|
of the DHCP deployment. In a typical deployment the default
|
|
- value of <command>"any"</command> is reasonable and there's no
|
|
|
|
- need to change it. This paramter is the most useful in cases
|
|
|
|
- when an administrator wants to disable certain method, e.g. if you
|
|
|
|
- trust the network infrastructure more than the information
|
|
|
|
- provided by the clients clients themselves, you may prefer
|
|
|
|
- information provided by the relays over that provided by the
|
|
|
|
- clients. The format of this parameter is as follows:
|
|
|
|
|
|
+ value of <command>"any"</command> is sufficient and there is no
|
|
|
|
+ need to select specific methods. Changing the value of this parameter
|
|
|
|
+ is the most useful in cases when an administrator wants to disable
|
|
|
|
+ certain method, e.g. if the administrator trusts the network infrastructure
|
|
|
|
+ more than the information provided by the clients themselves, the
|
|
|
|
+ administrator may prefer information provided by the relays over that
|
|
|
|
+ provided by the clients. The format of this parameter is as follows:
|
|
<screen>
|
|
<screen>
|
|
"Dhcp6": {
|
|
"Dhcp6": {
|
|
<userinput>"mac-sources": [ "method1", "method2", "method3", ... ]</userinput>,
|
|
<userinput>"mac-sources": [ "method1", "method2", "method3", ... ]</userinput>,
|