--- /dev/null
+[func]* fdupont
+ Added support fo the last DHCP RFC 9915 including
+ the deprecation of the unicast option.
+ (Gitlab #4368)
authentication-domain-name (variable length): The authentication
domain name of the encrypted DNS resolver. This field is
- formatted as specified in Section 10 of [RFC8415].
+ formatted as specified in Section 10 of [RFC9915].
Addr Length: Length of included IPv4 addresses in octets. When
present, it MUST be a multiple of 4.
server-address The IP address to which the client should send
messages delivered using unicast.
+
+ ***NOTE***: this option was deprecated by RFC9915.
*/
// Type: IPv6 address
{
authentication-domain-name (variable length): A fully qualified
domain name of the encrypted DNS resolver. This field is
- formatted as specified in Section 10 of [RFC8415].
+ formatted as specified in Section 10 of [RFC9915].
Addr Length: Length of enclosed IPv6 addresses in octets. When
present, it MUST be a multiple of 16.
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://datatracker.ietf.org/doc/html/rfc8415#section-21.17>`__). "Vendor
+ 9915 <https://datatracker.ietf.org/doc/html/rfc9915#section-21.17>`__). "Vendor
class option" means the Vendor-Identifying Vendor Class Option in DHCPv4
(code 124; see `Section 3 of RFC
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://datatracker.ietf.org/doc/html/rfc8415#section-21.16>`__). Vendor
+ 9915 <https://datatracker.ietf.org/doc/html/rfc9915#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
option[60] expression.
- `RFC 3925 <https://datatracker.ietf.org/doc/html/rfc3925>`__ and `RFC
- 8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__ allow for multiple
+ 9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__ 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``
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://datatracker.ietf.org/doc/html/rfc4361>`__ gives the recommendation
-to use a DUID (see `RFC 8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__,
+to use a DUID (see `RFC 9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__,
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
.. note::
- The unicast option was deprecated by the last DHCPv6 RFC.
+ The unicast option was deprecated by the last DHCPv6 RFC, trying
+ to add one in responses triggers a warning and the server no
+ longer accepts unicast direct queries (vs unicast relayed queries).
The example above
includes a server unicast option specification which causes the
----------------------------------
Subnets may also be configured to delegate prefixes, as defined in `RFC
-8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__, section 6.3. A subnet may
+9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__, 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
| addr-reg-enable | 148 | empty | false |
+--------------------------+-----------------+-----------------+-----------------+
+The unicast option was deprecated by the last DHCPv6 RFC, it is still
+supported but not be used and will be removed in a further Kea release.
+
Options marked with (1) have option definitions, but the logic behind
them is not implemented. That means that, technically, Kea knows how to
parse them in incoming messages or how to send them if configured to do
Controlling the Values Sent for T1 and T2 Times
-----------------------------------------------
-According to RFC 8415, section 21.4, the recommended T1 and T2 values
+According to RFC 9915, section 21.4, the recommended T1 and T2 values
are 50% and 80% of the preferred
lease time, respectively. Kea can be configured to send values that are
specified explicitly or that are calculated as percentages of the
- ``t1-percent`` - the percentage of the valid lease time to use for
T1. It is expressed as a real number between 0.0 and 1.0 and must be
- less than ``t2-percent``. The default value is 0.5, per RFC 8415.
+ less than ``t2-percent``. The default value is 0.5, per RFC 9915.
- ``t2-percent`` - the percentage of the valid lease time to use for
T2. It is expressed as a real number between 0.0 and 1.0 and must be
- greater than ``t1-percent``. The default value is 0.8 per RFC 8415.
+ greater than ``t1-percent``. The default value is 0.8 per RFC 9915.
.. note::
------------
The Rapid Commit option, described in `RFC
-8415 <https://datatracker.ietf.org/doc/html/rfc8415>`__, is supported by the Kea
+9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__, 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:
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://datatracker.ietf.org/doc/html/rfc8415>`__ currently
+same link. `RFC 9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__ 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://datatracker.ietf.org/doc/html/rfc8415>`__ to use DUID-LLT as the
+9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__ 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.
.. _dhcp6-rfc7550:
-Support for RFC 7550 (now part of RFC 8415)
+Support for RFC 7550 (now part of RFC 9915)
===========================================
`RFC 7550 <https://datatracker.ietf.org/doc/html/rfc7550>`__ introduced some
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://datatracker.ietf.org/doc/html/rfc8415>`__, which obsoleted `RFC
+9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__, 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
+9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__ along with these protocol
changes, which are briefly described below.
When a client, such as a requesting router, requests an allocation of
The following are the other behaviors first introduced in `RFC
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
+9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__) 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://datatracker.ietf.org/doc/html/rfc8415>`__
+ information. Although `RFC 9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__
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
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://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
+- *Dynamic Host Configuration Protocol for IPv6 (DHCPv6)*, `RFC 9915
+ <https://datatracker.ietf.org/doc/html/rfc9915>`__: This new DHCPv6 protocol specification
+ obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, RFC 7550,
+ and RFC 8415.. 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
- 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://datatracker.ietf.org/doc/html/rfc8415>`__ allows for multiple
+ 9915 <https://datatracker.ietf.org/doc/html/rfc9915>`__ 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://datatracker.ietf.org/doc/html/rfc8415>`__.
+ implement this feature, as it is deprecated in `RFC 9915
+ <https://datatracker.ietf.org/doc/html/rfc9915>`__.
- Client reconfiguration (RECONFIGURE) is not yet supported.
addrtotext(substring(option[25].option[26].hex, 9, 16))
All other parameters of the options are available at their respective offsets
-in the option. Please read RFC8415 for more details.
+in the option. Please read RFC9915 for more details.
Examples:
extern const isc::log::MessageID DHCP6_ADDR6_REGISTER_DISABLED_DROP = "DHCP6_ADDR6_REGISTER_DISABLED_DROP";
extern const isc::log::MessageID DHCP6_ADDR_REG_INFORM_CLIENT_CHANGE = "DHCP6_ADDR_REG_INFORM_CLIENT_CHANGE";
extern const isc::log::MessageID DHCP6_ADDR_REG_INFORM_FAIL = "DHCP6_ADDR_REG_INFORM_FAIL";
+extern const isc::log::MessageID DHCP6_ADD_DEPRECATED_UNICAST = "DHCP6_ADD_DEPRECATED_UNICAST";
extern const isc::log::MessageID DHCP6_ADD_GLOBAL_STATUS_CODE = "DHCP6_ADD_GLOBAL_STATUS_CODE";
extern const isc::log::MessageID DHCP6_ADD_STATUS_CODE_FOR_IA = "DHCP6_ADD_STATUS_CODE_FOR_IA";
extern const isc::log::MessageID DHCP6_ALREADY_RUNNING = "DHCP6_ALREADY_RUNNING";
"DHCP6_ADDR6_REGISTER_DISABLED_DROP", "ADDR-REG-INFORM from %1 was dropped because address registration is disabled.",
"DHCP6_ADDR_REG_INFORM_CLIENT_CHANGE", "received an ADDR-REG-INFORM for %1 from client '%2' but the address was registered by another client '%3'",
"DHCP6_ADDR_REG_INFORM_FAIL", "error on ADDR-REG-INFORM from client %1, %2",
+ "DHCP6_ADD_DEPRECATED_UNICAST", "%1: adding deprecated unicast option",
"DHCP6_ADD_GLOBAL_STATUS_CODE", "%1: adding Status Code to DHCPv6 packet: %2",
"DHCP6_ADD_STATUS_CODE_FOR_IA", "%1: adding Status Code to IA with iaid=%2: %3",
"DHCP6_ALREADY_RUNNING", "%1 already running? %2",
extern const isc::log::MessageID DHCP6_ADDR6_REGISTER_DISABLED_DROP;
extern const isc::log::MessageID DHCP6_ADDR_REG_INFORM_CLIENT_CHANGE;
extern const isc::log::MessageID DHCP6_ADDR_REG_INFORM_FAIL;
+extern const isc::log::MessageID DHCP6_ADD_DEPRECATED_UNICAST;
extern const isc::log::MessageID DHCP6_ADD_GLOBAL_STATUS_CODE;
extern const isc::log::MessageID DHCP6_ADD_STATUS_CODE_FOR_IA;
extern const isc::log::MessageID DHCP6_ALREADY_RUNNING;
message failed. The address of the client, usually also the address to
register, and the description of the problem are printed.
+% DHCP6_ADD_DEPRECATED_UNICAST %1: adding deprecated unicast option
+The warning is logged when the deprecated unicast option is added
+to a response which is displayed. Outside testing purpose the
+server configuration should be fixed as unicast queries are no
+longer accepted.
+
% DHCP6_ADD_GLOBAL_STATUS_CODE %1: adding Status Code to DHCPv6 packet: %2
Logged at debug log level 50.
This message is logged when the server is adding the top-level
opt, cclasses);
// Got it: add it and jump to the outer loop.
if (desc.option_) {
+ if (opt == D6O_UNICAST) {
+ LOG_WARN(dhcp6_logger, DHCP6_ADD_DEPRECATED_UNICAST)
+ .arg(answer->getLabel());
+ }
answer->addOption(desc.option_);
break;
}
// Lease types that correspond to ADDRESS6 leases
static const Lease::Type LEASETYPE6[] = {
Lease::TYPE_NA, Lease::TYPE_PD, Lease::TYPE_NA, Lease::TYPE_PD,
- Lease::TYPE_NA, Lease::TYPE_PD, Lease::TYPE_NA, Lease::TYPE_PD
+ Lease::TYPE_PD, Lease::TYPE_NA, Lease::TYPE_PD, Lease::TYPE_NA
};
GenericLeaseMgrTest::GenericLeaseMgrTest()
// Set the address of the lease
lease->addr_ = IOAddress(address);
- // Set other parameters. For historical reasons, address 0 is not used.
+ // Set other parameters.
if (address == straddress4_[0]) {
lease->hwaddr_.reset(new HWAddr(vector<uint8_t>(6, 0x08), HTYPE_ETHER));
lease->client_id_ = ClientIdPtr(new ClientId(vector<uint8_t>(8, 0x42)));
// Set the address of the lease
lease->addr_ = IOAddress(address);
- // Set other parameters. For historical reasons, address 0 is not used.
+ // Set other parameters.
if (address == straddress6_[0]) {
lease->hwaddr_.reset(new HWAddr(vector<uint8_t>(6, 0x08), HTYPE_ETHER));
lease->type_ = leasetype6_[0];
lease->fqdn_fwd_ = false;
lease->fqdn_rev_ = true;
lease->hostname_ = "myhost.example.com.";
- lease->pool_id_ = 7;
} else if (address == straddress6_[2]) {
lease->hwaddr_.reset(new HWAddr(vector<uint8_t>(6, 0x2a), HTYPE_ETHER));
lease->fqdn_fwd_ = false;
lease->fqdn_rev_ = false;
lease->hostname_ = "myhost.example.com.";
+ lease->pool_id_ = 7;
} else if (address == straddress6_[3]) {
// Hardware address same as lease 1.
lease->hwaddr_.reset(new HWAddr(vector<uint8_t>(6, 0x4c), HTYPE_ETHER));
// Same DUID and IAID as straddress6_1
lease->type_ = leasetype6_[4];
- lease->prefixlen_ = 128;
+ lease->prefixlen_ = 56;
lease->iaid_ = 42;
lease->duid_ = DuidPtr(new DUID(vector<uint8_t>(8, 0x42)));
lease->preferred_lft_ = 4800;
lease->hwaddr_.reset(new HWAddr(vector<uint8_t>(6, 0x19), HTYPE_ETHER));
// Same DUID and IAID as straddress6_1
lease->type_ = leasetype6_[5];
- lease->prefixlen_ = 56;
+ lease->prefixlen_ = 128;
lease->iaid_ = 42; // Same as lease 4
lease->duid_ = DuidPtr(new DUID(vector<uint8_t>(8, 0x42)));
// Same as lease 4
lease->hwaddr_.reset(new HWAddr(vector<uint8_t>(6, 0x6e), HTYPE_ETHER));
// Same DUID as straddress6_1
lease->type_ = leasetype6_[6];
- lease->prefixlen_ = 128;
+ lease->prefixlen_ = 56;
lease->iaid_ = 93;
lease->duid_ = DuidPtr(new DUID(vector<uint8_t>(8, 0x42)));
// Same as lease 4
lease->hwaddr_.reset(new HWAddr(vector<uint8_t>(), HTYPE_ETHER)); // Empty
// Same IAID as straddress6_1
lease->type_ = leasetype6_[7];
- lease->prefixlen_ = 56;
+ lease->prefixlen_ = 128;
lease->iaid_ = 42;
lease->duid_ = DuidPtr(new DUID(vector<uint8_t>(8, 0xe5)));
lease->preferred_lft_ = 5600;
TrackingLeaseMgr::TRACK_ADD_LEASE,
SUBNET_ID_GLOBAL, ph::_1));
// Add a lease. It should trigger the callback.
- Lease6Ptr lease = initializeLease6(straddress6_[2]);
+ Lease6Ptr lease = initializeLease6(straddress6_[1]);
EXPECT_TRUE(lmptr_->addLease(lease));
// Make sure that the callback has been invoked.
TrackingLeaseMgr::TRACK_UPDATE_LEASE,
SUBNET_ID_GLOBAL, ph::_1));
// Add a lease.
- Lease6Ptr lease = initializeLease6(straddress6_[2]);
+ Lease6Ptr lease = initializeLease6(straddress6_[1]);
EXPECT_TRUE(lmptr_->addLease(lease));
EXPECT_TRUE(logs_.empty());
TrackingLeaseMgr::TRACK_DELETE_LEASE,
SUBNET_ID_GLOBAL, ph::_1));
// Add a lease.
- Lease6Ptr lease = initializeLease6(straddress6_[2]);
+ Lease6Ptr lease = initializeLease6(straddress6_[1]);
EXPECT_TRUE(lmptr_->addLease(lease));
EXPECT_TRUE(logs_.empty());
void testBigStats();
/// @brief Checks that the static functions updateStatsOn{Add,Update,Delete)
- /// work for v4.
+ /// work for v4.
void testUpdateStatsOn4SameSubnet();
void testUpdateStatsOn4DifferentSubnet();
projects / thirdparty / kea.git / commitdiff
