Re: [v6ops] IPv6-Only Preferred DHCPv4 option

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

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 <[e-mail]> On Behalf Of Simon Hobson
Sent: Friday, December 6, 2019 4:42 PM
To: [e-mail]
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Mark Smith <[e-mail]> 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 <[e-mail]> 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 time. Why not do it right given we’re going to have to live with it for decades?

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.

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