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

[Lorenzo Colitti <[e-mail]>]

On Thu, Dec 5, 2019 at 11:50 AM Roy Marples <[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.

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.


> > 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. 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. 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.

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 <[e-mail]> any thoughts on this?