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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 14:45:28 +0000

Even if an "assigned" address is sent (which requires fewer changes on the DHCP server implementation), it should only be "associated" with that client for a very short duration (the server I work on limits it to 2 minutes by default and this is not saved to persistent storage). A DHCPACK is what confirms the lease for the returned lease-time and this is never sent (as the client will not send a DHCPREQUEST per the draft).

Existing servers can deploy this without ANY changes (provided you have a means to configure the server with whatever option number is finally assigned).

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.

One change to the server may be to simply not even temporarily associate the 'assigned' address with the client (since the client is not expected to send a DHCPREQUEST). But, again, I doubt this would be necessary.

Even in cases where there are minimal addresses available with a lot of clients coming online at once, the DHCP server would drop DHCPDISCOVERs that it has no available lease for. Thus, the client will just retry for a bit until an address becomes available. But other than generating the excess traffic, the end result is the same eventually - the client will stop DHCP.

This is one nice aspect of this design - there are minimal changes needed to deploy it at servers (and in fact, most servers may need no changes).

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Ted Lemon
Sent: Friday, December 6, 2019 9:31 AM
To: Philip Homburg <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option

I really feel like there is some point-missing going on here. It is trivial to make this feature only activate for clients that support it. If that is done, then there is no reason to assign an address at all. The offer doesn’t even need to include that option. So any discussion of what address to send is irrelevant and unnecessary. 

> On Dec 6, 2019, at 06:10, Philip Homburg <[email-masked]> wrote:
> 
> 
>> 
>> "number of IPv4 addresses in the pool" comes to mind.
>> 
>> Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a 
>> large enough subnet to cover 100% of all expected hosts if 20% will do?
>> 
>> IPv4 seems to be somewhat in short supply these days.
> 
> With a few exceptions, just about any DHCP pool I come across these 
> days is using RFC 1918.
> 
> Are you running out of RFC 1918 addresses in your pool? Or is the 
> setup that you give publicly routable IPv4 addresses to all dual stack 
> hosts and want to only put hosts that support NAT64 behind NAT?
> 
> In that case, what's the rational for providing dual stack hosts with 
> public
> IPv4 addresses?
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Dec 2019 08:02:02 -0800

On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <[email-masked]> 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.

> Existing servers can deploy this without ANY changes (provided you have a means to configure the server with whatever option number is finally assigned).

I think it’s okay to require changes to the server.   This is a significant new feature.

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

>> There is a reason why DHCP includes a parameter request list option.  If the client doesn’t ask for this newfangled option, it shouldn’t see it.  And so we can know for sure that the client supports this capability, because it asked for it.
> 
> Even if a DHCP server sent the option without it being requested, why would the client use it if it didn't ask for it?

If the DHCP server knows the client supports the feature, it can assume that when it sends the option, the client will implement the specified behavior.   If it doesn’t know for sure that the client supports the feature, then you have to deal with a much more complex set of possible behaviors.   Why add that complexity?

And that’s assuming that the client behaves correctly.  If you just send the new option, another possibility is that the client crashes when it doesn’t recognize the option, as we used to see with certain printers I the manufacturer of which I will not mention.   Or that it does some other random thing.  Why chance it?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 16:18:28 +0000

Comments inline below (BV>).

  *   Bernie

From: Ted Lemon <[email-masked]>
Date: Friday, December 6, 2019 at 11:02 AM
To: Bernie Volz <[email-masked]>
Cc: Philip Homburg <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option

On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
which requires fewer changes on the DHCP server implementation

BV> Why are any changes needed to the server? It’s normal processing will work just fine … if the network segment has the new option configured, it will return it if the client requests it. Then the server will never see the DHCPREQUEST and the address assigned to the client will just “timeout” in a short period (at least on our server, within 2 minutes or whatever an administrator has configured) and be usable by other clients. End of story as client has turned off DHCPv4 and everyone is happy. And, no changes to anything on the server. This is not different than a case where there the client never sends a DHCPREQUEST or selects a DHCPREQUEST from a different server.

BV> If the client does proceed to a DHCPREQUEST, normal processing would happen, and client would get the lease (or perhaps receive a DHCPNAK is some other device was assigned the lease because the short time it had been held expired).

BV> This is all normal DHCPv4 processing and so no changes are needed.

BV> Why there is no need? Yes, you could do optimizations to (1) have perhaps a much shorter temporary assignment time or (2) use a “reserved” address for clients that request this option in the PRL. But these are not necessary, and everything works just fine without the changes.

BV> Why need this testing to confirm that middleboxes aren’t doing bad stuff. If you stick to normal DHCP semantics, nothing needs to be tested or changed in your infrastructure. Yes, I am expecting this to work with no infrastructure changes as this is STANDARD DHCP. The DHCPOFFER just never turns in to a DHCPREQUEST – so what … this can happen today on all DHCP networks if the client stops (powered down, disconnects from network).

BV> If a DHCP client crashes when it receives an unknown option, my guess is that it would be quickly fixed as this just is broken behavior. Again, I’m not saying that a server should send this option if it wasn’t requested by a client, but I’m just clarifying your statements that even if a client were to see some arbitrary option that it didn’t request, it shouldn’t be doing anything with it. And, I would suspect that you would be hard pressed to find a client that crashes when it receives an unknown option.

BV> I will say that one issue that could exist with this option that is a bit unusual is that it is currently 0-length. We have only one other zero-length option that I recall, and that is Rapid Commit (which is client to server, not server to client). So, it is possible that there are clients that are unhappy about zero-length options. But again, in the ideal world no client will see this option unless it has requested it (in the PRL).

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 7 Dec 2019 01:35:30 +0900

On Sat, Dec 7, 2019 at 1:02 AM Ted Lemon <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Dec 2019 10:55:05 -0800

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 <[email-masked]> wrote:
> 
> 
> 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.
> 
> 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.
> 
> 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.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 22:07:38 +0000

I fully agree (no server changes, minimum investment for DHCPv4).

So where are these proposed changes to be done anyway?

In terms of adding new options, this happens by IETF/IANA all of the time and most servers, while they may ship with a pre-configure set, support defining new options and configuring instances of these options. And, servers already have the logic to return a configured option if the client sends that option in its Parameter Request List option.

And, in terms of the DHCPDISCOVER never transitioning to a DHCPREQUEST, what here needs changing? RFC2131 is clear that there are no issues with this as section 4.3.2 states:

         ... Because
      the servers have not committed any network address assignments on
      the basis of a DHCPOFFER, servers are free to reuse offered
      network addresses in response to subsequent requests.  As an
      implementation detail, servers SHOULD NOT reuse offered addresses
      and may use an implementation-specific timeout mechanism to decide
      when to reuse an offered address.

Section 3.1 also has:

                 ... Servers need not
      reserve the offered network address, although the protocol will
      work more efficiently if the server avoids allocating the offered
      network address to another client.

(In the server I work on, we took that avoids to mean within a reasonably short time period - by default 2 minutes though configurable.)

Is it the potential probing of an address before offering it? Is so, what's the harm? (And RFC2131 recommends this be configurable as to whether it happens.)

Sure, there are things you might do to optimize (such as what was mentioned in the draft), but I don't see that being necessary at all for this deployment. And, in some cases (such as if the client where to have changed its mind between the DHCPDISCOVER and when DHCPOFFER is returned, perhaps it is a bad thing - since you never really want to lease that address and this would require additional special logic). After the discussions, I just can't see this optimization being worth it since if all addresses are in use, the client just ends up sending DHCPDISCOVERs (which server drops if it cannot assign a lease). But other than wasting some packets and time before DHCPv4 is disabled, there's no harm.

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Simon Hobson
Sent: Friday, December 6, 2019 4:42 PM
To: [email-masked]
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Mark Smith <[email-masked]> wrote:

> - IPv6 only applications clearly indicate they're IPv6 only, by only 
> opening IPv6 sockets.

I think "IPv6 only" applications are a rare thing, and will remain so for a long time. Applications that can use IPv4 or IPv6, and which can work fine in IPv6 if IPv4 isn't available, are likely to be the norm for some time.

For an application to signal such compatibility modes to the OS would need substantial changes to the interaction model between application and OS. In the general case, that's just not going to happen.

> Ted Lemon <[email-masked]> wrote:

> 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 tim…

As previously described in terms of identifying bugs in intermediate equipment, raising bug reports, persuading the vendor (if they are still around and the kit is still in support) to fix it, and then rolling out the fix ...
Why require changes in DHCP servers when it can be done without any code changes at all ?

Perhaps define the option such that DHCP server vendors can, if they so desire, code in some optimisations - but I would say that allowing it to work without code changes would be much better.

There is one thought that comes to mind ... In effect, where this option is deployed, then (native) IPv4 is considered a legacy protocol that's being deprecated - why invest more effort than needed in supporting it.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Dec 2019 12:47:47 +1100

> 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 th…

The question is: how massive those infrastructure changes are and
what's the failure scenarios are expected. We might impede or even
completely prevent the adoption if the entrance barrier is too high.
Also in many cases people operating services (like DHCP) are not the
same people who are looking after the network infrastructure.

I see a big difference between 'incrementally enabling smth on clients
and servers' and 'getting switching and WiFi vendors involved and
upgrade the network infrastructure - which means moths or years of
delay, not mentioning non-obvious failure scenarios, when only some
clients are connected to way-too-smart-boxes'.
If we can make it transparent to the switching infrastructure we
probably should.
--
SY, Jen Linkova aka Furry

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Dec 2019 17:52:52 -0800

We’ve always assumed that the highest possible entry barrier is changes on the client. I’m not aware of any middleware that wouldn’t handle this correctly, and apparently Bernie isn’t either. I think this is a non issue. If we can get support in clients, we should be able to deploy. 

> On Dec 8, 2019, at 17:48, Jen Linkova <[email-masked]> wrote:
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Dec 2019 02:26:56 +0000

I’m with Jen to go with option A in her list. Safest and requires fewer changes / testing.

I said I have no idea whether middleware would have any issues, sure “i am not aware” — but I haven’t done any testing and don’t see a need to as option a is so much better.

- Bernie

> On Dec 8, 2019, at 8:53 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Dec 2019 15:30:37 +1100

On Mon, Dec 9, 2019 at 12:52 PM Ted Lemon <[email-masked]> wrote:
>
> We’ve always assumed that the highest possible entry barrier is changes on the client.

I'd say it's a barrier between 'now' and '100% adoption'. But it's not
a barrier for an incremental deployment. In this case in particular -
I'd not expect 100% of devices to support the option, but as many of
those devices would not have IPv6-only capability as well, that's
fine. So the long tail is acceptable here - that long tail is what we
are deploying IPv6-mostly (IPv4-as-a-Service) networks anyway.

>I’m not aware of any middleware that wouldn’t handle this correctly, and apparently Bernie isn’t either. I think this is a non issue. If we can get support in clients, we should be able to deploy.

To prove existence it's  enough to provide a single example. Proving
non-existence is much harder and absence of evidence is not evidence
of absence.
Practically speaking I'd prefer to minimize the risk.
While do not know the probability of a smart infrastructure device
getting an allergic reaction to abnormal DHCP packet, the potential
impact is quite high.

I'm not sure what's the impact of returning an address (ex. for making
that address unavailable for a short period of time)?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Dec 2019 15:37:09 +0900

> getting an allergic reaction to abnormal DHCP packet, the potential

+1

> that address unavailable for a short period of time)?

The only downside that I can think of is that if you have a thundering herd
of devices that come online all at the same time (e.g., power loss and
site-wide reboot), the offers handed to the v6only-capable devices, in the
brief time they are allocated, can exhaust the pool such that
v6only-incapable devices cannot immediately get an address. However, the
server can mitigate that in two ways:

   1. When issuing an offer, don't reserve the address, or reserve it for a
   very short time.
   2. When issuing an offer to a v6only-capable device, don't reserve the
   address. If the v6only-capable device then comes back and sends a request
   (which it shouldn't, unless something very strange happens), then the
   address may be in use by a v6only-incapable device. In that case, the
   v6only-capable device will get a nak and can go back to discover.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 00:40:55 +0100

On 06.12.2019 17:02, Ted Lemon wrote:
> 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.
This part of the discussion seems to have been mostly settled. But in
case it isn't, here's another opinion. As a DHCP server vendor, I'd very
much prefer no code changes. For several reasons:

1. You can start using the option now, without any server upgrades, just
tweak the server configuration to send one extra option. This is
expected to be a significant factor in the adoption process.

2. The basic DHCPv4 mechanism of clients requesting options in PRL and
the server sending them is decades old and there are tons of policy
mechanisms around it (send only when requested, force sending to
specific devices or class of devices, treat devices that request that
option as a separate class, etc.) These are all well understood by
network admins.

3. Extra logic requires extra testing. There may be incompatibilities,
especially with firewalls and relays that attempt to track state. Some
of them may be hard to detect.

Having said that, I'm willing to implement code changes if I have to.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 00:44:44 +0100

On 06.12.2019 17:18, Bernie Volz (volz) wrote:
> BV> I will say that one issue that could exist with this option that
> is a bit unusual is that it is currently 0-length. We have only one
> other zero-length option that I recall, and that is Rapid Commit
> (which is client to server, not server to client). So, it is possible
> that there are clients that are unhappy about zero-length options.

Agree it's a valid concern. It could have affected some middleboxes
(snooping relay, firewall tracking state etc.). Fortunately, it's going
to be addressed in upcoming -01 rev. The option format is redefined to
be 4 octets long and will contain a timer value.

Tomek