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

Brian Candler <brian@nsrc.org> Sat, 13 April 2024 11:15 UTC

Return-Path: <brian@nsrc.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 064D9C14F605 for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 04:15:14 -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=nsrc.org header.b="AwHQRgcg"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="cRsL+Ro7"
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 YNg4S0oHa4Yi for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 04:15:09 -0700 (PDT)
Received: from fout4-smtp.messagingengine.com (fout4-smtp.messagingengine.com [103.168.172.147]) (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 578CFC14F603 for <v6ops@ietf.org>; Sat, 13 Apr 2024 04:15:09 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.nyi.internal (Postfix) with ESMTP id 02F4E138022A; Sat, 13 Apr 2024 07:15:08 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 13 Apr 2024 07:15:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nsrc.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1713006907; x=1713093307; bh=zOO8QfOUOHFyAj8oKY9NOMUSZL0CLsIP9PbpN9Z6Bto=; b= AwHQRgcg2JKJEneP1QeW2vJA9Tlc12ntIw+6Z5JIV3HeSEx2UO1letilg9i8O+sI qUC7n9t4NMRTQZFx477LoPlqd0oKOAZIpbSF1NdbCakUXtyfLbaw6EXDUNgBzklj 07JyJNMB+UlSqjmedM2c1sP3lexNsYQxWh74pWWTbmtTm0GH+Fd5prh7aPKBrI0W WiZDWoDbHUDgqDMf/rN+DxofTEj0T9ykAgbbKdFHuomAKaCOoiEZSQxsJh19UzOR q9Tdh4zXvpu/50XVVAtnH6azBO2L1ikI3O3JVmTis619CtO+SR/cxfuYWV8ffYOH in3xSf+2K8WUwop2K2AM6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1713006907; x= 1713093307; bh=zOO8QfOUOHFyAj8oKY9NOMUSZL0CLsIP9PbpN9Z6Bto=; b=c RsL+Ro7huMYtxmGsAv2HtELq1Qaa8FcCyt4l975RyiXziDURC7cwlxfppkh0GUFs Q2j+REpOK+JfKop0FdJj0zU2eKlGzdHnerj25jV/glH3RolVdCYq9IzBOAnpXGXA fMbSacLy0nT6pS3Q33WXlZ79lmyLqrw2w60uM6JCXguZI9AjtG873t+OkL2VdmpY goJocj+2tDS6aRYyZBqIhUslY7qjVqi4FalYqjRwa7MIGgNTp68/vFUDYV16+Us8 6s/Tq9KwYS+KkcEQNPSBFiujzTOa8M53FLcknix8h3tKskvE/hxLE6cNPUkTaRk7 5OhJa/yOMh3UX492QmeUQ==
X-ME-Sender: <xms:O2kaZjOoE7g5IHGc0jHeWCh9yRb1N-j_a52kk4fQJd_SxDs3YIBweQ> <xme:O2kaZt-LdpqPXM60ZdzaBz5mA7ji-WmpmNu1MQZn59JS0xEBcFkqs3cZuwSc5vM1V kkljUKrtpnLp3Xts9I>
X-ME-Received: <xmr:O2kaZiRAGJF99BJWD8boTkfetTZWtL63FM3JFogVO0BR_93t_FICbglJvgk-e4M>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudeiiedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttddvjeenucfhrhhomhepuehrihgr nhcuvegrnhgulhgvrhcuoegsrhhirghnsehnshhrtgdrohhrgheqnecuggftrfgrthhtvg hrnhepffeviefhleehvedugfekveegvdeikeeugfetvdeuveelgfeljeehveehffeuheef necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrih grnhesnhhsrhgtrdhorhhg
X-ME-Proxy: <xmx:O2kaZnsTBy-6muL3vliUV6Z2938NgPBbkQNEDRd7N_2Gddm99VFPXQ> <xmx:O2kaZreRKz0INoLGDsvCntAtiSOiR9WHQuejXWzYo5d2gRjXJc4fdA> <xmx:O2kaZj0REriGrPeLDRpgVIn__zj5TeGLrJmxOFbEtFOoKJgYKMxs7A> <xmx:O2kaZn-2B9gVjIcIW5cCdfMrhfOXNKRoPs0GCSoEIpjUMmMD3z-QLA> <xmx:O2kaZi72ozljcEWUXAFqQrr1tBqDiMmKv9wxFKCNYaz3iGzGnxKISoYH>
Feedback-ID: i8f09498f:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 13 Apr 2024 07:15:07 -0400 (EDT)
Message-ID: <547145b0-21c0-457a-af58-2eeb8f44422d@nsrc.org>
Date: Sat, 13 Apr 2024 12:15:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: Tore Anderson <tore@fud.no>, "Soni \"They/Them\" L." <fakedme+ipv6@gmail.com>, IPv6 Operations <v6ops@ietf.org>
References: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com> <3c1e1f55-555f-42f2-b472-5f3a3a0c40a6@fud.no>
From: Brian Candler <brian@nsrc.org>
In-Reply-To: <3c1e1f55-555f-42f2-b472-5f3a3a0c40a6@fud.no>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/0Wlv1IYILXeddxBUMSHUSIIF5Sk>
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 11:15:14 -0000

On 13/04/2024 09:57, Tore Anderson wrote:
> 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. 

I just want to reiterate that point.

When composing my original reply, I starting thinking that a libc CLAT 
implementation in an unprivileged process would have difficulty getting 
an additional IPv6 address assigned - until I realised this was 
completely unnecessary.  You can, and should, just let the kernel do its 
default source address selection.

Imagine that you had a dozen processes all with their own userland CLAT: 
you wouldn't want, or need, a dozen additional IPv6 addresses created. 
But neither is there any point in creating a single additional IPv6 
address for all the CLATs to share.