|
|
# Design for DHCPv6 Reconfiguration Feature
|
|
|
|
|
|
## Scope
|
|
|
|
|
|
The Document describes the administrator's operational steps, internal mechanism for handling the reconfiguration along with command design and configuration changes.
|
|
|
|
|
|
A brief introduction and requirement for the reconfigure feature can be found at
|
|
|
|
|
|
[[wiki:ReconfigureRequirements]].
|
|
|
|
|
|
## Operation steps for the admin and Server's internal mechanism for Reconfiguration operation
|
|
|
|
|
|
**Step 1**
|
|
|
The Admin shall enable the Reconfigure feature through a flag(mandatory) and configure Keys for the clients in the host reservation(optional).
|
|
|
This is necessary prior to at least T1 and T2 expiry of the clients which needs to be reconfigured. This ensures Keys are exchanged during the Replies for the Renew, Rebind requests.
|
|
|
'''Internal mechanism:''' The Kea server shall use the host reservation for storing the keys for clients. Once the feature is enabled through internal flag any replies by the server as specified in the RFC shall contain keys needed for reconfiguration. If the Keys are not defined by the admin the server shall generate solely based on the feature flag enabled. The generated keys shall be stored in the host reservation internally. If no host reservation is defined for the client a new host reservation shall be defined which shall only contain keys.
|
|
|
|
|
|
The key generation shall be done when the server parses option reconfigure accept as specified in the RFC. This indicates the client is willing to accept the Reconfiguration message.
|
|
|
|
|
|
Transmission of reconfigure message must be unicast as specified in the RFC. So its necessary to store the link local address and the interface to which the client is connected for sending the reconfigure message (relays are not discussed as of now).
|
|
|
This will finally result in having host reservation defined for every client in the network once the feature is enabled.
|
|
|
|
|
|
**Step 2**
|
|
|
Admin applies new configuration with new Subnet/ DNS Server, FQDN, NTP servers. The admin shall issue a command to the Kea server with arguments of renew, rebind, information request for a set of clients.
|
|
|
|
|
|
'''Internal mechanism:''' The server upon receiving the request shall reduce the lifetime of the assigned leases immediately for the clients(This step could have been executed while processing the Renew/Rebind Request however it could be possible that client might not respond at all due to various reasons. This method hence ensures the IP addresses validity expires regardless of the client's response). The preferred lifetime shall be set to 0, valid lifetime shall be set to a random value less than T1 but greater than the maximum time required for the client to respond to the Reconfigure message.
|
|
|
|
|
|
* The server shall maintain a list of clients for which has been listed for Reconfiguring the client. This list will be useful for deciding during processing of the requests of the clients described later.
|
|
|
* The server will construct the reconfigure message.
|
|
|
* The server will calculate MD5 checksum for the Reconfigure message using the existing keys and openssl api and populate the authentication field. If the keys are missing/ corrupt the server shall abort the transmission of reconfigure message to the particular client and resume sending Reconfigure message for the other clients.
|
|
|
|
|
|
''Typical use cases where the admin shall use the Reconfigure message options''
|
|
|
|
|
|
* The admin shall issue option of Renew when there is a Subnet / IP address change in the network
|
|
|
* The admin shall issue option of Rebind when there the server will no longer serve clients and the new leases shall be issued by the other servers in the network.
|
|
|
* The admin shall issue option of information request when there is a change in the DNS server, NTP server, FQDN updates, vendor-specific options.
|
|
|
|
|
|
|
|
|
**Step 3**
|
|
|
The client processes the Reconfigure message and sends a Renew/ Rebind / Information Request to the server. ===
|
|
|
|
|
|
'''Internal mechanism:''' The server upon receiving the Renew / Rebind. Discovers that the message is not from a valid subnet(since the configuration has been updated). The server checks if the client is on the list of clients it sent Reconfigure message. If it's true then the server shall include multiple addresses/prefixes in the IA. It shall contain 2 set of addresses. One set of address having reduced valid lifetime of old IP and zero preferred lifetime which is extracted from the lease, next set of address with new IP and configured valid and preferred lifetime extracted from the configuration. The server will assign a new lease to the address/prefix assigned. In this way, the old lease shall expire gracefully and the client will be assigned to the new lease. These multiple addressed/prefixes are sent in the Reply message of the server.
|
|
|
|
|
|
|
|
|
|
|
|
## Command Examples
|
|
|
There are 3 cases to be supported here:
|
|
|
|
|
|
### Use case 1: Send reconfigure to a single client
|
|
|
|
|
|
Proposed command syntax:
|
|
|
```c++
|
|
|
{{{
|
|
|
{
|
|
|
“command” : “send-reconfigure"
|
|
|
"arguments": {
|
|
|
"duid": "01:02:03:04:05:06:07:08",
|
|
|
"subnet-id": 123,
|
|
|
"reconfigure-mode": "renew"
|
|
|
}
|
|
|
}
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Proposed response syntax:
|
|
|
```c++
|
|
|
{{{
|
|
|
{
|
|
|
"result": 0,
|
|
|
"text": "Reconfigure procedure initiated: RENEW message sent to IP address 2001:db8::123\
|
|
|
to a client with duid 01:02:03:04:05:06:07:08"
|
|
|
}
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
or
|
|
|
```c++
|
|
|
{{{
|
|
|
{
|
|
|
"result": 1,
|
|
|
"text": "Unable to send Reconfigure: no such client currently active"
|
|
|
}
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Note that reconfigure-mode takes one of three values: renew, rebind, inf-request. The parameter is optional. If not specified, "renew" value is assumed.
|
|
|
|
|
|
### Use case 2: Send reconfigure to all clients in a single subnet
|
|
|
|
|
|
Proposed command syntax:
|
|
|
```c++
|
|
|
{{{
|
|
|
{
|
|
|
“command” : “send-reconfigure"
|
|
|
"arguments": {
|
|
|
"subnet-id": 123,
|
|
|
"reconfigure-mode": "renew"
|
|
|
}
|
|
|
}
|
|
|
}}}
|
|
|
```
|
|
|
Note that reconfigure-mode takes one of three values: renew, rebind, inf-request. The parameter is optional. If not specified, "renew" value is assumed.
|
|
|
|
|
|
Proposed response syntax:
|
|
|
```c++
|
|
|
{{{
|
|
|
{
|
|
|
"result": 0,
|
|
|
"text": "Reconfigure procedure initiated: Sent REBIND message(s) to 5 clients, skipped\
|
|
|
2 clients due to not having keys or not supporting reconfigure.",
|
|
|
"reconf-success": 5,
|
|
|
"reconf-skip": 2,
|
|
|
"client-duids": [ "01:02:03:04", "aa:bb:cc:dd:ee", "1a:2b:3c:4d:5e:6f" ]
|
|
|
}
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
### Use case 3: Send reconfigure to all clients in all subnets
|
|
|
|
|
|
Proposed command syntax:
|
|
|
```c++
|
|
|
{{{
|
|
|
{
|
|
|
“command” : “send-reconfigure"
|
|
|
"arguments": {
|
|
|
"reconfigure-mode": "renew"
|
|
|
}
|
|
|
}
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Note that reconfigure-mode takes one of three values: renew, rebind, inf-request. The parameter is optional. If not specified, "renew" value is assumed. If reconfigure-mode is not specified, the whole arguments scope can be omitted.
|
|
|
|
|
|
Proposed response syntax is the same as for use case 2.
|
|
|
|
|
|
## Proposed Configuration
|
|
|
|
|
|
Existing Host structures will be extended to be able to store reconfigure keys, linklocal, interface. This field will be optional. If specified, Kea will use that specific value. If not specified, kea will generate a random key and will set that value in existing host reservation. The server stores the linklocal addresses and interface as it parses the Reconfig Accept Option in Solicit, Request, Renew, Rebind, Information Request message.
|
|
|
```c++
|
|
|
{{{
|
|
|
|
|
|
"reservations": [
|
|
|
{
|
|
|
“duid”: "01:02:03:04:05:0A:0B:0C:0D:0E",
|
|
|
“key”: “<128_BIT_KEY>”,
|
|
|
"iface": "eth1",
|
|
|
"link-local":"FE80::01"
|
|
|
}
|
|
|
]
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Note: The feature will work best with host backends configured (mysql, postgres or cassandra). Without backend configured, Kea will update its in-memory information about host reservations. These will be lost after restart or shutdown, unless administrator saves them using config-write command or retrieves them and stores them somewhere using config-get command.
|
|
|
|
|
|
## Required code changes
|
|
|
1) Support for keys storage in Host objects and backend databases.
|
|
|
2) Extend parser to be able to parse keys.
|
|
|
3) Support of auth option.
|
|
|
4) Support for reconfigure-send (use cases 1,2 and 3) in dhcpsrv.
|
|
|
5) Implement support of storing interface info and link local ip of the client in user context needed for reconfiguration.
|
|
|
6) Implement parsing reconfigure accept options and sending reconfigure accept option in the messages.
|
|
|
|
|
|
## Tasks
|
|
|
Normally we would list the tasks here (see [https://kea.isc.org/wiki/RadiusDesign#Tickets radius desing] for example). However, since we're experimenting with github, there's a dedicated project for tracking this: [https://github.com/isc-projects/kea/projects/2 github project].
|
|
|
|
|
|
## Implemented code
|
|
|
|
|
|
As of August 2018, major parts of the code are now implemented. Chunks of the code that was already accepted is on [master](../tree/master). The author has been properly [acknowledged here](https://gitlab.isc.org/isc-projects/kea/blob/master/AUTHORS). Additional code has been contributed on github and is in the process of review. |