Re: [v6ops] enable-ula.py

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 12 May 2022 22:18 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 3B892C159825 for <v6ops@ietfa.amsl.com>; Thu, 12 May 2022 15:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.954
X-Spam-Level:
X-Spam-Status: No, score=-3.954 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=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PNbX1cQSjh34 for <v6ops@ietfa.amsl.com>; Thu, 12 May 2022 15:18:12 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 49192C1595FD for <v6ops@ietf.org>; Thu, 12 May 2022 15:18:12 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id q76so5783518pgq.10 for <v6ops@ietf.org>; Thu, 12 May 2022 15:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=koSKJiPh1BvODEEa6eLKzrdT8E8d9kktd1meOdWzjLI=; b=VV7OMqiq9a8ghUEoLzXBpdUJIpKdNOFBUgUSosTZZgHvXgL9JSh/tNZVsQ0TgAhKfJ 4w1DJSrrTTO9uLcU7+GDexGTany6pSlqlDNP4sgvpm/2VFkUbZM1R3tOvLMdwkFGFaRh 5S8jBK1Id/GIn3WMzDXAr+PqGec8rQnwVBU5sqd6U/WSQgndnLHR0kJbxQ/6uE2M9CJc oUF5K/n/QRfdvK46RpN3H+vZsAw/gBN1Gb7ACa3Aq1fT4NPCYd8MLOX/EZkHdGkUPvJs tbYnh3rlSQUYrfpP4Go7U5uCtLeqjk4C7M5ljse0tRzpaMjd5nkGux33rZ/R3omfotyM 5YRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=koSKJiPh1BvODEEa6eLKzrdT8E8d9kktd1meOdWzjLI=; b=N0DMfAI8DWdMVTCjbjqgcq5PGFivQys0AlT5Ewxsd/Hlg2A83yPuPxeSd1CG9g4zvR wNXLAz29c18d5u3GVOgClZsuFM5tn93+CVxGTJyyRkuOJ3iPbtqVR4hbmaPL94kn3TiI F2hfXqBqE13W5OrNwjRzP1BHH2eMkXNkV2k6QHOvb/y5cZhAKnN4WoOY8/3CmouqAgbm l4TGoWWIIq0gP4yGah93SJxnIvEJe3JX8Z5apqbuI2joVt5BBl9UbrrEeI8J/EN+Yy1j hTPYIqh5QDEsniO7uQxlN5ZPgQliT+akipj6hP8W3TqdBwtSdl5R7Xd9AQ6SWMI1PbQe TUzA==
X-Gm-Message-State: AOAM5329y4gR5ZQ4jNu8PjE7NBoHofkwJ0eIXfr3SsJJPkfN82iKHSJe 6x48JhBCs8uX5fHmEfrPz+TpFkwdklA0NA==
X-Google-Smtp-Source: ABdhPJwTpqwhQ86ZStdJdIeiBsll3EsamN4jgeBAPwNGOxZkvGSmhDt1wmoiC8Gsnhi3XBHDl83TFg==
X-Received: by 2002:a65:5245:0:b0:39c:ce49:e97d with SMTP id q5-20020a655245000000b0039cce49e97dmr1351655pgp.301.1652393891280; Thu, 12 May 2022 15:18:11 -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 x16-20020a63f710000000b003c63d185d1csm195798pgh.55.2022.05.12.15.18.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 May 2022 15:18:10 -0700 (PDT)
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, "v6ops@ietf.org" <v6ops@ietf.org>
References: <c52c20ee-772c-3c4c-b87f-e76de7d157a9@gmail.com> <cbe52294-48c7-07f3-9d08-c0a68f56f637@gmail.com> <fd0b026e289b4e11a6636d1942c34315@huawei.com> <f978a0bd5771429381258e81541add98@huawei.com> <73b15db0-ab2b-8f13-0b59-106e177667c7@gmail.com> <03bdac98e61046b790afd433fcb0ffdc@huawei.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <27ca530a-0897-e615-b990-dd88ec22b2bc@gmail.com>
Date: Fri, 13 May 2022 10:18:06 +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: <03bdac98e61046b790afd433fcb0ffdc@huawei.com>
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/3qH4NXaJosHS-VLvs-CL0HNxdLU>
Subject: Re: [v6ops] enable-ula.py
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: Thu, 12 May 2022 22:18:16 -0000

Eduard,

In my opinion we are constrained by the socket library and in particular by getaddrinfo(). That is how essentially all software is written - call getaddrinfo() and use the first destination address that it returns. There may be exceptions (such as a browser that implements Happy Eyeballs) but that is the default. So we can only try to change the default behaviour 
of getaddrinfo().

Regards
    Brian Carpenter

On 12-May-22 18:58, Vasilenko Eduard wrote:
> Hi Brian,
> I do not see a problem. The sequence of events assumed:
> 0. Destination address choice (it is our initial goal)
> 1. Source address choice (to choose the SA that permits us to reach the 
destination, including the possibility for policy on what Carrier to use: 
latency, packet loss, etc.)
> 2. Next-hop choice (that announced the PIO for this SA, optimal forwarding on the 1st hop)
> In fact, I do not understand how it did happen that the Default Address 
selection algorithm is choosing the next hop before the packet has been formed (SA is not appointed).
> It complicates things pretty much and creates problems:
> 1. Ted has pointed to one on the last IETF (different routers for different purposes lead to one-way connectivity)
> 2. MHMP with non-equal PIOs (when destination should be reached only from the particular source/carrier)
> 3. ULA needs something special to be activated/prioritized.
> 
> This assumption (that Next-hop is chosen before the Source address of the packet) looks like a default assumption of DASA (RFC 6724) that was never properly discussed.
> This principal architecture decision is difficult to understand from DASA - it could be read only between the lines by looking at the algorithms.
> Eduard
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Wednesday, May 11, 2022 11:46 PM
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; v6ops@ietf.org
> Subject: Re: [v6ops] enable-ula.py
> 
> Eduard,
> 
>> 1. Source Address for the flow SHOULD be chosen first
> 
> How is that possible? Before I choose the destination, I cannot know the type of source address that would be appropriate.
> 
> A human can pick the best pair of addresses at a glance, but the software cannot.
> 
> Regards
>      Brian
> 
> On 11-May-22 22:48, Vasilenko Eduard wrote:
>> There are 2 problems: ULA prioritization and MHMP with policy for PIOs
>> (non-equal PIOs)
>>
>> The solution is the same for both:
>>
>> 1. Source Address for the flow SHOULD be chosen first
>>
>> then
>>
>> 2. next-hop SHOULD be chosen only between default routers that
>> announce
> this PIO
>>
>> (rule 5 & 5.5 are becoming redundant in this case - it is not possible
>> to check against non-chosen next hop)
>>
>> Then the solution for the ULA problem is very simple:
>>
>> just prioritize FC/7 above everything (GUA, IPv4), and keep a separate 
label for it.
>>
>> The current rule 6 (matching labels) would be enough to stick ULA source to ULA destination, or GUA to GUA.
>>
>> Eduard
>>
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Vasilenko
>> Eduard
>> Sent: Wednesday, May 11, 2022 12:41 PM
>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; v6ops@ietf.org
>> Subject: Re: [v6ops] enable-ula.py
>>
>> Hi all,
>>
>> It was fine to run the script by a geek who understands his environment.
>>
>> IMHO: It is not suitable for the default configuration.
>>
>> The link could have routers not in sync on purpose. For example, one for internal communication, and another for external.
>>
>> If one router would announce ULA PIO (and route to this ULA) But another router could not route to this ULA then the communication would be broken.
>>
>> Because the second router would have a good chance to be chosen as the 
default for ULA that it does not understand.
>>
>> It is a very similar situation that Ted has shown on the last IETF.
>>
>> The root cause is that RFC 6724 assumes that the next hop is chosen before the source. It SHOULD be the opposite.
>>
>> Of course, it is possible to patch the second router by the source routing configuration Then the second router would be just a redundant hop for every second flow.
>>
>> But it is for the geeks. It is not normal to have such a default assumption.
>>
>> Eduard
>>
>> -----Original Message-----
>>
>> From: v6ops [mailto:v6ops-bounces@ietf.org
>> <mailto:v6ops-bounces@ietf.org>] On Behalf Of Brian E Carpenter
>>
>> Sent: Wednesday, May 11, 2022 1:23 AM
>>
>> To: v6ops@ietf.org <mailto:v6ops@ietf.org>
>>
>> Subject: Re: [v6ops] enable-ula.py
>>
>> Hi,
>>
>> I've been asked off-list whether this script should be run as a cron job, since a new ULA prefix could be announced by a RA/PIO at any time.
>>
>> Good point, but my script is explicitly written to be used by a human to avoid blunders. However, what I think should happen is that the IPv6 stack should automatically do what the script does, whenever a new ULA is configured on a host. Namely, add the corresponding /48 prefix to the active precedence table. At the right place in the code, it should only be a 
few instructions.
>>
>> And of course, delete it when the last ULA under that /48 goes away.
>>
>> Any Linux core programmers here?
>>
>> Regards
>>
>>       Brian Carpenter
>>
>> On 08-May-22 15:21, Brian E Carpenter wrote:
>>
>>   > Hi,
>>
>>   >
>>
>>   > So, how hard is it to automagically set ULA precedence for a given 
/48, as suggested in section 10.6 of RFC 6724?
>>
>>   >
>>
>>   > Quite easy for Windows, as it turns out, and quite hard for Linux.
>>
>>   >
>>
>>   > In fact, if I wasn't being polite, I'd say that the Linux
>>
>>   > implementation is a mess. For more details, see Karl Auer's blog post from ten years ago, which explains it as best it can be explained: http://biplane.com.au/blog/?p=122 <http://biplane.com.au/blog/?p=122> . 
As far as I can tell, my quite recent Linux (5.4.0-109-generic x86_64) is 
still like that and mainly stuck in RFC-3484-land.
>>
>>   >
>>
>>   > So I wrote a little Python program which (a) detects if the host
>> it's running in has any ULAs, (b) extracts the corresponding /48
>> prefix(es),
> and (c) sets the corresponding label and precedence for such prefix(es) 
according to section 10.6 of RFC 6724.
>>
>>   >
>>
>>   > On Linux, the program also forces all the RFC 6724 defaults. It
>> does
> that by overwriting /etc/gai.conf, which is more drastic than Karl's script in his blog post.
>>
>>   >
>>
>>   > Sadly, both Windows and Linux need this treatment after every reboot. Someone with deeper knowledge of the operating systems might be able to get round this. And the program doesn't know what to do for other POSIX compliant systems. But it's open source, so contributions are welcome.
>>
>>   >
>>
>>   > As the program itself says "This is experimental software that
>> might
> disturb network access." So far, it hasn't disturbed either my Windows or my Linux laptop. However, if you want to try it, it's at your own risk 
and I strongly recommend using a spare machine.
>>
>>   >
>>
>>   > enable-ula.py is at https://github.com/becarpenter/misc
>> <https://github.com/becarpenter/misc>
>>
>>   >
>>
>>   > Regards
>>
>>   >       Brian
>>
>>   >
>>
>> _______________________________________________
>>
>> v6ops mailing list
>>
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>>
>> https://www.ietf.org/mailman/listinfo/v6ops
>> <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>> _______________________________________________
>>
>> v6ops mailing list
>>
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>>
>> https://www.ietf.org/mailman/listinfo/v6ops
>> <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>