Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

Mark Smith <markzzzsmith@gmail.com> Sat, 23 March 2024 03:18 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2292BC1519B7 for <ipv6@ietfa.amsl.com>; Fri, 22 Mar 2024 20:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3BsPrcSigYCM for <ipv6@ietfa.amsl.com>; Fri, 22 Mar 2024 20:18:44 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0805C1519AD for <ipv6@ietf.org>; Fri, 22 Mar 2024 20:18:44 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2d6a1ad08b8so37011501fa.1 for <ipv6@ietf.org>; Fri, 22 Mar 2024 20:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711163922; x=1711768722; 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=urC28dg8B+/ITJXIZe3KZ7zgiAYrNvF17gglXhUu/pY=; b=Z1YMAg5sxx1OPTgQwRYFoexnSmLw/WuMCPxt2qiLx0ZMl+ifM5838wsDLezzhN4K3+ mY+A01DPFVj8ZxachrYwTaLWyj9HKR79CLkSgF/qsXKp5CJtHKhWbjXQ2PLCClQ56qax b5CGfhJWjUAD2mxoAAv5MpnF54rA1AacnxPGc0Art1ELqqZVNg67mYUU0zwjTYOkpvg8 c5wvvdCdQzCKQktqZZbcxhsT0zu2g3Fto05T8ykbpZpg2G72uqBqlWw2QozCGBVhlIfj E7V8TDvj4EvsOpEPkqemYE5gkoLrJ3VUy8bAUiVJX8+UMo0/5UviuJhf00AXc/GICMLs 10tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711163922; x=1711768722; 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=urC28dg8B+/ITJXIZe3KZ7zgiAYrNvF17gglXhUu/pY=; b=oD0WA7/LMmffclQYtn4c31+TLpfCDiYRLFYUkkflPKRXe17nbPAJ/jEY3mJnwCxPzG owTJjCVFs2zRpX0qyr9V7RlL55NkISoAez0flQeWV8vxZqz+B/RXa6i395v1wLWgAHup 90JcwwbjkgKCqCGVJZ/l64QMR2IfWuHYWX/hACUsFik1Bpogg8Xt5nta/x8pZKDCiWV4 6ArDrsQYOurzbf9A6qCWu0ilGTx9jYKxY4OP8FiNH3T3RBF1tYDGXutDgDbvr3Is9I7g KkJr3cRp3rXq5A5eK09frgL8E7oYUkqs4PRzvmDW/rgB1VJtmGzC3yGlGO4QRmbrQwAG 3N4A==
X-Forwarded-Encrypted: i=1; AJvYcCXtHFcj1PB/vJG0PwyGvmlr722JXB9FM9vWe9jDLA90Sx/TSCeH8iLbGFVEAhxdQaVBLNxc0LUW6jLNCi7G
X-Gm-Message-State: AOJu0Yz5Rp+xKo10bxwwOYtBr+05cHoI41TSXVb+m5JnQ308MnxMLYxb 5i8rIHW3Bg7Hy7FMiHBsmhwWbhziP+lbKc7Mi9ApWMxTMHlWsKT1apL0jhyOqEqo7D5oLNcBEMx s+mi8/dq1oMTyBj6msNW5B1d4+4FUIicp
X-Google-Smtp-Source: AGHT+IFNbmBT0q7C37jRCwZpvQ3T534L48X/rACUANEvEPn7XG5I/TWZK4GgVWLy/DGL11fZL+lGvRtqqOU6qpl3b58=
X-Received: by 2002:a2e:4c12:0:b0:2d6:85ea:efa5 with SMTP id z18-20020a2e4c12000000b002d685eaefa5mr916219lja.15.1711163922124; Fri, 22 Mar 2024 20:18:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAPt1N1mOyG2jrLcK3Gc47_i-XkbVPY=GweTMWNKOK7O00BpaFg@mail.gmail.com> <04BB59E2-D7DD-4409-A5AB-17321FA8E061@employees.org>
In-Reply-To: <04BB59E2-D7DD-4409-A5AB-17321FA8E061@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 23 Mar 2024 13:18:30 +1000
Message-ID: <CAO42Z2yqemkhJx3Kpdx0_tg4f07XV6auJo5X8LOy93fQNK0A8w@mail.gmail.com>
To: Ole Trøan <otroan=40employees.org@dmarc.ietf.org>
Cc: Ted Lemon <mellon@fugue.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb1b0106144b65aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PB4CrQCNavmr9tFnbWW4tMEDwGM>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2024 03:18:49 -0000

On Sat, 23 Mar 2024, 08:11 Ole Trøan, <otroan=40employees.org@dmarc.ietf.org>
wrote:

>
>
> On 22 Mar 2024, at 22:25, Ted Lemon <mellon@fugue.com> wrote:
>
> 
> You have a single address you can’t advertise in the dns, yes. If you had
> a GUA you could advertise it in the DNS and have confidence that it would
> be reachable for some time.  Sometimes you’d be wrong, but usually not. If
> you have two GUAs you advertise both and let happy eyeballs take care of
> it.
>
>
> Yes, hand-waving is not hard.
> Do we have an example application that does all that’s required? Open
> source?
>
> I struggle to think of anything, but surely someone must take advantage of
> the end to end transparency in IPv6
>

Tailscale VPN

https://tailscale.com/kb/1121/ipv6

"IPv6 sometimes helps make NAT traversal work more efficiently, or removes
the need for NAT traversal entirely."

Xbox

https://archive.nanog.org/sites/default/files/wed.general.palmer.xbox_.47.pdf


Transmission BitTorrent application

https://github.com/transmission/transmission/issues/5336

(It's quite a while since I've run it, I'd see IPv6 addresses for peers.
Didn't dig into what was exactly happening, above bug report confirms
transmission isn't doing any ICE and reporting the host's global IPv6
addresses to trackers.)

Regards,
Mark.



> Cheers
> Ole
>
>
>
> Op za 23 mrt 2024 om 05:53 schreef Ole Troan <otroan=
> 40employees.org@dmarc.ietf.org>
>
>> Brian,
>>
>> >>> I don't support adoption.
>> >>>
>> >>> When NAT was first introduced, I experienced a lot of trouble. There
>> may be fewer problems these days, but I think the reason is that
>> applications are built with NAT in mind. In other words, I think it limits
>> the ability to create applications.
>> >>>
>> >>> I think it is undesirable that something works in an environment
>> without NAT but does not work in an environment with NAT. If this happens,
>> should I fix the application or the network?
>> >>>
>> >>> I think it would be desirable to regain an environment where
>> applications can be created without restrictions, and I think that would
>> make the Internet better.
>> >>>
>> >>> Even though IPv6 can eliminate this restriction, I do not agree with
>> restricting applications with NPTv6.
>> >> Could you say a little more about _how_ NPTv6 restricts applications?
>> >
>> > That's a slightly strange question since the draft already has a
>> "Implications for Applications" section. Possibly it needs modernisation.
>>
>> Perhaps I should have phrased it better. I meant what concerns he has
>> outside of what’s already in the application section of the document.
>>
>> > But I think Naoki is missing the trade-off here, and the comparison
>> with our bad experience with NAPT44
>> > and even with NAT444 is too simple.
>> >
>> > There are a few scenarios where NPTv6 makes things better for a user,
>> because otherwise they will lose connectivity. Outside those scenarios,
>> NPTv6 is a bad thing and should not be enabled.
>> >
>> > It's quite different from NAPT44. I could not use any IPv4-only
>> resource without NAPT44. I can use every IPv6 resource without NPTv6.
>> That's the situation for the majority of users.
>>
>> I think we are somewhat glossing over the complexities of what a native
>> IPv6 application would have to deal with if it was acting as server.
>> And I don’t know if we have written this down or we have good patterns in
>> implementations to follow.
>>
>> An IPv6 host has multiple addresses with different reachability
>> properties and lifetimes. And they may or may not be ephemeral. No way for
>> the host to know.
>> It has to pick one, and avoid picking one that leaks any of the temporary
>> addresses, and somehow get that registered in DNS.
>> Or exchange the right set of addresses through something like ICE.
>> Deal with the consequences when these addresses change.
>>
>> And if stuck behind a stateful firewall, an IPv6 application would have
>> to do some sort of firewall traversal.
>> And if the destination is behind a NAT64, it would have to do the full
>> set of IPv4 NAPT traversal techniques (and most of these are now going to
>> be endpoint dependent NATs).
>>
>> All this, without even involving NPTv6.
>> In my NPTv6 setup, I have a single IPv6 address. With infinite lifetime.
>> >From an application implementation perspective I am not convinced that
>> this is not a lot easier to implement than the above with ephemeral global
>> addressing.
>>
>> Cheers,
>> Ole
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>