IETF Logo Mail Archive

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

Nick Buraglio <buraglio@es.net> Mon, 25 April 2022 00:41 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 A1F9F3A0CF0 for <v6ops@ietfa.amsl.com>; Sun, 24 Apr 2022 17:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 CHWIS_8cM-qC for <v6ops@ietfa.amsl.com>; Sun, 24 Apr 2022 17:41:39 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 BCD4C3A0CEF for <v6ops@ietf.org>; Sun, 24 Apr 2022 17:41:38 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id bu29so23586223lfb.0 for <v6ops@ietf.org>; Sun, 24 Apr 2022 17:41:38 -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=x1zuQHYnmbNNPPdJc5QwLnUboT/QrdPVNeB5kI1Q5jU=; b=YZQD/T1NJum1zU9FRF5xuoPLQQ7Ijkq7Oysc4b0dNK1RhVYy+eI091yhcvwzcQCirB H3UoBxLjh9cQqmS6Dj6t1dzqDMnb7FotgRmJGk8OUh+qR2EqitqwIEKO7AUO58MAblj1 0ZdKHWyYzmdLoEs1lZX9d7G6ydW2a8Ap9rzSS7gIq0J13XpIsLioQleYWQal+HGmHlBQ 8FBh0tWICArTrNp1L97lXbD5ZofKcYhsMEM9rQCVdYRLUCnCIU3MdCx64KeWXd6vHBL6 KXUSOfOHeL2D65KppnYRILz+vc9w0XSMvZwc6Xv/JPgHvD+wubSQVHAXCRR7LQwsPmB2 Z3Tg==
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=x1zuQHYnmbNNPPdJc5QwLnUboT/QrdPVNeB5kI1Q5jU=; b=nj2a/EAu+9UDPSEgRHqic4InAo8G26Y2Ffkt2Uct57WR19tVjRqfNb1FokB8SUBlIA JKUlkccQPnw61yWcep8M/TL6A3aziYAhaQKBzHlncLotuTfmlRspc7EvUXjFcp6BOpQS DwiQ5whygKqaqQ3B4mhEjqKrugsWTv3pFJg16X41QLje3OpQ8+EwM+PtlbF1fEYikW4B YUINHJwy22tY90LM3TIADN4Jb88yQPbauBKQ+lR+NTPhpot65wE9GKyTLzVPv0LrRLjb ZrKJYkE5e9fR2V4vGDmGhuH6hLtTvczadouf5HFPMWuVkQZ0aMglvKc6FylTGJukim0S ftRA==
X-Gm-Message-State: AOAM533ph9+3O+LspBfD2dVzmoABaKQNzYHCm4WnU8F+t0PtW0nov7Tj HSMI7embtEbnqIzJFEkn1hd4BbpuG4v6AMRq5wRgc3971EvX5HQ2sdqdm179PFeOMokRpxCmhX3 X32f3aKR+NtSLyHMbIdtE3ufAcmUHlpXA47iIgv2dQhWT1x37dCu+36/NOq7vJgL2mOrIFewMzm c=
X-Google-Smtp-Source: ABdhPJxIXgpGzpLnYw5piMw35tsSg21WKj5unNNxXWutM3MvQBblKGawQTKtAVJd2QDJfsmG7Qrajj+YwlMb8CHdBJA=
X-Received: by 2002:a05:6512:b21:b0:471:c0de:51ff with SMTP id w33-20020a0565120b2100b00471c0de51ffmr11313060lfu.299.1650847296146; Sun, 24 Apr 2022 17:41:36 -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> <CAM5+tA9boLSaXmVwDV=iV+VV9iN8STirdZxV2XfETE2HN_Upuw@mail.gmail.com> <CAKD1Yr1WJi-2kg-BEcCWHcEQGfMdMigsRt_15ZmeMkA27eqZKw@mail.gmail.com>
In-Reply-To: <CAKD1Yr1WJi-2kg-BEcCWHcEQGfMdMigsRt_15ZmeMkA27eqZKw@mail.gmail.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Sun, 24 Apr 2022 19:41:25 -0500
Message-ID: <CAM5+tA_KL3rBktJZCqAGzkoNhQiyxX11-Bz=6OY4K9EUHWz_vQ@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="000000000000aab14205dd6fd6b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/U2O30zdejcBzjeINvcAX2qkt9rM>
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:41:45 -0000

Next time I have my lab up I'll grab some packet captures. My experience
messing with this last night did not behave as expected (i.e. no IPv6 was
used in any of my ULA tests that involved dual stack), but I did not grab a
packet capture of anything but the http process, and not a verbose one.

nb


ᐧ

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

> On Mon, Apr 25, 2022 at 9:29 AM Nick Buraglio <buraglio@es.net> wrote:
>
>> 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.
>>
>
> Looks like at least one popular implementation does apply it:
>
>
> https://cs.android.com/android/platform/superproject/+/master:packages/modules/DnsResolver/getaddrinfo.cpp
>
> AFAICT the code assigns ULA a label of 13 and a precedence of 3 as per RFC
> 6724 section 2.1, and applies the common prefix length rule to all IPv6
> addresses including ULA.
>
>>

v2.23.0 | Report a Bug | By Email