Re: [v6ops] DHCP Option 108 Issue with Mac and iOS devices

[Ted Lemon <[e-mail]>]

These feel like really unlikely hypotheticals. I think we could safely wait
until such a thing happened, but I don't think it will happen—this would be
a weird default configuration for a vendor to provide. I agree that network
operators don't know the details of every implementation; that's why we
have careful rollouts of new behavior. I think Jen's work in this area has
been exemplary, and I think the work done by the other folks here rolling
out v6-mostly in conference networks has also been really helpful in
surfacing issues. So I don't think we need to go looking for hypothetical
problems that could occur if somebody who ought to know better did
something silly.

On Thu, Dec 21, 2023 at 11:02 AM Ole Trøan <[e-mail]> wrote:

>
>
> On 21 Dec 2023, at 16:28, Ted Lemon <[e-mail]> wrote:
>
> 
> The network operator has decided to do this.
>
>
> Perhaps. Or someone else provisioned the network like this. Or network
> devices came with that as the default configuration.
>
> I don’t think we can assume every network operator knows the tidbits of
> every implementation.
>
> We have to ensure host configuration is robust.
> “Don’t allow those devices on the network or don’t configure the network
> that way then.”  Isn’t an acceptable answer.
>
> There was a reason why the IPv6 only flag proposal failed. Sounds like 108
> have similar set of issues.
> I don’t think writing documents is going to help with particular
> implementations either. We could possibly do an interop.
>
> O.
>
> Presumably they already know that Android doesn't support DHCPv6, and they
> don't want BYOD to work, so it's fine. Or maybe they didn't know that, in
> which case they will try to roll this out, hopefully not on every network
> at once, discover that they have an issue, and either change their
> DHCP/SLAAC policy, or decide not to roll out option 108 after all. I don't
> see any work for us to do here. I would say that Android implementations
> should pay attention to the fact that SLAAC isn't supported and ignore
> option 108 in this case, and perhaps we could write up a document
> explaining that, but it's not clear to me that this is necessary.
>
>
> On Thu, Dec 21, 2023 at 5:17 AM Ole Troan <otroan=
> [e-mail]> wrote:
>
>> Take the perfectly valid network deployment where addresses are assigned
>> with DHCPv6 IA_NA. And NAT64 is supported.
>>
>> The subset of hosts that supports 108 but is missing the DHCPv6 feature,
>> how are they supposed to behave?
>>
>> I prefer the two protocols to run ships in the night. Can we come up with
>> some recommendations that limit the v4/v6 interdependence and also avoid
>> increasing brittleness with the introduction of 108?
>>
>> Ole
>>
>>
>>
>> > On 21 Dec 2023, at 01:08, Jen Linkova <[e-mail]> wrote:
>> >
>> > On Wed, Dec 20, 2023 at 11:18 PM Gert Doering <[e-mail]> wrote:
>> >>>> So the message needs to be carried back "I can not take a laptop with
>> >>>> such a configuration to conferences anymore".
>> >>>
>> >>> This answer, while possibly technically correct, is unreasonable.
>> >>
>> >> "Employees coming back and yelling at the IT support desk" is a fairly
>> >> good feedback mechanism for "what you do to my laptop makes me look
>> like
>> >> a fool out there, AND I couldn't join that super-important Zoom call".
>> >
>> > I very much agree with Gert here.
>> > There is a spectrum. On one side there is a network which is unusable
>> > for the vast majority of the clients.  Let's say, IPv6-only WiFi w/o
>> > NAT64. It's unlikely that anyone would deploy that as a public
>> > network.
>> >
>> > On the other end of the spectrum is an ideal, perfect network which
>> > any client can use.
>> >
>> > The real network is always somewhere in the middle, and the closer you
>> > are trying to get to the ideal, the harder (and more expensive) it
>> > gets.
>> > In real networks there are always some clients having some issues. So
>> > the decision the network administrator has to make is where to draw a
>> > line. What corner cases to support and what falls into the 'go and fix
>> > your client' category. The key criteria would be along the lines of
>> > "can it be fixed or can a workaround be provided?" and "how many of
>> > those cases are there?"
>> > And it's quite possible that other people have different views on
>> > where the line is (also, clients footprint might vary for different
>> > networks).
>> >
>> > Why do I think that the scenario of 'a Macbook with disabled IPv6'
>> > belongs to the "not supported, fix your device" case?
>> >
>> > - it is not a bug/OS issue which requires totally unpredictable time
>> > to fix. It's a configuration issue.
>> > - it's not the default state of the device. Someone has configured it
>> > that way, and they shall be able to change it.
>> > - the problem is very well scoped, unlike "please go and fix all
>> > IPv4-only applications".  I have no words to express how many issues I
>> > discovered when I got rid of the HE safety net. I wish I found those
>> > issues earlier.
>> > - it's very important to send the message back to people who
>> > configured the device that way. I think it's unlikely for a personal
>> > device to be configured like that (and even then it's easy to fix,
>> > unlike corporate policy) - and for corporate devices their techsupport
>> > shall know that a new use case exists now. They might be shocked to
>> > know there are IPv6-enabled networks out there, not mentioning
>> > IPv6-mostly. Otherwise that issue would never get fixed.
>> >
>> > The problem with "run some tests and keep IPv4 if IPv6 doesn't work"
>> > is not just that it's harmful for applications on properly working
>> > devices, as I've said.
>> > It's also that it would be almost impossible to come up with tests.
>> > which can be completed in reasonable time and still covers all cases.
>> > There is another danger which really scares me. The main issue with
>> > operating a dual-stack network is that troubleshooting is much harder:
>> > you never know what protocol the endpoint uses right now. If we let
>> > the devices decide 'oh, I do not like what I saw, I'm going to stay
>> > IPv4-enabled for now', it would complicate troubleshooting and IPv4
>> > subnet planning.
>> >
>> > There might be other cases when a device has issues on IPv6-mostly -
>> > one well-known example is pre-Sonoma MacOS with custom IPv4 DNS
>> > servers configured. I think it was great that such devices stayed
>> > IPv6-only, so we could find the issue and get it fixed. Yes, today the
>> > answer to such users would be " don't configure it that way" or, if
>> > it's a corporate policy, "go and complain to your support so they
>> > either change it or upgrade your device". I do not think it should be
>> > a reason for keeping IPv4 on those devices.
>> >
>> > --
>> > Cheers, Jen Linkova
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>