IETF Logo Mail Archive

Re: [v6ops] ULA precedence [Thoughts about wider operational input]

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 07 May 2022 21:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 83E34C147930; Sat, 7 May 2022 14:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level:
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=no 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 Ag8ndT-R1QVS; Sat, 7 May 2022 14:53:45 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 0FB49C14F732; Sat, 7 May 2022 14:53:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1262838C19; Sat, 7 May 2022 18:07:03 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dSJlftxafqRs; Sat, 7 May 2022 18:07:02 -0400 (EDT)
Received: from sandelman.ca (unknown [172.30.2.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 135D038C16; Sat, 7 May 2022 18:07:02 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 85EFA22E; Sat, 7 May 2022 17:53:41 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops list <v6ops@ietf.org>, 6man list <ipv6@ietf.org>
In-Reply-To: <51da336e-bc56-9228-0c93-0b7682295eca@gmail.com>
References: <CAM5+tA8WvjvWirxqE6kQ9LQAG0NcpWyCLGVooB=G7gZ9ETb2zQ@mail.gmail.com> <20220424172743.GA218999@fg-networking.de> <CAKD1Yr1v0Tkh+pWD-ts=PL3gZf7Qj6OHW6Cuvj8iGcSSMibjew@mail.gmail.com> <20220425100310.GF67548@fg-networking.de> <CAPt1N1=XedJ7tY9pKDS3LvDMak6iPsK9fA=oF7Z0KkmGcA6-_A@mail.gmail.com> <CAO42Z2ydhe3hVOqSaN814hYh3oF3yG_du+gRkg6yD5haCqDnLQ@mail.gmail.com> <CAPt1N1=YdnZ_N+47v4A_EM70TobSt1sw5tcmBfQJEP5Y1zCwMg@mail.gmail.com> <CAO42Z2xyx2MpCCYQoXA9izRM7Xk42+Z-1OnL2PuzgsGfw1SFiw@mail.gmail.com> <20220428075001.GA86458@fg-networking.de> <3499CB52-0873-4DF5-A923-62BF91AA6FAB@gmail.com> <CAE=N4xcci50tOhtdxYVevcEFh4y8_CyF8qd0dRsXvpAKoX4yZQ@mail.gmail.com> <48435B34-A6F0-45B6-AA28-CB1E9E61EA6D@gmail.com> <CAE=N4xdwvMPbUwOk6N=5quU+Bhc84u8F2Ep+bNOqE+A9_hAGcg@mail.gmail.com> <15039.1651807402@localhost> <51da336e-bc56-9228-0c93-0b7682295eca@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 07 May 2022 17:53:41 -0400
Message-ID: <4921.1651960421@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/i1iXc_2Th8PuR59tejaqaRuXrhQ>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.34
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: Sat, 07 May 2022 21:53:46 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    mcr> I don't know how it would know to use fd01:abcd:1234:4567::A/64 when
    mcr> talking
    mcr> to fd02:fedc:8765::/48 ("ULA2").  Really, this comes back to the general
    mcr> source address selection problem with multi-homing, which homenet tried
    mcr> to solve.

    > Surely, two addresses in fd00::/8 will always have a longer match than
    > either for them does with any address in 2000::/3 ?

Sure, but my understanding is that it is proposed to add the /48 associated
with any fc00::/7 (fd00::/8?) /64 that is found locally.
That this /48 would now have higher precedence than the IPv4 NAT44 address.

Think about a laptop/desktop that is inside the company, trying to reach
smtp.example for outgoing email.  Said name might have a variety of address
types for inside, outside, VPN, .. maybe even geographically distributed.

    > That being so, section 10.6 of RFC6724 will still work, won't it?

Probably.  But, we were discussing prioritizing ULA over NAT44, right?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email