DHCPv6 Prefix Length Mode

There has been much debate on various technical mailing lists about what the default prefix size should be for DHCPv6 prefix delegation. This post is not about what the prefix size should be, but about how you enable your DHCP server to provide an appropriate length prefix based on a “hint” from the client.

Background

The DHCPv6 protocol (including RFC 3315bis) allows a client to send an empty prefix with just a prefix length as a hint for the server specifying the desired prefix length.

According to RFC 3633, DHCPv6 clients may specify preferences when soliciting prefixes by including an IA_PD Prefix option within the IA_PD option. Among the preferences that may be conveyed is the “prefix-length”. The RFC states that servers “MAY choose to use the information…to select prefix(es)” but does not specify any particular rules for doing so. The prefix-length-mode statement can be used to set the prefix selection rules employed by the server, when clients send a non-zero prefix-length value. The mode parameter must be one of:

1. ignore - The requested length is ignored. The server will offer the first available prefix.
2. prefer - The server will offer the first available prefix with the same length as the requested length. If none are found then it will offer the first available prefix of any length.
3. exact - The server will offer the first available prefix with the same length as the requested length. If none are found, it will return a status indicating no prefixes available.
4. minimum - The server will offer the first available prefix with the same length as the requested length. If none are found, it will return the first available prefix whose length is greater than (e.g. longer than) the requested value. If none of those are found, it will return a status indicating no prefixes available. For example, if the client requests a length of /60, and the server has available prefixes of lengths /56 and /64, it will offer a prefix of length /64.
5. maximum - The server will offer the first available prefix with the same length as the requested length. If none are found, it will return the first available prefix whose length is less than (e.g. shorter than) the requested value. If none of those are found, it will return a status indicating no prefixes available. For example, if the client requests a length of /60, and the server has available prefixes of lengths /56 and /64, it will offer a prefix of length /56.

In general, “first available” is determined by the order in which pools are defined in the server’s configuration. For example, if a subnet is defined with three prefix pools A, B, and C:

subnet 3000::/64 { # pool A pool6 { : } # pool B pool6 { : } # pool C pool6 { : }}

then the pools will be checked in the order A, B, C. For modes prefer, minimum, and maximum, this may mean checking the pools in that order twice. A first pass through is made looking for an available prefix of exactly the preferred length. If none are found, then a second pass is performed starting with pool A but with appropriately adjusted length criteria.

ISC DHCP support

Support for this feature was implemented in ISC DHCP 4.3.1.

The directive is prefix-length-mode and the default is “exact”. The “exact” value was chosen as the default for backwards compatibility; it preserves the prior behavior.

This means that if the client requests a prefix length and that exact length is supported, it is granted. If the server is not configured to specify that exact prefix length, NoPrefixAvail is sent back.

EXAMPLE:

If the network is configured to give /64 by default with “prefer” and the client sends a /60 hint, it gets a /60. If the network is configured with the default “exact” behavior, the home gateway may not get any prefix if the network is only offering /64.

The “exact” behavior is difficult to use successfully, because client has to implement some non-trivial logic to retry without the hint if it receives a “NoPrefixAvail” response.

Change in default planned

RFC 8168 was published after the ISC DHCP 4.3.5 release. It clarifies what the server should do when a hint is received. “prefer” is not exactly what the RFC suggests, but it is closer than “exact”.

The “prefer” setting seems better than “exact” because the server will do its best to honor the hint, but will also give something if the hint cannot be honored. We will be changing ISC DHCP’s default behavior to “prefer” in a future release. (Planned for ISC DHCP 4.4.0)

Bugs found in ISC DHCP

DHCP is a rich environment for corner cases.

One issue addressed in ISC DHCP 4.3.6 was documented in the change log:

“The server now checks both the address and length of a prefix delegation when attempting to match it to a prefix pool. This ensures the server responds properly when pool configurations change such that once valid, “in-pool” delegations are now treated as being invalid. During lease-file loading at startup, the server will discard any PD leases that are deemed “out-of-pool” either by address or mis-matched prefix length.

Clients seeking to renew or rebind such leases will get a response of “No Binding” in the case of the former, and the prefix delegation with lifetimes set to zero in the case of the latter.

Thanks to Mark Nejedlo at TDS Telecom for reporting this issue.
[ISC-Bugs #35378]”

Another issue was recently reported when the client changes prefix size after obtaining a lease. This issue, found in ISC DHCP 4.3.6, was discussed on dhcp-users and then a bug was opened in ISC’s bug tracker. When a client released a /64 and requested a /60, ISC DHCP was returning the prior /64 lease. We plan to fix this issue in our next ISC DHCP release, 4.4.0.

Kea has not yet implemented prefix-length-mode

Kea supports prefix delegation, but currently, will ignore the prefix-length hint from a client. In Kea, subnet selection is based on network topology but prefix delegation is not necessarily related to subnet selection. As long as the administrator has configured some prefixes in pools, clients will be assigned the next available prefix in order until the pool is exhausted. At that point Kea will begin assigning prefixes from the next pool. We hope to implement prefix-length hint support in some future Kea release (this is not currently a high priority).

1. See RFC7934 and the discussion it created here: https://mailarchive.ietf.org/arch/msg/v6ops/5x3eUTkXR0lAdxoBf_ktUqhWgTE (74 posts so far)
2. draft-pioxfolks-6man-pio-exclusive-bit-02