Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

Ted Lemon <mellon@fugue.com> Thu, 11 April 2024 12:41 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 A30FFC14F691 for <ipv6@ietfa.amsl.com>; Thu, 11 Apr 2024 05:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 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] 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 KBTL_vukmzUb for <ipv6@ietfa.amsl.com>; Thu, 11 Apr 2024 05:41:26 -0700 (PDT)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 8B3CFC14F680 for <ipv6@ietf.org>; Thu, 11 Apr 2024 05:41:26 -0700 (PDT)
Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-6963c0c507eso8279986d6.1 for <ipv6@ietf.org>; Thu, 11 Apr 2024 05:41:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1712839285; x=1713444085; 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=7M+lUK7YmDGoigl9jRuYHjynmDo5utMByxUGXNW1FT8=; b=AmfVaK3XAO3bxEdMfRuJdstikM3AZTA9LiB7UfWzLV4FKOiisw+37WjHRFeeO8aaDa BPdgpS418IHH40B8vBanM+xSB5STfbewQ4WCx5HX1e10Q16afBt+/GOdpK9f/r6af8aA FCn9cFI1OlIs/PLTzil/PtdEaObQeQYWU0M+L5DQurNsWMg01vCu802RiW5roD5WQcfF CsiNMJ9nRIRGBlW0Juvwvb3nCdSiYC/+1HnEJVUM5EvVh3YsMLyo5UtfvB2qOqROJfKg v1JeaSJlWd/Wmt5NPILcwLFQ3b9Uyvme0/84KCo2Hln/iQTREOXSMKFhPlfxu+2MHX1l 8C0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712839285; x=1713444085; 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=7M+lUK7YmDGoigl9jRuYHjynmDo5utMByxUGXNW1FT8=; b=LaOkpdLcP0HtVA42Q0Czmsa6UaT+24FI3pbzPC1pJXGOQzkT5o7b8/7vQXUiHqM5/D QY8lkIBUpVBMrHQ/5/vLZ6IKDSL2+7KD2U2tddBkJrb2878nkgxDhNtN1en2cbj2Inh5 pBMmGYEzDruV5xxnQLniH/CDGnKbveJj4FF4BFfRLuFMZA6Hh0VjUh42nY3lECZ7OW2S QFrABRh7JEZprWIV/SbvnoVfo+53j6MF0LHQO5JiqzPV0gCY6EtBWb+U4Hx/6RcSaVAJ NSzUChjup2NWO8TAfCKV/0rpeslFW6FwPjlZF1sMZq0CcYJBuRc0HIdtQtCKnZY8hHsQ OcEQ==
X-Forwarded-Encrypted: i=1; AJvYcCWccYn8sbMnPWxSgd4nkQpytekU8Vm3nPGRqt3VyBHe6Bq1VryDdY+fydJxGnvpO/OWXb2X3l4iKlGzsOzz
X-Gm-Message-State: AOJu0YzDc8TfOsfOxfGSGjf/2uxCFn+KE6Z5EC7TwKk8LO7AIjqYkhCB wmNdWIkoQM2u6fW5ZJDRrAfMudwh92L0fXpAbuXQCxMMz514SGnZYlGdC3CVCMqe6g5MV/jLBj4 k5N/xgztOV5BWCeA/SSvk1UKNZ+Lxh+vWMEMWbA==
X-Google-Smtp-Source: AGHT+IElZfy8wl5k26phPCX9Xjmexjr0q9FACw0nF/J7WH2ishpGhPKwHvEnFCz1Y9tEHlouAQmBhdZlYpPjgLJwkxs=
X-Received: by 2002:a05:6214:20c4:b0:69b:46cd:5458 with SMTP id 4-20020a05621420c400b0069b46cd5458mr6268357qve.1.1712839285489; Thu, 11 Apr 2024 05:41:25 -0700 (PDT)
MIME-Version: 1.0
References: <6A5E5F35-B35F-4358-8EE1-3BD82329141E@jisc.ac.uk> <6FBC1B5A-BF28-4B05-B2B2-A60DA4707755@gmail.com> <CAPt1N1m-Ye8vfOVnsPesFshLMV5QuVoxWqM=HVZiJ37zaBg6AA@mail.gmail.com> <CAKD1Yr1NTvFj0zB0=+nnUKck7TBtwHFz2XoFkD1smx4yCuZohQ@mail.gmail.com> <CAJU8_nWyE5TqBTXB9wfSkn6refaqYNVN967YAtCp-0VMk-5qWQ@mail.gmail.com> <CAPt1N1mqszfafMMY=54ezpoRymoy=bBjeVnWzxj6A27smR1eig@mail.gmail.com> <CAJU8_nWDDfwWEoahU4dqTEh3_HCq2UfpkFjefnXohb+5DAbjew@mail.gmail.com>
In-Reply-To: <CAJU8_nWDDfwWEoahU4dqTEh3_HCq2UfpkFjefnXohb+5DAbjew@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 11 Apr 2024 08:40:49 -0400
Message-ID: <CAPt1N1nTJ1sDEQrn1iNUbvreu5bt0BweWgX7iOw6fmPgNBvUqw@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002b61880615d17907"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sHH999J5Sz7b5cg3qkU5iy1DdPY>
Subject: Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>
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: Thu, 11 Apr 2024 12:41:27 -0000

But this is counterfactual. Rght now if you publish a ULA in the global
DNS, it will not cause a delay because no host with IPv6 connectivity will
try to connect to it. We only run into a problem if we decide to prefer all
ULAs over all IPv4 addresses. That /will/ in fact cause delays. Making the
known-local mitigation mandatory corrects that problem. So it gets you what
you actually want, whereas what you are currently advocating for makes
things worse for you, and is presumably behind your concerns about not
publishing ULAs in the DNS.

On Thu, Apr 11, 2024 at 8:22 AM Kyle Rose <krose@krose.org> wrote:

> Globally publishing addresses that are unreachable means clients will try
> to connect to addresses that are known a priori to the address publisher to
> be unreachable from much of its audience. Anyone who cares about
> performance will not want to take the hit of clients waiting for a timeout,
> if the application even implements retries.
>
> Happy Eyeballs is a mitigation for configuration errors and transient
> connectivity problems: it's not part of the TCP handshake for a reason, and
> should not be required for a properly-configured client on a
> properly-configured and fully-working network to reach a
> properly-configured service.
> Kyle
>
> On Thu, Apr 11, 2024 at 8:02 AM Ted Lemon <mellon@fugue.com> wrote:
>
>> Perhaps we could start by having you explain why it's a bad practice,
>> Kyle, since this does not appear to be universally accepted as true? :)
>>
>> On Thu, Apr 11, 2024 at 7:53 AM Kyle Rose <krose@krose.org> wrote:
>>
>>> Also, MUST allows us to make ULA more useful than it is today. It is
>>>> *desirable* to be able to publish non-local ULAs and have hosts know what
>>>> is local and what is not. As a simple example: once all hosts implement the
>>>> MUST, it will be safe to publish local ULAs in the global DNS, because
>>>> hosts won't try to use them unless they are local.
>>>>
>>>
>>> Perhaps ironically, this is the best argument I've read in opposition to
>>> mandating the policy table be updated for known-local ULAs. Unreachable
>>> addresses should never be published in global DNS with the intent that
>>> clients figure it out, and the IETF should publish a standards track
>>> document explaining why this is a bad practice.
>>> Kyle
>>>
>>>