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

[Roy Marples <[e-mail]>]

On 05/12/2019 03:48, Lorenzo Colitti wrote:
> On Thu, Dec 5, 2019 at 11:50 AM Roy Marples <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>      > The T2 timer is about the validity of the address that is offered
> 
>     Wrong.
>     The T2 timer addresses the lease as a whole. At this point the address
>     is just meta data, just like domain or dns servers.
> 
> 
> Regardless: the T2 timer is about the validity of the information that 
> is offered. The V6ONLY_WAIT timer is different: it's about when the 
> client should ask again if the client *does not request* the offer.

So in simple terms.
The server offers some information.
Given this information (in current DHCP semantics) we can RENEW (T1) or 
REBIND (T2).
If the client does not request the offer (hey! I see this new fangled 
option here that says NO DHCP) the client can still accept the T2 timer 
at the very least.

Think of the analogus RFC 7083 - Modification to Default Values of 
SOL_MAX_RT and INF_MAX_RT. This RFC goes out of its way not to add new 
timers.

>     Or at least V6ONLY_WAIT is at the very least badly worded, but DHCP
>     should not depend on any IPv6 settings - or vice versa. Is it too much
>     to ask to keep protocol setup separate?
> 
> 
> Then suggest a name that you like more? I can think of DISCOVER_WAIT and 
> INIT_WAIT, but I'm fine with any name that has WG consensus.
> 
>     As we're not offering an address in this situation, how is V6ONLY_WAIT
>     different from a timer source that cannot exist? As such, why invent a
>     new timer source?
> 
> 
> In the document as currently worded, the network does offer an address. 
> It says that the client MUST NOT configure the address if it supports 
> the new option.

You are directly correlating T2 to an address. Please don't - T2 is for 
the whole lease.

> 
>      > If there is consensus that this is useless we can remove it, but
>     I don't
>      > see a a strong reason to give up that extra flexibility. Is there?
> 
>     I don't see any extra flexibility offered. You talk about lease times
>     and yet say T1/T2 can't be used - why? All I see is more complication
>     when things can be kept simple.
> 
> 
> There's a difference in semantics: the least time is meaningful to 
> clients that request the lease and directly affects their behaviour and 
> the number and frequency of DHCP packets that they send. The V6ONLY_WAIT 
> timer is meaningful to clients that do not request the lease.

I'm not fully following here.
DISOVER - DHCP optional
server says - OK, retry around T2 (our new option)

vs

DISCOVER - No new option, I want a lease
server says - Sure! here's T1 and T2 timers


  As in the
> example I provided, the operator is likely going to want to configure 
> them differently. We should also bear in mind that there may be devices 
> on the path (e.g., relays, snooping switches) that see these offer 
> packets. Using a separate timer avoids the possibility that these 
> devices would act on the T2 field in ways that we don't anticipate or 
> desire. Using a separate option also makes it clear that there is no 
> need for this document to update RFC 2132 and RFC 8415 to amend the 
> definition of the IP address lease time option and the T1/T2 timers. >
>  From a complexity perspective, I think a separate timer is actually 
> simpler. While it does need to be parsed, that needs to happen anyway.

Only because you are insistent in putting it into a new option.
It's not needed.

> The fact that it's a separate option and has separate semantics makes it 
> easier to reason about the behaviour of the state machine than if we 
> were overloading the existing option. As the maintainer of a popular 
> DHCP client myself, I would prefer it.

Well, if you prefer extra code, unit tests and bloat, don't let me stop you.
But when it comes to my code I would rather keep it lean and mean.

Or to put it another way - I would not like anyone to force needless 
code when it's not really needed.

> Additionally, I would expect that a separate option would be simpler to 
> implement on the server side. This is because the server can just 
> continue to consider the lease time a property of the address pool, and 
> treat this new option simply as a statically-configured option that is 
> returned to clients iff they requested it in the PRL. If we use the same 
> field for the lease timer and the V6ONLY_WAIT timer, then the server 
> will need to change the lease timer in DHCPOFFER packets depending on 
> whether the option was requested or not, and I would expect that to be 
> more complex. +Tomek Mrugalski <mailto:[e-mail]> any 
> thoughts on this?

 From what I'm proposing, the extra option server side is like DHCP:on/off
It's not complex or rocket science. It addreses the need.
There is no concern about IPv6 or future IPv8 or whatever.

Roy