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

Tore Anderson <tore@fud.no> Sat, 13 April 2024 09:56 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 7AD29C14F6B6 for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 02:56:43 -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 k4PzcfLthpXN for <v6ops@ietfa.amsl.com>; Sat, 13 Apr 2024 02:56:39 -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 2C4B7C14F5F1 for <v6ops@ietf.org>; Sat, 13 Apr 2024 02:56:38 -0700 (PDT)
Received: from vpn.i.bitbit.net ([2a02:c0:2:6:18:59ff:fe38:da0d]:40152 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 1rva7e-0001qa-WE; Sat, 13 Apr 2024 11:56:35 +0200
Message-ID: <92417d17-0207-430c-a231-4cb303447496@fud.no>
Date: Sat, 13 Apr 2024 11:56:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Brian Candler <brian@nsrc.org>, "Soni \"They/Them\" L." <fakedme+ipv6@gmail.com>, IPv6 Operations <v6ops@ietf.org>
References: <91ee2782-c98a-4ccf-ae8f-71be571420b6@gmail.com> <0ea1d4ca-d00f-4b08-b5d6-16fe18415702@nsrc.org>
Content-Language: en-GB, nn-NO
From: Tore Anderson <tore@fud.no>
In-Reply-To: <0ea1d4ca-d00f-4b08-b5d6-16fe18415702@nsrc.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vAmVNkhkQCW9AC4qoJ7bw3Y-MZg>
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:56:43 -0000

* Brian Candler
> Having said that, accepting incoming traffic for an application that 
> opens an IPv4-only socket is probably not a big concern.

Actually, it would be very nice if this CLAT implementation could 
support inbound connections to listening sockets opened by IPv4-only 
applications as well.

That would essentially implement the node-based edge relay for SIIT-DC 
described in RFC 7756 section 3.1. This feature, in combination with a 
SIIT-DC border relay as described in RFC 7755, facilitates building 
IPv6-only data centres or public cloud environments that retain 
compatibility with IPv4-only legacy application software.

Tore