IETF Logo Mail Archive

Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Dan Wing <danwing@gmail.com> Mon, 07 February 2022 00:58 UTC

Return-Path: <danwing@gmail.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D66D3A10CB for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 16:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwr3vwyoBeqo for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 16:58:22 -0800 (PST)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4023A10A0 for <behave@ietf.org>; Sun, 6 Feb 2022 16:58:22 -0800 (PST)
Received: by mail-pj1-x1032.google.com with SMTP id v5-20020a17090a4ec500b001b8b702df57so1431858pjl.2 for <behave@ietf.org>; Sun, 06 Feb 2022 16:58:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a56LuTLxOrJ4Un+QCI2k3qD7n48Xj4UP2FXO0zP+THk=; b=bhIeZTRMv++yLSdfsrhYXt7lEcHmAdRMj5rdv7+5Ym+nJGXh8QpFe0NRXcq9GwamHR Mbi++hTFaewnKPuqffGF3BUZF5i6gQZqWVcQjgbNNRFa/hI5i/gMSpU3yyOGuSwluJuU OotX77G9nN2jDehZK0PgliJFGWlqKMdYvOYYrr8ThF9jk+Zm7ctVRETE7VPXeU/6t7ue 7h+uXXHqDF+HXbKuk2qkkFZm99EbjUd1HAaqfYK2rIZxFTLtApuQ66++RBy5djGysNjZ /yZDBV7YKR0cB3PHkm1ZOoMpmlhTC2IpGLpamgGQvOf+Gm20brif+sOrs+cvm1wJ4AHx SP9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a56LuTLxOrJ4Un+QCI2k3qD7n48Xj4UP2FXO0zP+THk=; b=wdyRe/XMzqpzMi0GiWkZWHM+YKE0yBHINrVtiW0apdNvlXt7mJekA7WX6RlQ7rGqhS vXHrUbzJQueXFlNsbqAZMoABOL4klZoonWPSZhldzcUkHfPtFeyamHvl3JqmHyT+ddNz zbtNPtU4fSBFVs/LVSdHUO13bT7l9B52krQ798AH3sVtoa/NmxQ112FPHY1roRrd9klq 0jaY6jiq3T1Qwb4fK5m4V6VDD37/YVNzfBUFtmRTLa8IrRcarzyjQ8NhOPhy+Vf43GqC EGMd3DYrCYI0pDuTOCOPfEEH1WzQNPjuho9feGihIwfJvVajf/ToNWG0FTGVg3k88Lo2 4jOw==
X-Gm-Message-State: AOAM532dT5KEBCig0XLCYzqEdtbtn6Wa5GS4wNaqJ1wy59YQ+oRLFy64 sMZe8l+99V+PuwJAxDRYv5XultMh2J0=
X-Google-Smtp-Source: ABdhPJxi2k/vBhTdD708P6QLKDMWWvgFIja5fcgaVHDPmI9gqHuzrWLqPc9EhMUrTiPDAI5zwaOzRA==
X-Received: by 2002:a17:902:6b8c:: with SMTP id p12mr4104922plk.51.1644195500831; Sun, 06 Feb 2022 16:58:20 -0800 (PST)
Received: from smtpclient.apple (47-208-218-46.trckcmtc01.res.dyn.suddenlink.net. [47.208.218.46]) by smtp.gmail.com with ESMTPSA id h10sm9843808pfc.103.2022.02.06.16.58.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Feb 2022 16:58:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Dan Wing <danwing@gmail.com>
In-Reply-To: <ee760818-a3c4-3755-6bdf-afcec6fcaaad@posteo.de>
Date: Sun, 06 Feb 2022 16:58:18 -0800
Cc: behave@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7DFC369-E7B7-4171-9C85-F75986B5AEF6@gmail.com>
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <ff858dee-a21a-a50d-72a5-da7915ac2de4@network-heretics.com> <71b5cdb0-78af-0f77-debc-84e178fe5e3a@posteo.de> <7a008cc2-e8a3-f91d-c782-96866c36a9db@network-heretics.com> <ee760818-a3c4-3755-6bdf-afcec6fcaaad@posteo.de>
To: Klaus Frank <klaus.frank@posteo.de>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/fekQKxZg0KO9w7thqpSzl_VduHc>
Subject: Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 00:58:28 -0000

The philosophy in RFC3338 became 464XLAT, https://datatracker.ietf.org/doc/html/rfc6877

As for the DNS64 issue, could the application become NAT64-aware and do the SPF rewriting itself?  See https://datatracker.ietf.org/doc/html/rfc7050 which discusses how that can work on the local application.


A problem with rewriting SPF records within DNS64 is that other IPv4 addresses may well appear in TXT records, throwing a loop to applications which won't know if the DNS64 has done rewriting or if the application needs to do rewriting.  A long-standing problem with NAT "support" for applications since the days of FTP PASV.

I will also +1 Keith's comment that SPF is a borked standard, even if the world had no NATs.  DKIM and DMARC are superior.

-d


> On Feb 6, 2022, at 4:47 PM, Klaus Frank <klaus.frank@posteo.de> wrote:
> 
> This is neither helpful nor constructive.
> 
> But if you really want to talk about spilled milk, why don't we talk about RFC3338 then? If that one is a bit polished it could completely eliminate the need for NAT64. But it was dropped in the process and never got past Experimental. I'd have some ideas on how to make it fly, but I don't see value in following up an RFC that was dropped 20 years ago and diverge from a bad but industry favored solution (NAT64) that compared to RFC3338 has seen adoption and is also already used in the wild...
> 
> On 2022-02-07 01:41, Keith Moore wrote:
>> On 2/6/22 19:38, Klaus Frank wrote:
>> 
>>> I can understand you. I also don't like NAT. And I would also have favored different migration paths from IPv4 to IPv6. But NAT64+DNS64 is the one we got. I'm sure there have been discussions earlier. I didn't want to resume or repeat those discussions. I'm certain there are valid reasons for why we have the current migration paths and that the pros and cons of different strategies have been covered adequately.
>>> 
>>> Nonetheless DNS64 is incomplete without also addressing the SPF record.
>>> 
>> Disagree.  DNS64 is inherently incomplete and cannot be fixed.  I will strongly object to any effort to further pollute DNS in the name of making NAT appear to work.
>> 
>> Keith
>> 
>> 
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

v2.23.0 | Report a Bug | By Email