mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-31 05:55:28 +00:00
Code Issues Releases Wiki Activity

[master] Merge branch 'trac3554' (mac-sources parameter added)

Browse Source
This commit is contained in:
Tomek Mrugalski
2014-12-23 16:43:43 +01:00
parent 4eb8976aa8 c12560be72
commit 2e7c32e7c1
32 changed files with 783 additions and 123 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
doc/Makefile.am
View File

@@ -9,6 +9,7 @@ nobase_dist_doc_DATA += examples/kea4/reservations.json
nobase_dist_doc_DATA += examples/kea6/simple.json
nobase_dist_doc_DATA += examples/kea6/several-subnets.json
nobase_dist_doc_DATA += examples/kea6/multiple-options.json
nobase_dist_doc_DATA += examples/kea6/advanced.json
nobase_dist_doc_DATA += examples/ddns/sample1.json
nobase_dist_doc_DATA += examples/ddns/template.json

6
doc/examples/kea4/multiple-options.json
View File

@@ -4,8 +4,8 @@
{ "Dhcp4":
{
# Kea is told to listen on eth0 interface only.
"interfaces": [ "eth0" ],
# Kea is told to listen on ethX interface only.
"interfaces": [ "ethX" ],
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require
@@ -36,7 +36,7 @@
{
"pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"interface": "eth0",
"interface": "ethX",
"option-data": [
{
"name": "domain-name-servers",

4
doc/examples/kea4/several-subnets.json
View File

@@ -5,8 +5,8 @@
{ "Dhcp4":
{
# Kea is told to listen on eth0 interface only.
"interfaces": [ "eth0" ],
# Kea is told to listen on ethX interface only.
"interfaces": [ "ethX" ],
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require

8
doc/examples/kea4/single-subnet.json
View File

@@ -5,8 +5,8 @@
{ "Dhcp4":
{
# Kea is told to listen on eth0 interface only.
"interfaces": [ "eth0" ],
# Kea is told to listen on ethX interface only.
"interfaces": [ "ethX" ],
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require
@@ -35,8 +35,8 @@
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"interface": "eth0"
}
"interface": "ethX"
}
]
},

79
doc/examples/kea6/advanced.json Normal file
View File

@@ -0,0 +1,79 @@
# This is an example configuration file for DHCPv6 server in Kea.
# It attempts to showcase some of the more advanced features.
# Topology wise, it's a basic scenario with one IPv6 subnet configured.
# It is assumed that one subnet (2001:db8:1::/64) is available directly
# over ethX interface.
#
# The following features are currently showcased here:
# 1. Configuration of MAC/hardware address sources in DHCPv6
{ "Dhcp6":
{
# Kea is told to listen on ethX network interface only.
"interfaces": [ "ethX" ],
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require
# any prior set up.
"lease-database": {
"type": "memfile"
},
# Kea 0.9.1 introduced MAC/hardware addresses support in DHCPv6. There is
# no single reliable method of getting MAC address information in DHCPv6.
# Kea supports several methods. Depending on your network set up, some
# methods may be more preferable than others, hence the configuration
# parameter. 'mac-sources' is a list of methods. Allowed parameters are:
# any, raw, duid, ipv6-link-local, client-link-addr-option, rfc6939 (which
# is an alias for client-link-addr-option), remote-id, rfc4649 (which is an
# alias for remote-id, subscriber-id, rfc4580 (which is an alias for
# subscriber-id) and docsis.
#
# Note that the order matters. Methods are attempted one by one in the order
# specified until hardware address is obtained. If you don't care which method
# is used, using 'any' is marginally faster than enumerating them all.
#
# If mac-sources are not specified, a default value of 'any' is used.
"mac-sources": [ "client-link-addr-option", "duid", "ipv6-link-local" ],
# Addresses will be assigned with preferred and valid lifetimes
# being 3000 and 4000, respectively. Client is told to start
# renewing after 1000 seconds. If the server does not repond
# after 2000 seconds since the lease was granted, client is supposed
# to start REBIND procedure (emergency renewal that allows switching
# to a different server).
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
# The following list defines subnets. Each subnet consists of at
# least subnet and pool entries.
"subnet6": [
{
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"interface": "ethX"
}
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
"Logging": {
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
}
],
"debuglevel": 99,
"severity": "DEBUG"
}
]
}
}

6
doc/examples/kea6/multiple-options.json
View File

@@ -4,8 +4,8 @@
{ "Dhcp6":
{
# Kea is told to listen on eth0 interface only.
"interfaces": [ "eth0" ],
# Kea is told to listen on ethX interface only.
"interfaces": [ "ethX" ],
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require
@@ -32,7 +32,7 @@
{
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"interface": "eth0",
"interface": "ethX",
"option-data": [
{
"name": "dns-servers",

4
doc/examples/kea6/several-subnets.json
View File

@@ -5,8 +5,8 @@
{ "Dhcp6":
{
# Kea is told to listen on eth0 interface only.
"interfaces": [ "eth0" ],
# Kea is told to listen on ethX interface only.
"interfaces": [ "ethX" ],
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require

10
doc/examples/kea6/simple.json
View File

@@ -1,13 +1,13 @@
# This is an example configuration file for DHCPv6 server in Kea.
# It's a basic scenario with four IPv6 subnets configured. It is
# It's a basic scenario with one IPv6 subnet configured. It is
# assumed that one subnet (2001:db8:1::/64 is available directly
# over eth0 interface.
# over ethX interface.
{ "Dhcp6":
{
# Kea is told to listen on eth0 interface only.
"interfaces": [ "eth0" ],
# Kea is told to listen on ethX interface only.
"interfaces": [ "ethX" ],
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require
@@ -33,7 +33,7 @@
{
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"interface": "eth0"
"interface": "ethX"
}
]
},

111
doc/guide/dhcp6-srv.xml
View File

@@ -1838,6 +1838,117 @@ should include options from the isc option space:
</para>
</section>
<section id="mac-in-dhcpv6">
<title>MAC/Hardware addresses in DHCPv6</title>
<para>MAC/hardware addesses are available in DHCPv4 messages
from the clients 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 retrieve that information. To mitigate that issue a number of mechanisms
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 for 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. In a typical deployment the default
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>
"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>