Re: [v6ops] IPv6-Only Preferred DHCPv4 option

["Bernie Volz (volz)" <[e-mail]>]

We already don’t commit to disk per rfc2131 and use a short, tuneable time-out. So, again, we are all set without server changes.

You can also classify these devices into a separate client class to reduce timeout for them (such as to a few seconds).

Again, I see no need for special server changes.

If a server doesn’t provide for these mechanics, the server should. But this is configuration issue, not protocol issue.

- Bernie

> On Dec 9, 2019, at 8:56 AM, Ted Lemon <[e-mail]> wrote:
> 
> You said it yourself. If there’s a thundering herd, we don’t have to wait for them all to time out, because there’s no limit to how many answers we  can send prior to acknowledgment. We don’t need to write anything to disk to give an answer.
> 
> Plus, if something is snooping the DHCP exchange it won’t be able to take any inappropriate action because the signaling on which it would base that action is not present. 
> 
>> On Dec 8, 2019, at 22:40, Lorenzo Colitti <[e-mail]> wrote:
>> 
>> 
>> It sounds like you're arguing that the network should put 0.0.0.0 in the yiaddr field when sending an offer, even if doing so requires more server changes. What I don't understand though, is: why? What is the advantage of putting 0.0.0.0 in the offer? What do those server changes buy us?
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops