IETF Logo Mail Archive

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

Owen DeLong <owen@delong.com> Thu, 16 November 2023 04:00 UTC

Return-Path: <owen@delong.com>
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 A0A1FC14CF1C for <v6ops@ietfa.amsl.com>; Wed, 15 Nov 2023 20:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 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_HELO_NONE=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=delong.com
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 tQCjBXdxLsmu for <v6ops@ietfa.amsl.com>; Wed, 15 Nov 2023 20:00:04 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4CC14F726 for <v6ops@ietf.org>; Wed, 15 Nov 2023 20:00:04 -0800 (PST)
Received: from smtpclient.apple ([192.168.100.138]) (authenticated bits=0) by owen.delong.com (8.17.1/8.15.2) with ESMTPSA id 3AG402Q2773289 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Nov 2023 04:00:03 GMT
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 3AG402Q2773289
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1700107203; bh=1kZcicLw3GZ4bGuAu7ozpEbkimll7fxx3ynfjFK0BTQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=epZMdQO0ZxYqrup89RHzdGqViIz7sR0a90+1aB/2Ggzo01quBTGuRudattqnUVh7v yFM6+12u5plZvMNX0W0dui7XztJk9sazFVWnOIvnx3Gy/qtlqRx8IavSQAewnwqZVX aoWUt0JgVCvLyQhkIs3vT6sX3cYgOxPySd2m4o8E=
From: Owen DeLong <owen@delong.com>
Message-Id: <E10E14B1-DE3D-44A4-951A-66458FCAB7AA@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E050A1A6-C169-4915-A8AE-EB4A83809532"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\))
Date: Wed, 15 Nov 2023 19:59:52 -0800
In-Reply-To: <BL1PR18MB4277AAD4CFD760FC7DC413F2ACB1A@BL1PR18MB4277.namprd18.prod.outlook.com>
Cc: v6ops <v6ops@ietf.org>
To: Jeremy Duncan <jduncan@tachyondynamics.com>
References: <BL1PR18MB4277AAD4CFD760FC7DC413F2ACB1A@BL1PR18MB4277.namprd18.prod.outlook.com>
X-Mailer: Apple Mail (2.3774.100.2.1.4)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [192.159.10.2]); Thu, 16 Nov 2023 04:00:03 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/eJugUX_TVdr7F7svIfdKhnwN11o>
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: Thu, 16 Nov 2023 04:00:08 -0000

I think that this is a misconfiguration by the entities configuring the end hosts in question and that having them go back and explain the brokenness it causes to their IT team is the desirable result.

Owen


> On Nov 15, 2023, at 14:25, Jeremy Duncan <jduncan@tachyondynamics.com> wrote:
> 
> Hi v6ops-
>  
> Nick and I were involved with the Supercomputing Conference this year and part of the decision was to provide a real-world network to experiment with IPv6 transition technologies in an IPv6-only state. So a part of the wireless network was configured with an IPv4 DHCP scope with Option 108 with a value of 3600. The IPv6 part was configured with IPv6 SLAAC only with RADNS options pointing to a DNS64 resolver that mapped to the 64:ff9b::/96 scope - where the intermediate upstream device has NAT64 functional.
>  
> As we expected, most Android and all later version Mac/iOS systems performed as expected:
> IPv4 DHCP request for option 108
> Response with 108, 3600
> Disable IPv4 functionality on the wireless NIC
> Spin up the CLAT/464XLAT functionality
> Happy IPv6-only-ing
>  
> Well, with one exception: organizations that provided misconfigured firewall rules (blocking all ICMPv6/IPv6) or disabling of the IPv6 stack entirely.
>  
> In this specific use case, the iOS/Mac would do exactly as instructed by the DHCP server, it would disable IPv4 and spin up its CLAT/464XLAT – but without any verification that IPv6 is functional before doing so.
>  
> As you are probably aware, this resulted in a total endpoint denial of service as it has a non-functional IPv6 stack, but the IPv4 stack (network) did not have the awareness of any issues therefore disabled IPv4 functionality.
>  
> The question for the v6ops group – is there something we can do to tighten up any kind of RFC that will require IPv6 stack capabilities and functionality?
>  
>  
> 0101001101100101011011010111000001100101011100100100011001101001
> 
> Jeremy Duncan
> IPv6 Architect, Managing Partner
> Tachyon Dynamics, Inc
> Phone: (703) 259-8550 x 103
> Fax: (703) 259-8548
> https:// <https://www.tachyondynamics.com/>www.tachyondynamics.com <https://www.tachyondynamics.com/>
>  
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops

v2.41.0 | Report a Bug | By Email | System Status