From 8c1ce6673dd14e6bdcc49969ff18485d2f4f712c Mon Sep 17 00:00:00 2001 From: Marcin Siodelski Date: Wed, 5 Dec 2018 15:50:37 +0100 Subject: [PATCH] [288,!158] Updated user guide to reference to RFC 8415 rather than 3315. --- doc/guide/classify.xml | 10 ++--- doc/guide/dhcp4-srv.xml | 2 +- doc/guide/dhcp6-srv.xml | 87 +++++++++++++++++++++++------------------ 3 files changed, 55 insertions(+), 44 deletions(-) diff --git a/doc/guide/classify.xml b/doc/guide/classify.xml index 8ee002cbfa..595d17b5ea 100644 --- a/doc/guide/classify.xml +++ b/doc/guide/classify.xml @@ -660,12 +660,12 @@ option in DHCPv4 (code 125, see Section 4 of RFC 3925) and Vendor-specific Information Option in DHCPv6 (code 17, defined in - Section 22.17 of - RFC 3315). Vendor class option means Vendor-Identifying Vendor + Section 21.17 of + RFC 8415). Vendor class option means Vendor-Identifying Vendor Class Option in DHCPv4 (code 124, see Section 3 of RFC 3925) in DHCPv4 and Class Option in DHCPv6 (code 16, see - Section 22.16 of RFC 3315). + Section 21.16 of RFC 8415). 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. - RFC3925 and - RFC3315 + RFC 3925 and + RFC 8415 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 6bd21b49aa..709c35e1fb 100644 --- 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, RFC 4361 gives the recommendation to use a DUID - (see RFC 3315, + (see RFC 8415, 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 f3e30db2df..5c419a2c5d 100644 --- a/doc/guide/dhcp6-srv.xml +++ b/doc/guide/dhcp6-srv.xml @@ -2060,7 +2060,7 @@ should include options from the isc option space:
Rapid Commit The Rapid Commit option, described in - RFC 3315, is supported + RFC 8415, 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 rapid-commit parameter as shown below: @@ -4245,18 +4245,16 @@ autogenerated IDs are not stable across configuration changes. 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. - RFC 3315 - defines three DUID types: DUID-LLT, DUID-EN and DUID-LL. - RFC 6355 - also defines DUID-UUID. Future specifications may introduce new - DUID types. + RFC 8415 + defines four DUID types: DUID-LLT, DUID-EN, DUID-LL and DUID-UUID. + Future specifications may introduce new DUID types. 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. Kea follows recommendation from - RFC 3315 + RFC 8415 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.
- Support for RFC 7550 + Support for RFC 7550 (being now part of RFC 8415) The RFC 7550 - 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. - - 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, RFC 3315 and RFC 3633, - and has been introduced in - RFC 7550. - 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, + RFC 8415, + which obsoleted RFC 7550. + Kea supports RFC 8415 + along with these protocol changes, which are briefly described below. + 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. + - The following are the other behaviors specified in the + The following are the other behaviors first introduced in the RFC 7550 - supported by the Kea DHCPv6 server: + (now being part of the + RFC 8415) + and supported by the Kea DHCPv6 server: 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. duid - 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 RFC 3315 forbids + Although RFC 8415 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: All options specified in this specification are supported by the DHCPv6 server. + + Dynamic Host Configuration Protocol for IPv6 (DHCPv6), + RFC 8415: + New DHCPv6 protocol specification which obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, + RFC 7283 and RFC 7550 +
@@ -5510,9 +5522,8 @@ autogenerated IDs are not stable across configuration changes. 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. - RFC 3315 and - RFC 3633 allow - for multiple addresses or prefixes to be allocated for a single IA. + RFC 8415 + allows for multiple addresses or prefixes to be allocated for a single IA. -- 2.47.2