IETF Logo Mail Archive

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

Ed Horley <ed@hexabuild.io> Wed, 04 May 2022 18:02 UTC

Return-Path: <ed@hexabuild.io>
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 25F76C159527 for <v6ops@ietfa.amsl.com>; Wed, 4 May 2022 11:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hexabuild-io.20210112.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 PNqgbc9GpIVM for <v6ops@ietfa.amsl.com>; Wed, 4 May 2022 11:02:24 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 4BFECC1594B3 for <v6ops@ietf.org>; Wed, 4 May 2022 11:02:24 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id h29so3693071lfj.2 for <v6ops@ietf.org>; Wed, 04 May 2022 11:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hexabuild-io.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bQeS2bDDSRHqVUer4jem29A38WR7MHJWF6wtW3oVWU0=; b=FbtzC6/k00olyBSjfk0yQ+ghohlkMTPGjdMC8FzwluqNd78veXOxES4KvumjhFFpPj eihGenBWnb2BxtQ/IrMQLppRzqF1ZkkynDcRs3BeBliNtgdiLVhoFkHHL34CY3W7JmZ7 rhnkKPd6d+gDIrX9C04w5oTIdVZEqN/BohiaaZ+683n+E4FU4Hwp9GazLv8Vn9lDnmpD W0AzBFOhkQj/l2xCSdLxeud1RnIpbgtBoVXkSzLs1NSif6f8zAXpfurmHE3VNqgnYWvW gVPq33dbJHoG/Q6M37VgGCw82FXdnlefp7sm6gohPt0dcDW69hkndrZ12jd2KJBDJ26e vZag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bQeS2bDDSRHqVUer4jem29A38WR7MHJWF6wtW3oVWU0=; b=EmSk15y7iRIHydjDzT2BduQpUpnycYdoBThP8T8nMSURmDAvzLet74lh6lwJfohsAD zthcOEnfcFngBKS84NVsbhQq5RTgu69vjkGGc+nTr3+jx2rW4XSuuFjwHLAbGTtUhTgW k6fpIqV6dAmXhVy2YS8Io7uFQJRq31TszwRHxLXFra26sgIvqciGY9vFRmMKQmXdtq1a VSPg2gNMPs3KLnPNfF8ORolS7PCmcsk3AnYKaAHrhxPv5PYO2vZ6HL1+czOWR6GHMX5o 1k6nYPSGxCd3bZSQDtrA9trDXiASCUTCLvo0O2BfJAko3x8tgzdacn551EQxkx2CH5mT Q92A==
X-Gm-Message-State: AOAM531CKzlNxV3HFLb1sbyujaBSwZvxc3+1gRa4RkYfG2esisjLNlSj 6C/rS780nuo5IbD1PYJlmNsfhwerZk0aLlncN2BcRw==
X-Google-Smtp-Source: ABdhPJykkAZtUq2wSadQYdCR6Mg+R1liNqvEtshkfTgb3tPYhd2y8mppBIPEi2ZNv6JlUPOmYbeEm/b0SRmTlUvLVLM=
X-Received: by 2002:a05:6512:3a95:b0:473:ab60:a94f with SMTP id q21-20020a0565123a9500b00473ab60a94fmr5231938lfu.674.1651687342105; Wed, 04 May 2022 11:02:22 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <3499CB52-0873-4DF5-A923-62BF91AA6FAB@gmail.com>
From: Ed Horley <ed@hexabuild.io>
Date: Wed, 04 May 2022 11:02:10 -0700
Message-ID: <CAE=N4xcci50tOhtdxYVevcEFh4y8_CyF8qd0dRsXvpAKoX4yZQ@mail.gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: Erik Auerswald <auerswald@fg-networking.de>, v6ops list <v6ops@ietf.org>, 6man list <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e8b5e05de336d26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/GyY5lXE7Mkt9QjeKDn1GLTSBjR0>
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: Wed, 04 May 2022 18:02:28 -0000

On Wed, May 4, 2022 at 10:54 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:

>
>
> > On Apr 28, 2022, at 12:50 AM, Erik Auerswald <auerswald@fg-networking.de>
> wrote:
> >
> > I'd say that _remote_ ULAs are less reliable than GUAs. Selecting ULA
> > source to reach GUA destination risks that the return traffic would be
> > sent to a _remote_ ULA (if the initial packet even reaches the
> > destination; it could be filtered because of using a "wrong" source
> > address).
> >
> > The RFC 6724 default errs on the side of caution by assuming that ULA
> > are non-local, unless either auto-detected or configured as local.
>
> From a specification perspective, it seems to me that the two cases should
> be separated. If I have a local ULA address and a peer I want to
> communicate with has an address in the same prefix, then I probably should
> prefer to use that address pair unless I have a reason not to. In any other
> case, I should use my own GUA and send the message to my peer's GUA - I
> have no guarantee of connectivity otherwise.
>
> Just for clarification - when you say "same prefix" for ULA - are you
assuming in the same /48? Or do you mean within all of ULA (fc00::/7 or the
useable fd00::/8)?

In fact, I'm not sure how I would know that my peer has an address that is
> not in my ULA prefix. It shouldn't be in DNS, as I recall (RFC 4193 section
> 4.4). That might mean a split DNS implementation...


The majority of customers we are working with are doing split DNS in some
capacity. However, we are running into designs where they are planning on
doing ULA everywhere and NPTv6 or NAT66 to a GUA at the Internet edge. Plus
they are dual-stacked (which is why Nick's ULA draft is important for us.
We can point customers to something that explains the problem space.)

>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
Ed Horley
ed@hexabuild.io | (925) 876-6604
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io
And check out the IPv6 Buzz Podcast at
https://packetpushers.net/series/ipv6-buzz/

v2.23.0 | Report a Bug | By Email