This document defines the requirements for shared subnet, a feature implemented in Kea 1.3. See SharedSubnetsDesign for the design. This feature allows a DHCP server to have two or more subnets configured on the same physical link.
It does not allow the server to share the same subnet over multiple links (this is something you already can do to some degree by splitting your subnet into smaller ones).
DHCP servers use subnet information for two purposes: first is topology detection (the server has to understand where the client is located in the network) and second is lease assignment (the server has to choose specific address for a client). In a typical scenario, there is a physical network and for each physical link there is exactly one IP subnet assigned. Clients physically connected to that segment will get assigned an address from that subnet.
However, there are some cases when there is a need to run multiple IP subnets on the same physical link. This poses a challenge for the server, as it must be able to understand that two disjoint IP subnets are really the same from physical (topological) point of view.
The most common use seem to be an IPv4 network, perhaps in an office or a campus. Certain IPv4 subnet, e.g. /24, has been assigned to a physical link, e.g. one floor in an office. With new devices being connected reaches 254, the address space runs out. A sysadmin wants to configure an additional /24 subnet on top of existing one, without disrupting existing configuration of existing devices or much less renumber the whole network. The server is supposed to know that both devices from the old and new subnet are physically connected to the same link and dynamically start using the second subnet once the first one is full.
Cable networks. In cable networks there are two types of devices connected: cable modems (CMs) and other devices connected behind them. Typically ISPs use different subnet for CMs, so users won't be able to fiddle with their CMs management interfaces. In this use case, there is a clear distinction between devices and it is immediately known whether a request should be assigned to one subnet or another.
Changing IPv6 addressing schemes. Although IPv6 is not expected to run out of address space, there are use cases for shared subnets in IPv6. Vast address space lets sysadmins to design their addressing scheme. Once deployed, it sometimes becomes apparent that a different addressing scheme would be better. Instead of transitioning abruptly to a new scheme, both old and new ones are being run in parallel for some time. This scenario is sometimes called renumbering.
Multiple addresses to containers. TODO need a description of this use case.
Datacenters using shared subnets instead of VLANs. There are datacenter deployments that hold machines (be it bare metal or VMs) owned or leased by different customers. Typically each customer gets his own VLAN, but due to VLAN limitations (limited number of vlans, tricky management), some deployment use shared networks. In this deployment scenario, many customers have many devices located in different places. The subnet selection is based on who owns a device rather than where it is physically located. This usually requires an additional database.
'''Subnet''' - an IPv4 or IPv6 subnet, which is a block of continuous address space.
'''Single Subnet''' - a subnet that is not part of shared network.
'''Shared network''' - a set of more than one subnets configured on the same physical link. A shared network consisting of only one subnet is considered a configuration error, but it may be permitted for testing purposes.
'''Subnet selection''' - a process conducted by Kea as one of the early processing steps for incoming packet.
The overall requirement is that the implementation should work as close as possible to what is being offered in ISC DHCP. If there are differences, those should be justified properly.
S.1. Shared network MUST be simple to understand and use.
S.2. Existing configuration of a single subnet MUST be extensible to case of shared network. In other words, it should be easy to add new subnet on top of existing subnet.
S.3. When the set of shared subnets is reduced to one, it MUST behave the same as if a single subnet was configured.
S.4. The shared subnets MUST be supported for both relayed and direct traffic.
S.5. It MUST be possible to segregate clients connected to shared network into specific subnets based on certain criteria (e.g. to handle use case 2). This distinction MUST NOT be mandatory (e.g. to handle use case 1). The server MUST be able to use all subnets in case of absence of classification criteria.
S.6. It SHOULD be possible to grant or reject access to a shared network based on a client class.
S.7. It SHOULD be possible to grant or reject access to subnet based on a client class.
S.8. It MUST be possible to specify options based for each subnet in a shared network separately. This is especially important for subnet-specific options, like default gateway.
S.9. It SHOULD be possible to specify options for the whole shared network. If options are specified both on shared network and specific subnet within it, the values from specific subnet take precedence.
S.10. One subnet can belong to at most one shared network.
Additional engineering requirements:
E.1. The shared network implementation SHOULD take advantage of existing code when possible.
E.2. Kea is a complex system and its complexity increases over time. Where feasible, the simplest solution SHOULD be chosen.
E.3. The solution SHOULD minimize DB schema changes, if possible.
E.4. Configuration of a shared network consisting of just one subnet is considered a (benign) configuration error. This case MAY be permitted for testing reasons, but warning should be produced.
E.5. Where possible, the additional logic behind shared subnets SHOULD be implemented in hook library. The reason for this is that people who do not want to use it (which seems to be the majority of deployments), would simply not load it.