mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-29 21:18:02 +00:00
Code Issues Releases Wiki Activity

[288,!158] Updated user guide to reference to RFC 8415 rather than 3315.

Browse Source
This commit is contained in:
Marcin Siodelski 2018-12-05 15:50:37 +01:00
parent 5658cd9e11
commit 8c1ce6673d
3 changed files with 55 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/guide/classify.xml
View File

@ -660,12 +660,12 @@
option in DHCPv4 (code 125, see
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3925#section-4">Section 4 of RFC 3925</link>) and
Vendor-specific Information Option in DHCPv6 (code 17, defined in
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/html/rfc3315#section-22.17">Section 22.17 of
RFC 3315</link>). Vendor class option means Vendor-Identifying Vendor
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/html/rfc8415#section-21.17">Section 21.17 of
RFC 8415</link>). Vendor class option means Vendor-Identifying Vendor
Class Option in DHCPv4 (code 124, see
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3925#section-3">Section 3 of RFC 3925</link>) in DHCPv4 and
Class Option in DHCPv6 (code 16, see
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/html/rfc3315#section-22.16">Section 22.16 of RFC 3315</link>).
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/html/rfc8415#section-21.16">Section 21.16 of RFC 8415</link>).
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
@ -683,8 +683,8 @@
accessed using option[60] expression.</para></listitem>
<listitem><para>
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3925">RFC3925</link> and
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3315">RFC3315</link>
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3925">RFC 3925</link> and
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>
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 vendor.enterprise

2
doc/guide/dhcp4-srv.xml
View File

@ -3111,7 +3111,7 @@ It is merely echoed by the server
the lease. Moreover,
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/html/rfc4361">RFC 4361</link> gives
the recommendation to use a DUID
(see <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/html/rfc3315">RFC 3315</link>,
(see <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://tools.ietf.org/html/rfc8415">RFC 8415</link>,
the DHCPv6 specification)
carried as "client identifier" when dual stack networks are in use
to provide consistent identification information of the client, regardless

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

@ -2060,7 +2060,7 @@ should include options from the isc option space:
<section xml:id="dhcp6-rapid-commit">
<title>Rapid Commit</title>
<para>The Rapid Commit option, described in
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3315">RFC 3315</link>, is supported
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>, is supported
by the Kea DHCPv6 server. However, support is disabled by default for
all subnets. It can be enabled for a particular subnet using the
<command>rapid-commit</command> parameter as shown below:
@ -4245,18 +4245,16 @@ autogenerated IDs are not stable across configuration changes.
<para>The DHCPv6 protocol uses a "server identifier" (also known
as a DUID) for clients to be able to discriminate between several
servers present on the same link.
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3315">RFC 3315</link>
defines three DUID types: DUID-LLT, DUID-EN and DUID-LL.
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc6355">RFC 6355</link>
also defines DUID-UUID. Future specifications may introduce new
DUID types.</para>
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>
defines four DUID types: DUID-LLT, DUID-EN, DUID-LL and DUID-UUID.
Future specifications may introduce new DUID types.</para>
<para>The Kea DHCPv6 server generates a server identifier once, upon
the first startup, and stores it in a file. This identifier isn't
modified across restarts of the server and so is a stable identifier.</para>
<para>Kea follows recommendation from
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3315">RFC 3315</link>
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>
to use DUID-LLT as the default server identifier. However, we have
received reports that some deployments require different DUID
types, and there is a need to administratively select both DUID
@ -4520,40 +4518,48 @@ autogenerated IDs are not stable across configuration changes.
</section>
<section xml:id="dhcp6-rfc7550">
<title>Support for RFC 7550</title>
<title>Support for RFC 7550 (being now part of RFC 8415)</title>
<para>The <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc7550">RFC 7550</link>
introduced some changes to the DHCPv6 protocol to resolve a few issues
with the coexistence of multiple stateful options in the messages sent
between the clients and servers.</para>
<para>The typical example is when the client, such as a requesting
router, requests an allocation of both addresses and prefixes when
it performs the 4-way (SARR) exchange with the server. If the
server is not configured to allocate any prefixes but it can allocate
some addresses, it will respond with the IA_NA(s) containing allocated
addresses and the IA_PD(s) containing the NoPrefixAvail status code. If
the client can operate without prefixes it may transition to the
'bound' state when it sends Renew/Rebind messages to the server,
according to the T1 and T2 times, to extend the lifetimes of the
allocated addresses. If the client is still interested in obtaining
prefixes from the server it may also include an IA_PD in the Renew/Rebind
to request allocation of the prefixes. If the server still cannot
allocate the prefixes, it will respond with the IA_PD(s) containing
NoPrefixAvail status code. However, if the server can now allocate
the prefixes it will do so, and send them in the IA_PD(s) to the client.
Allocation of leases during the Renew/Rebind was not supported in the
introduced some changes to the previous DHCPv6 specifications,
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3315">RFC 3315</link>
and <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3633">RFC 3633</link>,
and has been introduced in
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc7550">RFC 7550</link>.
Kea supports this new behavior and it doesn't provide any configuration
mechanisms to disable it.
to resolve a few issues with the coexistence of multiple stateful
options in the messages sent between the clients and servers. Those
changes were later included in the most recent DHCPv6 protocol specification,
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>,
which obsoleted <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc7550">RFC 7550</link>.
Kea supports <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>
along with these protocol changes, which are briefly described below.
</para>
<para>When a client, such as a requesting router, requests an allocation
of both addresses and prefixes during the 4-way (SARR) exchange with the
server, and the server is not configured to allocate any prefixes but it
can allocate some addresses, it will respond with the IA_NA(s) containing
allocated addresses and the IA_PD(s) containing the NoPrefixAvail status code.
According to the updated specifications, if the client can operate without
prefixes it should accept allocated addresses and transition to
the 'bound' state. When the client subsequently sends Renew/Rebind messages
to the server, according to the T1 and T2 times, to extend the lifetimes of
the allocated addresses, if the client is still interested in obtaining
prefixes from the server, it may also include an IA_PD in the Renew/Rebind
to request allocation of the prefixes. If the server still cannot
allocate the prefixes it will respond with the IA_PD(s) containing
NoPrefixAvail status code. However, if the server can allocate the
prefixes it will allocate and send them in the IA_PD(s) to the client.
Similar situation occurs when the server is unable to allocate addresses
for the client but can delegate prefixes. The client may request allocation
of the addresses while renewing the delegated prefixes. Allocating leases for
other IA types while renewing existing leases is by default supported by
the Kea DHCPv6 server, and the server provides no configuration mechanisms
to disable this behavior.</para>
<para>
The following are the other behaviors specified in the
The following are the other behaviors first introduced in the
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc7550">RFC 7550</link>
supported by the Kea DHCPv6 server:
(now being part of the
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>)
and supported by the Kea DHCPv6 server:
<itemizedlist>
<listitem><simpara>Set T1/T2 timers to the same value for all
stateful (IA_NA and IA_PD) options to facilitate renewal of all
@ -4738,7 +4744,7 @@ autogenerated IDs are not stable across configuration changes.
<simpara><command>duid</command> - DHCPv6 uses DUID identifiers instead of
MAC addresses. There are currently four DUID types defined, with two of them
(DUID-LLT, which is the default one and DUID-LL) convey MAC address information.
Although <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="" utl="http://tools.ietf.org/html/rfc3315">RFC 3315</link> forbids
Although <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="" utl="http://tools.ietf.org/html/rfc8415">RFC 8415</link> forbids
it, it is possible to parse those DUIDs and extract
necessary information from them. This method is not completely reliable, as
clients may use other DUID types, namely DUID-EN or DUID-UUID.
@ -5496,6 +5502,12 @@ autogenerated IDs are not stable across configuration changes.
7598</ulink>: All options specified in this specification are
supported by the DHCPv6 server.</simpara>
</listitem>
<listitem>
<simpara><emphasis>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</emphasis>,
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>:
New DHCPv6 protocol specification which obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083,
RFC 7283 and RFC 7550</simpara>
</listitem>
</itemizedlist>
</section>
@ -5510,9 +5522,8 @@ autogenerated IDs are not stable across configuration changes.
<simpara>
The server will allocate, renew or rebind a maximum of one lease
for a particular IA option (IA_NA or IA_PD) sent by a client.
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3315">RFC 3315</link> and
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc3633">RFC 3633</link> allow
for multiple addresses or prefixes to be allocated for a single IA.
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc8415">RFC 8415</link>
allows for multiple addresses or prefixes to be allocated for a single IA.
</simpara>
</listitem>