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

[Jen Linkova <[e-mail]>]

Sorry for coming late to the party.. dealing with a month of IETF
mailing lists backlog..

On Mon, Nov 27, 2023 at 8:10 PM David Farmer
<farmer=[e-mail]> wrote:
>
> Simply receiving an RA isn’t enough. Receiving a RA is necessary but not quite sufficient, configuring a GUA or ULA, something more than link-local is the threshold that needs to be met, and probably a default route as well. Without these a host is probably better off getting a IPv4 address.
>
> In the case we are discussing, the host had a firewall blocking the RA. However, it is also possible for the RA to be missing critical information needed to configure an address and default route. These are both misconfigurations, but without DHCP option 108, IPv4 would have likely worked.

I think it all comes to a fundamental definition of "IPv6-only capable
host" - and Option 108 is supposed to be sent by such hosts.
What it means is outside of scope for RFC8925 - it's more in scope of
"Deploying Ipv6-mostly networks" draft I'm writing (as was suggested
at IETF118).

Administrators which block IPv6 on endpoints effectively disable
IPv6-only capability on those devices. So they shall also disable
Option 108.
It's a case of misconfigured hosts. Let's say I have an IPv6-only
enterprise network and disable IPv4 on laptops - to increase security.


> On Mon, Nov 27, 2023 at 12:38 Nick Buraglio <[e-mail]> wrote:
>>
>> Mine were similar, as I sent in a prior email:
>> 1. Host listens for an RA. If RA received and a default route is installed, implement 108 and disable IPv4
>> 2. If no RA is received, request IPv4 lease.
>>
>> The trick is the timing. If a host operates correctly it should perform a RS on link, if it does not receive a RA in a few seconds, then it probably has some limit or problem that disabling IPv4 would expose. Again, this is in a failure state of the IPv6 network - so by definition if this is occurring there is a problem that needs to be addressed. Perhaps a very slight delay of a few seconds (3?) is not necessarily a *bad* thing.
>> The grey failure that this covers is very real but difficult to diagnose, ironically, on systems that do 108 correctly. On systems that do not do 108 it is largely a non-issue because IPv4 papers over the problem.
>>
>> Stretch goal - if the host has a delayed RA but *can* do 108, it could potentially just delay the disablement until an address and default route are configured.
>>
>> On Mon, Nov 27, 2023 at 8:14 AM Jeremy Duncan <[e-mail]> wrote:
>>>
>>> The simplest idea is always the best here...
>>>
>>> I have 2 ideas:
>>> 1. if the v6 side receives an RA, and the host configures an address - either with DHCPv6 or with SLAAC
>>> or
>>> 2. use the S-flag in the RA as that signaling that IPv6 is indeed expected in this network
>>>
>>>
>>> Jeremy
>>>
>>>
>>> -----Original Message-----
>>> From: v6ops <[e-mail]> On Behalf Of Brian E Carpenter
>>> Sent: Thursday, November 23, 2023 11:39 PM
>>> To: Lorenzo Colitti <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [v6ops] DHCP Option 108 Issue with Mac and iOS devices
>>>
>>> On 24-Nov-23 17:21, Lorenzo Colitti wrote:
>>> > Well, do we have an idea of what such a "relatively simple" health check would do?
>>>
>>> Pass, I'll leave that one for Nick and Jeremy.
>>>
>>>     Brian
>>>
>>> >
>>> > On Fri, Nov 24, 2023 at 1:20 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>>> >
>>> >     On 24-Nov-23 16:28, Lorenzo Colitti wrote:
>>> >      > As someone with real experience writing and maintaining network health checking code, I would strongly dispute the assertion that health checks aren't hard. :-)
>>> >
>>> >     In the general case, I'm sure you're right. I would think that for this specific case, it could be kept relatively simple. I could be wrong, of course.
>>> >
>>> >          Brian
>>> >
>>> >
>>> >      > The Android implementation <https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/NetworkStack/src/com/android/server/connectivity/NetworkMonitor.java <https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/NetworkStack/src/com/android/server/connectivity/NetworkMonitor.java>> is almost 5000 lines of code once you count utility classes.
>>> >      >
>>> >      > Part of the problem is that there can be many different failure modes because the host cannot know what the network supports.  For example, let's say that we specify a health check using ping. What if the network drops all ping packets for "security" reasons? Should the check fail? So then maybe we should use something else, HTTP perhaps? But to whose server? How do we distinguish a server problem from a health check failure? And so on and so forth.
>>> >      >
>>> >      > 6rd was able to define a very robust health check mechanism that loops the packet back to the host itself. See https://datatracker.ietf.org/doc/html/rfc5969#section-8 <https://datatracker.ietf.org/doc/html/rfc5969#section-8> <https://datatracker.ietf.org/doc/html/rfc5969#section-8 <https://datatracker.ietf.org/doc/html/rfc5969#section-8>> . That works well, but I think it was only possible it was a greenfield deployment. I don't think we can do the same type of thing with NAT64 because deployed NAT64s might not support hairpinning, or ping, or... well, anything other than forwarding traffic to external IPv4 addresses.
>>> >      > On Wed, Nov 22, 2023 at 5:56 PM Philip Homburg <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>> >      >
>>> >      >     If DHCP returns an option 108 then the hosts starts a connectivity check. If
>>> >      >     the check fails, then the host retries DHCP without option 108.
>>> >      >
>>> >      >     This results in a small delay if both the host and the network think they are
>>> >      >     supporting IPv6-mostly, but something is broken.
>>> >      >
>>> >      >     Obviously, this approach does mask that something is broken. Though it should
>>> >      >     be visible from the DHCP logs where a host first tries with option 108 and
>>> >      >     then without.
>>> >      >
>>> >      >     _______________________________________________
>>> >      >     v6ops mailing list
>>> >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>> >      > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>>> >      >
>>> >      >
>>> >      > _______________________________________________
>>> >      > v6ops mailing list
>>> >      > [e-mail] <mailto:[e-mail]>
>>> >      > https://www.ietf.org/mailman/listinfo/v6ops <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
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops



-- 
Cheers, Jen Linkova