Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability

Ted Lemon <mellon@fugue.com> Sat, 25 November 2023 01:36 UTC

Return-Path: <mellon@fugue.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 6AA07C15198D for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 17:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=fugue-com.20230601.gappssmtp.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 L0xUce1NjrBW for <ipv6@ietfa.amsl.com>; Fri, 24 Nov 2023 17:36:33 -0800 (PST)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 E903BC151983 for <ipv6@ietf.org>; Fri, 24 Nov 2023 17:36:33 -0800 (PST)
Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6d7e794f5d3so1574209a34.0 for <ipv6@ietf.org>; Fri, 24 Nov 2023 17:36:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1700876192; x=1701480992; 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=2C/awe9JG0Tkz75MIBeQx3XTbgiKbFZNCzs7MLbX2/I=; b=jAuGB9if1InwnaGTOCFF52DfBTW5XvEpJHKD/LoB679WTmz0+BrvbwFNnKKydCjP/p AaybJOFh/zC3tJWfbVaCCcHbkFfyFmOzet0vYkV99zg+hNS3I+MDzXp5RpKiYSAJ2WX/ vxySl286nzJIZED8sC4mEkbOS2bijrii5q1tW/8uh2nZeUboYGjtKy72utC27tx51UFx WVVY4z3xOJ8IyTE509MGDq+Qimr5XlTIOKsqu4iZ4e5qS08AnF/eQqwkBN1X6eAnXvYn cwcHUeDtitmpe2jXZvsvgm3SMSQwZ+6x5IwZEoFuQPM36lMAayRf+zSqjwR93y4levd0 ECAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700876192; x=1701480992; 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=2C/awe9JG0Tkz75MIBeQx3XTbgiKbFZNCzs7MLbX2/I=; b=Fxvgwqq/K53/wvVAbCGTwR1oFaoY0W0rnsEIE+YCg4GOZY+GzDMxZl/I+RW37lC3RF 6ZbVHGlaW/QDO9fs9jtjNubIOsUZ/zHBONiOUYvFydMy/yJrPp/yi81BQkOPn0QZ6Tvk ql4gkAUWwmkfggg6jfxiySy3uazUZB0exYLXBxATbHFDRGaEFNlS/GThy4g5AY5gbWH2 1Kcycj7Ff6I3s8AwAjGq9QugGDjYIq064PcFJnbCZq3JvgzH7crbB6B224/vUZO2czaP O9G+1krchUwxFwOkLAqnGf2rNWttr5h5vbpqNLv6DxoBGryDSh5UwsNn4Rhp+dTBws+g ro1g==
X-Gm-Message-State: AOJu0Yw0T20OXPFHbmKuajigcJKTwfHVbtPxt1sQCNsaCrgBxTitKaLt Lu20dCrY80HET61t8cjAvVk3FYf9nSg4XI6+MOzj+A==
X-Google-Smtp-Source: AGHT+IEDNCPxSaeX2vHekno+flrwJqePZgpvPwQQbtmxiP3KpdNK6FvWaqep48jAQNJaKpqt/vKnS/PVRdGi4139m+Y=
X-Received: by 2002:a05:6830:213:b0:6d6:5577:4922 with SMTP id em19-20020a056830021300b006d655774922mr4587643otb.35.1700876192705; Fri, 24 Nov 2023 17:36:32 -0800 (PST)
MIME-Version: 1.0
References: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com> <10D22CA5-CD7A-471A-B4A9-21B77D16F5F7@employees.org> <CAJU8_nVQFvp_5ZnkByCvBeA7wFz9J5FVAeud2CD1Xd4UkyL_3Q@mail.gmail.com> <4202668E-EEBE-4FA6-9801-F2A9FC92CBD8@tiesel.net> <CAO42Z2y9g3ebZ2VuXDFSK71p3X2VMVQu2=h+sXSVhcfvvxn-Qg@mail.gmail.com> <CACMsEX8q7dmRAVXuOZFVS+z_hrks=n0ChBHR4Bz9gB9ryF0ZAA@mail.gmail.com> <CAO42Z2yFiKs09K-O+SxDytLst_Uu4MAae65PTgz3URLnc5MnQw@mail.gmail.com> <CAE=N4xcFU+87wXy8NkHuO7rZ-T7Z7VmTkfcYFJH3PAJ+8+NPww@mail.gmail.com> <CAJU8_nWEAwzEw-2RpYxyf-i8x_0t8AS5O4GQ8=uB0GGYDFB5jA@mail.gmail.com> <a24c332c-e949-32cc-f660-a4434aab4eef@gmail.com> <CAJU8_nUmuxZc8USDTZPJ-nQ05K3joYcXgVsExZBo6GDioWW4mg@mail.gmail.com>
In-Reply-To: <CAJU8_nUmuxZc8USDTZPJ-nQ05K3joYcXgVsExZBo6GDioWW4mg@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 24 Nov 2023 20:36:21 -0500
Message-ID: <CAPt1N1mNOtwZvqF7TQxJZiq_Kn8R2a94tZTHDwAei4kBBY1pyQ@mail.gmail.com>
To: Kyle Rose <krose=40krose.org@dmarc.ietf.org>
Cc: 6man WG <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000046080e060af019b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/79-FGuWVaantuu-T7LuIjNB3e5M>
Subject: Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability
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, 25 Nov 2023 01:36:36 -0000

I thought we’d decided that this was a misconfiguration and hence not a
problem we need to solve.

Regarding ULA->GUA I think we need to be careful to say that this is less
preferable than GUA->GUA or 1918->GUAv4, not that it is always wrong or
requires NPT. What is the case where, when ULA->GUA is the only option, we
are better off not trying it?

I know we’ve been around before on the second point and I thought what I
just said was what we intended, but I keep seeing “only with NPT” repeated
and I would really appreciate it if we could get on the same page.

Op vr 24 nov 2023 om 19:34 schreef Kyle Rose <krose=
40krose.org@dmarc.ietf.org>

> On Fri, Nov 24, 2023 at 7:22 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>
>> > ULA and GUA must be treated differently for purposes of address
>> selection: what remains in dispute is exactly *how* that treatment should
>> differ, not *whether* it should.
>>
>> Yes. What we want, I think, is ULA->ULA to win over GUA->GUA and that
>> means picking source and destination simultaneously. And we want ULA->GUA
>> to never be tried unless the stack knows that NPTv6 is in place. And we
>> can't do any of that correctly based on getaddrinfo() alone. So the draft
>> is the best compromise given that we currently live with getaddrinfo().
>>
>
> I think it's still an open question (to Mark's email from Wednesday night
> ET) whether we want to prefer GUA->GUA over ULA->ULA or vice versa. As a
> small-time operator I don't have a preference since I do not use the same
> names for both ULA and GUA AAAA records, but preferring ULA->ULA does
> introduce one failure mode not under control of the local operator, which
> is *another operator* leaking ULA addresses for public services, in so
> doing causing connection timeouts or failovers to Happy Eyeballs. I don't
> have an informed opinion about the relative impact of that kind of
> configuration error versus whatever the costs are for using GUAs internally
> to a network when ULAs would work.
>
> Kyle
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>