IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 04 May 2022 20:47 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 0490EC159827; Wed, 4 May 2022 13:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.955
X-Spam-Level:
X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-1.857, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 x7TUUmlYiDFB; Wed, 4 May 2022 13:47:17 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 F1DF6C14F73D; Wed, 4 May 2022 13:47:16 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id t11-20020a17090ad50b00b001d95bf21996so6207655pju.2; Wed, 04 May 2022 13:47:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WVfFDzmnJkp0zL/B0MEbs+4nL/S87n/ErntGGaV8oio=; b=U2BYTBbtgBcYXHnoqKr/GMEBlOUx8ayklUEhf00T+8jD0o7cOlTps0EKgAHEB8Pgzz cLjskYY04s+CCr/H598sce1AKk+rb/PsvKJgZP6QScouP15JvagjAVptipVo+3jQXcvw Qj5j8PZC0PVjCXG3/88aBTVHStymFq2blM9jIyXp/W79kAtK53/v4bdszt52VX/Ks4AC +c1CqrwbwG5N/4pJhfhyJ3yjEG1OefOdicMxAAqe46QZamZZxOmnUAr3/BCljDe0N4M9 n25l2jS0E3ieazH9gzOckqoC4xYovRXp2iqA2MBB1qVICAbYTk1/RcvmpDfVVzCwNkiG SRrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WVfFDzmnJkp0zL/B0MEbs+4nL/S87n/ErntGGaV8oio=; b=BjAfyPJD7RhzReGsK5wwZM4OMzFsef2R7LqPhWfLS9qot8HXx/9PQp4jjJbb2xJRqY 6qgEGMfiwVytvOPLDa2DYYcPWa4CCqfDtE9K86lkv/i3E7GyI8VZXlFae4LFxbBMlpGw iK0HUKw/KV9vCsjnTqC5imEgqwN6SGRSSgAraM5589WtOe7gnESheWXjfsTjm3yQTbGE tHl9s2SZJBSReFTPnr2UCsJhyEChCEPgphbVuprl+zr4M/4gix6QKAQffHfZTo0tJ+GW q2ic5XtRB+r3x5WEsIcibs0DHklbiRGVTSTvT4WtSGEO+cq4mH0LJssKoS7Zli/hwbbT hw3g==
X-Gm-Message-State: AOAM5328gYMEliC4OC1Ftjl4JVS1a3M3MJ7FIkaJZ7fu1sxBJQeVJGLX Hpx3H5Ux8/LlEOfFXGtF00cm1SmweCbNOw==
X-Google-Smtp-Source: ABdhPJzzAC3NEXHY+SPXTVNHx/9CCwfmdaJwnpdQZTOfn99lbvaCAYp4sgFGXHRAM5DIALkn8iJGfg==
X-Received: by 2002:a17:90a:8d82:b0:1d2:cd8c:ed6 with SMTP id d2-20020a17090a8d8200b001d2cd8c0ed6mr1603886pjo.63.1651697235979; Wed, 04 May 2022 13:47:15 -0700 (PDT)
Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o19-20020a170902e29300b0015e8d4eb231sm8750560plc.123.2022.05.04.13.47.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 May 2022 13:47:15 -0700 (PDT)
To: Ed Horley <ed@hexabuild.io>, Fred Baker <fredbaker.ietf@gmail.com>
Cc: Erik Auerswald <auerswald@fg-networking.de>, v6ops list <v6ops@ietf.org>, 6man list <ipv6@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <efb9ff12-60d1-c4a8-9833-c5fcd06d05f1@gmail.com>
Date: Thu, 05 May 2022 08:47:10 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CAE=N4xcci50tOhtdxYVevcEFh4y8_CyF8qd0dRsXvpAKoX4yZQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mtAVOmFnubP9HehTmiW9G6mGnB0>
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 20:47:18 -0000

On 05-May-22 06:02, Ed Horley wrote:
> 
> On Wed, May 4, 2022 at 10:54 AM Fred Baker <fredbaker.ietf@gmail.com <mailto:fredbaker.ietf@gmail.com>> wrote:
> 
> 
> 
>      > On Apr 28, 2022, at 12:50 AM, Erik Auerswald <auerswald@fg-networking.de <mailto: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)?

I hope he means the same /48. If you do what RFC6724 section 10.6 says, it works as Fred describes.
  
>     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...

I agree, it would be odd, but the standard policy "fc00::/7 3 13" will save you in that case.
  
> 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.)

Right, but if the host has *no* GUA won't a policy like "fd11:1111:1111::/48 45 14" work anyway and direct your packets to the exit gateway that runs NPTv6 or NAT66?

     Brian

v2.23.0 | Report a Bug | By Email