Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Jen Linkova <[e-mail]>]

On Mon, Dec 9, 2019 at 12:52 PM Ted Lemon <[e-mail]> 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)?

>
> > On Dec 8, 2019, at 17:48, Jen Linkova <[e-mail]> wrote:
> >
> > On Sat, Dec 7, 2019 at 3:02 AM Ted Lemon <[e-mail]> wrote:
> >>> 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.
> >
> > 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



-- 
SY, Jen Linkova aka Furry