summaryrefslogtreecommitdiffstats
path: root/doc/sphinx/arm
diff options
context:
space:
mode:
authorTomek Mrugalski <tomek@isc.org>2024-01-25 14:26:05 +0100
committerPiotrek Zadroga <piotrek@isc.org>2024-02-23 17:14:05 +0100
commitbf76f04bc6fba0d0452e5317447e2a181b3ff308 (patch)
tree7fb23a6d87a95191038a632bdb0327a3ffd587e0 /doc/sphinx/arm
parent[#3245] Minor UT change (diff)
downloadkea-bf76f04bc6fba0d0452e5317447e2a181b3ff308.tar.xz
kea-bf76f04bc6fba0d0452e5317447e2a181b3ff308.zip
[#3141] ARM updated
- Added DNR description - added to list of supported RFCs - Also removed one server limitation that's no longer valid (because we have ping-check). Not related, but small enough.
Diffstat (limited to 'doc/sphinx/arm')
-rw-r--r--doc/sphinx/arm/dhcp4-srv.rst43
-rw-r--r--doc/sphinx/arm/dhcp6-srv.rst57
2 files changed, 90 insertions, 10 deletions
diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst
index e37ace4c05..6e8bcfbbb6 100644
--- a/doc/sphinx/arm/dhcp4-srv.rst
+++ b/doc/sphinx/arm/dhcp4-srv.rst
@@ -4726,6 +4726,29 @@ and class levels. Choosing an appropriate value for ``offer-lifetime`` is extrem
site-dependent, but a value between 60 and 120 seconds is a reasonable starting
point.
+.. _dnr4-options:
+
+DNR (Discovery of Network-designated Resolvers) Options for DHCPv4
+------------------------------------------------------------------
+
+One of the more recently added option is Discovery of Network-designated Resolvers or DNR,
+introduced in `RFC 9463 <https://tools.ietf.org/html/rfc9463>`__. The goal of that RFC is
+to provide a way to communicate location of DNS resolvers available over other means than
+the classic DNS over UDP over port 53. At the time of this writing, the supported technologies
+are DoT (DNS-over-TLS), DoH (DNS-over-HTTPS), and DoQ (DNS-over-QUIC), but the option was
+designed to be extensible to also cover future extensions.
+
+The DHCPv4 option and its corresponding DHCPv6 options are almost exactly the same,
+with the exception of cardinality. Only one DHCPv4 option is allowed, while for DHCPv6
+multiple options are allowed. To be able to convey multiple entries, the DHCPv4 is an
+array that allows multiple DNS instances. Each instance is logically equal to one
+DHCPv6 option, except the minor difference of using IPv4 rather than IPv6 addresses.
+
+For detailed example how to configure DNR option, see :ref:`dnr6-options`.
+Examples for DNR DHCPv4 options are provided in the Kea sources in
+`dnr.json` and `all-options.json` in the `doc/examples/kea4` directory.
+
+
.. _host-reservation-v4:
Host Reservations in DHCPv4
@@ -7699,6 +7722,12 @@ The following standards are currently supported in Kea:
<https://tools.ietf.org/html/rfc4703>`__: The DHCPv6 server uses a DHCP-DDNS
server to resolve conflicts.
+- *Server Identifier Override sub-option for the Relay Agent Option*, `RFC 5107
+ <https://tools.ietf.org/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.
+
- *Client Identifier Option in DHCP Server Replies*, `RFC 6842
<https://tools.ietf.org/html/rfc6842>`__: The server by default sends back
the ``client-id`` option. That capability can be disabled. See
@@ -7718,11 +7747,10 @@ The following standards are currently supported in Kea:
its pools and subnets as IPv6-Only Preferred and send back the
``v6-only-preferred`` option to clients that requested it.
-- *Server Identifier Override sub-option for the Relay Agent Option*, `RFC 5107
- <https://tools.ietf.org/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 and Router Advertisement Options for the Discovery of Network-designated
+ Resolvers (DNR)*, `RFC 9463 <https://tools.ietf.org/html/rfc9463>`__. The Kea server
+ supports the DNR option. Part of its value (SvcParams) must be configured in
+ hex.
Known RFC Violations
--------------------
@@ -7760,11 +7788,6 @@ are clearly marked as such.
format for all interfaces. Thus, Kea does not work on interfaces
which use different data-link-layer header formats (e.g. Infiniband).
-- The DHCPv4 server does not verify that an assigned address is unused.
- According to `RFC 2131 <https://tools.ietf.org/html/rfc2131>`__, the
- allocating server should verify that an address is not used by
- sending an ICMP echo request.
-
.. _dhcp4-srv-examples:
Kea DHCPv4 Server Examples
diff --git a/doc/sphinx/arm/dhcp6-srv.rst b/doc/sphinx/arm/dhcp6-srv.rst
index a5450fa9c1..dd93174e37 100644
--- a/doc/sphinx/arm/dhcp6-srv.rst
+++ b/doc/sphinx/arm/dhcp6-srv.rst
@@ -1838,6 +1838,9 @@ processing, the support for those options is non-functional. However, it
may be useful in some limited lab testing; hence the definition formats
are listed here.
+Some options are more complex to configure than others. In particular, the Softwire46 family of options
+and DNR are discussed in separate sections below.
+
Kea supports more options than those listed above. The following list is mostly useful for readers who
want to understand whether Kea is able to support certain options. The following options are
returned by the Kea engine itself and in general should not be configured manually.
@@ -2062,6 +2065,55 @@ PSID-length fields in the format of PSID/PSID length. This is equivalent
to the values of ``PSID-len=4`` and ``PSID=12288`` conveyed in the S46 Port
Parameters option.
+.. _dnr6-options:
+
+DNR (Discovery of Network-designated Resolvers) Options for DHCPv6
+------------------------------------------------------------------
+
+One of the more recently added option is Discovery of Network-designated Resolvers or DNR,
+introduced in `RFC 9463 <https://tools.ietf.org/html/rfc9463>`__. The goal of that RFC is
+to provide a way to communicate location of DNS resolvers available over other means than
+the classic DNS over UDP over port 53. At the time of this writing, the supported technologies
+are DoT (DNS-over-TLS), DoH (DNS-over-HTTPS), and DoQ (DNS-over-QUIC), but the option was
+designed to be extensible to also cover future extensions.
+
+Let's imagine an example that we want to convey a DoT server operating at dot1.example.org
+on a non-standard port 8530. An example option that would convey this information looks as follows:
+
+::
+
+ {
+ "name": "v6-dnr", // name of the option
+ // 100 - service priority
+ // 18 - length of the Authentication Domain Name (name of the resolver)
+ // the binary data has the following meaning:
+ // 00 10 - 16 octects is the length of the following IPv6 address
+ // 20 01 0d b8 00 00 00 01 00 00 00 00 00 00 00 01 - 2001:db8:1::1
+ // Remaining part is to be interpreted as svcParams field. In particular:
+ // 00 01 - next record is alpn
+ // 00 03 - length of the alpn-id field (3 octects)
+ // 64 6f 74 - "dot"
+ // 00 03 - next record is port
+ // 00 02 - length of the record is 2 octets
+ // 21 52 - the actual is 0x2152 or 8530 in decimal
+ "data": "100, 18, dot1.example.org., 00 10 20 01 0d b8 00 00 00 01 00 00 00 00 00 00 00 01 00 01 00 03 64 6f 74 00 03 00 02 21 52"
+ }
+
+A reader interested in configuring this option is encouraged to read the following materials:
+
+- `RFC 9463 <https://www.rfc-editor.org/rfc/rfc9463>`__ which provide option definitions. In terms of SvcParams, it states
+ that at `alpn` and `port` must be supported, and `dotpath` (used for DoT) is recommended to be supported.
+- Section 2.2 of `RFC 9460 <https://www.rfc-editor.org/rfc/rfc9460>`__, which define the on-wire format for SvcParams.
+- Sections 7.1, 7.2 of `RFC 9460 <https://www.rfc-editor.org/rfc/rfc9460>`__, which define the on-wire format for alpn and port.
+- Section 5 of `RFC 9460 <https://www.rfc-editor.org/rfc/rfc9461#name-new-svcparamkey-dohpath>`__, which defines
+ on-wire format for `dohpath`.
+- A very nice set of examples is available in Section 7 of `RFC 9461 <https://www.rfc-editor.org/rfc/rfc9461#name-examples>`__.
+
+Further examples are provided in Kea sources in `dnr.json` and `all-options.json` files
+in the `doc/examples/kea6` directory. The DHCPv4 option is almost equivalent, and is described
+in :ref:`dnr4-options`.
+
+
.. _dhcp6-custom-options:
Custom DHCPv6 Options
@@ -7483,6 +7535,11 @@ The following standards are currently supported in Kea:
<https://tools.ietf.org/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
+ supports the DNR option. Part of its value (SvcParams) must be configured in
+ hex.
+
.. _dhcp6-limit:
DHCPv6 Server Limitations