Re: [v6ops] enable-ula.py

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 10 May 2022 22:23 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 B7E79C14F74F for <v6ops@ietfa.amsl.com>; Tue, 10 May 2022 15:23:04 -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 KBhmCdpMU7ja for <v6ops@ietfa.amsl.com>; Tue, 10 May 2022 15:23:00 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 6FAD7C14F736 for <v6ops@ietf.org>; Tue, 10 May 2022 15:22:55 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id d22so88559plr.9 for <v6ops@ietf.org>; Tue, 10 May 2022 15:22:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=s7Ths454bUs/DVeB56KTuJUWh20uswBJt+QDYJzEjJg=; b=I6HDsRfxT/ZY8kiC+RmPFd0zvHwgRaCbBzvwg2BfeE5ew3+eBAhbQ7YekOQFLp+kdb m4sMGwB0/OGBXgh6CWsRmuYmG7SWn9pASZNBzEiK913IUEFpresSFsHWqfxbzM2eo0zv SBqwOf8Ksd+YDKhlFf2xqYVo05q9+l4rkTtUFuDiOCDfNzOPsbt+/j5oq+dAu0ksF0+0 KqW6z26/potJEeum3lbfBvVOUjZKbIcIOL20M8S7ncBA46AffWckD5wbY0BuG1cB56+E x4y78dCVCJwJqMyMOy4Wt5nG8khS/zGf4n17LWgiVQHoW3LsMQVPgYocbK4Ua5MHOBB+ znaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s7Ths454bUs/DVeB56KTuJUWh20uswBJt+QDYJzEjJg=; b=UO+JPmNhuNz+TrIrXxh4BOfum7bGqld5VSDi6UTRx2hqlgi8+9Q5Dv59Pt7iaxxFGJ RKhasfJtPcLCLBhU57QdryaiH/QyNl1zpvVC7RvoLXc4oL4Nucuiqe0fbV0K0dgXS3Yj 1hWNfJoSZC4QlVl7UKG4fjKz+HcQQqBljt99Z9lU93Hlu/7LA9ezBc00dHSwdSDEDDXv tFesqxZ7ZmKgLbAYF8SSjNaGUN8k5xOjYkLPOD3sLvc6nnaPA5lPV/f/p94HnyagH9yY 2Fbq7uvjTo18J2TjDTKkBHTL9qGG1pXZzrQKjpWbP6gxyRG4H0K2zYVaTUkavp0TOIZ1 cwgA==
X-Gm-Message-State: AOAM532aIVoWew7fvkWcGPeMH9W8Q2J+ZaOdQs2zsWzkaYSpHp7K1Y2p fpHwSdLXTTy02I60LRac2s2qm5ZI6rkRGw==
X-Google-Smtp-Source: ABdhPJxuXIcJQcR7zE6WkDmDrv5m8N8QOqGHvMLCxi62oQCGkoXkyXqoeC4BHXbj+5XT4jx+VrDQiA==
X-Received: by 2002:a17:90b:388b:b0:1dc:515e:1b0c with SMTP id mu11-20020a17090b388b00b001dc515e1b0cmr2015762pjb.224.1652221374396; Tue, 10 May 2022 15:22:54 -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 y22-20020a170902d65600b0015e8d4eb27dsm118739plh.199.2022.05.10.15.22.52 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 May 2022 15:22:53 -0700 (PDT)
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: v6ops@ietf.org
References: <c52c20ee-772c-3c4c-b87f-e76de7d157a9@gmail.com>
Message-ID: <cbe52294-48c7-07f3-9d08-c0a68f56f637@gmail.com>
Date: Wed, 11 May 2022 10:22:50 +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: <c52c20ee-772c-3c4c-b87f-e76de7d157a9@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/v2rhVuRDZ9iRIWSRbQYaIESkRqg>
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: Tue, 10 May 2022 22:23:04 -0000

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
>