Commit 72f999e3 authored by Tomek Mrugalski's avatar Tomek Mrugalski 🛰
Browse files

[3554] User's Guide updated.

parent 417c4130
......@@ -1838,6 +1838,109 @@ should include options from the isc option space:
</para>
</section>
<section id="mac-in-dhcpv6">
<title>MAC/Hardware addresses in DHCPv6</title>
<para>MAC or hardware addesses are available in DHCPv4 and administrators
frequently use that information to perform certain tasks, like per host
configuration, address reserveration for specific MAC addresses and other.
Unfortunately, DHCPv6 protocol does not provide any completely reliable way
to access 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>
<para>Kea allows configuration which of the supported methods should be
used and in which order. This configuration may be considered a fine tuning
of the DHCP deployment. The format of this parameter is as follows:
<screen>
"Dhcp6": {
<userinput>"mac-sources: [ "method1", "method2", "method3", ... ]</userinput>,
"subnet6": [ ... ],
...
}
</screen>
When not specified, a special value of <emphasis>any</emphasis> is used, which
instructs the server to attempt to use all the methods in sequence and use
value returned by the first one that succeeds.</para>
<para>Supported methods are:
<itemizedlist>
<listitem>
<simpara><command>any</command> - not an actual method, just a keyword that
instructs Kea to try all other methods and use the first one that succeeds.
This is the default operation if no <command>mac-sources</command> are defined.
</simpara>
</listitem>
<listitem>
<simpara><command>raw</command> In principle, a DHCPv6 server could use raw
sockets to receive incoming traffic and extract MAC/hardware address
information. This is currently not implemented and this value has no effect.
</simpara>
</listitem>
<listitem>
<simpara><command>duid</command> - DHCPv6 uses DUID identifiers instead of
MAC addresses. There are currently four DUID types defined, with two of them
(DUID-LLT, which is the default one and DUID-LL) convey MAC address information.
Although RFC3315 forbids it, it is possible to parse those DUIDs and extract
necessary information from them. This method is not completely reliable, as
clients may use other DUID types, namely DUID-EN or DUID-UUID.
</simpara>
</listitem>
<listitem>
<simpara><command>ipv6-link-local</command> - Another possible aquisition
method comes from the source IPv6 address. In typical usage, clients are
sending their packets from IPv6 link-local addresses. There's a good chance
that those addresses are based on EUI-64, which contains MAC address. This
method is not completely reliable, as clients may use other link-local address
types. In particular, privacy extensions, defined in RFC4941, do not use
MAC addresses.
</simpara>
</listitem>
<listitem>
<simpara><command>client-link-addr-option</command> - One extension defined
to alleviate missing MAC issues is client link-layer address option, defined
in <ulink url="http://tools.ietf.org/html/rfc6939">RFC 6939</ulink>. This is
an option that is inserted by a relay and contains information about client's
MAC address. This method requires a relay agent that supports the option and
is configured to insert it. This method is useless for directly connected
clients. This parameter can also be specified as <command>rfc6939</command>,
which is an alias for <command>client-link-addr-option</command>.
</simpara>
</listitem>
<listitem>
<simpara><command>remote-id</command> <ulink
url="http://tools.ietf.org/html/rfc4649">RFC 4649</ulink>
defines remote-id option that is inserted by a relay agent. Depending
on the relay agent configuration, the inserted option may convey client's
MAC address information. This parameter can also be specified as
<command>rfc4649</command>, which is an alias for <command>remote-id</command>.
</simpara>
</listitem>
<listitem>
<simpara><command>subscriber-id</command> - Another option
that is somewhat similar to the previous one is subscriber-id,
defined in <ulink url="http://tools.ietf.org/html/rfc4580">RFC
4580</ulink>. It is, too, inserted by a relay agent that is
configured to insert it. This parameter can also be specified
as <command>rfc4580</command>, which is an alias for
<command>subscriber-id</command>. This method is currently not
implemented.
</simpara>
</listitem>
<listitem>
<simpara><command>docsis</command> - Yet another possible source of MAC
address information are DOCSIS options inserted by a CMTS that acts
as a DHCPv6 relay agent in cable networks. This method is
currently not implemented.
</simpara>
</listitem>
</itemizedlist>
</para>
</section>
<section id="dhcp6-std">
<title>Supported DHCPv6 Standards</title>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment