Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

[Tomek Mrugalski <[e-mail]>]

On 06.12.2019 08:21, Lorenzo Colitti wrote:
> On Fri, Dec 6, 2019 at 4:14 PM Jen Linkova <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     "If the pool is explicitly configured with a dedicated IPv4
>        address to be returned to IPv6-only capable clients the server MUST
>        specify that address as the client's network address and MUST NOT
>        verify its uniqueness.
>
>
> That seems difficult to implement on the server. Why not just return a
> normal OFFER from the pool? That way, if something unexpected happens
> and the client sends a DHCPREQUEST for it, the server can hand it out
> as normal.
>
> The alternative is risky. If the server uses a bogus OFFER value, and
> some client requests it and the server hands it out, that creates the
> possibility for misconfiguration or bugs to create really bad outcomes
> where multiple hosts have the same IP address, or some things on the
> network (e.g., snooping switches) think that multiple hosts have the
> same IP address. +Tomek Mrugalski
> <mailto:[e-mail]> any thoughts on whether this can
> be implemented easily and reliably on the server side?

I would go with a normal OFFER from the pool. Some servers (such as Kea)
don't reserve the address at all when sending back OFFERS. This seems
like the most robust approach. Clients that correctly implement the
draft would never send a REQUEST for addresses offered. Buggy clients
that implement the draft in a broken way and request the address, would
simply get the address and the server will continue offering other
addresses to IPv6-only Preferred capable clients. In Kea, sending an
address from a pool would work out of the box and not a single address
would be allocated for ipv6-only preferred clients.

The alternative (bogus address or small pool of just one address) is
much more tricky to set up and there may be messy corner cases. Every
DHCP server I know does various checks if the address belongs to a pool
(so setting something completely out of the range could break down
various mechanisms), it could mess up statistics and thresholds. The
fundamental role every DHCP server is supposed to play is to ensure that
the addresses are not duplicated and there are many mechanisms to help
ensure that. If we decided to go with bogus address shared by all
ipv6-only preferred clients, most (all?) of such mechanisms would have
to be conditionally disabled. Let's not do that.

Tomek