Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Ted Lemon <[e-mail]>]

Lorenzo, it might help for you to make explicit why you do not want to require changes on the server. This seems like a short sicher choice for a solution that’s going to be deployed for a long time. Why not do it right given we’re going to have to live with it for decades?

> On Dec 6, 2019, at 08:35, Lorenzo Colitti <[e-mail]> wrote:
> 
> 
> On Sat, Dec 7, 2019 at 1:02 AM Ted Lemon <[e-mail]> wrote:
>>> which requires fewer changes on the DHCP server implementation
>> 
>> This is almost certainly not true.  In order for this to work, you’re going to have to have some special-purpose code to support it.  Better to do the clean solution than a hack that minimizes changes to the server at the expense of more complication in the client-server interaction.
> 
> I don't think this option requires any server changes other than the code to parse and serialize the option. That the server doesn't even need to know or care whether the client supports the option or not. At worst, it can simply blindly include the option on any pool that is configured to send it. Obviously, in the presence of buggy clients, the server should only send the option if it was requested, but servers typically already do that. The offer behaviour can stay the same: if the server gets a discover, it picks an address and responds with an offer from the pool. Per RFC 2131 section 3.1, that address need not be reserved, but it could be reserved for a brief time as well. Either works. If the client gets the option and decides it doesn't need IPv4, it won't send a request; after a while, the server can free the address if it had briefly reserved it. If the client wants IPv4, it will send a request and get an ack.
> 
> As Bernie says, if the pool is too small for the number of clients (which it will be, if this option is to be useful), and too many clients send discovers simultaneously (e.g., they're rebooted all at the same time), then the server will either not respond with offers to some of them, or will respond with offers and be forced to nak if two clients request the same address. Things continue to work.
> 
> The current text in the draft proposes an optimization on top of that:
> 
>    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.  Otherwise the server SHOULD follow the
>    recommendations in [RFC2131].  The client is not expected to use that
>    IPv4 address so if the client responds with the DHCPREQUEST message
>    for that address the server SHOULD respond with DHCPNAK.
> 
> This does indeed require code changes on the server side. But I think it would be good if such changes were optional. Additionally, this optimization creates the problem that if the client and responds to the nak with a discover, and the server replies with the same offer as before, then the client could gets stuck in a loop.
> 
>>> Personally, I would NOT recommend breaking the semantics of a DHCPOFFER and always include an address because you never know how intermediate devices that may be "snooping" this traffic will handle this; for example, the intermediate device might drop what it feels is an invalid packet.
>> 
>> This is definitely not an issue, though, because the network operator is choosing to deploy this.  They can be responsible for ensuring correct behavior if there are any middleboxes intercepting the DHCPv4 traffic and doing stuff with it.   Expecting this to Just Work with no infrastructure changes seems unnecessary.
> 
> I don't think this is a good justification for doing things that could break compatibility. It's true that the network operator is choosing to deploy this. But the network operator may not fully control all the devices on the network, and even if they do, fixing bugs is expensive: the bug needs to be reported, the vendor (assuming they're still around) might need to be convinced that it's a bug, code changes need to be made, the device may need to be updated to a substantially newer version, software needs to be re-qualified, etc. I agree with Bernie that if we can avoid changing the observed behaviour, that would be better.