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

Ole Trøan <otroan@employees.org> Sat, 13 April 2024 09:08 UTC

Return-Path: <otroan@employees.org>
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 5E4DCC14F5F6 for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 02:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
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 rVyRGZrcOKvB for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 02:08:02 -0700 (PDT)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [IPv6:2607:7c80:54:6::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 50900C14F6B6 for <v6ops@ietf.org>; Sat, 13 Apr 2024 02:08:02 -0700 (PDT)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 075ADE1CB8; Sat, 13 Apr 2024 09:08:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=MGIX8e9R5FkJ4vsJ 1iO6eJ644sQoejjjN56fl5hWsfE=; b=EiElVxZR73iELwar694fWCY4nx3zb629 c46hUF5Kw+YxkmJvVgNKeU7mVS2D26z90/82QP0IeCSI3pIzbj8PmdXGIqW/H9I3 Msw6vlibSOImYgfs4v9dDJviX/KMYpf2suQlaaAOaKOKZYItTq52EZ9ZTdtGPs4k Mk+TQO7gSV2brQYefw1d49b3fEcVPTmKKgvD1vPddp1zOr1vFV8fVeo/eZFDN6JK 3TaIq10wkRan33EFoREtrS4SPANQDljpCVro2Sjjy+Kwf7P45VpIOToIoc0PSKz0 TczrzGaVg1Ih54lequ8rbqaHczxjiIop4fBBVeVQgTMdkSX1HesVQw==
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id CDBA0E1C97; Sat, 13 Apr 2024 09:08:01 +0000 (UTC)
Received: from smtpclient.apple (unknown [IPv6:2a02:2121:2ce:20ef:5dca:f5fd:112a:b994]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 5911C4E11A3E; Sat, 13 Apr 2024 09:08:01 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ole Trøan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Sat, 13 Apr 2024 11:07:48 +0200
Message-Id: <EFE36D93-52E3-4908-96C2-CF41978DA401@employees.org>
References: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com>
Cc: IPv6 Operations <v6ops@ietf.org>
In-Reply-To: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com>
To: "Soni They/Them L." <fakedme+ipv6@gmail.com>
X-Mailer: iPhone Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hzIdxx8XDRNwFI-eH3dx3w2v_ck>
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 09:08:06 -0000

Interesting work!
Second Tore’s comments. 

You may also find the bump in {API, stack, host} documents interesting. RFC2767, RFC3338, RFC6535…

Cheers 
Ole

> On 12 Apr 2024, at 16:05, Soni "They/Them" L. <fakedme+ipv6@gmail.com> wrote:
> 
> Hello!
> 
> We've recently set up our home network as IPv6-only with NAT64, as such we no longer have DHCPv4 or any other IPv4 address assignment to end nodes. It has been... uneventful really; aside from needing to reboot our phone every time we get home, things just work, as expected.
> 
> We set this up so we could work on "Stackless IPv4". Traditionally, an OS will bring with it an IPv4 stack and an IPv6 stack, and (for our purposes) some IPv4-IPv6 translation mechanism (NAT64/NAT46/SIIT) that takes packets from one stack and dumps them on the other stack, and from there the stack handles things such as routing and packet filtering and connection tracking and whatnot. We would like to try an alternative approach where we just don't have an IPv4 stack, and thus don't need to do any of the aforementioned operations (routing, packet filtering, connection tracking) in the IPv4 world.
> 
> Nevertheless a lot of apps only work on IPv4, with IPv4 APIs. Now that we have an IPv6-only network, our first project is what we call "CLAT in libc", where the CLAT functions are implemented entirely in libc, without kernel IPv4 support, in order to satisfy these apps. We didn't strictly need the IPv6-only network before trying to build this, the network just makes it significantly easier to test it. 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. And again, this can be accomplished without any of the features of an IPv4 stack: namely, without routing, packet filtering, or connection tracking (in the IPv4 world).
> 
> If we get CLAT in libc working, then we'll move on to enabling the use of this OS on IPv4-only and dual-stack networks, but again without introducing an IPv4 stack. This can be done by taking IPv4 packets from the wire, without passing through any functionality associated with an IPv4 stack (routing, packet filtering, or connection tracking), and turning them into IPv6 packets, which then go on to get processed by the IPv6 stack. The combination of CLAT in libc and this non-traditional SIIT would allow the OS to be deployed on existing IPv4-only and dual-stack networks, fully implemented without an IPv4 stack. Wouldn't it be exciting, as a sysadmin, to be able to use all-IPv6 tools for both IPv4 and IPv6?
> 
> Well, that's the plan anyway. Let's see how much we can actually get done.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>