Re: [v6ops] FYI: Microsoft's latest on CLAT

Gert Doering <gert@space.net> Sun, 10 March 2024 09:18 UTC

Return-Path: <gert@space.net>
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 641E8C14F681 for <v6ops@ietfa.amsl.com>; Sun, 10 Mar 2024 01:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net
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 CbfLwx2y5Ixl for <v6ops@ietfa.amsl.com>; Sun, 10 Mar 2024 01:18:24 -0800 (PST)
Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C2DC14F690 for <v6ops@ietf.org>; Sun, 10 Mar 2024 01:18:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1710062304; x=1741598304; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Tpj+BHO/hztID17x3IMPh4eL6QD601mPu9vIvfTsZ6s=; b=ZAV6U46YH8nBC2SjsvrncBXvki3RwKnk78ugdU7dqPpinCDkkPS0yrls QKzaI/y+KghdA/V6w0kkXPcKrcgG+ii2l+4T0eYdn0DjQsYW/wPbRQ70w h7X30f9Szi7PzyPkk3fhXf86AfrgmZbP6onfvYoRO0fdU7K9WJFB/RZmj oOFmll5a0+aSyYC+gP9tdhfagiknI4t8fR5bLKx0H7D0oWAKKj5kGs1Dh yr06HU6BXrlbr9bovj7OTNkQQ/aC7gBiwWYLSrlbu49IDzyp9oUf8726i KV9eMIQUURDHLcUlxN4Z7Dbq5K8YewdX0Jrlaee71aFkEQDjfqVB+amEp g==;
X-CSE-ConnectionGUID: SiTiImP/Snaj7VY6PgpfNQ==
X-CSE-MsgGUID: jqDx6M4GSd61mFOSW6kZ3A==
X-SpaceNet-SBRS: None
Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2024 10:18:19 +0100
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9A01842718 for <v6ops@ietf.org>; Sun, 10 Mar 2024 10:18:18 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 7388241B6B; Sun, 10 Mar 2024 10:18:18 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 6BB303AC8A; Sun, 10 Mar 2024 10:18:18 +0100 (CET)
Date: Sun, 10 Mar 2024 10:18:18 +0100
From: Gert Doering <gert@space.net>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Gert Doering <gert@space.net>, Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <Ze162vZPi0SBXhp_@Space.Net>
References: <SJ0PR00MB1348781EB81293E8A0521F23FA202@SJ0PR00MB1348.namprd00.prod.outlook.com> <CABNhwV38kS8aMT5-CiZa_hxeack=Ezrxjjxf3Ek8in8MSSPAFQ@mail.gmail.com> <ZezMpssztQQ9rPZQ@Space.Net> <CABNhwV1OD1CH9npKg7Ga5mH6v+dT5=RZ2v5wukQBBanH8mNxOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="J+19yPv2D6Osy8U8"
Content-Disposition: inline
In-Reply-To: <CABNhwV1OD1CH9npKg7Ga5mH6v+dT5=RZ2v5wukQBBanH8mNxOw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ppECIEwssbPtMyVZUtPdzOp7xp8>
Subject: Re: [v6ops] FYI: Microsoft's latest on CLAT
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: Sun, 10 Mar 2024 09:18:28 -0000

Hi,

On Sat, Mar 09, 2024 at 04:12:36PM -0500, Gyan Mishra wrote:
> @Gert
> 
> AFAIK I thought dual stack was always the primary method to deploy IPv6 and
> that is where also Happy Eyeballs comes in to help in case of IPv6
> connectivity failures failover to IPv4.

HE is actually a good indicator why dual-stack is not the right answer -
if you need extra logic in the application layer because you never know
which of IPv4 or IPv6 might be broken today, there is something wrong
underneath.

If you only have single-stack - either one - you do not need HE (in the
way deployed today), because things either work, or get repaired.


>   With dual stack you have a single
> URL FQDN  with A / AAAA record instead of separate FQDNs instances for IPv4
> and IPv6.  Allows for simplicity as you migrate client and server apps to
> IPv6 and IPv4 only host community can still hit the same FQDN as IPv6 hosts
> community.
> 
> To me it seemed much more complicated to have separate FQDN instances for
> IPv4 and IPv6 applications.

"separate FQDN instances for IPv4 and IPv6" is not "not dual-stack", that's
just a very complicated way to do dual-stack.


The issue I have with dual-stack is that it needs double tending on all
layers (dual setup costs, dual monitoring to ensure that your web
application is properly behaving on v4 and v6, dual firewall rules, ...),
and it gains you... nothing, except a warm and fuzzy feeling "oh, my
DHCPv4 server broke, but I can still use IPv6, isn't that great?".


You seem to be looking at this only from the "content" side, where there
is no way to avoid dual-stack today, with too many clients still stuck on
IPv4 only.  I agree that this is a "MUST" today, but it's not a state we
want to end in.

I'm looking at dual-stack in the larger picture - operating system stacks,
application software, client networks, transport networks, server networks,
firewalls and loadbalancers (generic middleboxes), ... - doubling all the
maintenance and development effort can not be the correct way forward.

I'm still bumping into places where stuff just breaks with IPv6, because
vendors cannot be bothered(*).  After 25+ years.  Take away one of the stacks
very much ensures that the other one gets actually used and tested.


(*) most recent example: Fortigate firewalls with guest access portal
on a dual-stack wifi sgment.  Needs dual sign-in, once for v4, once for
v6...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer,
                                           Ingo Lalla, Karin Schuler
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279