Re: [v6ops] Thoughts about wider operational input

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 24 March 2022 02:00 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 06B253A07A5 for <v6ops@ietfa.amsl.com>; Wed, 23 Mar 2022 19:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASphJacG5RpX for <v6ops@ietfa.amsl.com>; Wed, 23 Mar 2022 19:00:18 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 442E73A079F for <v6ops@ietf.org>; Wed, 23 Mar 2022 19:00:18 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id x2so3299063plm.7 for <v6ops@ietf.org>; Wed, 23 Mar 2022 19:00:18 -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=D+mcfRA7sTHAQP1gLUDiyWMfwjB6GumVPZgTiSFaX6s=; b=b5l4OknFrEkhWCLMYfwu7W3bXSiyvFBz4CAhoIgjAOf+ddrVuV6n0hM8pwAA8TY+Bv pk55lE46YlUjSaB2XwOs+0Q9bSjiVvPA7LJryUubkSW1EB73CRcOnPjLKLUTxsq+jIwi lf0ERF2ZU9AqP05GzA2QbJ3D1JJKoXkj76l6eDrXEFxwIp2UPq694YVo7sWF26IxCjAx 7WYHZ1YvnP1cSTtX5HlXlUbiCWSwuFVl0/PgAixlk8JRRwQ13SFB8GFGb5g7e3VbuXCZ Qwhy2O5dJiIw5riV0g67mafp/Jq9UqKGXD4mL+WD4bSImIelkrZJ5DfTIsL10xK9bOU1 u/RQ==
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=D+mcfRA7sTHAQP1gLUDiyWMfwjB6GumVPZgTiSFaX6s=; b=hEjvYN7FVZAZNG4Nnp8pgkINYMBKklnJqHTegfZ0aAghqEt7orfq4BJrdS9zX0Nnab fC4SfoeCqO8A2FzVL8hBu3kuzKXY9r4n4m6EKsbt1bS/6LDslchNdro3Z4KGp58O0EgT XBBh4KM7N5u3pzIseNzSPXjJ7Hmrwy8Aq+t5vz0mF3sJR3FLYQlwgFZHf5L9yazOK4iP 8IsCchH4LSYkOzrojSbDlhfjomTYcAFOcVyw9/zAIUF3Fg1CiUihkolgF64Ix3zi1pFu 6pqYgvGz5P1yjfOJ851JT0vu9RNWA8ZUTnxBLKW8Gpg40w1pQcVnI+PBCXzcPi9oNqs0 KVcQ==
X-Gm-Message-State: AOAM532n6iGmvbigZYg5AwLcS/skR+XRvJuyT02f+Gu2JEc4QTuwvQ0B 0zMHGyI/2cQe7zEvq94l0tekMxpZ2Byqbw==
X-Google-Smtp-Source: ABdhPJzR4QitA0PsWYMJXvXh9KquHUkZZBPK5wQy+e/wLVFdIBu5syK5CdF/Bw65ymO+gRzCHbRfgQ==
X-Received: by 2002:a17:902:e74d:b0:154:46d4:fcd1 with SMTP id p13-20020a170902e74d00b0015446d4fcd1mr3170164plf.58.1648087216593; Wed, 23 Mar 2022 19:00:16 -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 f13-20020a056a001acd00b004f7a2f18e61sm1090455pfv.137.2022.03.23.19.00.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Mar 2022 19:00:15 -0700 (PDT)
To: Mark Andrews <marka@isc.org>
Cc: buraglio@es.net, Vasilenko Eduard <vasilenko.eduard@huawei.com>, v6ops@ietf.org
References: <8f918356-89ce-e2a1-a807-7d382568db0a@gmail.com> <5A071DCB-DFDC-47F7-85B3-8C9E58B691DA@isc.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <0151f9ba-c32a-9d52-8113-035269e33edd@gmail.com>
Date: Thu, 24 Mar 2022 15:00:10 +1300
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: <5A071DCB-DFDC-47F7-85B3-8C9E58B691DA@isc.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/NuDdBlHm6KMEyRda3n8oF9C4yF4>
Subject: Re: [v6ops] 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: Thu, 24 Mar 2022 02:00:36 -0000

Yes, that's the theory. The trouble is that the default produces the problem that Nick describes, and configuring the table is far from straightforward, so ULAs don't work out of the box.

Regards
    Brian Carpenter

On 24-Mar-22 09:48, Mark Andrews wrote:
> The table is designed to be patched for local topology. You add in the local ULA prefixes before IPv4.  The default will allow connection to succeed provided hosts and links are up and configured as expected on the first attempt.   If you push ULA above IPv4 and you have a non reachable ULA you are need fast failover to the next address.
> 
> The OP complaint about the table indicates lack of understanding of what is intended.
> 
> Note there are defined mechanisms for distributing a more site specific 
table. The OS and administrators should avail themselves of them.  A node 
doesn’t necessarily have the requisite knowledge to do this for itself (multiple ULA prefixes reachable). It can add directly connected prefixes.
>