|
|
# Requirements for Reconfigure in Kea
|
|
|
|
|
|
## Introduction
|
|
|
IPv6 reconfiguration through DHCP is a server triggered mechanism for the clients to update their IPv6 addresses and prefixes. The idea is to make the clients renew their configuration by making them send an Information request/Renew message/Rebind message to the server when the server configuration changes. The server sends a Reconfigure message and specifies an option ( Information-request, Renew, Rebind ) to each of the clients in their network and the clients will initiate Information-request, Renew or Rebind message.
|
|
|
|
|
|
The update of client’s configuration will happen after the DHCP server replies to the client. The replies shall contain the updated addresses/prefixes and reduced preferred, valid lifetime for old IP. Prior to this feature, each IA ( Identity association ) had a single IP address/prefix for the client. IPv6 stack allows multiple IPv6 address to be used simultaneously. Hence the migration to the new address/prefix will be seen seamless because their existing connection will continue to use old address/prefix and the new connection shall be based on the updated address/prefix.
|
|
|
|
|
|
## Use case
|
|
|
**1. As a Kea admin, I want a command to send reconfigure message to a single client.**
|
|
|
|
|
|
**Requirements**
|
|
|
|
|
|
G1. The Kea-server shall support a command which takes DUID as an argument, along with options to /Rebind, Renew, Information Request/ and send Reconfigure message to the client.
|
|
|
|
|
|
''Rationale: The admin solely knows the configuration change in the network and be responsible for choosing the reconfiguration options options in the Reconfiguration message.''
|
|
|
|
|
|
G2. The Reconfigure message must contain authentication field as specified in RFC 3315 bis internet draft. The authentication field shall be constructed by retrieving the keys from the host reservation/configuration file for the system.
|
|
|
|
|
|
G3. The kea-server shall throw an error if the corresponding DUID for client is not valid in its database.
|
|
|
|
|
|
G4. The kea-server shall handle the unicast message for Information request resulting as a response to a previous Reconfigure message sent by the server.
|
|
|
|
|
|
G5. The kea-server shall construct Reconfigure message with Reconfiguration Message options to request for Information Request, Renewal, Rebind based on the admin request.
|
|
|
|
|
|
G6. The Kea server shall include Authentication field with values of protocol-3, algorithm-1, RDM-0, Replay value and {type = 1, HMAC MD5 checksum} while sending Reconfigure message.
|
|
|
|
|
|
|
|
|
**2. As a Kea admin, I want a command to send reconfigure message to all the clients in a given subnet.**
|
|
|
|
|
|
**Requirements**
|
|
|
|
|
|
G7. The Kea-server shall support a command which takes subnet as an argument and an option to send whether //Information Request,Rebind,Renew// option.
|
|
|
|
|
|
G8. The Kea-server must check if there are keys available for the client before sending Reconfigure message and abort sending Reconfigure message for the client if keys are missing.
|
|
|
''Rationale: It is assumed keys are already shared with the client during initial request / reply exchanges with the client. Keys may be auto-generated or configured by the admin. No mechanism exists to share keys while sending Reconfigure message. ''
|
|
|
|
|
|
G9. The Kea-server must continue to try sending messages to other clients in the subnet if sending of Reconfigure message fails for a given client in a given subnet.
|
|
|
|
|
|
**3. As a Kea admin, I want a command to send Reconfigure message to all clients in all subnets.**
|
|
|
|
|
|
**Requirements**
|
|
|
|
|
|
G10. The Kea-server shall support a command which can send Reconfigure message to all the clients on the server.
|
|
|
|
|
|
G11. All the Requirements under Use case 3 must hold good for this use case as well.
|
|
|
|
|
|
**4. As a Kea server, I want to respond with appropriate replies for the Information //Request, Renew, Rebind// message sent by the client as a part of //Reconfiguration-Renumbering// process only to the client to which Reconfigure message is sent.**
|
|
|
|
|
|
**Requirements**
|
|
|
|
|
|
G12. The Kea-server shall respond only to the //Information Request,Renewal,Rebind// from those clients for which Reconfigure message has been sent.
|
|
|
|
|
|
//Note: For the reconfiguration message sent the server shall maintain a list of clients for which a reconfigure message was sent and only to those clients the server shall respond with a reply for Rebind, Renew. This is necessary as the client may be requesting from a subnet which is non-existent due to reconfiguration (currently we send no binding error).//
|
|
|
|
|
|
|
|
|
**5. As a Kea admin, I want to configure Keys to be used in Authentication field for sending the Reconfiguration messages.**
|
|
|
|
|
|
**Requirements**
|
|
|
|
|
|
G13. The server shall support the configuration with a parameter name and value to be stored persistently in both host reservation and kea configuration file.
|
|
|
|
|
|
G14. The server shall not validate the keys at the time of the configuring the DHCP server.
|
|
|
|
|
|
G15. If the keys are invalid the sending of reconfiguration message will fail and an error will be propagated to the kea admin. Rationale: invalid keys are result of misconfiguration and will not be explicitly validated by the server during configuration thus saving configuration time. Validation will be done only by the cryptolibrary during construction of Authentication field.
|
|
|
|
|
|
**6. As a Kea server, I want to advertise the Reconfigure capability of the server.**
|
|
|
|
|
|
**Requirements**
|
|
|
|
|
|
G16. The Kea server shall include Reconfigure Accept options in Advertise and Reply messages as specified in the RFC 3315 section 21.2.
|
|
|
|
|
|
G17. The Kea server shall only support parsing Reconfigure Accept option but not store the reconfigure capabilities of the client in any of its internal data structure. Therefore the Kea server shall send the Reconfigure message to the clients irrespective of whether they support Reconfiguration message or not.
|
|
|
|
|
|
G18. The Kea server shall include Authentication field with values of protocol-3, algorithm-1, RDM-0, and {type = 1 + key information} in the authentication information field during an exchange with the client. (//Request- Reply, Solicit-Reply or Information-request-Reply// message exchange).
|
|
|
|
|
|
G19. The Kea server must auto-generate keys and include them in the initial responses to the messages sent by the server if the admin has not configured keys for the client.
|
|
|
As specified in section 20.3 Kea server must support Replay detection messages and related field. The RDM value must be consistent across restarts. |