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

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 05:55:52 -0800

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 <[email-masked]> 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?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Dec 2019 14:00:28 +0000

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 <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 06:17:10 -0800

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

Does rfc2131 actually say that?

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

That’s a special server change. 

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

So servers other than yours should be the ones that have to change?  :)

The reason I think this merits a change is that we actually want different behavior. The change is trivial.

You aren’t actually arguing for no change: you are arguing for a change that is minimally inconvenient assuming a certain existing implementation.

That is a good short term move, but this is a long term solution. So I’m arguing to do it right. 

One way to resolve this impasse would be to specify it do it would work with your minimal change, but also allow the server to send no address in the offer. That way you can implement the full change at your leisure, but we still get a good long term outcome.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Dec 2019 14:31:58 +0000

No, I am strongly arguing for no change.

Again, the things I suggested are optimizations if you feel there is a need to reduce the impact if lots of clients come online at same time. You don’t have to do any of these things.

If a server commits lease to disk with full lease time on an offer, yes you have to change that. Rfc 2131 already states that this is appropriate to do (not commit, use short time to hold lease).

Sure, we can document that as something that is a consideration if you have lots of clients and not much address space.

Sending 0 address is bad:
- might impact middleboxes
- has issues if option has been hijacked for other purposes and is in prl
- doesn’t allow client to continue with lease if it changes its configuration between discover & offer

And even if addresses all used, retransmissions will allow client to eventually proceed.

- Bernie

On Dec 9, 2019, at 9:18 AM, Ted Lemon <[email-masked]> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 06:58:15 -0800

> No, I am strongly arguing for no change.

Yes, but why?

My concern here is for the end state in ten years.   In ten years, it should be the case that virtually every client supports this feature, and virtually every network offers it.  We don’t want there to be a DHCPv4 server on this network at all.   What we want is a dumb little thing sitting in the router on the link that, when it gets a DHCPDISCOVER, immediately responds with a directive to use IPv6.   So I want to optimize for what that little stub should look like, /not/ what your solution should look like now.

I think it’s pretty clear that that little stub should not offer an IPv4 address at all.  What is the utility of offering one?   We’ve seen several proposed hacks for this, but they are just that: hacks.  They are additional complexity we don’t need.

So that leads me to want you to think really hard about why you want to do something else, and not just strongly argue for no change.   Would you mind doing that?  It’s quite possible that there is some problem with what I’m proposing that you haven’t yet articulated, because you’re satisfied by the superficial answer.  It would be nice to figure out why, for example, the compromise I proposed is unacceptable to you.  What is bad about that solution?  You could, if you chose, make no changes to your server forever, and I could implement my trivial stub in the router, and I think we’d both be happy.

Why do you think we wouldn’t both be happy?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Dec 2019 15:19:22 +0000

Perhaps as a middle ground, draft could allow a server to return 0.0.0.0 as “assigned” address and then client MUST NOT send a DHCPREQUEST.

But I do not see this as being a requirement.

When responding to a DHCPDISCOVER that requested the ipv6-only option in the PRL and that the server includes it in the DHCPOFFER, a server can either;

- return an address that it is willing to offer a client should the client proceed. Or,
- MAY return the 0.0.0.0 address, in which case the client MUST NOT proceed with DHCPREQUEST.

- Bernie

On Dec 9, 2019, at 9:34 AM, [email-masked] wrote:

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 07:21:21 -0800

> But I do not see this as being a requirement.

This isn’t a middle ground.  This is (at best) meaningless behavior: a hack.   Worse, it could actually cause problems with middleboxes because they might try to treat 0.0.0.0 as a real address.   Why are you doing the hack?   What is the problem you are trying to prevent by doing the hack?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Dec 2019 00:21:32 +0900

On Mon, Dec 9, 2019 at 11:17 PM Ted Lemon <[email-masked]> wrote:

> One way to resolve this impasse would be to specify it do it would *work*
> with your minimal change, but *also* allow the server to send no address
> in the offer. That way you can implement the full change at your leisure,
> but we still get a good long term outcome.
>

>From the perspective of a host OS developer and not a server developer,
that seems like a good compromise. I hadn't thought of the "I just want a
little stub on my network" argument. Though I'd wager it will be more than
ten years before every network has one of those, it does seem like a nice
minimalist approach especially good for small/home networks where we don't
expect there to be any middleboxes to choke on an offer for 0.0.0.0.

If we want hosts to support this (and we do, because otherwise even on such
networks hosts might choke on the offer for 0.0.0.0) it should be in the
document from day one and we should say that if the host gets 0.0.0.0 in
the offer and a v6only-preferred option it MUST operate in IPv6-only mode
and MUST NOT send a request for the address.

Presumably what happens if the host gets 0.0.0.0 in the offer and no
v6only-preferred option is left to the implementer. Just as a data point,
the Android implementation will ignore it and continue to send discover
packets. At the moment I can't remember why I did that and I don't know
what other implementations do.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Dec 2019 00:24:24 +0900

On Tue, Dec 10, 2019 at 12:21 AM Ted Lemon <[email-masked]> wrote:

> Perhaps as a middle ground, draft could allow a server to return 0.0.0.0
> as “assigned” address and then client MUST NOT send a DHCPREQUEST.
> This isn’t a middle ground.  This is (at best) meaningless behavior: a
> hack.   Worse, it could actually cause problems with middleboxes because
> they might try to treat 0.0.0.0 as a real address.   Why are you doing the
> hack?   What is the problem you are trying to prevent by doing the hack?
>

Ted, I'm confused as to what you're proposing. I thought you were
suggesting that the server would send back an OFFER with a yiaddr of
0.0.0.0. Is that not what you mean?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 07:37:02 -0800

On Dec 9, 2019, at 7:24 AM, Lorenzo Colitti <[email-masked]> wrote:
> Ted, I'm confused as to what you're proposing. I thought you were suggesting that the server would send back an OFFER with a yiaddr of 0.0.0.0. Is that not what you mean?

Oh crap, you’re right.  This is probably why Bernie isn’t agreeing.  I was confusing yiaddr and DHCP requested address.

BTW, I’ve been arguing for using the parameter request list to signal this option, and that is how it’s supposed to be used, but I’m realizing that some clients may still not actually correctly implement the parameter request list—this was always a problem.  And so these clients may be relying on the behavior they get when they don’t send a PRL.   So it might be better for the client to send the option, rather than requesting it, and then the server can reply back with it if the network is IPv6-preferred.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Dec 2019 00:39:46 +0900

On Tue, Dec 10, 2019 at 12:37 AM Ted Lemon <[email-masked]> wrote:

> BTW, I’ve been arguing for using the parameter request list to signal this
> option, and that is how it’s supposed to be used, but I’m realizing that
> some clients may still not actually correctly implement the parameter
> request list—this was always a problem.  And so these clients may be
> relying on the behavior they get when they don’t send a PRL.   So it might
> be better for the client to send the option, rather than requesting it, and
> then the server can reply back with it if the network is IPv6-preferred.
>

Can we simply say that those clients cannot use this option, then? It seems
unfortunate to say that well-behaved clients that do know how to use the
PRL should have to add the option to their request packets outside the PRL.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 07:44:22 -0800

On Dec 9, 2019, at 7:39 AM, Lorenzo Colitti <[email-masked]> wrote:
> Can we simply say that those clients cannot use this option, then? It seems unfortunate to say that well-behaved clients that do know how to use the PRL should have to add the option to their request packets outside the PRL.

The trouble is, I don’t know how prevalent this problem is.  Maybe it’s okay, though—just looking at my own desktop computer, it definitely does seem to be sending a PRL.   Does Android also?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Dec 2019 15:50:47 +0000

As clients have to change to support this, fix the PRL option handling.

- Bernie (from iPhone)

On Dec 9, 2019, at 10:45 AM, Ted Lemon <[email-masked]> wrote:

 On Dec 9, 2019, at 7:39 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Can we simply say that those clients cannot use this option, then? It seems unfortunate to say that well-behaved clients that do know how to use the PRL should have to add the option to their request packets outside the PRL.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 07:52:36 -0800

> As clients have to change to support this, fix the PRL option handling.

Okay, WFM.