Re: [v6ops] IPv6-Only Preferred DHCPv4 option

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

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 <[e-mail]> On Behalf Of Ted Lemon
Sent: Friday, December 6, 2019 9:31 AM
To: Philip Homburg <[e-mail]>
Cc: [e-mail]
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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops

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