Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Ted Lemon <[e-mail]>]

If the client lists the option in the parameter request list, then the server knows it supports it. It can then send back a dhcpoffer with no address, knowing the client will do the right thing.

I don’t think there is a way to shut the client up if it does not support the new behavior. 

> On Dec 8, 2019, at 16:01, Jen Linkova <[e-mail]> wrote:
> 
> On Sat, Dec 7, 2019 at 1:31 AM Ted Lemon <[e-mail]> wrote:
>> 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.
> 
> The goal is that whatever the server does, it should be able to
> distinguish it  from any failure scenarios and stop asking. That's the
> reason why we are not suggesting that
> the server should just ignore requests from the clients if the clients
> sends the option. The positive signal 'I understand the option and
> this network is offering IPv6-only service'. Is there any way to do it
> w/o sending an OFFER back?
> 
>> 
>>>> 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
> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry