Re: RFC6724-bis?

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 22 September 2022 18:33 UTC

Return-Path: <mcr@sandelman.ca>
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 25917C1524DC for <ipv6@ietfa.amsl.com>; Thu, 22 Sep 2022 11:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=unavailable autolearn_force=no
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 NXpqQ0xwZEhk for <ipv6@ietfa.amsl.com>; Thu, 22 Sep 2022 11:33:07 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B3EC14F74F for <ipv6@ietf.org>; Thu, 22 Sep 2022 11:33:06 -0700 (PDT)
Received: from dooku.sandelman.ca (dynamic-077-011-150-065.77.11.pool.telefonica.de [77.11.150.65]) by relay.sandelman.ca (Postfix) with ESMTPS id 538D41F4AF; Thu, 22 Sep 2022 18:33:05 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 9B87F1A01CD; Thu, 22 Sep 2022 20:33:01 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
cc: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC6724-bis?
In-reply-to: <CAN-Dau2QO5sxevJwUbOj+_wyiCdOjnPEZM14Jhevvkq4YZqU7Q@mail.gmail.com>
References: <66892DC8-6DA4-4DC8-85B0-E1E1647CD9F7@gmail.com> <CAM5+tA9kttCKrZaoB7UzNdE6TU1qGNMaxDmWvFtRvpB4A8+WHA@mail.gmail.com> <8FE71499-D155-4853-A964-6617F6EA2069@gmail.com> <CAM5+tA9QuYxVs+NXBD3dAYr_Y=95bWt63WjmEMDOfegL0Z4otA@mail.gmail.com> <CAM5+tA_hg2sXXsYw6Tcx-ytRAMkKQcFw8a3N7SfEXwbuPm0LMw@mail.gmail.com> <00ea3b70-ba8e-b6ef-e1ce-fdd56828f506@gmail.com> <CAPt1N1=_9Rwj-HnUZKWfatARbHWptArmSAV-qdi8MKyoBf9R0A@mail.gmail.com> <CAO42Z2xZ_-mDh66A9DK+3ieEqGMqW0Pt+mZzVOmzz4cDRUTEXA@mail.gmail.com> <CAPt1N1nqwMvVHvEGAx0jxgWhbW9ZUQfAZSDn-qRYQ0CDy-EGKQ@mail.gmail.com> <17a28c173ed640e68b1cbf504bbeae49@huawei.com> <CAPt1N1=xR_2Xw+1KL6vbzZ69N+vonhcTNvO=DBceeApfoS2bMQ@mail.gmail.com> <e76267b6101146cf8a1bd6fa567c6b77@huawei.com> <CAN-Dau2QO5sxevJwUbOj+_wyiCdOjnPEZM14Jhevvkq4YZqU7Q@mail.gmail.com>
Comments: In-reply-to David Farmer <farmer=40umn.edu@dmarc.ietf.org> message dated "Thu, 22 Sep 2022 12:21:16 -0500."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 22 Sep 2022 20:33:01 +0200
Message-ID: <406795.1663871581@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-6zCONiFrEFwWeAncevRnS2xqXc>
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, 22 Sep 2022 18:33:10 -0000

David Farmer <farmer=40umn.edu@dmarc.ietf.org> wrote:
    > Experience has shown us that despite recommendations to the contrary, ULAs
    > are in the Public DNS, how much is questionable, but it exists
    > nonetheless.

... I think it's a feature of IPv6 over IPv4 :-)

    > Now I have some related questions, is this connection failure going to
    > result in a full TCP timeout or happy eyeballs timer expiring? Or, will an
    > ICMP destination unreachable or other ICMP message shortcut the TCP timeout
    > or the happy eyeballs timer? Will most CPEs on the market generate an

I think that we should be getting ICMPs.
That's also why I think that we should have 2000::/3 routes, rather than
default routes.

    > destination unreachable, an ICMP administratively disallowed, or simply
    > just forward the packet to the upstream ISP using the default route? Would
    > most ISPs generate an ICMP destination unreachable for the ULA in this
    > case? Finally, even if the ISP’s router generates the ICMP destination
    > unreachable, in most cases, I don’t believe the ISP will have a route back
    > to the originating ULA address anyway.

    > So, I think we are probably better off with SA/DA selection not preferring
    > ULA unless the prefix is know to be local.  This is the best guess.

I totally agree.
I thought that we were just debating about the different ways that we would
recommend implementing this.  That presence of a /64 ULA implied that the
entire /48 is probably routable.  That maybe we need some additional signal
if there were multiple ULAs present.



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-