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
- [v6ops] Our IPv6-only home network and future exp… Soni "They/Them" L.
- Re: [v6ops] Our IPv6-only home network and future… Brian Candler
- Re: [v6ops] Our IPv6-only home network and future… Soni "They/Them" L.
- Re: [v6ops] Our IPv6-only home network and future… Brian Candler
- Re: [v6ops] Our IPv6-only home network and future… Tore Anderson
- Re: [v6ops] Our IPv6-only home network and future… Tore Anderson
- Re: [v6ops] Our IPv6-only home network and future… Brian Candler
- Re: [v6ops] Our IPv6-only home network and future… Soni "They/Them" L.
- Re: [v6ops] Our IPv6-only home network and future… Brian Candler
- Re: [v6ops] Our IPv6-only home network and future… Ole Trøan
- Re: [v6ops] Our IPv6-only home network and future… Vasilenko Eduard
- Re: [v6ops] Our IPv6-only home network and future… Gert Doering
- Re: [v6ops] Our IPv6-only home network and future… Vasilenko Eduard
- Re: [v6ops] Our IPv6-only home network and future… Gert Doering
- Re: [v6ops] Our IPv6-only home network and future… Vasilenko Eduard
- Re: [v6ops] Our IPv6-only home network and future… Vasilenko Eduard
- Re: [v6ops] Our IPv6-only home network and future… Brian Candler
- Re: [v6ops] Our IPv6-only home network and future… Vasilenko Eduard
- Re: [v6ops] Our IPv6-only home network and future… Brian Candler
- Re: [v6ops] Our IPv6-only home network and future… Gert Doering
- Re: [v6ops] Our IPv6-only home network and future… Brian Candler
- Re: [v6ops] Our IPv6-only home network and future… Vasilenko Eduard
- Re: [v6ops] Our IPv6-only home network and future… Gert Doering