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

diff --git a/doc/guide/classify.xml b/doc/guide/classify.xml
index 8ee002cbfae06c5d2f45030d5989bf08a3115fbf..595d17b5eafda8038ad99b96b3df9237923fc756 100644 (file)
--- a/doc/guide/classify.xml
+++ b/doc/guide/classify.xml
@@ -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

diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml
index 6bd21b49aaaf81f05d5024e366ae0d1d235e01af..709c35e1fb139ee6fa6c3123043fc19671302c33 100644 (file)
--- a/doc/guide/dhcp4-srv.xml
+++ b/doc/guide/dhcp4-srv.xml
@@ -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

diff --git a/doc/guide/dhcp6-srv.xml b/doc/guide/dhcp6-srv.xml
index f3e30db2df4441ea8157cf5f452d25ee9499f084..5c419a2c5d996b1aa98d1d4cdc0d7e8b370e19f8 100644 (file)
--- a/doc/guide/dhcp6-srv.xml
+++ b/doc/guide/dhcp6-srv.xml
@@ -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>