|
|
@@ -1950,6 +1950,171 @@ temporarily override a list of interface names and listen on all interfaces.
|
|
|
</screen>
|
|
|
</section>
|
|
|
|
|
|
+ <section id="dhcp4-match-client-id">
|
|
|
+ <title>Using Client Identifier and Hardware Address</title>
|
|
|
+ <para>DHCP server must be able to identify the client (distinguish it from
|
|
|
+ other clients) from which it receives the message. There are many reasons
|
|
|
+ why this identification is required and the most important ones are listed
|
|
|
+ below.
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem><simpara>When the client contacts the server to allocate a new
|
|
|
+ lease, the server must store the client identification information in
|
|
|
+ the lease database as a search key.</simpara></listitem>
|
|
|
+ <listitem><simpara>When the client is trying to renew or release the existing
|
|
|
+ lease, the server must be able to find the existing lease entry in the
|
|
|
+ database for this client, using the client identification information as a
|
|
|
+ search key.</simpara></listitem>
|
|
|
+ <listitem><simpara>Some configurations use static reservations for the IP
|
|
|
+ addreses and other configuration information. The server's administrator
|
|
|
+ uses client identification information to create these static assignments.
|
|
|
+ </simpara></listitem>
|
|
|
+ <listitem><simpara>In the dual stack networks there is often a need to
|
|
|
+ correlate the lease information stored in DHCPv4 and DHCPv6 server for
|
|
|
+ a particular host. Using common identification information by the DHCPv4
|
|
|
+ and DHCPv6 client allows the network administrator to achieve this
|
|
|
+ correlation and better administer the network.</simpara></listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>The DHCPv4 makes use of two distinct identifiers which are placed
|
|
|
+ by the client in the queries sent to the server and copied by the server
|
|
|
+ to its responses to the client: 'chaddr' and 'client identifier'. The
|
|
|
+ former was introduced as a part of the BOOTP specification and it is also
|
|
|
+ used by DHCP to carry the hardware address of the interface used to send
|
|
|
+ the query to the server (MAC address for the Ethernet). The latter is
|
|
|
+ carried in the Client-identifier option, introduced in the
|
|
|
+ <ulink url="http://tools.ietf.org/html/rfc2132">RFC 2132</ulink>.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>The <ulink url="http://tools.ietf.org/html/rfc2131">RFC 2131</ulink>
|
|
|
+ indicates that the server may use both of these identifiers to identify
|
|
|
+ the client but the 'client identifier', if present, takes precedence
|
|
|
+ over 'chaddr'. One of the reasons for this is that 'client identifier'
|
|
|
+ is independent from the hardware used by the client to communicate with
|
|
|
+ the server. For example, if the client obtained the lease using one
|
|
|
+ network card and then the network card is moved to another host, the
|
|
|
+ server will wrongly identify this host is the one which has obtained
|
|
|
+ the lease. Moreover, the
|
|
|
+ <ulink url="https://tools.ietf.org/html/rfc4361">RFC 4361</ulink> gives
|
|
|
+ the recommendation to use DUID
|
|
|
+ (see <ulink url="https://tools.ietf.org/html/rfc3315">DHCPv6 specification</ulink>)
|
|
|
+ carried as 'client identifier' when dual stack networks are in use,
|
|
|
+ to provide consistent identification information of the client, regardless
|
|
|
+ of the protocol type it is using. Kea adheres to these specifications and
|
|
|
+ the 'client identifier' by default takes precedence over the value carried
|
|
|
+ in 'chaddr' field when the server searches, creates, updates or removes
|
|
|
+ the client's lease.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>When the server receives DHCPDISCOVER or DHCPREQUEST message from the
|
|
|
+ client, it will try to find out if the client already has a lease in the
|
|
|
+ database and will hand out the existing lease rather than allocate
|
|
|
+ a new one. Each lease in the lease database is associated with the
|
|
|
+ 'client identifier' and/or 'chaddr'. The server will first use the
|
|
|
+ 'client identifer' (if present) to search the lease. If the lease is
|
|
|
+ found, the server will consider that this lease belongs to this client,
|
|
|
+ regardless if the current 'chaddr' and the 'chaddr' associated with
|
|
|
+ the lease match. This facilitates the scenario when the network card
|
|
|
+ on the client system has been replaced and thus the new MAC address
|
|
|
+ appears in the messages sent by the DHCP client. If the server fails
|
|
|
+ to find the lease using the 'client identifier' it will use the 'chaddr'
|
|
|
+ and will perform another lookup. If this lookup returns no result, the
|
|
|
+ client is considered to not have a lease and the new lease will
|
|
|
+ be created.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>A common problem reported by the network operators is that bogus
|
|
|
+ client implementations do not use stable client identifiers, e.g.
|
|
|
+ new 'client identifier' is generated every time when the client connects
|
|
|
+ to the network. Another well known case is when the client changes its
|
|
|
+ 'client identifier' during the multi-stage boot process (PXE). In those
|
|
|
+ cases, the MAC address of the client's interface remains stable and
|
|
|
+ using 'chaddr' field to identify the client guarantees that the
|
|
|
+ particular system is considered to be the same client, even though its
|
|
|
+ 'client identifier' gets changed.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>To address this problem Kea includes a configuration option
|
|
|
+ which enables client identification using 'chaddr' and causes the
|
|
|
+ server to "ignore" the 'client identifier' during the lease lookup
|
|
|
+ and allocation for a particular subnet. Consider the following
|
|
|
+ simplified server configuration:</para>
|
|
|
+<screen>
|
|
|
+"Dhcp4": {
|
|
|
+ ...
|
|
|
+ <userinput>"match-client-id": true,</userinput>
|
|
|
+ ...
|
|
|
+ "subnet4": [
|
|
|
+ {
|
|
|
+ "subnet": "192.0.10.0/24",
|
|
|
+ "pools": [ { "pool": "192.0.2.23-192.0.2.87" } ],
|
|
|
+ <userinput>"match-client-id": false</userinput>
|
|
|
+ },
|
|
|
+ {
|
|
|
+ "subnet": "10.0.0.0/8",
|
|
|
+ "pools": [ { "pool": "10.0.0.23-10.0.2.99" } ],
|
|
|
+ }
|
|
|
+ ]
|
|
|
+}
|
|
|
+</screen>
|
|
|
+
|
|
|
+ <para>The <command>match-client-id</command> is a boolean value which
|
|
|
+ controls this behavior. The default value of <userinput>true</userinput>
|
|
|
+ indicates that the server will use the 'client identifier' for lease
|
|
|
+ lookups and 'chaddr' if the first lookup returns no results. The
|
|
|
+ <command>false</command> means that the server will only
|
|
|
+ use the 'chaddr' to search for client's lease. Whether the DHCID for
|
|
|
+ DNS updates is generated from the 'client identifier' or 'chaddr' is
|
|
|
+ controlled through the same parameter accordingly.</para>
|
|
|
+
|
|
|
+ <para>The <command>match-client-id</command> parameter may appear
|
|
|
+ both in the global configuration scope and/or under any subnet
|
|
|
+ declaration. In the example shown above, the effective value of the
|
|
|
+ <command>match-client-id</command> will be <userinput>false</userinput>
|
|
|
+ for the subnet 192.0.10.0/24, because the subnet specific setting
|
|
|
+ of the parameter overrides the global value of the parameter. The
|
|
|
+ effective value of the <command>match-client-id</command> for the subnet
|
|
|
+ 10.0.0.0/8 will be set to <userinput>true</userinput> because the
|
|
|
+ subnet declaration lacks this parameter and the global setting is
|
|
|
+ by default used for this subnet. In fact, the global entry for this
|
|
|
+ parameter could be omitted in this case, because
|
|
|
+ <userinput>true</userinput> is the default value.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>It is important to explain what happens when the client obtains
|
|
|
+ its lease for one setting of the <command>match-client-id</command>
|
|
|
+ and then renews when the setting has been changed. Let's first consider
|
|
|
+ the case when the client obtains the lease when the
|
|
|
+ <command>match-client-id</command> is set to <userinput>true</userinput>.
|
|
|
+ The server will store the lease information including 'client identifier'
|
|
|
+ (if supplied) and 'chaddr' in the lease database. When the setting is
|
|
|
+ changed and the client renews the lease the server will determine that
|
|
|
+ it should use the 'chaddr' to search for the existing lease. If the
|
|
|
+ clien't hasn't changed its MAC address the server should successfully
|
|
|
+ find the existing lease. The 'client identifier' associated with the
|
|
|
+ returned lease is ignored and the client is allowed to use this lease.
|
|
|
+ When the lease is renewed only the 'chaddr' is recorded for this
|
|
|
+ lease according to the new server setting.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>In the second case the client has the lease with only a 'chaddr'
|
|
|
+ value recorded. When the setting is changed to
|
|
|
+ <command>match-client-id</command> set to <userinput>true</userinput>
|
|
|
+ the server will first try to use the 'client identifier' to find the
|
|
|
+ existing client's lease. This will return no results because the
|
|
|
+ 'client identifier' was not recorded for this lease. The server will
|
|
|
+ then use the 'chaddr' and the lease will be successfully found. If the
|
|
|
+ lease appears to have no 'client identifier' recorded, the server will
|
|
|
+ assume that this lease belongs to the client and that it was created
|
|
|
+ with the previous setting of the <command>match-client-id</command>.
|
|
|
+ However, if the lease contains 'client identifier' which is different
|
|
|
+ from the 'client identifier' used by the client the lease will be
|
|
|
+ assumed to belong to another client and the new lease will be
|
|
|
+ allocated.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
</section> <!-- end of configuring kea-dhcp4 server section with many subsections -->
|
|
|
|
|
|
<!-- Host reservation is a large topic. There will be many subsections,
|
Marcin Siodelski