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

"Soni \"They/Them\" L." <fakedme+ipv6@gmail.com> Fri, 12 April 2024 14:04 UTC

Return-Path: <fakedme+ipv6@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 ACA85C14F68F for <v6ops@ietfa.amsl.com>; Fri, 12 Apr 2024 07:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ne7IK_8Q1Hr5 for <v6ops@ietfa.amsl.com>; Fri, 12 Apr 2024 07:04:51 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 60BA4C14F5E8 for <v6ops@ietf.org>; Fri, 12 Apr 2024 07:04:51 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-516dc51bb72so989701e87.1 for <v6ops@ietf.org>; Fri, 12 Apr 2024 07:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712930689; x=1713535489; darn=ietf.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=bR29g3V4UkLtJDwhYxGeEZjPsNNvijMNfXEviCzqTdE=; b=MMmzZgSeWujJUpOLk8YG0QxUl1uyVDrr+w9iVMw540mXKtIDxtG2mqphQM4HTrnz9u OlYjQvLg+BCyT6LTZGR1hJ26O6P58vpEdYqLRJhKKuvbX5Q2tCJLAPQiq5G60A6VDe7T 8Etz7p3cjoQiqvGasUqwtpjKLGBVKowEA3gQHugsL2TLz2COZBToWPoSCryYKOIsVowK Ei79rtVcmjiY7rh1aU7p5SGU79Aa2DmzRWWKXI8sQmyBCWxl/VeRspcMbOAZx+QWFtL+ XF1GJtXcGWxx2OEVc+Rg+pXFFCth1jlotRd6y0cg25q/8ETHuxb4SWIFNxQgTIdlsmCe UQpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712930689; x=1713535489; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bR29g3V4UkLtJDwhYxGeEZjPsNNvijMNfXEviCzqTdE=; b=uWIgXumX/QAEdJiyxpwYL7DCJEsFKv5mkBXXuZn+NyzXIv41QKzs2DZ1ER3SVyKKeq F+BbCnic4E7q/j0pCGyAksRRCGnuIdCb5zsT66CIyURwNu9Eh9lMFJ3KO/oD92UfQzpp OrEmxPUoddHRGvBzbTOqHrR5UIsUChwXZ3fzY5qEyrP1D7TStZr/iUoGI6U+JromwgPs 8kM9fZ3ChwmmgMQ77PN2aXJX4ltXnTxP+ISkQRXkHo0ePGqC5C7nGGuzQW/jC8+tAFP3 ObLuLI1sUQnArTFfMJK1Wo9eVk4lPWY+weZcIF7OtwFvrx6HAtpn7sQ+Rv42m4hKhKsK j6kw==
X-Gm-Message-State: AOJu0Yx/DevTN4+yJJCmbJNTB1EVuM/gp2MsEnCmlDcwLfQRijuljbh/ 9xdlAXBgA+1EFxq879k2+92GQcEoQ6VyCdPXVqMN6JWSnS1RZiltCXc6fA==
X-Google-Smtp-Source: AGHT+IESp/HBbFb39Obx49f03rnRpwW705xoNcQED7ZCGC8hoEDwNVAQaCzWesYs3bk8MBVp28uxlA==
X-Received: by 2002:a05:6512:3ca0:b0:516:c764:b3e7 with SMTP id h32-20020a0565123ca000b00516c764b3e7mr2514765lfv.9.1712930689216; Fri, 12 Apr 2024 07:04:49 -0700 (PDT)
Received: from ?IPV6:2804:431:cfcd:6eab::536f:6e69? ([2804:431:cfcd:6eab::536f:6e69]) by smtp.googlemail.com with ESMTPSA id d33-20020a0565123d2100b005188f6f9477sm122004lfv.297.2024.04.12.07.04.47 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Apr 2024 07:04:48 -0700 (PDT)
Sender: "Soni L." <fakedme@gmail.com>
Message-ID: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com>
Date: Fri, 12 Apr 2024 11:04:43 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: IPv6 Operations <v6ops@ietf.org>
From: "Soni \"They/Them\" L." <fakedme+ipv6@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Hut6vdjj1cpFky5mK3C1Wr8nfh4>
Subject: [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: Fri, 12 Apr 2024 14:04:55 -0000

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.