Re: [v6ops] Our IPv6-only home network and future experiments

Tore Anderson <tore@fud.no> Sat, 13 April 2024 08:57 UTC

Return-Path: <tore@fud.no>
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 EBE21C14F69D for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 01:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ih4ULDW1HxzV for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 01:57:52 -0700 (PDT)
Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:2f0:de01:f816:3eff:fede:dc6a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73500C14F68A for <v6ops@ietf.org>; Sat, 13 Apr 2024 01:57:51 -0700 (PDT)
Received: from vpn.i.bitbit.net ([2a02:c0:2:6:18:59ff:fe38:da0d]:48556 helo=[IPV6:2a02:c0:2:7::2]) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <tore@fud.no>) id 1rvZCl-0001cf-Lz; Sat, 13 Apr 2024 10:57:47 +0200
Message-ID: <3c1e1f55-555f-42f2-b472-5f3a3a0c40a6@fud.no>
Date: Sat, 13 Apr 2024 10:57:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: "Soni \"They/Them\" L." <fakedme+ipv6@gmail.com>, IPv6 Operations <v6ops@ietf.org>
References: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com>
Content-Language: en-GB, nn-NO
From: Tore Anderson <tore@fud.no>
In-Reply-To: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/033Ex_MXrTguT8Fy_IKxI5qgNS4>
Subject: Re: [v6ops] Our IPv6-only home network and future experiments
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 13 Apr 2024 08:57:58 -0000

Hi Soni!

Very interesting, thanks for sharing your plans! I have one comment:

> Additionally, we note that this approach easily allows us to work a 
> CLAT into a DHCPv6 deployment with a single /128, but we don't really 
> want to encourage bad practices so we have no plans to actually 
> support that.

It seems strange to me artificially block this use case, if it is indeed 
easy for you to support it. Assuming you plan on open-sourcing and 
upstreaming your work I expect that it would not take long before 
someone sent a patch to remove the block. Users/distributors would in 
anycase be able to get around the block by using a random ULA address as 
the CLAT's IPv6 address and running it through Netfilter's stateful 
NAPT66 function (this is also possible with other CLAT implementations 
such as Jool and TAYGA).

Having IPv6 nodes with a single global IPv6 address is not «bad 
practice», it is very common, even in networks using SLAAC.

As for the CLAT as described in RFC6877, it was simply easier to 
implement in a bolt-on fashion by requiring a dedicated IPv6 address, 
since that meant the implementer did not have to care about things like 
sockets, TCP/UDP ports and such. Your proposed implementation goes 
directly into those areas though, so it does appear to me that you could 
do better than the original. I would therefore suggest you reconsider 
this decision.

Tore