@section parserIntro Parser background
-Kea's data format of choice is JSON (defined in https://tools.ietf.org/html/rfc7159), which is used
+Kea's data format of choice is JSON (defined in https://datatracker.ietf.org/doc/html/rfc7159), which is used
in configuration files, in the command channel and also when communicating between the DHCP servers
and the DHCP-DDNS component. It is almost certain to be used as the data format for any new
features.
- "Vendor option" means the Vendor-Identifying Vendor-Specific Information
option in DHCPv4 (code 125; see `Section 4 of RFC
- 3925 <https://tools.ietf.org/html/rfc3925#section-4>`__) and the
+ 3925 <https://datatracker.ietf.org/doc/html/rfc3925#section-4>`__) and the
Vendor-Specific Information Option in DHCPv6 (code 17, defined in
`Section 21.17 of RFC
- 8415 <https://tools.ietf.org/html/rfc8415#section-21.17>`__). "Vendor
+ 8415 <https://datatracker.ietf.org/doc/html/rfc8415#section-21.17>`__). "Vendor
class option" means the Vendor-Identifying Vendor Class Option in DHCPv4
(code 124; see `Section 3 of RFC
- 3925 <https://tools.ietf.org/html/rfc3925#section-3>`__) in DHCPv4 and
+ 3925 <https://datatracker.ietf.org/doc/html/rfc3925#section-3>`__) in DHCPv4 and
the Class Option in DHCPv6 (code 16; see `Section 21.16 of RFC
- 8415 <https://tools.ietf.org/html/rfc8415#section-21.16>`__). Vendor
+ 8415 <https://datatracker.ietf.org/doc/html/rfc8415#section-21.16>`__). Vendor
options may have sub-options that are referenced by their codes.
Vendor class options do not have sub-options, but rather data chunks,
which are referenced by index value. Index 0 means the first data
- Vendor Class Identifier (option 60 in DHCPv4) can be accessed using the
option[60] expression.
-- `RFC 3925 <https://tools.ietf.org/html/rfc3925>`__ and `RFC
- 8415 <https://tools.ietf.org/html/rfc8415>`__ allow for multiple
+- `RFC 3925 <https://datatracker.ietf.org/doc/html/rfc3925>`__ and `RFC
+ 8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__ allow for multiple
instances of vendor options to appear in a single message. The client
classification code currently examines the first instance if more
than one appear. For the ``vendor.enterprise`` and ``vendor-class.enterprise``
Configuration files for the DHCPv4, DHCPv6, DDNS, Control Agent, and
NETCONF modules are defined in an extended JSON format. Basic JSON is
-defined in `RFC 7159 <https://tools.ietf.org/html/rfc7159>`__ and `ECMA
+defined in `RFC 7159 <https://datatracker.ietf.org/doc/html/rfc7159>`__ and `ECMA
404 <https://www.ecma-international.org/publications/standards/Ecma-404.htm>`__.
In particular, the only boolean values allowed are true or false (all
lowercase). The capitalized versions (True or False) are not accepted.
The DHCP-DDNS Server (:iscman:`kea-dhcp-ddns`, known informally as D2) conducts
the client side of the Dynamic DNS protocol (DDNS, defined in `RFC
-2136 <https://tools.ietf.org/html/rfc2136>`__) on behalf of the DHCPv4
+2136 <https://datatracker.ietf.org/doc/html/rfc2136>`__) on behalf of the DHCPv4
and DHCPv6 servers (:iscman:`kea-dhcp4` and :iscman:`kea-dhcp6`, respectively).
The DHCP servers construct DDNS update requests, known as NameChangeRequests
(NCRs), based on DHCP lease change events and then post them to D2. D2
-------------------
D2 implements the conflict resolution strategy prescribed by `RFC
-4703 <https://tools.ietf.org/html/rfc4703>`__. Conflict resolution is
+4703 <https://datatracker.ietf.org/doc/html/rfc4703>`__. Conflict resolution is
intended to prevent different clients from mapping to the same FQDN at
the same time. To make this possible, the RFC requires that forward DNS
entries for a given FQDN must be accompanied by a DHCID resource record
-----------------------
`RFC 4703, section
-5.2, <https://tools.ietf.org/html/rfc4703#section-5.2>`__ describes
+5.2, <https://datatracker.ietf.org/doc/html/rfc4703#section-5.2>`__ describes
issues that may arise with dual-stack clients. These are clients that
wish to have both IPv4 and IPv6 mappings for the same FQDN.
To work properly, clients must embed their IPv6 DUID
within their IPv4 client identifier option, as described in `RFC
-4361 <https://tools.ietf.org/html/rfc4361>`__. In this way, DNS updates
+4361 <https://datatracker.ietf.org/doc/html/rfc4361>`__. In this way, DNS updates
for both IPv4 and IPv6 can be managed under the same DHCID RR. This feature
is supported by Kea beginning with release 2.1.2.
A DDNS protocol exchange can be conducted with or without a transaction
signature, or TSIG (defined
-in `RFC 2845 <https://tools.ietf.org/html/rfc2845>`__). This
+in `RFC 2845 <https://datatracker.ietf.org/doc/html/rfc2845>`__). This
configuration section allows the administrator to define the set of TSIG
keys that may be used in such exchanges.
The following RFCs are supported by the DHCP-DDNS server:
- *Secret Key Transaction Authentication for DNS (TSIG)*, `RFC 2845
- <https://tools.ietf.org/html/rfc2845>`__: All DNS update packets sent and
+ <https://datatracker.ietf.org/doc/html/rfc2845>`__: All DNS update packets sent and
received by the DHCP-DDNS server can be protected by TSIG signatures.
- *Dynamic Updates in the Domain Name System (DNS UPDATE)*, `RFC 2136
- <https://tools.ietf.org/html/rfc2136>`__: The complete DNS update mechanism is
+ <https://datatracker.ietf.org/doc/html/rfc2136>`__: The complete DNS update mechanism is
supported.
- *Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host
Configuration Protocol (DHCP) Clients*, `RFC 4703
- <https://tools.ietf.org/html/rfc4703>`__: DHCP-DDNS takes care of
+ <https://datatracker.ietf.org/doc/html/rfc4703>`__: DHCP-DDNS takes care of
conflict resolution, for both DHCPv4 and DHCPv6 servers.
- *A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol
(DHCP) Information (DHCID RR)*, `RFC 4701
- <https://tools.ietf.org/html/rfc4701>`__: The DHCP-DDNS server uses DHCID
+ <https://datatracker.ietf.org/doc/html/rfc4701>`__: The DHCP-DDNS server uses DHCID
records.
only sends ``renew-timer``, via DHCPv4 option code 58, if it is less
than ``rebind-timer`` (or ``valid-lifetime`` if ``rebind-timer`` was not
specified). In their absence, the client should select values for T1
- and T2 timers according to `RFC 2131 <https://tools.ietf.org/html/rfc2131>`_.
+ and T2 timers according to `RFC 2131 <https://datatracker.ietf.org/doc/html/rfc2131>`_.
See section :ref:`dhcp4-t1-t2-times`
for more details on generating T1 and T2.
In this section we focus on the case when the server receives the
DHCPINFORM message from the client via a relay. According to `RFC
-2131 <https://tools.ietf.org/html/rfc2131>`__, the server should unicast
+2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__, the server should unicast
the DHCPACK response to the address carried in the ``ciaddr`` field. When
the UDP socket is in use, the DHCP server relies on the low-level
functions of an operating system to build the data link, IP, and UDP
Sending T1 (Option 58) and T2 (Option 59)
-----------------------------------------
-According to `RFC 2131 <https://tools.ietf.org/html/rfc2131>`__,
+According to `RFC 2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__,
servers should send values for T1 and T2 that are 50% and 87.5% of the
lease lifetime, respectively. By default, :iscman:`kea-dhcp4` does not send
either value; it can be configured to send values that are either specified
.. note::
The ``default-url`` option was replaced with ``v4-captive-portal`` in Kea 2.1.2, as introduced by
- `RFC 8910 <https://tools.ietf.org/html/rfc8910>`_. The new option has exactly the same format as the
+ `RFC 8910 <https://datatracker.ietf.org/doc/html/rfc8910>`_. The new option has exactly the same format as the
old one. The general perception is that ``default-url`` was seldom used. Migrating users should
replace ``default-url`` with ``v4-captive-portal`` in their configurations.
.. table:: List of standard DHCP option types
- +-----------------+-------------------------------------------------------+
- | Name | Meaning |
- +=================+=======================================================+
- | binary | An arbitrary string of bytes, specified as a set |
- | | of hexadecimal digits. |
- +-----------------+-------------------------------------------------------+
- | boolean | A boolean value with allowed |
- | | values true or false. |
- +-----------------+-------------------------------------------------------+
- | empty | No value; data is carried in |
- | | sub-options. |
- +-----------------+-------------------------------------------------------+
- | fqdn | Fully qualified domain name (e.g. |
- | | www.example.com). |
- +-----------------+-------------------------------------------------------+
- | ipv4-address | IPv4 address in the usual |
- | | dotted-decimal notation (e.g. |
- | | 192.0.2.1). |
- +-----------------+-------------------------------------------------------+
- | ipv6-address | IPv6 address in the usual colon |
- | | notation (e.g. 2001:db8::1). |
- +-----------------+-------------------------------------------------------+
- | ipv6-prefix | IPv6 prefix and prefix length |
- | | specified using CIDR notation, |
- | | e.g. 2001:db8:1::/64. This data |
- | | type is used to represent an |
- | | 8-bit field conveying a prefix |
- | | length and the variable length |
- | | prefix value. |
- +-----------------+-------------------------------------------------------+
- | psid | PSID and PSID length separated by |
- | | a slash, e.g. 3/4 specifies |
- | | PSID=3 and PSID length=4. In the |
- | | wire format it is represented by |
- | | an 8-bit field carrying PSID |
- | | length (in this case equal to 4) |
- | | and the 16-bits-long PSID value |
- | | field (in this case equal to |
- | | "0011000000000000b" using binary |
- | | notation). Allowed values for a |
- | | PSID length are 0 to 16. See `RFC |
- | | 7597 <https://tools.ietf.org/html/rfc7597>`__ |
- | | for details about the PSID wire |
- | | representation. |
- +-----------------+-------------------------------------------------------+
- | record | Structured data that may be |
- | | comprised of any types (except |
- | | "record" and "empty"). The array |
- | | flag applies to the last field |
- | | only. |
- +-----------------+-------------------------------------------------------+
- | string | Any text. Please note that Kea |
- | | silently discards any |
- | | terminating/trailing nulls from |
- | | the end of "string" options when |
- | | unpacking received packets. This |
- | | is in keeping with `RFC 2132, |
- | | Section |
- | | 2 <https://tools.ietf.org/html/rfc2132#section-2>`__. |
- +-----------------+-------------------------------------------------------+
- | tuple | A length field encoded as an 8-bit |
- | | or 16-bit unsigned integer followed by |
- | | a string of this length. Typically, for DHCPv4, |
- | | the length is 8-bit, and for DHCPv6, it is 16-bit. |
- | | However, there are exceptions to that rule. |
- | | E.g. for the DHCPv4 SZTP Redirect Option, |
- | | bootstrap-server-list is encoded as a list of |
- | | tuples where the URI-length in each tuple is |
- | | a 16-bit unsigned integer. |
- +-----------------+-------------------------------------------------------+
- | uint8 | An 8-bit unsigned integer with |
- | | allowed values 0 to 255. |
- +-----------------+-------------------------------------------------------+
- | uint16 | A 16-bit unsigned integer with |
- | | allowed values 0 to 65535. |
- +-----------------+-------------------------------------------------------+
- | uint32 | A 32-bit unsigned integer with |
- | | allowed values 0 to 4294967295. |
- +-----------------+-------------------------------------------------------+
- | int8 | An 8-bit signed integer with allowed |
- | | values -128 to 127. |
- +-----------------+-------------------------------------------------------+
- | int16 | A 16-bit signed integer with |
- | | allowed values -32768 to 32767. |
- +-----------------+-------------------------------------------------------+
- | int32 | A 32-bit signed integer with |
- | | allowed values -2147483648 to |
- | | 2147483647. |
- +-----------------+-------------------------------------------------------+
+ +-----------------+---------------------------------------------------------------+
+ | Name | Meaning |
+ +=================+===============================================================+
+ | binary | An arbitrary string of bytes, specified as a set |
+ | | of hexadecimal digits. |
+ +-----------------+---------------------------------------------------------------+
+ | boolean | A boolean value with allowed |
+ | | values true or false. |
+ +-----------------+---------------------------------------------------------------+
+ | empty | No value; data is carried in |
+ | | sub-options. |
+ +-----------------+---------------------------------------------------------------+
+ | fqdn | Fully qualified domain name (e.g. |
+ | | www.example.com). |
+ +-----------------+---------------------------------------------------------------+
+ | ipv4-address | IPv4 address in the usual |
+ | | dotted-decimal notation (e.g. |
+ | | 192.0.2.1). |
+ +-----------------+---------------------------------------------------------------+
+ | ipv6-address | IPv6 address in the usual colon |
+ | | notation (e.g. 2001:db8::1). |
+ +-----------------+---------------------------------------------------------------+
+ | ipv6-prefix | IPv6 prefix and prefix length |
+ | | specified using CIDR notation, |
+ | | e.g. 2001:db8:1::/64. This data |
+ | | type is used to represent an |
+ | | 8-bit field conveying a prefix |
+ | | length and the variable length |
+ | | prefix value. |
+ +-----------------+---------------------------------------------------------------+
+ | psid | PSID and PSID length separated by |
+ | | a slash, e.g. 3/4 specifies |
+ | | PSID=3 and PSID length=4. In the |
+ | | wire format it is represented by |
+ | | an 8-bit field carrying PSID |
+ | | length (in this case equal to 4) |
+ | | and the 16-bits-long PSID value |
+ | | field (in this case equal to |
+ | | "0011000000000000b" using binary |
+ | | notation). Allowed values for a |
+ | | PSID length are 0 to 16. See `RFC 7597 |
+ | | <https://datatracker.ietf.org/doc/html/rfc7597>`__ |
+ | | for details about the PSID wire |
+ | | representation. |
+ +-----------------+---------------------------------------------------------------+
+ | record | Structured data that may be |
+ | | comprised of any types (except |
+ | | "record" and "empty"). The array |
+ | | flag applies to the last field |
+ | | only. |
+ +-----------------+---------------------------------------------------------------+
+ | string | Any text. Please note that Kea |
+ | | silently discards any |
+ | | terminating/trailing nulls from |
+ | | the end of "string" options when |
+ | | unpacking received packets. This |
+ | | is in keeping with `RFC 2132, |
+ | | Section 2 |
+ | | <https://datatracker.ietf.org/doc/html/rfc2132#section-2>`__. |
+ +-----------------+---------------------------------------------------------------+
+ | tuple | A length field encoded as an 8-bit |
+ | | or 16-bit unsigned integer followed by |
+ | | a string of this length. Typically, for DHCPv4, |
+ | | the length is 8-bit, and for DHCPv6, it is 16-bit. |
+ | | However, there are exceptions to that rule. |
+ | | E.g. for the DHCPv4 SZTP Redirect Option, |
+ | | bootstrap-server-list is encoded as a list of |
+ | | tuples where the URI-length in each tuple is |
+ | | a 16-bit unsigned integer. |
+ +-----------------+---------------------------------------------------------------+
+ | uint8 | An 8-bit unsigned integer with |
+ | | allowed values 0 to 255. |
+ +-----------------+---------------------------------------------------------------+
+ | uint16 | A 16-bit unsigned integer with |
+ | | allowed values 0 to 65535. |
+ +-----------------+---------------------------------------------------------------+
+ | uint32 | A 32-bit unsigned integer with |
+ | | allowed values 0 to 4294967295. |
+ +-----------------+---------------------------------------------------------------+
+ | int8 | An 8-bit signed integer with allowed |
+ | | values -128 to 127. |
+ +-----------------+---------------------------------------------------------------+
+ | int16 | A 16-bit signed integer with |
+ | | allowed values -32768 to 32767. |
+ +-----------------+---------------------------------------------------------------+
+ | int32 | A 32-bit signed integer with |
+ | | allowed values -2147483648 to |
+ | | 2147483647. |
+ +-----------------+---------------------------------------------------------------+
Kea also supports the Relay Agent Information (RAI, defined in
-`RFC 3046 <https://tools.ietf.org/html/rfc3046>`_) option, sometimes referred to as the relay option, agent
+`RFC 3046 <https://datatracker.ietf.org/doc/html/rfc3046>`_) option, sometimes referred to as the relay option, agent
option, or simply option 82. The option itself is just a container and does not convey any information
on its own. The following table contains a list of RAI sub-options that Kea can understand. The RAI
and its sub-options are inserted by the relay agent and received by Kea; there is no need for Kea
+------------------------+------+-----------------------------+
These suboptions are defined in
-`RFC 3495 <https://tools.ietf.org/html/rfc3495>`_ including its errata
+`RFC 3495 <https://datatracker.ietf.org/doc/html/rfc3495>`_ including its errata
which clarifies the realm format,
-`RFC 3594 <https://tools.ietf.org/html/rfc3594>`_ and
-`RFC 3634 <https://tools.ietf.org/html/rfc3634>`_.
+`RFC 3594 <https://datatracker.ietf.org/doc/html/rfc3594>`_ and
+`RFC 3634 <https://datatracker.ietf.org/doc/html/rfc3634>`_.
.. note::
By default, in the Vendor-Specific Information option (code 43),
sub-option code 0 and 255 mean PAD and END respectively, according to
- `RFC 2132 <https://tools.ietf.org/html/rfc2132>`_. In other words, the
+ `RFC 2132 <https://datatracker.ietf.org/doc/html/rfc2132>`_. In other words, the
sub-option code values of 0 and 255 are reserved. Kea does, however,
allow users to define sub-option codes from 0 to 255. If
sub-options with codes 0 and/or 255 are defined, bytes with that value are
--------------------------------------
The ``v6-only-preferred`` (code 108) option is handled in a specific
-way described in `RFC 8925 <https://tools.ietf.org/html/rfc8925>`_
+way described in `RFC 8925 <https://datatracker.ietf.org/doc/html/rfc8925>`_
by :iscman:`kea-dhcp4` when it is configured in a subnet or a
shared network: when the client requests the option (i.e. puts
the 108 code in the DHCP parameter request list option) and
example checks whether the client identifies itself as a PXE device with
architecture EFI x86-64, and sets several fields if it does. See
`Section 2.1 of RFC
-4578 <https://tools.ietf.org/html/rfc4578#section-2.1>`__) or the
+4578 <https://datatracker.ietf.org/doc/html/rfc4578#section-2.1>`__) or the
client documentation for specific values.
::
The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. This
boolean parameter was passed through to D2 and enabled or disabled conflict resolution
-as described in `RFC 4703 <https://tools.ietf.org/html/rfc4703>`__. Beginning with
+as described in `RFC 4703 <https://datatracker.ietf.org/doc/html/rfc4703>`__. Beginning with
Kea 2.5.0, it is deprecated and replaced by ``ddns-conflict-resolution-mode``, which
offers four modes of conflict resolution-related behavior:
Setting ``ddns-conflict-resolution-mode`` to any value other than
``check-with-dhcid`` disables the overwrite safeguards
that the rules of conflict resolution (from
- `RFC 4703 <https://tools.ietf.org/html/rfc4703>`__) are intended to
+ `RFC 4703 <https://datatracker.ietf.org/doc/html/rfc4703>`__) are intended to
prevent. This means that existing entries for an FQDN or an
IP address made for Client-A can be deleted or replaced by entries
for Client-B. Furthermore, there are two scenarios by which entries
The DNS entries Kea creates contain a value for TTL (time to live).
By default, the :iscman:`kea-dhcp4` server calculates that value based on
-`RFC 4702, Section 5 <https://tools.ietf.org/html/rfc4702#section-5>`__,
+`RFC 4702, Section 5 <https://datatracker.ietf.org/doc/html/rfc4702#section-5>`__,
which suggests that the TTL value be 1/3 of the lease's lifetime, with
a minimum value of 10 minutes. There are four optional parameters which
may be used to influence the TTL calculation:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :iscman:`kea-dhcp4` server follows the behavior prescribed for DHCP servers in
-`RFC 4702 <https://tools.ietf.org/html/rfc4702>`__. It is important to keep
+`RFC 4702 <https://datatracker.ietf.org/doc/html/rfc4702>`__. It is important to keep
in mind that :iscman:`kea-dhcp4` makes the initial decision of when and what to
update and forwards that information to D2 in the form of NCRs. Carrying
out the actual DNS updates and dealing with such things as conflict
respectively.
(Note that the flag combination N=1, S=1 is prohibited according to `RFC
-4702 <https://tools.ietf.org/html/rfc4702>`__. If such a combination is
+4702 <https://datatracker.ietf.org/doc/html/rfc4702>`__. If such a combination is
received from the client, the packet is dropped by :iscman:`kea-dhcp4`.)
To override client delegation, set the following values in the
----------------------------
The original DHCPv4 specification (`RFC
-2131 <https://tools.ietf.org/html/rfc2131>`__) states that the DHCPv4
+2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__) states that the DHCPv4
server must not send back client-id options when responding to clients.
However, in some cases that results in confused clients that do not have a MAC
address or client-id; see `RFC
-6842 <https://tools.ietf.org/html/rfc6842>`__ for details. That behavior
+6842 <https://datatracker.ietf.org/doc/html/rfc6842>`__ for details. That behavior
changed with the publication of `RFC
-6842 <https://tools.ietf.org/html/rfc6842>`__, which updated `RFC
-2131 <https://tools.ietf.org/html/rfc2131>`__. That update states that
+6842 <https://datatracker.ietf.org/doc/html/rfc6842>`__, which updated `RFC
+2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__. That update states that
the server must send the client-id if the client sent it, and that is Kea's
default behavior. However, in some cases older devices that do not
-support `RFC 6842 <https://tools.ietf.org/html/rfc6842>`__ may refuse to
+support `RFC 6842 <https://datatracker.ietf.org/doc/html/rfc6842>`__ may refuse to
accept responses that include the client-id option. To enable backward
compatibility, an optional configuration parameter has been introduced.
To configure it, use the following configuration statement:
correlation and better administer the network. Beginning with
release 2.1.2, Kea supports DHCPv6 DUIDs embedded within DHCPv4
Client Identifier options as described in
- `RFC 4361 <https://tools.ietf.org/html/rfc4361>`__.
+ `RFC 4361 <https://datatracker.ietf.org/doc/html/rfc4361>`__.
DHCPv4 uses two distinct identifiers which are placed by the client in
the queries sent to the server and copied by the server to its responses
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 `RFC
-2132 <https://tools.ietf.org/html/rfc2132>`__.
+2132 <https://datatracker.ietf.org/doc/html/rfc2132>`__.
-`RFC 2131 <https://tools.ietf.org/html/rfc2131>`__ indicates that the
+`RFC 2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__ 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 the client identifier is independent from the
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 as the one which obtained the lease. Moreover, `RFC
-4361 <https://tools.ietf.org/html/rfc4361>`__ gives the recommendation
-to use a DUID (see `RFC 8415 <https://tools.ietf.org/html/rfc8415>`__,
+4361 <https://datatracker.ietf.org/doc/html/rfc4361>`__ gives the recommendation
+to use a DUID (see `RFC 8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__,
the DHCPv6 specification) carried as a client identifier when dual-stack
networks are in use to provide consistent identification information for
the client, regardless of the type of protocol it is using. Kea adheres to
------------------------------------
The original DHCPv4 specification (`RFC
-2131 <https://tools.ietf.org/html/rfc2131>`__) states that if a client
+2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__) states that if a client
requests an address in the INIT-REBOOT state of which the server has no
knowledge, the server must remain silent, except if the server knows
that the client has requested an IP address from the wrong network. By
-------------------------------
The support of DHCPv4-over-DHCPv6 transport is described in `RFC
-7341 <https://tools.ietf.org/html/rfc7341>`__ and is implemented using
+7341 <https://datatracker.ietf.org/doc/html/rfc7341>`__ and is implemented using
cooperating DHCPv4 and DHCPv6 servers. This section is about the
configuration of the DHCPv4 side (the DHCPv6 side is described in
:ref:`dhcp6-dhcp4o6-config`).
----------------------------------
To support such features as DHCP Leasequery
-(`RFC 4388 <https://tools.ietf.org/html/rfc4388>`__) and
+(`RFC 4388 <https://datatracker.ietf.org/doc/html/rfc4388>`__) and
stash agent options (:ref:`stash-agent-options`),
additional information must be stored with each lease. Because the amount
of information for each lease has ramifications in terms of
IPv6-Only Preferred Networks
----------------------------
-`RFC 8925 <https://tools.ietf.org/html/rfc8925>`_, recently published by the IETF,
+`RFC 8925 <https://datatracker.ietf.org/doc/html/rfc8925>`_, recently published by the IETF,
specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to
forgo obtaining an IPv4 address if the network provides IPv6 connectivity. The general idea is that
a network administrator can enable this option to signal to compatible dual-stack devices that
------------------------------------------------------------------
The Discovery of Network-designated Resolvers, or DNR option, was
-introduced in `RFC 9463 <https://tools.ietf.org/html/rfc9463>`__ as
+introduced in `RFC 9463 <https://datatracker.ietf.org/doc/html/rfc9463>`__ as
a way to communicate location of DNS resolvers available over means other than
the classic DNS over UDP over port 53. As of spring 2024, the supported technologies
are DoT (DNS-over-TLS), DoH (DNS-over-HTTPS), and DoQ (DNS-over-QUIC), but the option was
The following standards are currently supported in Kea:
- *BOOTP Vendor Information Extensions*, `RFC 1497
- <https://tools.ietf.org/html/rfc1497>`__: This requires the open source
+ <https://datatracker.ietf.org/doc/html/rfc1497>`__: This requires the open source
BOOTP hook to be loaded. See :ref:`hooks-bootp` for details.
- *Dynamic Host Configuration Protocol*, `RFC 1531
- <https://tools.ietf.org/html/rfc1531>`__: This RFC is obsolete and
+ <https://datatracker.ietf.org/doc/html/rfc1531>`__: This RFC is obsolete and
was replaced by RFC 1541, which in turn was replaced by RFC 2131.
Kea supports all three RFCs.
- *Clarifications and Extensions for the Bootstrap Protocol*, `RFC 1532
- <https://tools.ietf.org/html/rfc1532>`__: This RFC has an editorial
+ <https://datatracker.ietf.org/doc/html/rfc1532>`__: This RFC has an editorial
error and was quickly superseeded by RFC 1542. Kea supports them both.
- *DHCP Options and BOOTP Vendor Extensions*, `RFC 1533
- <https://tools.ietf.org/html/rfc1533>`__: This RFC is obsolete and
+ <https://datatracker.ietf.org/doc/html/rfc1533>`__: This RFC is obsolete and
was replaced by RFC 2132. Nevertheless, Kea supports the options
defined in it.
- *Dynamic Host Configuration Protocol*, `RFC 1541
- <https://tools.ietf.org/html/rfc1541>`__: This RFC is obsolete and
+ <https://datatracker.ietf.org/doc/html/rfc1541>`__: This RFC is obsolete and
was replaced by RFC 2131. Kea supports both.
- *Clarifications and Extensions for the Bootstrap Protocol*, `RFC 1542
- <https://tools.ietf.org/html/rfc1542>`__: This RFC is supported.
+ <https://datatracker.ietf.org/doc/html/rfc1542>`__: This RFC is supported.
- *Dynamic Host Configuration Protocol*, `RFC 2131
- <https://tools.ietf.org/html/rfc2131>`__: Supported messages are
+ <https://datatracker.ietf.org/doc/html/rfc2131>`__: Supported messages are
DHCPDISCOVER (1), DHCPOFFER (2), DHCPREQUEST (3), DHCPRELEASE (7),
DHCPINFORM (8), DHCPACK (5), and DHCPNAK(6).
- *DHCP Options and BOOTP Vendor Extensions*, `RFC 2132
- <https://tools.ietf.org/html/rfc2132>`__: Supported options are PAD (0),
+ <https://datatracker.ietf.org/doc/html/rfc2132>`__: Supported options are PAD (0),
END(255), Message Type(53), DHCP Server Identifier (54), Domain Name (15),
DNS Servers (6), IP Address Lease Time (51), Subnet Mask (1), and Routers (3).
- *DHCP Options for Novell Directory Services*, `RFC 2241
- <https://tools.ietf.org/html/rfc2241>`__: All three options are supported.
+ <https://datatracker.ietf.org/doc/html/rfc2241>`__: All three options are supported.
- *Management of IP numbers by peg-dhcp*,
- `RFC 2322 <https://tools.ietf.org/html/rfc2322>`__: This RFC is supported,
+ `RFC 2322 <https://datatracker.ietf.org/doc/html/rfc2322>`__: This RFC is supported,
although additional hardware is required for full deployment.
- *DHCP Option for The Open Group's User Authentication Protocol*,
- `RFC 2485 <https://tools.ietf.org/html/rfc2485>`__: The option is supported.
+ `RFC 2485 <https://datatracker.ietf.org/doc/html/rfc2485>`__: The option is supported.
- *DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients*,
- `RFC 2563 <https://tools.ietf.org/html/rfc2563>`__: The option is supported.
+ `RFC 2563 <https://datatracker.ietf.org/doc/html/rfc2563>`__: The option is supported.
- *DHCP Options for Service Location Protocol*, `RFC 2610
- <https://tools.ietf.org/html/rfc2610>`__: Both options are supported.
+ <https://datatracker.ietf.org/doc/html/rfc2610>`__: Both options are supported.
- *The Name Service Search Option for DHCP*, `RFC 2937
- <https://tools.ietf.org/html/rfc2937>`__: The option is supported.
+ <https://datatracker.ietf.org/doc/html/rfc2937>`__: The option is supported.
-- *The User Class Option for DHCP*, `RFC 3004 <https://tools.ietf.org/html/rfc3004>`__:
+- *The User Class Option for DHCP*, `RFC 3004 <https://datatracker.ietf.org/doc/html/rfc3004>`__:
The user class is supported and can be used in any expression. The option's
structure is not parsed and has to be referenced using hex.
- *The IPv4 Subnet Selection Option for DHCP*, `RFC 3011
- <https://tools.ietf.org/html/rfc3011>`__: The subnet-selection option is
+ <https://datatracker.ietf.org/doc/html/rfc3011>`__: The subnet-selection option is
supported; if received in a packet, it is used in the subnet-selection
process.
- *DHCP Relay Agent Information Option*, `RFC 3046
- <https://tools.ietf.org/html/rfc3046>`__: Relay Agent Information,
+ <https://datatracker.ietf.org/doc/html/rfc3046>`__: Relay Agent Information,
Circuit ID, and Remote ID options are supported.
- *The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class
DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option*,
- `RFC 3256 <https://tools.ietf.org/html/rfc3256>`__: The DOCSIS sub-option
+ `RFC 3256 <https://datatracker.ietf.org/doc/html/rfc3256>`__: The DOCSIS sub-option
is supported and can be used in any expression.
- *Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)*,
- `RFC 3396 <https://tools.ietf.org/html/rfc3396>`__: The Kea server can both
+ `RFC 3396 <https://datatracker.ietf.org/doc/html/rfc3396>`__: The Kea server can both
receive and send long options. The long options can be configured and Kea
will send them as separate instances if the payload length is longer than
255 octets.
- *Dynamic Host Configuration Protocol (DHCP) Domain Search Option*, `RFC 3397
- <https://tools.ietf.org/html/rfc3397>`__: The option is supported.
+ <https://datatracker.ietf.org/doc/html/rfc3397>`__: The option is supported.
- *The Classless Static Route Option for Dynamic Host Configuration Protocol
- (DHCP) version 4*, `RFC 3442 <https://tools.ietf.org/html/rfc3442>`__:
+ (DHCP) version 4*, `RFC 3442 <https://datatracker.ietf.org/doc/html/rfc3442>`__:
The option is supported.
- *Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client
- Configuration*, `RFC 3495 <https://tools.ietf.org/html/rfc3495>`__:
+ Configuration*, `RFC 3495 <https://datatracker.ietf.org/doc/html/rfc3495>`__:
The option and its suboptions 1, 2, 4, 5, 6, 7 and 8 are supported.
See :ref:`cablelabs-client-conf-suboptions` for details.
- *Link Selection sub-option for the Relay Agent Option*, `RFC 3527
- <https://tools.ietf.org/html/rfc3527>`__: The link selection sub-option
+ <https://datatracker.ietf.org/doc/html/rfc3527>`__: The link selection sub-option
is supported.
- *PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs
Client Configuration (CCC) Option*, `RFC 3594
- <https://tools.ietf.org/html/rfc3594>`__: The Security Ticket Control
+ <https://datatracker.ietf.org/doc/html/rfc3594>`__: The Security Ticket Control
sub-option is supported.
- *Key Distribution Center (KDC) Server Address Sub-option for the
Dynamic Host Configuration Protocol (DHCP) CableLabs Client
Configuration (CCC) Option*, `RFC 3634
- <https://tools.ietf.org/html/rfc3634>`__: The Key Distribution Center
+ <https://datatracker.ietf.org/doc/html/rfc3634>`__: The Key Distribution Center
IP Address sub-option is supported.
- *Unused Dynamic Host Configuration Protocol (DHCP) Option Codes*, `RFC 3679
- <https://tools.ietf.org/html/rfc3679>`__: Kea does not support any of the
+ <https://datatracker.ietf.org/doc/html/rfc3679>`__: Kea does not support any of the
old options that were obsoleted by this RFC.
- *Vendor-Identifying Vendor Options for Dynamic Host Configuration
Protocol version 4*, `RFC 3925
- <https://tools.ietf.org/html/rfc3925>`__: The Vendor-Identifying Vendor Class
+ <https://datatracker.ietf.org/doc/html/rfc3925>`__: The Vendor-Identifying Vendor Class
and Vendor-Identifying Vendor-Specific Information options are supported.
- *Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options*,
- `RFC 3942 <https://tools.ietf.org/html/rfc3942>`__: Kea supports options with
+ `RFC 3942 <https://datatracker.ietf.org/doc/html/rfc3942>`__: Kea supports options with
codes greater than 127.
- *Subscriber-ID Suboption for the DHCP Relay Agent Option*, `RFC 3993
- <https://tools.ietf.org/html/rfc3993>`__: The Subscriber-ID option is
+ <https://datatracker.ietf.org/doc/html/rfc3993>`__: The Subscriber-ID option is
supported.
- *Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast
- Control Servers*, `RFC 4280 <https://tools.ietf.org/html/rfc4280>`__:
+ Control Servers*, `RFC 4280 <https://datatracker.ietf.org/doc/html/rfc4280>`__:
The DHCPv4 options are supported.
- *Node-specific Client Identifiers for Dynamic Host Configuration Protocol
are supported.
- *A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol
- (DHCP) Information (DHCID RR)*, `RFC 4701 <https://tools.ietf.org/html/rfc4701>`__:
+ (DHCP) Information (DHCID RR)*, `RFC 4701 <https://datatracker.ietf.org/doc/html/rfc4701>`__:
The DHCPv4 server supports DHCID records. The DHCP-DDNS server must be running
to add, update, and/or delete DHCID records.
- *The Dynamic Host Configuration Protocol (DHCP) Client Fully
Qualified Domain Name (FQDN) Option*, `RFC 4702
- <https://tools.ietf.org/html/rfc4702>`__: The Kea server is able to handle
+ <https://datatracker.ietf.org/doc/html/rfc4702>`__: The Kea server is able to handle
the Client FQDN option. Also, it is able to use the :iscman:`kea-dhcp-ddns`
component to initiate appropriate DNS Update operations.
- *Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic
Host Configuration Protocol (DHCP) Clients*, `RFC 4703
- <https://tools.ietf.org/html/rfc4703>`__: The DHCPv6 server uses a DHCP-DDNS
+ <https://datatracker.ietf.org/doc/html/rfc4703>`__: The DHCPv6 server uses a DHCP-DDNS
server to resolve conflicts.
-- *Timezone Options for DHCP*: `RFC 4833 <https://tools.ietf.org/html/rfc4833>`__:
+- *Timezone Options for DHCP*: `RFC 4833 <https://datatracker.ietf.org/doc/html/rfc4833>`__:
Both DHCPv4 options are supported.
- *The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags
- Suboption*: `RFC 5010 <https://tools.ietf.org/html/rfc5010>`__: The Relay Agent
+ Suboption*: `RFC 5010 <https://datatracker.ietf.org/doc/html/rfc5010>`__: The Relay Agent
Flags sub-option is understood by Kea and can be used in an expression.
- *Server Identifier Override sub-option for the Relay Agent Option*, `RFC 5107
- <https://tools.ietf.org/html/rfc5107>`__: The server identifier override
+ <https://datatracker.ietf.org/doc/html/rfc5107>`__: The server identifier override
sub-option is supported. The implementation is not complete according to the
RFC, because the server does not store the RAI, but the functionality handles
expected use cases.
- *DHCP Options for Protocol for Carrying Authentication for Network Access
- (PANA) Authentication Agents*: `RFC 5192 <https://tools.ietf.org/html/rfc5192>`__:
+ (PANA) Authentication Agents*: `RFC 5192 <https://datatracker.ietf.org/doc/html/rfc5192>`__:
The PANA option is supported.
- *Discovering Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)*: `RFC 5223
- <https://tools.ietf.org/html/rfc5223>`__: The LOST option is supported.
+ <https://datatracker.ietf.org/doc/html/rfc5223>`__: The LOST option is supported.
- *Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller
- DHCP Option*: `RFC 5417 <https://tools.ietf.org/html/rfc5417>`__: The CAPWAP
+ DHCP Option*: `RFC 5417 <https://datatracker.ietf.org/doc/html/rfc5417>`__: The CAPWAP
for IPv4 option is supported.
- *DHCPv4 Lease Query by Relay Agent Remote ID*, `RFC 6148
- <https://tools.ietf.org/html/rfc6148>`__: The leasequery by remote-id is
+ <https://datatracker.ietf.org/doc/html/rfc6148>`__: The leasequery by remote-id is
supported. This requires leasequery hook. See :ref:`hooks-lease-query` for details.
- *Client Identifier Option in DHCP Server Replies*, `RFC 6842
- <https://tools.ietf.org/html/rfc6842>`__: The server by default sends back
+ <https://datatracker.ietf.org/doc/html/rfc6842>`__: The server by default sends back
the ``client-id`` option. That capability can be disabled. See
:ref:`dhcp4-echo-client-id` for details.
- *The DHCPv4 Relay Agent Identifier Sub-Option*, `RFC 6925
- <https://tools.ietf.org/html/rfc6925>`__: The relay-id option is supported and
+ <https://datatracker.ietf.org/doc/html/rfc6925>`__: The relay-id option is supported and
can be used in all features that are using expressions (client classification,
flex-id reservations, etc.).
-- *DHCPv4 Bulk Leasequery*, `RFC 6926 <https://tools.ietf.org/html/rfc6926>`__: The
+- *DHCPv4 Bulk Leasequery*, `RFC 6926 <https://datatracker.ietf.org/doc/html/rfc6926>`__: The
server functionality (TCP connections, new query types, multiple responses, etc.)
is supported. This requires leasequery hook. See :ref:`hooks-lease-query` for details.
- *Generalized UDP Source Port for the DHCP Relay Agent Option*, `RFC 8357
- <https://tools.ietf.org/html/rfc8357>`__: The Kea server handles the Relay
+ <https://datatracker.ietf.org/doc/html/rfc8357>`__: The Kea server handles the Relay
Agent Information Source Port sub-option in a received message, remembers the
UDP port, and sends back a reply to the same relay agent using this UDP port.
- *Captive-Portal Identification in DHCP and Router Advertisements (RAs)*, `RFC
- 8910 <https://tools.ietf.org/html/rfc8910>`__: The Kea server can configure
+ 8910 <https://datatracker.ietf.org/doc/html/rfc8910>`__: The Kea server can configure
both v4 and v6 versions of the captive portal options.
- *IPv6-Only Preferred Option for DHCPv4*, `RFC 8925
- <https://tools.ietf.org/html/rfc8925>`__: The Kea server is able to designate
+ <https://datatracker.ietf.org/doc/html/rfc8925>`__: The Kea server is able to designate
its pools and subnets as IPv6-Only Preferred and send back the
``v6-only-preferred`` option to clients that requested it.
- *DHCP and Router Advertisement Options for the Discovery of Network-designated
- Resolvers (DNR)*, `RFC 9463 <https://tools.ietf.org/html/rfc9463>`__. The Kea server
+ Resolvers (DNR)*, `RFC 9463 <https://datatracker.ietf.org/doc/html/rfc9463>`__. The Kea server
supports the DNR option.
Known RFC Violations
In principle, Kea aspires to be a reference implementation and aims to implement 100% of the RFC standards.
However, in some cases there are practical aspects that prevent Kea from completely adhering to the text of all RFC documents.
-- `RFC 2131 <https://tools.ietf.org/html/rfc2131>`__, page 30, says that if the incoming DHCPREQUEST packet has no
+- `RFC 2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__, page 30, says that if the incoming DHCPREQUEST packet has no
"requested IP address" option and ``ciaddr`` is not set, the server is supposed to respond with NAK. However,
broken clients exist that will always send a DHCPREQUEST without those options indicated. In that event, Kea accepts the DHCPREQUEST,
assigns an address, and responds with an ACK.
-- `RFC 2131 <https://tools.ietf.org/html/rfc2131>`__, table 5, says that messages
+- `RFC 2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__, table 5, says that messages
of type DHCPDECLINE or DHCPRELEASE must have the server identifier set and
should be dropped if that option is missing. However, ISC DHCP does not enforce this, presumably as a compatibility
effort for broken clients, and the Kea team decided to follow suit.
----------------------------------
Subnets may also be configured to delegate prefixes, as defined in `RFC
-8415 <https://tools.ietf.org/html/rfc8415>`__, section 6.3. A subnet may
+8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__, section 6.3. A subnet may
have one or more prefix delegation pools. Each pool has a prefixed
address, which is specified as a prefix (``prefix``) and a prefix length
(``prefix-len``), as well as a delegated prefix length
For each delegated prefix, the delegating router may choose to exclude a
single prefix out of the delegated prefix as specified in `RFC
-6603 <https://tools.ietf.org/html/rfc6603>`__. The requesting router must
+6603 <https://datatracker.ietf.org/doc/html/rfc6603>`__. The requesting router must
not assign the excluded prefix to any of its downstream interfaces.
The excluded prefix is intended to be used on a link through which the delegating router
exchanges DHCPv6 messages with the requesting router. The configuration
Softwire46 options are involved in IPv4-over-IPv6 provisioning by means
of tunneling or translation, as specified in `RFC
-7598 <https://tools.ietf.org/html/rfc7598>`__. The following sections
+7598 <https://datatracker.ietf.org/doc/html/rfc7598>`__. The following sections
provide configuration examples of these options.
.. _s46-containers:
------------------------------------------------------------------
The Discovery of Network-designated Resolvers, or DNR option, was
-introduced in `RFC 9463 <https://tools.ietf.org/html/rfc9463>`__ as
+introduced in `RFC 9463 <https://datatracker.ietf.org/doc/html/rfc9463>`__ as
a way to communicate location of DNS resolvers available over means other than
the classic DNS over UDP over port 53. As of spring 2024, the supported technologies
are DoT (DNS-over-TLS), DoH (DNS-over-HTTPS), and DoQ (DNS-over-QUIC), but the option was
protocol, to separate them. The "pipe" (``0x7C``) character can be used in the ``dohpath`` service parameter,
as it is allowed in a URI.
-`RFC 9463 <https://www.rfc-editor.org/rfc/rfc9463#name-option-format>`__, Section 4.1
+`RFC 9463 <https://datatracker.ietf.org/doc/html/rfc9463#name-option-format>`__, Section 4.1
encourages the use of the ``ALPN`` (Application-Layer Protocol Negotiation) SvcParam, as it is required in most cases.
It defines the protocol for reaching the encrypted resolver. The most common values are
``dot``, ``doq``, and ``h2`` (meaning HTTP/2.0 over TLS, used in DoH).
-Per `RFC 9461 <https://www.rfc-editor.org/rfc/rfc9461.html#name-new-svcparamkey-dohpath>`__ Section 5: if the
+Per `RFC 9461 <https://datatracker.ietf.org/doc/html/rfc9461#name-new-svcparamkey-dohpath>`__ Section 5: if the
``alpn`` SvcParam indicates support for HTTP, ``dohpath`` MUST be present. The URI Template MUST contain
a "dns" variable. For example, when advertising a DoH resolver available at
``https://doh1.example.org/query{?dns}``, the ``dohpath`` should be set to relative URI ``/query{?dns}``.
Users interested in configuring this option are encouraged to read the following materials:
- A very nice set of examples is available in Section 7 of `RFC 9461
- <https://www.rfc-editor.org/rfc/rfc9461#name-examples>`__.
+ <https://datatracker.ietf.org/doc/html/rfc9461#name-examples>`__.
- A list of all currently defined service parameters is maintained in the `IANA registry
<https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml>`__. This specifies records that can be
stored in the svcParams field of the DNR option.
- A list of currently allowed protocols in the ALPN parameter is maintained in `another IANA registry
<https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>`__.
-- `RFC 9463 <https://www.rfc-editor.org/rfc/rfc9463>`__ provides option definitions. In terms of SvcParams, it states
+- `RFC 9463 <https://datatracker.ietf.org/doc/html/rfc9463>`__ provides option definitions. In terms of SvcParams, it states
that ``alpn`` and ``port`` must be supported, and support for ``dohpath`` (used for DoH) is recommended.
-- Section 2.2 of `RFC 9460 <https://www.rfc-editor.org/rfc/rfc9460>`__ defines the on-wire format for SvcParams.
-- Sections 7.1 and 7.2 of `RFC 9460 <https://www.rfc-editor.org/rfc/rfc9460>`__ define the on-wire format for alpn and port.
-- Section 5 of `RFC 9461 <https://www.rfc-editor.org/rfc/rfc9461#name-new-svcparamkey-dohpath>`__ defines the
+- Section 2.2 of `RFC 9460 <https://datatracker.ietf.org/doc/html/rfc9460>`__ defines the on-wire format for SvcParams.
+- Sections 7.1 and 7.2 of `RFC 9460 <https://datatracker.ietf.org/doc/html/rfc9460>`__ define the on-wire format for alpn and port.
+- Section 5 of `RFC 9461 <https://datatracker.ietf.org/doc/html/rfc9461#name-new-svcparamkey-dohpath>`__ defines the
on-wire format for ``dohpath``.
Kea currently supports the following service parameters:
NTP server option is a container of suboptions: ntp-server-address (1), ntp-server-multicast (2)
carrying an IPv6 address, and ntp-server-fqdn (3) carrying a FQDN in wire format defined
in the "v6-ntp-server-suboptions" option space. Each option instance carries one and only one
-suboption as required by `RFC 5908 <https://tools.ietf.org/html/rfc5908>`__.
+suboption as required by `RFC 5908 <https://datatracker.ietf.org/doc/html/rfc5908>`__.
.. _dhcp6-custom-options:
------------
The Rapid Commit option, described in `RFC
-8415 <https://tools.ietf.org/html/rfc8415>`__, is supported by the Kea
+8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__, is supported by the Kea
DHCPv6 server. However, support is disabled by default. It can be
enabled on a per-subnet basis using the ``rapid-commit`` parameter as
shown below:
Relay-Supplied Options
----------------------
-`RFC 6422 <https://tools.ietf.org/html/rfc6422>`__ defines a mechanism
+`RFC 6422 <https://datatracker.ietf.org/doc/html/rfc6422>`__ defines a mechanism
called Relay-Supplied DHCP Options. In certain cases relay agents are
the only entities that may have specific information, and they can
insert options when relaying messages from the client to the server. The
The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. This
boolean parameter was passed through to D2 and enabled or disabled conflict resolution
-as described in `RFC 4703 <https://tools.ietf.org/html/rfc4703>`__. Beginning with
+as described in `RFC 4703 <https://datatracker.ietf.org/doc/html/rfc4703>`__. Beginning with
Kea 2.5.0, it is deprecated and replaced by ``ddns-conflict-resolution-mode``, which
offers four modes of conflict resolution-related behavior:
Setting ``ddns-conflict-resolution-mode`` to any value other than
``check-with-dhcid`` disables the overwrite safeguards
that the rules of conflict resolution (from
- `RFC 4703 <https://tools.ietf.org/html/rfc4703>`__) are intended to
+ `RFC 4703 <https://datatracker.ietf.org/doc/html/rfc4703>`__) are intended to
prevent. This means that existing entries for an FQDN or an
IP address made for Client-A can be deleted or replaced by entries
for Client-B. Furthermore, there are two scenarios by which entries
The DNS entries Kea creates contain a value for TTL (time to live).
By default, the :iscman:`kea-dhcp4` server calculates that value based on
-`RFC 4702, Section 5 <https://tools.ietf.org/html/rfc4702#section-5>`__,
+`RFC 4702, Section 5 <https://datatracker.ietf.org/doc/html/rfc4702#section-5>`__,
which suggests that the TTL value be 1/3 of the lease's life time, with
a minimum value of 10 minutes. There are four optional parameters which
may be used to influence the TTL calculation:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :iscman:`kea-dhcp6` server follows the behavior prescribed for DHCP servers in
-`RFC 4704 <https://tools.ietf.org/html/rfc4704>`__. It is important to keep
+`RFC 4704 <https://datatracker.ietf.org/doc/html/rfc4704>`__. It is important to keep
in mind that :iscman:`kea-dhcp6` makes the initial decision of when and what to
update and forwards that information to D2 in the form of NCRs. Carrying
out the actual DNS updates and dealing with such things as conflict
respectively.
(Note that the flag combination N=1, S=1 is prohibited according to `RFC
-4702 <https://tools.ietf.org/html/rfc4702>`__. If such a combination is
+4702 <https://datatracker.ietf.org/doc/html/rfc4702>`__. If such a combination is
received from the client, the packet will be dropped by :iscman:`kea-dhcp6`.)
To override client delegation, set the following values in the
-------------------------------
The support of DHCPv4-over-DHCPv6 transport is described in `RFC
-7341 <https://tools.ietf.org/html/rfc7341>`__ and is implemented using
+7341 <https://datatracker.ietf.org/doc/html/rfc7341>`__ and is implemented using
cooperating DHCPv4 and DHCPv6 servers. This section is about the
configuration of the DHCPv6 side (the DHCPv4 side is described in
:ref:`dhcp4-dhcp4o6-config`).
Storing Extended Lease Information
----------------------------------
To support such features as DHCPv6 Reconfigure
-(`RFC 3315 <https://tools.ietf.org/html/rfc3315>`__) and Leasequery
-(`RFC 5007 <https://tools.ietf.org/html/rfc5007>`__),
+(`RFC 3315 <https://datatracker.ietf.org/doc/html/rfc3315>`__) and Leasequery
+(`RFC 5007 <https://datatracker.ietf.org/doc/html/rfc5007>`__),
additional information must be stored with each lease. Because the amount
of information stored for each lease has ramifications in terms of
performance and system resource consumption, storage of this additional
The DHCPv6 protocol uses a "server identifier" (also known as a DUID) to
allow clients to discriminate between several servers present on the
-same link. `RFC 8415 <https://tools.ietf.org/html/rfc8415>`__ currently
+same link. `RFC 8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__ currently
defines four DUID types: DUID-LLT, DUID-EN, DUID-LL, and DUID-UUID.
The Kea DHCPv6 server generates a server identifier once, upon the first
restarts of the server and so is a stable identifier.
Kea follows the recommendation from `RFC
-8415 <https://tools.ietf.org/html/rfc8415>`__ to use DUID-LLT as the
+8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__ to use DUID-LLT as the
default server identifier. However, ISC has received reports that some
deployments require different DUID types, and that there is a need to
administratively select both the DUID type and/or its contents.
Support for RFC 7550 (now part of RFC 8415)
===========================================
-`RFC 7550 <https://tools.ietf.org/html/rfc7550>`__ introduced some
+`RFC 7550 <https://datatracker.ietf.org/doc/html/rfc7550>`__ introduced some
changes to the previous DHCPv6 specifications, `RFC
-3315 <https://tools.ietf.org/html/rfc3315>`__ and `RFC
-3633 <https://tools.ietf.org/html/rfc3633>`__, to resolve issues
+3315 <https://datatracker.ietf.org/doc/html/rfc3315>`__ and `RFC
+3633 <https://datatracker.ietf.org/doc/html/rfc3633>`__, to resolve issues
with the coexistence of multiple stateful options in the messages sent
between clients and servers. Those changes were later included in
the most recent DHCPv6 protocol specification, `RFC
-8415 <https://tools.ietf.org/html/rfc8415>`__, which obsoleted `RFC
-7550 <https://tools.ietf.org/html/rfc7550>`__. Kea supports `RFC
-8415 <https://tools.ietf.org/html/rfc8415>`__ along with these protocol
+8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__, which obsoleted `RFC
+7550 <https://datatracker.ietf.org/doc/html/rfc7550>`__. Kea supports `RFC
+8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__ along with these protocol
changes, which are briefly described below.
When a client, such as a requesting router, requests an allocation of
disable this behavior.
The following are the other behaviors first introduced in `RFC
-7550 <https://tools.ietf.org/html/rfc7550>`__ (now part of `RFC
-8415 <https://tools.ietf.org/html/rfc8415>`__) and supported by the Kea
+7550 <https://datatracker.ietf.org/doc/html/rfc7550>`__ (now part of `RFC
+8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__) and supported by the Kea
DHCPv6 server:
- Set T1/T2 timers to the same value for all stateful (IA_NA and IA_PD)
- ``duid`` - DHCPv6 uses DUID identifiers instead of MAC addresses.
There are currently four DUID types defined, and two of them
(DUID-LLT, which is the default, and DUID-LL) convey MAC address
- information. Although `RFC 8415 <https://tools.ietf.org/html/rfc8415>`__
+ information. Although `RFC 8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__
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
those addresses are based on EUI-64, which contains a MAC address.
This method is not completely reliable, as clients may use other
link-local address types. In particular, privacy extensions, defined
- in `RFC 4941 <https://tools.ietf.org/html/rfc4941>`__, do not use MAC
+ in `RFC 4941 <https://datatracker.ietf.org/doc/html/rfc4941>`__, do not use MAC
addresses. Also note that successful extraction requires that the
address's u-bit must be set to "1" and its g-bit set to "0", indicating
that it is an interface identifier as per `RFC 2373, section
- 2.5.1 <https://tools.ietf.org/html/rfc2373#section-2.5.1>`__.
+ 2.5.1 <https://datatracker.ietf.org/doc/html/rfc2373#section-2.5.1>`__.
- ``client-link-addr-option`` - one extension defined to alleviate
missing MAC issues is the client link-layer address option, defined
- in `RFC 6939 <https://tools.ietf.org/html/rfc6939>`__. This is an
+ in `RFC 6939 <https://datatracker.ietf.org/doc/html/rfc6939>`__. This is an
option that is inserted by a relay and contains information about a
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. The value ``rfc6939`` is an alias for
``client-link-addr-option``.
-- ``remote-id`` - `RFC 4649 <https://tools.ietf.org/html/rfc4649>`__
+- ``remote-id`` - `RFC 4649 <https://datatracker.ietf.org/doc/html/rfc4649>`__
defines a ``remote-id`` option that is inserted by a relay agent.
Depending on the relay agent configuration, the inserted option may
convey the client's MAC address information. The value ``rfc4649``
is an alias for ``remote-id``.
-- ``subscriber-id`` - Defined in `RFC 4580 <https://tools.ietf.org/html/rfc4580>`__,
+- ``subscriber-id`` - Defined in `RFC 4580 <https://datatracker.ietf.org/doc/html/rfc4580>`__,
``subscriber-id`` is somewhat similar to ``remote-id``; it is also inserted
by a relay agent. The value ``rfc4580`` is an alias for
``subscriber-id``. This method is currently not implemented.
=======================================
Kea version 2.7.7 introduces the support of self-generated address registration
-as defined in `RFC 9686 <https://tools.ietf.org/html/rfc9686>`__ i.e.
+as defined in `RFC 9686 <https://datatracker.ietf.org/doc/html/rfc9686>`__ i.e.
when a valid ADDR-REG-INFORM (36) message is received a registered lease is
added or updated and a ADDR-REG-REPLY (37) is sent back to the client.
setting the parameter, ``allow-address-registration`` to true or false
respectively. It is enabled by default.
-`RFC 9686 <https://tools.ietf.org/html/rfc9686>`__ calls for servers
+`RFC 9686 <https://datatracker.ietf.org/doc/html/rfc9686>`__ calls for servers
that support address registration to return option 148 to clients that
request it via the ORO option. As with any other standard option, this
option must be specified in the server configuration in order to be
The following standards are currently supported in Kea:
- *Dynamic Host Configuration Protocol for IPv6*, `RFC
- 3315 <https://tools.ietf.org/html/rfc3315>`__: Supported messages are
+ 3315 <https://datatracker.ietf.org/doc/html/rfc3315>`__: Supported messages are
SOLICIT, ADVERTISE, REQUEST, RELEASE, RENEW, REBIND,
INFORMATION-REQUEST, CONFIRM, DECLINE and REPLY. The only
unsupported message is RECONFIGURE. Almost all options are supported,
- *Dynamic Host Configuration Protocol (DHCPv6) Options for
Session Initiation Protocol (SIP) Servers*, `RFC 3319
- <https://tools.ietf.org/html/rfc3319>`__: All defined options are supported.
+ <https://datatracker.ietf.org/doc/html/rfc3319>`__: All defined options are supported.
- *IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP)
- version 6*, `RFC 3633 <https://tools.ietf.org/html/rfc3633>`__:
+ version 6*, `RFC 3633 <https://datatracker.ietf.org/doc/html/rfc3633>`__:
Supported options are IA_PD and IA_PREFIX. Also supported is the
status code NoPrefixAvail.
- *DNS Configuration options for Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)*, `RFC 3646 <https://tools.ietf.org/html/rfc3646>`__: All defined
+ (DHCPv6)*, `RFC 3646 <https://datatracker.ietf.org/doc/html/rfc3646>`__: All defined
options are supported.
- *Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6*, `RFC
- 3736 <https://tools.ietf.org/html/rfc3736>`__: Server operation in
+ 3736 <https://datatracker.ietf.org/doc/html/rfc3736>`__: Server operation in
stateless mode is supported. Kea is currently server-only, so the client side
is not implemented.
- *Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6*, `RFC
- 4075 <https://tools.ietf.org/html/rfc4075>`__: The SNTP option is supported.
+ 4075 <https://datatracker.ietf.org/doc/html/rfc4075>`__: The SNTP option is supported.
- *Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)*, `RFC 4076 <https://tools.ietf.org/html/rfc4076>`__: The server
+ IPv6 (DHCPv6)*, `RFC 4076 <https://datatracker.ietf.org/doc/html/rfc4076>`__: The server
supports all the stateless renumbering requirements.
- *Information Refresh Time Option for Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)*, `RFC 4242 <https://tools.ietf.org/html/rfc4242>`__: The
+ IPv6 (DHCPv6)*, `RFC 4242 <https://datatracker.ietf.org/doc/html/rfc4242>`__: The
sole defined option (``information-refresh-time``) is supported.
- *Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast
- Control Servers*, `RFC 4280 <https://tools.ietf.org/html/rfc4280>`__:
+ Control Servers*, `RFC 4280 <https://datatracker.ietf.org/doc/html/rfc4280>`__:
The DHCPv6 options are supported.
- *Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID
- Option*, `RFC 4580 <https://tools.ietf.org/html/rfc4580>`__: The
+ Option*, `RFC 4580 <https://datatracker.ietf.org/doc/html/rfc4580>`__: The
subscribed-id option is supported and can be used in any expression.
- *The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay
Agent Remote-ID Option*, `RFC
- 4649 <https://tools.ietf.org/html/rfc4649>`__: The Remote-ID option is
+ 4649 <https://datatracker.ietf.org/doc/html/rfc4649>`__: The Remote-ID option is
supported.
- *A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol
- (DHCP) Information (DHCID RR)*, `RFC 4701 <https://tools.ietf.org/html/rfc4701>`__:
+ (DHCP) Information (DHCID RR)*, `RFC 4701 <https://datatracker.ietf.org/doc/html/rfc4701>`__:
The DHCPv6 server supports DHCID records. The DHCP-DDNS server must be running
to add, update, and/or delete DHCID records.
- *Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host
Configuration Protocol (DHCP) Clients*, `RFC 4703
- <https://tools.ietf.org/html/rfc4703>`__: The DHCPv6 server uses the DHCP-DDNS
+ <https://datatracker.ietf.org/doc/html/rfc4703>`__: The DHCPv6 server uses the DHCP-DDNS
server to resolve conflicts.
- *The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client
Fully Qualified Domain Name (FQDN) Option*, `RFC
- 4704 <https://tools.ietf.org/html/rfc4704>`__: The supported option is
+ 4704 <https://datatracker.ietf.org/doc/html/rfc4704>`__: The supported option is
CLIENT_FQDN.
-- *Timezone Options for DHCP*: `RFC 4833 <https://tools.ietf.org/html/rfc4833>`__:
+- *Timezone Options for DHCP*: `RFC 4833 <https://datatracker.ietf.org/doc/html/rfc4833>`__:
Both DHCPv6 options are supported.
-- *DHCPv6 Leasequery*: `RFC 5007 <https://tools.ietf.org/html/rfc5007>`__: The
+- *DHCPv6 Leasequery*: `RFC 5007 <https://datatracker.ietf.org/doc/html/rfc5007>`__: The
server functionality (message types, options) is supported. This requires
the leasequery hook. See :ref:`hooks-lease-query` for details.
- *DHCP Options for Protocol for Carrying Authentication for Network Access
- (PANA) Authentication Agents*: `RFC 5192 <https://tools.ietf.org/html/rfc5192>`__:
+ (PANA) Authentication Agents*: `RFC 5192 <https://datatracker.ietf.org/doc/html/rfc5192>`__:
The PANA option is supported.
- *Discovering Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)*: `RFC 5223
- <https://tools.ietf.org/html/rfc5223>`__: The LOST option is supported.
+ <https://datatracker.ietf.org/doc/html/rfc5223>`__: The LOST option is supported.
- *Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller
- DHCP Option*: `RFC 5417 <https://tools.ietf.org/html/rfc5417>`__: The CAPWAP for IPv6
+ DHCP Option*: `RFC 5417 <https://datatracker.ietf.org/doc/html/rfc5417>`__: The CAPWAP for IPv6
option is supported.
-- *DHCPv6 Bulk Leasequery*: `RFC 5460 <https://tools.ietf.org/html/rfc5460>`__:
+- *DHCPv6 Bulk Leasequery*: `RFC 5460 <https://datatracker.ietf.org/doc/html/rfc5460>`__:
The server functionality (TCP connection, new message types and options, new
query types) is supported. This requires the leasequery hook. See
:ref:`hooks-lease-query` for details.
- *Network Time Protocol (NTP) Server Option for DHCPv6*:
- `RFC 5908 <https://tools.ietf.org/html/rfc5908>`__: The NTP server option and its
+ `RFC 5908 <https://datatracker.ietf.org/doc/html/rfc5908>`__: The NTP server option and its
suboptions are supported. See :ref:`ntp-server-suboptions` for details.
-- *DHCPv6 Options for Network Boot*: `RFC 5970 <https://tools.ietf.org/html/rfc5970>`__:
+- *DHCPv6 Options for Network Boot*: `RFC 5970 <https://datatracker.ietf.org/doc/html/rfc5970>`__:
The network boot options are supported.
- *Lightweight DHCPv6 Relay Agent*, `RFC 6221
- <https://tools.ietf.org/html/rfc6221>`__: Kea can handle lightweight relay
+ <https://datatracker.ietf.org/doc/html/rfc6221>`__: Kea can handle lightweight relay
messages and use other methods than link address to perform subnet selection.
- *Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for
- Dual-Stack Lite*, `RFC 6334 <https://tools.ietf.org/html/rfc6334>`__:
+ Dual-Stack Lite*, `RFC 6334 <https://datatracker.ietf.org/doc/html/rfc6334>`__:
The AFTR-Name DHCPv6 Option is supported.
- *Relay-Supplied DHCP Options*, `RFC
- 6422 <https://tools.ietf.org/html/rfc6422>`__: The full functionality is
+ 6422 <https://datatracker.ietf.org/doc/html/rfc6422>`__: The full functionality is
supported, including OPTION_RSOO; the ability of the server to echo back the
options; verification of whether an option is RSOO-enabled; and the ability to mark
additional options as RSOO-enabled.
- *The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option*,
- `RFC 6440 <https://tools.ietf.org/html/rfc6440>`__: The option is supported.
+ `RFC 6440 <https://datatracker.ietf.org/doc/html/rfc6440>`__: The option is supported.
- *Prefix Exclude Option for DHCPv6-based Prefix Delegation*, `RFC
- 6603 <https://tools.ietf.org/html/rfc6603>`__: The Prefix Exclude option
+ 6603 <https://datatracker.ietf.org/doc/html/rfc6603>`__: The Prefix Exclude option
is supported.
- *Client Link-Layer Address Option in DHCPv6*, `RFC
- 6939 <https://tools.ietf.org/html/rfc6939>`__: The supported option is
+ 6939 <https://datatracker.ietf.org/doc/html/rfc6939>`__: The supported option is
the client link-layer address option.
- *Modification to Default values of SOL_MAX_RT and INF_MAX_RT*, `RFC 7083
- <https://tools.ietf.org/html/rfc7083>`__: The new options are
+ <https://datatracker.ietf.org/doc/html/rfc7083>`__: The new options are
supported.
- *Issues and Recommendations with Multiple Stateful DHCPv6 Options*,
- `RFC 7550 <https://tools.ietf.org/html/rfc7550>`__: All
+ `RFC 7550 <https://datatracker.ietf.org/doc/html/rfc7550>`__: All
recommendations related to the DHCPv6 server operation are supported.
- *DHCPv6 Options for Configuration of Softwire Address and Port-Mapped
- Clients*, `RFC 7598 <https://tools.ietf.org/html/rfc7598>`__: All
+ Clients*, `RFC 7598 <https://datatracker.ietf.org/doc/html/rfc7598>`__: All
options indicated in this specification are supported by the DHCPv6
server.
- *Generalized UDP Source Port for DHCP Relay*, `RFC 8357
- <https://tools.ietf.org/html/rfc8357>`__: The Kea server is able
+ <https://datatracker.ietf.org/doc/html/rfc8357>`__: The Kea server is able
to handle the Relay Source Port option in a received Relay-forward
message, remembers the UDP port, and sends back Relay-reply with a
copy of the option to the relay agent using this UDP port.
- *Dynamic Host Configuration Protocol for IPv6 (DHCPv6)*, `RFC 8415
- <https://tools.ietf.org/html/rfc8415>`__: This new DHCPv6 protocol specification
+ <https://datatracker.ietf.org/doc/html/rfc8415>`__: This new DHCPv6 protocol specification
obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283,
and RFC 7550. All features, with the exception of the RECONFIGURE mechanism and
the now-deprecated temporary addresses (IA_TA) mechanism, are supported.
- *Captive-Portal Identification in DHCP and Router Advertisements (RAs)*, `RFC 8910
- <https://tools.ietf.org/html/rfc8910>`__: The Kea server can configure both v4
+ <https://datatracker.ietf.org/doc/html/rfc8910>`__: The Kea server can configure both v4
and v6 versions of the captive portal options.
- *DHCP and Router Advertisement Options for the Discovery of Network-designated
- Resolvers (DNR)*, `RFC 9463 <https://tools.ietf.org/html/rfc9463>`__. The Kea server
+ Resolvers (DNR)*, `RFC 9463 <https://datatracker.ietf.org/doc/html/rfc9463>`__. The Kea server
supports the DNR option.
-- *Registering Self-Generated IPv6 Addresses Using DHCPv6*, `RFC 9686 <https://tools.ietf.org/html/rfc9686>`__. The Kea server supports self-generated address registration. See :ref:`dhcp6-address-registration` for details.
+- *Registering Self-Generated IPv6 Addresses Using DHCPv6*, `RFC 9686 <https://datatracker.ietf.org/doc/html/rfc9686>`__. The Kea server supports self-generated address registration. See :ref:`dhcp6-address-registration` for details.
.. _dhcp6-limit:
- The server allocates, renews, or rebinds a maximum of one lease for
a particular IA option (IA_NA or IA_PD) sent by a client. `RFC
- 8415 <https://tools.ietf.org/html/rfc8415>`__ allows for multiple
+ 8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__ allows for multiple
addresses or prefixes to be allocated for a single IA.
- Temporary addresses are not supported. There is no intention to ever
implement this feature, as it is deprecated in `RFC 8415
- <https://tools.ietf.org/html/rfc8415>`__.
+ <https://datatracker.ietf.org/doc/html/rfc8415>`__.
- Client reconfiguration (RECONFIGURE) is not yet supported.
Kea supports GSS-TSIG to protect DNS updates sent by
the Kea DHCP-DDNS (D2) server in a hook, called :ischooklib:`libddns_gss_tsig.so`.
-GSS-TSIG is defined in `RFC 3645 <https://tools.ietf.org/html/rfc3645>`__.
+GSS-TSIG is defined in `RFC 3645 <https://datatracker.ietf.org/doc/html/rfc3645>`__.
The GSS-TSIG protocol itself is an implementation of generic GSS-API v2
-services, defined in `RFC 2743 <https://tools.ietf.org/html/rfc2743>`__.
+services, defined in `RFC 2743 <https://datatracker.ietf.org/doc/html/rfc2743>`__.
Many protocols are involved in this mechanism:
- - Kerberos 5 - `RFC 4120 <https://tools.ietf.org/html/rfc4120>`__, which
+ - Kerberos 5 - `RFC 4120 <https://datatracker.ietf.org/doc/html/rfc4120>`__, which
provides the security framework;
- GSS-API (Generic Security Services Application Program Interface) -
- `RFC 2743 <https://tools.ietf.org/html/rfc2743>`__ for the API,
- `RFC 2744 <https://tools.ietf.org/html/rfc2743>`__ for the C bindings, and
- `RFC 4121 <https://tools.ietf.org/html/rfc4121>`__ for the application
+ `RFC 2743 <https://datatracker.ietf.org/doc/html/rfc2743>`__ for the API,
+ `RFC 2744 <https://datatracker.ietf.org/doc/html/rfc2743>`__ for the C bindings, and
+ `RFC 4121 <https://datatracker.ietf.org/doc/html/rfc4121>`__ for the application
to Kerberos 5;
- SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) -
- `RFC 4178 <https://tools.ietf.org/html/rfc4178>`__ for the negotiation;
- - DNS update `RFC 2136 <https://tools.ietf.org/html/rfc2136>`__;
+ `RFC 4178 <https://datatracker.ietf.org/doc/html/rfc4178>`__ for the negotiation;
+ - DNS update `RFC 2136 <https://datatracker.ietf.org/doc/html/rfc2136>`__;
- TSIG (Secret Key Transaction Authentication for DNS) -
- `RFC 8945 <https://tools.ietf.org/html/rfc8945>`__, which
+ `RFC 8945 <https://datatracker.ietf.org/doc/html/rfc8945>`__, which
protects DNS exchanges;
- Secure Domain Name System (DNS) Dynamic Update -
- `RFC 3007 <https://tools.ietf.org/html/rfc3007>`__, which is the
+ `RFC 3007 <https://datatracker.ietf.org/doc/html/rfc3007>`__, which is the
application of TSIG to DNS update protection;
- TKEY (Secret Key Establishment for DNS) -
- `RFC 2930 <https://tools.ietf.org/html/rfc2930>`__, which establishes
+ `RFC 2930 <https://datatracker.ietf.org/doc/html/rfc2930>`__, which establishes
secret keys for TSIG by transmitting crypto payloads between DNS
parties; and
- - GSS-TSIG - `RFC 3645 <https://tools.ietf.org/html/rfc3645>`__, which
+ - GSS-TSIG - `RFC 3645 <https://datatracker.ietf.org/doc/html/rfc3645>`__, which
is the application of GSS-API to TSIG.
To summarize, GSS-API for Kerberos 5 with SPNEGO and TKEY are used to
The Network Configuration Protocol, or NETCONF, is a network management protocol defined
in `RFC 6241 <https://datatracker.ietf.org/doc/html/rfc6241>`__. It uses the YANG modeling language,
-defined in `RFC 6020 <https://tools.ietf.org/html/rfc6020>`__, to provide a uniform way
+defined in `RFC 6020 <https://datatracker.ietf.org/doc/html/rfc6020>`__, to provide a uniform way
of handling the configuration syntax of various networking devices. Kea provides optional
support for a YANG/NETCONF interface with the :iscman:`kea-netconf` agent.
`RFC 3579 <https://datatracker.ietf.org/doc/html/rfc3579>`__.
The Status-Server message is specified in
-`RFC 5997 <https://www.rfc-editor.org/rfc/rfc5997.html>`__.
+`RFC 5997 <https://datatracker.ietf.org/doc/html/rfc5997>`__.
The TCP transport (not supported by heavily referenced for TLS) is specified
in `RFC 6613 <https://datatracker.ietf.org/doc/html/rfc6613>`__.
===============================================
This hook library adds support for BOOTP with vendor-information extensions
-(`RFC 1497 <https://tools.ietf.org/html/rfc1497>`__). Received BOOTP
+(`RFC 1497 <https://datatracker.ietf.org/doc/html/rfc1497>`__). Received BOOTP
requests are recognized, translated into DHCPREQUEST packets by adding
a ``dhcp-message-type`` option, and put into the "BOOTP" client class.
Members of this class get infinite lifetime leases but the class can
Currently the BOOTP library has the following limitation:
- Basic BOOTP, as defined in `RFC 951
- <https://tools.ietf.org/html/rfc951>`__, is not supported. Kea only
+ <https://datatracker.ietf.org/doc/html/rfc951>`__, is not supported. Kea only
supports BOOTP with vendor-information extensions.
``load-balancing``, ``hot-standby``, and ``passive-backup``. In the
``load-balancing`` mode, two servers respond to DHCP requests. The
``load-balancing`` function is implemented as described in `RFC
-3074 <https://tools.ietf.org/html/rfc3074>`__, with each server responding to
+3074 <https://datatracker.ietf.org/doc/html/rfc3074>`__, with each server responding to
half the received DHCP queries. When one of the servers allocates a lease for a
client, it notifies the partner server over the control channel (via the RESTful
API), so the partner can save the lease information in its own database. If the
==============================================
This library provides support for DHCPv4 Leasequery as described in
-`RFC 4388 <https://tools.ietf.org/html/rfc4388>`__; and for DHCPv6
-Leasequery as described in (`RFC 5007 <https://tools.ietf.org/html/rfc5007>`__).
+`RFC 4388 <https://datatracker.ietf.org/doc/html/rfc4388>`__; and for DHCPv6
+Leasequery as described in (`RFC 5007 <https://datatracker.ietf.org/doc/html/rfc5007>`__).
.. note::
:iscman:`kea-dhcp6` process.
Kea version 2.3.4 added support for DHCPv6 Bulk Leasequery
-(`RFC 5460 <https://tools.ietf.org/html/rfc5460>`__);
+(`RFC 5460 <https://datatracker.ietf.org/doc/html/rfc5460>`__);
Kea version 2.3.5 added support for DHCPv4 Bulk Leasequery
-(`RFC 6926 <https://tools.ietf.org/html/rfc6926>`__) using
+(`RFC 6926 <https://datatracker.ietf.org/doc/html/rfc6926>`__) using
the memfile lease backend.
.. _lease-query-dhcpv4:
.. note::
- `RFC 5007, Section 3.3 <https://tools.ietf.org/html/rfc5007#section-3.3>`__
+ `RFC 5007, Section 3.3 <https://datatracker.ietf.org/doc/html/rfc5007#section-3.3>`__
states that querying by IP address should return either a lease (e.g.
binding) for the address itself or a lease for a delegated prefix that
contains the address.
is empty, then, in addition to the status-code, the ``DHCPV6_LEASEQUERY_REPLY``
contains an ``lq-client-link`` option (48). The ``lq-client-link`` contains a list of
IPv6 addresses, one for each subnet in which a lease was found (see
-`RFC 5007, Section 4.1.2.5 <https://tools.ietf.org/html/rfc5007#section-4.1.2.5>`__)
+`RFC 5007, Section 4.1.2.5 <https://datatracker.ietf.org/doc/html/rfc5007#section-4.1.2.5>`__)
If, however, the query's ``link-address`` is not empty, the list of queries is
pruned to contain only leases that belong to that subnet.
When the query results in one or more active leases which all belong to a single
subnet, in addition to the ``status-code``, the ``DHCPV6_LEASEQUERY_REPLY`` contains a
``client-data`` option (45) (see
-`RFC 5007, Section 4.1.2.2 <https://tools.ietf.org/html/rfc5007#section-4.1.2.2>`__).
+`RFC 5007, Section 4.1.2.2 <https://datatracker.ietf.org/doc/html/rfc5007#section-4.1.2.2>`__).
The client-data option encapsulates the following options:
.. tabularcolumns:: |p{0.2\linewidth}|p{0.1\linewidth}|p{0.7\linewidth}|
value has relay information in its user context (see
:ref:`store-extended-info-v6`), then an ``OPTION_LQ_RELAY_DATA`` option is
added to the reply (see
-`RFC 5007, Section 4.1.2.4 <https://tools.ietf.org/html/rfc5007#section-4.1.2.4>`__).
+`RFC 5007, Section 4.1.2.4 <https://datatracker.ietf.org/doc/html/rfc5007#section-4.1.2.4>`__).
The relay information on the lease is a list with an entry for each
relay layer the client packet (e.g. ``DHCPV6_REQUEST``) traversed, with the
This hook library adds the ability to perform a "ping check" of a candidate
IPv4 address prior to offering it to a DHCP client. This feature is similar
to a behavior available in ISC DHCP and one suggested in `RFC
-2131 <https://tools.ietf.org/html/rfc2131>`__, section 3.1, item 2.
+2131 <https://datatracker.ietf.org/doc/html/rfc2131>`__, section 3.1, item 2.
.. note::
Authentication for Kea's RESTful API
------------------------------------
-Kea 1.9.0 added support for basic HTTP authentication (`RFC 7617 <https://tools.ietf.org/html/rfc7617>`_),
+Kea 1.9.0 added support for basic HTTP authentication (`RFC 7617 <https://datatracker.ietf.org/doc/html/rfc7617>`_),
to control access for incoming REST commands over HTTP. The credentials (username, password) are
stored in a local Kea configuration file on disk. The username is logged with the API command, so it
is possible to determine which authenticated user performed each command. The access control details
projects / thirdparty / kea.git / commitdiff
