Re: [v6ops] IPv6-Only Preferred DHCPv4 option

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

I’m with Jen to go with option A in her list. Safest and requires fewer changes / testing.

I said I have no idea whether middleware would have any issues, sure “i am not aware” — but I haven’t done any testing and don’t see a need to as option a is so much better.

- Bernie

> On Dec 8, 2019, at 8:53 PM, Ted Lemon <[e-mail]> wrote:
> 
> We’ve always assumed that the highest possible entry barrier is changes on the client. 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. 
> 
>> 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