[#2984] Updated doc

diff --git a/doc/sphinx/arm/ext-radius.rst b/doc/sphinx/arm/ext-radius.rst
index 16653d221a5758ae8cd8c6804294967a36298d41..17ff5461c2e12ab69a597c5cb5b6205aa7a8da63 100644 (file)
--- a/doc/sphinx/arm/ext-radius.rst
+++ b/doc/sphinx/arm/ext-radius.rst
@@ -30,9 +30,10 @@ Access-Request to the RADIUS server and waits for a response. The server
 then sends back either an Access-Accept with specific client attributes,
 or an Access-Reject. There are two cases supported here: first, the
 Access-Accept includes a Framed-IP-Address attribute (for DHCPv4) or a
-Framed-IPv6-Address attribute (for DHCPv6), which are interpreted by Kea as
-instructions to assign the specified IPv4 or IPv6 address. This
-effectively means RADIUS can act as an address-reservation database.
+Framed-IPv6-Address attribute or a Delegated-IPv6-Prefix (for DHCPv6),
+which are interpreted by Kea as instructions to assign the specified IPv4
+or IPv6 address, or IPv6 prefix. This effectively means RADIUS can act
+as an address-reservation database.
 
 The second supported case is the ability to assign clients to specific
 pools based on a RADIUS response. In this case, the RADIUS server sends
@@ -40,7 +41,7 @@ back an Access-Accept with a Framed-Pool attribute.
 For both DHCPv4 and DHCPv6, Kea interprets this attribute as a client class.
 With the addition of the ability to limit access to pools to
 specific classes (see :ref:`classification-pools`), RADIUS can be
-used to force the client to be assigned a dynamic address from a
+used to force the client to be assigned a dynamic address or prefix from a
 specific pool. Furthermore, the same mechanism can be used to control
 what kind of options the client gets if there are DHCP options
 specified for a particular class.