| Subject: | Add EUI-64 address assignment policy |
Excerpted from support ticket 10833:
Here is the description of the short-term patch we need:
1. If a host declaration exists for the DUID, the server grants the address (fixed-prefix6, fixed-address6) according to the host declaration, regardless of the DUID type of the client (even for DUID type 3 devices)
2. On a /64 subnet6/pool6 (with full range6 – it has to have the whole network available for the address space ), whenever a client with a DUID type 3, HW Type EUI-64 requests an address (IA_NA ), it will be granted an IPv6 calculated out of the EUI-64 link layer address, conforming to RFC 2373, except if there is a host declaration for this client-id.
3. On a /64 subnet6, any client with a non-conforming DUID (not type 3 or not hw type EUI-64) that is not linked to a host declaration, will be ignored and the event will be logged (I don't think there is a way to decline the request in dhcpv6 protocol definition, correct?)
4. On a /64 subnet6, any client with a DUID 3, HW Type EUI-64, requesting a solicit/renew and including IA_NA that do not match the EUI-64 policy, will have the suggested IA_NAs ignored and will receive a new address in conformance to the EUI-64 policy
5. Once the policy is in place, whenever a new device requests a lease, and even if the server has knowledge of a previously granted IPv6 address that conflicts with a new EUI-64 based address (old IPv6 calculated out of the MD5 hash), it should grant the new address to the new device.
This is supposed to work with rapid commit enabled.
Mid-term solution should also include:
1. EUI-64 policy configured per subnet6/ pool6
a. Should throw an error if pool is not a /64 or doesn’t have the full range
2. Option to not store the lease on lease DB when EUI-64 policy is enabled. Since this is pretty much like a reservation, there is little value in having it stored in the DB. Making it optional would be ideal