Re: [v6ops] IPREF as a transitioning tool

"Soni \"They/Them\" L." <fakedme+ipv6@gmail.com> Sun, 12 November 2023 11:23 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 25BEAC1705F4 for <v6ops@ietfa.amsl.com>; Sun, 12 Nov 2023 03:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 40AyGnpJmwlR for <v6ops@ietfa.amsl.com>; Sun, 12 Nov 2023 03:23:09 -0800 (PST)
Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) (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 B128DC1522DB for <v6ops@ietf.org>; Sun, 12 Nov 2023 03:23:09 -0800 (PST)
Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-1f084cb8b54so2218826fac.1 for <v6ops@ietf.org>; Sun, 12 Nov 2023 03:23:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699788188; x=1700392988; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=Tc6MwyDvttE9IeT6qH5bHbA0Fm0CKke7zhtK/iDejOY=; b=bWffhFvNeWmp8Rgoj8C37qfDhvF2YBKcL9mKcousvbIu392TH1MfhXEvdFGXuKErk6 cseVwNUeJzGzvSyPy9tKtizGXSKoWjMxla7c8A5viZJU2jVWFwAYMD0zGN/NpRpLRXy0 19/zQwkJn3+rQTqvySfLbO6R4m0fm8YlptnciNwK9ijWHSY+8NuVxHEz8vUTSGyFuYFQ zrJ+d5IJaHChe05V+7p4Q3HNVNAnTt2wGfib2fNYrya1aoQWJezd6P4YWj7d4Cca3x/u 7IW8cVdvBQOZZ2lSbu3+jcoZDhkqDiTxTPDaUI+iOuaOoX0Ufi4aZopcdznHUCFZ/svV LT6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699788188; x=1700392988; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Tc6MwyDvttE9IeT6qH5bHbA0Fm0CKke7zhtK/iDejOY=; b=xSh4w9JpAisqvh79pQxZ5KU9IDbzLd3ADtyfkrZW6CA+6KdtW7U/Jotfm9KRQwyAgW w+qoj4Kv9X3TzkWC88jV+lBaTmj1aAR2rr1lsbq3/CU6pcb8xrBsIrHprKsBE2gBnvDJ t2kj2vE09oucThvSQC2NhURrkIskULxFnVhwJx9w3hnRSEr2MwQBzagMcYJHZR7qlbtY i0a4t5xSRT/Qf3SXy/1mv2Yijc4d5VnHsJ0WSgs+tJTr6XZP6k+tahYRucOFtQTJWf0+ jJY2NWfVdVHPUpiHPssMPoH1WYOxZEll0RqASP5ho205yIjDJDlpyMVUoLRJFSz+LaYY 3lRg==
X-Gm-Message-State: AOJu0YwGQSyDEzPJ++EBpEN24gPThyT+3TwhyyAj0hlISy33doZDcZYn wd4ntGvYy+xCESZMXzyXqJc=
X-Google-Smtp-Source: AGHT+IHo3hmEdHWcVrrZeZTvDFfK60ecNR74VasjhxC+QIIlY5FtJPiigbZhxu+Gij0vzE22vm//og==
X-Received: by 2002:a05:6870:7d81:b0:1ea:fd94:965 with SMTP id oq1-20020a0568707d8100b001eafd940965mr5976150oab.24.1699788188190; Sun, 12 Nov 2023 03:23:08 -0800 (PST)
Received: from ?IPV6:2804:431:cfcd:5af6::536f:6e69? ([2804:431:cfcd:5af6::536f:6e69]) by smtp.googlemail.com with ESMTPSA id u3-20020a05687036c300b001eb7196de06sm635500oak.54.2023.11.12.03.23.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Nov 2023 03:23:07 -0800 (PST)
Sender: "Soni L." <fakedme@gmail.com>
Message-ID: <aa2dec60-0ec3-4b16-9931-ed3cc9bfb608@gmail.com>
Date: Sun, 12 Nov 2023 08:23:03 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Gert Doering <gert@space.net>
Cc: v6ops@ietf.org
References: <33892F6F-A2AF-4BAA-BB33-1ED99F9FD674@isc.org> <442536ba-f736-5106-615c-7fcc0b8dc2a1@wdmsys.com> <1964267.2dr1X8vxzf@asclepius.adm.tul.cz> <9f1eede1-ab65-0b52-4cda-58d305544b4c@wdmsys.com> <07bb6f08-188a-4ecb-8327-7db4221845c6@tul.cz> <e61d1472-03c4-c537-c81d-903264c976a4@wdmsys.com> <ZVCkrRYy9ggE_ypf@Space.Net> <bae285c5-9d8a-4f72-b278-fed92d6cab75@gmail.com> <ZVCqn0Sd7kDggAbP@Space.Net> <4db34850-54b1-4f3a-8403-615572216e46@gmail.com> <ZVC0l_Mivbyggxur@Space.Net>
From: "Soni \"They/Them\" L." <fakedme+ipv6@gmail.com>
In-Reply-To: <ZVC0l_Mivbyggxur@Space.Net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/q_kL4D9w62xUexYeGxYLueHo-OU>
Subject: Re: [v6ops] IPREF as a transitioning tool
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: Sun, 12 Nov 2023 11:23:10 -0000


On 2023-11-12 08:18, Gert Doering wrote:
> Hi,
>
> On Sun, Nov 12, 2023 at 08:07:12AM -0300, Soni "They/Them" L. wrote:
> > > For server setups, SIIT-DC seems to work well (and server applications
> > > are usually better controlled and can be taught to use v6 sockets).
> > > 
> > > What scenarios do you have in mind where a 464xlat on the server itself
> > > would be beneficial, as compared to a v6-only datacenter with SIIT-DC in
> > > front?
> > 
> > SIIT-DC appears to use the same packet translation building blocks as
> > 464XLAT/NAT64...? (From skimming, it looks like the same thing, just with
> > different names for the various components! And the addition of a "reverse"
> > mode of operation, where it accepts connections from v4 hosts.)
>
> Yes.  Basically, IPv6 only (as in a mobile network) but with IPv4->IPv6
> translation at the edge, so IPv4 clients can reach IPv6-only servers
> (= "publically visible services" appear dual-stacked, with v4 going
> through the translator)
>
> > So what makes 464XLAT (on *top* of SIIT-DC, as opposed to replacing it)
> > better is the ability to let the server know about it. As well as being able
> > to standardize on a protocol already supported by (some) operating systems
> > (systemd is slowly working on adding a CLAT, and FreeBSD allegedly already
> > has one).
>
> Not sure why this is a benefit for the server.  Assuming a v6-only world,
> and not having to care any bit about v4 or translation technologies sounds
> like a great benefit.
>
> So, asking again - why do you think it would be beneficial if the server
> had to care?
>
> (On a *Client*, which is where systemd seems to be evolving Linux to,
> local 464xlat brings obvious benefits to v4-only applications)

Because DNS64 is a crime (sometimes literally, but often at least breach 
of contract, because it breaks DNSSEC) and 464XLAT lets you avoid it. 
And on a server, you might wanna run NixOS, which depends on github and 
that's still IPv4-only.

>
> Gert Doering
>          -- NetMaster