Re: [v6ops] enable-ula.py

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 11 May 2022 10:48 UTC

Return-Path: <vasilenko.eduard@huawei.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 CCEAAC157B58 for <v6ops@ietfa.amsl.com>; Wed, 11 May 2022 03:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2xySzirDwlHm for <v6ops@ietfa.amsl.com>; Wed, 11 May 2022 03:48:14 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F77C157B49 for <v6ops@ietf.org>; Wed, 11 May 2022 03:48:12 -0700 (PDT)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Kys2K1sq5z6H7KW; Wed, 11 May 2022 18:43:21 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Wed, 11 May 2022 12:48:06 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 11 May 2022 13:48:06 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Wed, 11 May 2022 13:48:06 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] enable-ula.py
Thread-Index: AQHYYor2ksF1Lf3GKEaTiZZJuKVSvq0YgZYAgADqviCAABInAA==
Date: Wed, 11 May 2022 10:48:06 +0000
Message-ID: <f978a0bd5771429381258e81541add98@huawei.com>
References: <c52c20ee-772c-3c4c-b87f-e76de7d157a9@gmail.com> <cbe52294-48c7-07f3-9d08-c0a68f56f637@gmail.com> <fd0b026e289b4e11a6636d1942c34315@huawei.com>
In-Reply-To: <fd0b026e289b4e11a6636d1942c34315@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.199.245]
Content-Type: multipart/related; boundary="_004_f978a0bd5771429381258e81541add98huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Iir0_K-lB2g8EPoyvdI6WVSQKow>
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: Wed, 11 May 2022 10:48:18 -0000

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.



[cid:image003.jpg@01D8653D.BC8A4BA0]



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] 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 . 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

>

> Regards

>       Brian

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org<mailto:v6ops@ietf.org>

https://www.ietf.org/mailman/listinfo/v6ops



_______________________________________________

v6ops mailing list

v6ops@ietf.org<mailto:v6ops@ietf.org>

https://www.ietf.org/mailman/listinfo/v6ops