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

David Farmer <farmer@umn.edu> Fri, 24 November 2023 14:34 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8283FC151083 for <v6ops@ietfa.amsl.com>; Fri, 24 Nov 2023 06:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92Z1YmWlNe4Z for <v6ops@ietfa.amsl.com>; Fri, 24 Nov 2023 06:34:38 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70041C151078 for <v6ops@ietf.org>; Fri, 24 Nov 2023 06:34:37 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 4ScHYm5Cxqz9wKNn for <v6ops@ietf.org>; Fri, 24 Nov 2023 14:34:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpM4UYfkxCOQ for <v6ops@ietf.org>; Fri, 24 Nov 2023 08:34:36 -0600 (CST)
Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 4ScHYm1vRVz9wF4W for <v6ops@ietf.org>; Fri, 24 Nov 2023 08:34:36 -0600 (CST)
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p7.oit.umn.edu 4ScHYm1vRVz9wF4W
DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p7.oit.umn.edu 4ScHYm1vRVz9wF4W
Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-540150414efso1270436a12.3 for <v6ops@ietf.org>; Fri, 24 Nov 2023 06:34:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; t=1700836475; x=1701441275; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zexkh0C3FYJQutGHE7whUfZOC84q9x8AJs79Z6I4Fjo=; b=dWbYPnY6RUEVXzEjQcV2po65JZ+a+VaaRoGt1JcmhTkeJzsJCZTyPtAExK4okbJXNb lzCeXESTRhC2jmKy8ssJm2SKT0yO5DVbc6xg2dsu9E+AexWONML1pyASRzpnNsUZreF0 M457z9TugwvAk2ZV1cEzM/ZiRPK5yo+axl4cWlZ0ZMllxq4B26/EpRfy+hjYrG3kiVaS b9/fF9Ra9YKCCdOD+xRPvUKCz6CXLiZ8wfWlJF7UwYkoy3VCLmfoC7L4Nyd/PW3q4lxV 9Fe6TX9p9nMe2da8fXY/n+2ExTeqqWs299G8PEjl59TD/wC+zsjkeC0FbkWIo006D+C+ wF7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700836475; x=1701441275; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Zexkh0C3FYJQutGHE7whUfZOC84q9x8AJs79Z6I4Fjo=; b=V/pA9Bd8FXllOBMtVm15VHzdbSyP1rMd7p03HHLXwAZ/QIxMvLfQO0Xkk/zWiC31Y3 0Xs769IPKUJ29E5kLZbxi0R1GI3uUV9DFc9YQ79w3KialzY537mMTv6A5MP1z2Mb8dR9 QEupP6ovKJDIFqhiiDYhhhNlXu0yyL3SDDWaWFsxa0XvA4uyHKfm9EAAEYhUbLJS+uka gMFEww1g1ympfXaD/+QCFxPzad0RCkynaUCh9azOzmVyjoK30XI+5q0Eumpz3B/FHJSU 9HoPfBQUnMVxiAhtvK3NKBuETWvBZcNYyqJ16djfBswJCDmCOsgfJimQKA4QETy4Uk1i 9glQ==
X-Gm-Message-State: AOJu0Yw1vrT8tkZQRtNn3HFGBOf2a7vuz/zUdfF715pM73+230KgzbWE EjvOIZj78RV0JHRdxWFliPaPd4bHhFnjmSNM7Thvg9Rg70ck1I+77Jz3x19soNvoIT2WL0bg3sx PgaFWoUop0Lx9IgnWZLHpOcxvBw==
X-Received: by 2002:a17:906:7494:b0:a09:1178:a336 with SMTP id e20-20020a170906749400b00a091178a336mr1948526ejl.23.1700836475038; Fri, 24 Nov 2023 06:34:35 -0800 (PST)
X-Google-Smtp-Source: AGHT+IEVGPfhSrrDOTYG8RKDtVvvrZKIU4niOujCrLCLM/HWauVQf8F0ccldxjAntw4V2vrm3LDfs6awugrUNLp1DYg=
X-Received: by 2002:a17:906:7494:b0:a09:1178:a336 with SMTP id e20-20020a170906749400b00a091178a336mr1948499ejl.23.1700836474519; Fri, 24 Nov 2023 06:34:34 -0800 (PST)
MIME-Version: 1.0
References: <BL1PR18MB427723EC69CD715FDA7E1CD9ACB0A@BL1PR18MB4277.namprd18.prod.outlook.com> <a13d3deb-e285-4c0a-8fbf-44feab9edd4a@gmail.com> <BL1PR18MB4277BE878F335B8BEC218B21ACB0A@BL1PR18MB4277.namprd18.prod.outlook.com> <e0470656-97d1-425d-a9b2-a5a39bf4fcc2@gmail.com> <BL1PR18MB42779B01A0EFE62142EE19AEACB0A@BL1PR18MB4277.namprd18.prod.outlook.com> <666bdf4a-abdf-9c2c-d6f9-c67907778c3d@gmail.com> <BL1PR18MB4277F8FD1820B111FBA95477ACB0A@BL1PR18MB4277.namprd18.prod.outlook.com> <CAKD1Yr0P_QKGZO_wc4EcuFD=d4pw24se0w-+bfm8Wgns0Ah0Jg@mail.gmail.com> <187BF493-685B-4F8C-B7CF-642EA8166233@delong.com> <27b3ae83-e930-76a8-cdc4-f7098a07ddd7@gmail.com> <ZV2z9WwJKJTxQL0i@Space.Net> <m1r5j1R-0000KXC@stereo.hq.phicoh.net> <CAKD1Yr1tsWbzniGQeu9y_bzoKhBFFg0T=yKfqaXZK05CWA5isw@mail.gmail.com>
In-Reply-To: <CAKD1Yr1tsWbzniGQeu9y_bzoKhBFFg0T=yKfqaXZK05CWA5isw@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Fri, 24 Nov 2023 08:34:22 -0600
Message-ID: <CAN-Dau0LB3ErWi-xo+uHKZ2nGo6aR50okPrHMWjOSAt3r74c1A@mail.gmail.com>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Cc: Philip Homburg <pch-v6ops-12@u-1.phicoh.com>, v6ops@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e295c3060ae6d988"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Xt2chGxhhs1Bv1CHLZokMrNvZmU>
Subject: Re: [v6ops] DHCP Option 108 Issue with Mac and iOS devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2023 14:34:42 -0000

A full blown health check, isn’t easy, and may or may not be advisable.
Nevertheless, if I understand the reported issue correctly, the IPv6 stack
wasn’t even getting as far as configuring a globally scoped address.
Therefore, even without a full blown health check, it seems advisable that
if after some timeout, the IPv6 stack hasn’t successfully configured a
globally scoped address, then maybe it should reconsider it’s DHCP Option
108 status.

If there is no globally scoped IPv6 address available, both NAT64 and
Native IPv6 are NOT going to work. So, then retrying IPv4 seems like a
reasonable next step, especially since it got a DHCP Option 108 response,
that is a clue that there is at least some level of IPv4 functionality
available.

So rather than calling this a health check, I’d call it a sanity check.

Thanks

On Thu, Nov 23, 2023 at 21:29 Lorenzo Colitti <lorenzo=
40google.com@dmarc.ietf.org> 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. :-) The Android implementation
> <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 . 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 <
> pch-v6ops-12@u-1.phicoh.com> 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
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>