Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Lorenzo Colitti <[e-mail]>]

Ted,

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?

Cheers,
Lorenzo

On Mon, Dec 9, 2019 at 9:47 AM Ted Lemon <[e-mail]> wrote:

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