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

Nick Buraglio <buraglio@es.net> Mon, 25 April 2022 00:30 UTC

Return-Path: <buraglio@es.net>
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 465353A07F0 for <v6ops@ietfa.amsl.com>; Sun, 24 Apr 2022 17:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=es.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6wiXKoG5Zfe for <v6ops@ietfa.amsl.com>; Sun, 24 Apr 2022 17:30:01 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B8E3A07EC for <v6ops@ietf.org>; Sun, 24 Apr 2022 17:30:01 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id h3so18778732lfu.8 for <v6ops@ietf.org>; Sun, 24 Apr 2022 17:30:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=oZJ4QbCBqHpj5hGow5KWKaVgxtf+oH5sKhCvVjl+87g=; b=VBIJlQfGVlHsIr97cmaHZTxi2KKhDb0mQHTmaKgnqIRFOPJHtkZcuOUb9WiJDZApeX godNf5NzTq13/KU+rIDm7kItCPbabe61ZdxV2005tWbN2xK7FYjme2Yy3zs9xh0jI6tM Cd2D8eT4xNZUDqPHQeZHSkrBuWB32fMjSTMIFTcJfE1/yhblqOocuARbhvbFPqGKfUjw BqB1lEtfjvHF4ef857PwJyOS/2+Uf2uRBPDs5EKExutAm96rs5GMsuZs1N5av8IRxFJv rs30/KhXj3uBpaCLF7/CcObucTKPHVCZejRceLNZ6lxyJwqYdHzsyp/JZs9y5vS4Jd0Y /oUA==
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:reply-to :from:date:message-id:subject:to:cc; bh=oZJ4QbCBqHpj5hGow5KWKaVgxtf+oH5sKhCvVjl+87g=; b=zY6waSodW4PV7/EDKe49Dh2t/1QZj3ibRTbKQhSJ6t0XaEuE5f8LNgVA9I2vGzxPj7 /WtTcs/Y6S8vIFtGFuRxED40bzXPwytlFXXw7wvj4MMv8TpHs/FFq5CtctusiufJGL/O gieALBdOthz/GcWRs4dgcsDQv4aOPSdnf5sQfekO4J/mbF8JhU/w7uRkw3EQSrxa9LKP eDSHSbb7Z20QgOUPWxBEdg2vXfht2XzYKLNUdvmzMiMirjQpVXY1RDeuvHHwRsVRn30R 4ifclGlggi3hIKFCDY4QrkQyfaoCfl9ZzujQrL6IkdfwCEBEIAtEGTVehhF1OMLLhQvT IF/A==
X-Gm-Message-State: AOAM5334GYxUmLzSP/QaElmUqjz4QqX9/uEm6pQII7mc8LX9WjdziJDU GpL0FnhLYFIgC09OQ3FjH1Orn5Z/X1+Y1uKN89kYv+W+hN/xr3UKEVi1eDIR8NFPrmx2iueUy3g h+M1g0/9TNbaqAvQ8L41g+wp2vRFPO9uZjWj45NdMfSisTm7+jmblMY2FOM4+sywedBwmlCUqxQ E=
X-Google-Smtp-Source: ABdhPJxza3g0R/lWiI77NVp6V9qRa8CO/ICRnuRG9CYEVBwHTrkLeqNDfZBY3493JCPl0ogJ2tBVmiEoVWx+ShKJqow=
X-Received: by 2002:a05:6512:128a:b0:471:b3fa:221c with SMTP id u10-20020a056512128a00b00471b3fa221cmr11629368lfs.169.1650846598335; Sun, 24 Apr 2022 17:29:58 -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>
In-Reply-To: <CAKD1Yr1v0Tkh+pWD-ts=PL3gZf7Qj6OHW6Cuvj8iGcSSMibjew@mail.gmail.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Sun, 24 Apr 2022 19:29:47 -0500
Message-ID: <CAM5+tA9boLSaXmVwDV=iV+VV9iN8STirdZxV2XfETE2HN_Upuw@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: Erik Auerswald <auerswald@fg-networking.de>, Ted Lemon <elemon@apple.com>, v6ops list <v6ops@ietf.org>, 6man list <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001318b305dd6fad08"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/fLa0W34FozA4swI1nSyc5-RKb7E>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 25 Apr 2022 00:30:07 -0000

On Sun, Apr 24, 2022 at 7:16 PM Lorenzo Colitti <lorenzo@google.com> wrote:

> On Mon, Apr 25, 2022 at 2:28 AM Erik Auerswald <auerswald@fg-networking.de>
> wrote:
>
>>  "Since ULAs are defined to have a /48 site prefix, an implementation
>>   might choose to add such a row automatically on a machine with
>>   a ULA."
>>
>> The result is that only the local ULA prefix, i.e., exactly the
>> local IPv6 addresses, are preferred over IPv4 (and IPv6 GUA).
>> This should be exactly what is needed to use ULA addresses inside
>> an organization, or for a lab.
>> [...]
>> Implementing the non-normative suggestion from Section 10.6 of RFC
>> 6724 would in all likelihood result in making ULA usable for local
>> tests and even first steps in deploying IPv6.  ULA addresses would
>> only be used locally.  Existing IPv4 based Internet access would not
>> be impaired by adding IPv6 ULA.
>>
>
> That does seem like it might make ULA more useful, yes.
>
> Additionally, maybe we could clarify that the longest-prefix match rule
> does not apply to ULAs outside the same /48? I think that would fix the
> issue observed by +Ted Lemon <elemon@apple.com> in home networks:
> https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00
> .
>

I also have data that supports the longest match not applying to ULA.

>
>
>> In order to keep IPv6 deployment similar to IPv4, IPv6 NAT could be
>> considered.  To make this work as intended, the address selection
>> policy table could be adjusted to contain the local ULA prefix
>> with precedence greater or equal to GUA and the same label as GUA.
>>
>
> This seems like it would encourage the use of IPv6 NAT. I think there is
> reasonably strong consensus within the IETF that that is not the right way
> to go, because it pushes problems on to application developers. This adds
> costs for NAT traversal software development and maintenance, and requires
> devices to implement NAT keepalives, increasing battery usage.
>


ᐧ