|
|
@@ -11,7 +11,7 @@
|
|
|
<title>Starting and Stopping the DHCPv6 Server</title>
|
|
|
|
|
|
<para>
|
|
|
- It is recommended that the Kea DHCPv4 server be started and stopped
|
|
|
+ It is recommended that the Kea DHCPv6 server be started and stopped
|
|
|
using <command>keactrl</command> (described in <xref linkend="keactrl"/>).
|
|
|
However, it is also possible to run the server directly: it accepts
|
|
|
the following command-line switches:
|
|
|
@@ -1716,6 +1716,189 @@ should include options from the isc option space:
|
|
|
|
|
|
</section>
|
|
|
|
|
|
+ <!-- Host reservation is a large topic. There will be many subsections,
|
|
|
+ so it should be a section on its own. -->
|
|
|
+ <section id="host-reservation-v6">
|
|
|
+ <title>Host reservation in DHCPv6</title>
|
|
|
+
|
|
|
+ <para>There are many cases where it is useful to provide a configuration on
|
|
|
+ a per host basis. The most obvious one is to reserve specific, static IPv6
|
|
|
+ address or prefix for exclusive use by a given client ‐ returning
|
|
|
+ client will get the same address or prefix every time and other clients will
|
|
|
+ never get that address. Other example may be a host that has specific
|
|
|
+ requirements, e.g. a printer that needs additional options or a cable modem
|
|
|
+ need specific parameter. Yes another possible use case for host reservation
|
|
|
+ is to define unique host names for hosts. Although not all of those
|
|
|
+ scenarios are possible yet, Kea software will support them in the near
|
|
|
+ future.</para>
|
|
|
+
|
|
|
+ <para>Hosts are defined as parameters for each subnet. Each host
|
|
|
+ can be identified by either DUID or its hardware/MAC address. See
|
|
|
+ <xref linkend="mac-in-dhcpv6"/> for details. There is an optional
|
|
|
+ <command>reservations</command> array in the
|
|
|
+ <command>Subnet6</command> structure. Each element in that array
|
|
|
+ is a structure, that holds information about a single host. In
|
|
|
+ particular, such a structure has to have an indentifer that
|
|
|
+ uniquely identifies a host. In DHCPv6 context, such an identifier
|
|
|
+ is a hardware (MAC) address or a DUID. Also, either one or more
|
|
|
+ addresses or prefixes should be specified. It is possible to
|
|
|
+ specify a hostname. Additional capabilities are planed.</para>
|
|
|
+
|
|
|
+ <para>The following example shows how to reserve addresses and prefixes
|
|
|
+ for specific hosts:
|
|
|
+
|
|
|
+<screen>
|
|
|
+"subnet6": [
|
|
|
+ {
|
|
|
+ "subnet": "2001:db8:1::/48",
|
|
|
+ "pools": [ { "pool": "2001:db8:1::/80" } ],
|
|
|
+ "pd-pools": [
|
|
|
+ {
|
|
|
+ "prefix": "2001:db8:1:8000::",
|
|
|
+ "prefix-len": 56,
|
|
|
+ "delegated-len": 64
|
|
|
+ }
|
|
|
+ ],
|
|
|
+ <userinput>"reservations": [
|
|
|
+ {
|
|
|
+ "duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
|
|
|
+ "ip-addresses": [ "2001:db8:1::100" ]
|
|
|
+ },
|
|
|
+ {
|
|
|
+ "hw-address": "00:01:02:03:04:05",
|
|
|
+ "ip-addresses": [ "2001:db8:1::101" ]
|
|
|
+ },
|
|
|
+ {
|
|
|
+ "duid": "01:02:03:04:05:06:07:08:09:0A",
|
|
|
+ "ip-addresses": [ "2001:db8:1::102" ],
|
|
|
+ "prefixes": [ "2001:db8:2:abcd::/64" ],
|
|
|
+ "hostname": "foo.example.com"
|
|
|
+ }
|
|
|
+ ]</userinput>
|
|
|
+ }
|
|
|
+]
|
|
|
+</screen>
|
|
|
+ This example makes 3 reservations. The first one reserves 2001:db8:1::100 address
|
|
|
+ for the client using DUID 01:02:03:04:05:0A:0B:0C:0D:0E. The second one
|
|
|
+ also reserves an address, but does so using MAC or hardware address, rather than
|
|
|
+ DUID. The third example is most advanced. It reserves an address, a prefix and
|
|
|
+ a hostname at the same time.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>Note that DHCPv6 allows for a single client to lease multiple addresses
|
|
|
+ and multiple prefixes at the same time. In the upcoming Kea releases, it will
|
|
|
+ be possible to have multiple addresses and prefixes reserved for a single
|
|
|
+ host. Therefore <command>ip-addresses"</command> and <command>prefixes</command>
|
|
|
+ are plural and are actually arrays. As of 0.9.1 having more than one IPv6
|
|
|
+ address or prefix is only partially supported.</para>
|
|
|
+
|
|
|
+ <para>Making a reservation for a mobile host that may visit multiple subnets
|
|
|
+ requires a separate host definition in each subnet it is expected to visit.
|
|
|
+ It is not allowed to define multiple host definitions with the same hardware
|
|
|
+ address in a single subnet. It is a valid configuration, if such definitions
|
|
|
+ are specified in different subnets, though.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>Adding host reservation incurs a performance penalty. In principle,
|
|
|
+ when the server that does not support host reservation responds to a query,
|
|
|
+ it needs to check whether there is a lease for a given address being
|
|
|
+ considered for allocation or renewal. The server that also supports host
|
|
|
+ reservation, has to perform additional checks: not only if the address is
|
|
|
+ currently used (if there is a lease for it), but also whether the address
|
|
|
+ could be used by someone else (if there is a reservation for it). That
|
|
|
+ additional check incurs performance penalty.</para>
|
|
|
+
|
|
|
+ <section id="reservation6-types">
|
|
|
+ <title>Address/prefix reservation types</title>
|
|
|
+
|
|
|
+ <para>In a typical scenario there's an IPv6 subnet defined with a certain
|
|
|
+ part of it dedicated for dynamic address allocation by the DHCPv6
|
|
|
+ server. There may be an additional address space defined for prefix
|
|
|
+ delegation. Those dynamic parts is referred to as dynamic pools, address
|
|
|
+ and prefix pools or simply pools. In principle the host reservation can
|
|
|
+ reserve any address or prefix that belongs to the subnet. The reservations
|
|
|
+ that specify an address that belong to configured pools are called
|
|
|
+ <command>in-pool reservations</command>. In contract, those that do not
|
|
|
+ belong to dynamic pools are called <command>out-of-pool
|
|
|
+ reservations</command>. There is no formal difference in the reservation
|
|
|
+ syntax. As of 0.9.1, both reservation types are handled
|
|
|
+ uniformly. However, upcoming releases may offer improved performance if
|
|
|
+ there are only out-of-pool reservations as the server will be able to skip
|
|
|
+ reservation checks when dealing with existing leases. Therefore, system
|
|
|
+ administrators are encouraged to use out-of-pool reservations, if
|
|
|
+ possible.</para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section it="reservation6-conflict">
|
|
|
+ <title>Conflicts in DHCPv6 reservations</title>
|
|
|
+ <para>As reservations and lease information are kept in different places,
|
|
|
+ conflict may arrise. Consider the following series of events. The server
|
|
|
+ has configured 2001:db8::10 to 2001:db8::20 dynamic pool range. Host A
|
|
|
+ requests an address and gets 2001:db8::10. Now the system administrator
|
|
|
+ decides to reserve an address for host B. He decides to reserve 2001:db8::10
|
|
|
+ for that purpose. In general, reserving an address that is currently
|
|
|
+ assigned to someone else is not recommended, but there are valid use
|
|
|
+ cases where such an operation is warranted.</para>
|
|
|
+
|
|
|
+ <para>The server now has a conflict to resolve. Let's analyze the
|
|
|
+ situation here. If host B boots up and request an address, the server is
|
|
|
+ not able to assign the reserved address 2001:db8::10. A naive approach
|
|
|
+ would to be immediately remove the lease for host A and create a new one
|
|
|
+ for host B. That would not solve the problem, though, because as soon as
|
|
|
+ host B get the address, it will detect that the address is already in use
|
|
|
+ by someone else (host A) and would send Decline. Therefore in this
|
|
|
+ situation, the server has to temporarily assign a different address (not
|
|
|
+ matching what has been reserved) to host B.</para>
|
|
|
+
|
|
|
+ <para>When the host A renews its address, the server will discover that
|
|
|
+ the address being renewed is now reserved for someone else (host
|
|
|
+ B). Therefore the server will remove the lease for 2001:db8::10 and select
|
|
|
+ a new address and will create a new lease for it. It will send two
|
|
|
+ addresses in its response: the old address with lifetimes set to 0 to
|
|
|
+ explicitly indicate that it is no longer valid and a new address with
|
|
|
+ non-zero lifetimes.When the host B renews its temporarily assigned
|
|
|
+ address, the server will detect that the existing lease does not match
|
|
|
+ reservation, so it will release the current address host B has and will
|
|
|
+ create a new lease matching the reservation. Similar as before, the server
|
|
|
+ will send two addresses: the temporary one with zeroed lifetimes and the
|
|
|
+ new one that matches reservation with proper lifetimes set.</para>
|
|
|
+
|
|
|
+ <para>This recovery will succeed, even if other hosts will attempt to get
|
|
|
+ the reserved address. Had the host C requested address 2001:db8::10 after
|
|
|
+ the reservation was made, the server will propose a different address.</para>
|
|
|
+
|
|
|
+ <para>This recovery mechanism allows the server to fully recover from a
|
|
|
+ case where reservations conflict with existing leases. This procedure
|
|
|
+ takes time and will roughly take as long as renew-timer value specified.
|
|
|
+ The best way to avoid such recovery is to not define new reservations that
|
|
|
+ conflict with existing leases. Another recommendation is to use
|
|
|
+ out-of-pool reservations. If the reserved address does not belong to a
|
|
|
+ pool, there is no way that other clients could get this address (note that
|
|
|
+ having multiple reservations for the same address is not allowed).
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section id="reservation6-hostname">
|
|
|
+ <title>Reserving a hostname</title>
|
|
|
+ <!-- @todo: replace this with the actual text once #3689 is implemented -->
|
|
|
+ <para>Reserving a hostname is currently not supported. It is possible
|
|
|
+ to specify that information in the configuration file, but that data
|
|
|
+ is not used by the server engine yet.</para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section id="reservation6-options">
|
|
|
+ <title>Reserving specific options</title>
|
|
|
+ <!-- @todo: replace this with the actual text once #3573 is implemented -->
|
|
|
+ <para>Currently it is not possible to specify options in host
|
|
|
+ reservation. Such a feature will be added in the upcoming Kea
|
|
|
+ releases.</para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <!-- @todo: add support for per IA reservation (that specifies IAID in
|
|
|
+ the ip-addresses and prefixes) -->
|
|
|
+ </section>
|
|
|
+ <!-- end of host reservations section -->
|
|
|
+
|
|
|
<section id="dhcp6-serverid">
|
|
|
<title>Server Identifier in DHCPv6</title>
|
|
|
<para>The DHCPv6 protocol uses a "server identifier" (also known
|
Tomek Mrugalski