IETF Logo Mail Archive

Re: [spfbis] RFC6147 and RFC7208 interoperability issues

John Levine <johnl@taugh.com> Sun, 06 February 2022 22:16 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECFA3A0E38 for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 14:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level:
X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=LRjxE2b3; dkim=pass (2048-bit key) header.d=taugh.com header.b=nbMP/WQZ
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 Kke4T0WTm65L for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 14:16:24 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 B8E743A0E37 for <spfbis@ietf.org>; Sun, 6 Feb 2022 14:16:23 -0800 (PST)
Received: (qmail 64693 invoked from network); 6 Feb 2022 22:16:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=fcb3.620048b4.k2202; bh=Sr/7PNRI+cEBFcQo7vGvI8ogjMQ8hs2lPX8FMwc5b/o=; b=LRjxE2b35o4qzaY4/RubbXZ6i2k9MhTMwggFNEmNMHfz3Ulk0964+WMcrG/4FgZ+nyell0aw9jEaL/5tJk+M9nMXPAX2Rn8mqxwsM57uKaEWuECYTKBXcwt6kdXJkUpYqQtCfaLSTnH+OlRuyA4lQNgxdP42/BqsqlAmGb+3fqFFkTpsPrbpzvVeetou9s7nkE0a2s15VICv5CyVeZxDWyLIfjtX4WW1SYuXsH9SODwnbFU1ru+lZiekSZHYTbo1JqatY53Hi54jpBs4/HEIG+RL6g3XAGGJU0skxjVXwzcwxzdjIpsoCubaTgj8ZSPEKDxlN8jidBwLF8U4hYiwNA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=fcb3.620048b4.k2202; bh=Sr/7PNRI+cEBFcQo7vGvI8ogjMQ8hs2lPX8FMwc5b/o=; b=nbMP/WQZKn0FPFEsWyVgnDv4Ep3/3e5dCbaAnxNW54B9oEA8FNJkPICXqhH0bj13aFRLUClnQhXtQR04VXXvdVXZZD8RC80bfKmfwL8g0ga8Q4AjPM6P1lQNsqX6QMc27ku4709zl8wYLYs6+xw3gMecVtLp0jQLMdhHcqJZHT8Danhf8JJsWru37ApOW9kmC53n52J8UC1ZbusLTKs+jjlewImMYhnquKRdnAQxG60Sowabh/i0wxI2ZT7ikirEVoLzZkc/jUD4bySHmpMPFvaFngegd2kcLb+0PxluUeBv2JMiX7dEXdxKok72X0dSVHW0TnR0v0MbVOIUfxQuhg==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Feb 2022 22:16:20 -0000
Received: by ary.qy (Postfix, from userid 501) id 53E4836687AF; Sun, 6 Feb 2022 17:16:18 -0500 (EST)
Date: Sun, 06 Feb 2022 17:16:18 -0500
Message-Id: <20220206221619.53E4836687AF@ary.qy>
From: John Levine <johnl@taugh.com>
To: spfbis@ietf.org
Cc: spf2@kitterman.com
In-Reply-To: <45673006.FIhfuaby8d@localhost>
Organization: Taughannock Networks
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/zjZPv8IjqW2wwIq1CiwOJKbtcpg>
Subject: Re: [spfbis] RFC6147 and RFC7208 interoperability issues
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Feb 2022 22:16:30 -0000

It appears that Scott Kitterman  <spf2@kitterman.com> said:
>It looks like situations like this one were contemplated by the RFC 6147 
>authors:
>
>> 6.  Deployment Notes
>> 
>>    While DNS64 is intended to be part of a strategy for aiding IPv6
>>    deployment in an internetworking environment with some IPv4-only and
>>    IPv6-only networks, it is important to realize that it is
>>    incompatible with some things that may be deployed in an IPv4-only or
>>    dual-stack context.
>
>On the SPF side of the discussion, I think it would, at least in theory, be 
>feasible to interpret an ip4: mechanism as <prefix> + <address> if the 
>connection is IPv6, but I don't see how a receiving SPF processor could know 
>what the prefix is.  As I read RFC 6147 Section 5.2, it could be anything.

See RFCs 7050 and 8880 for how you find the prefix(es).

That seems like a more reasonable way to go, patch the SPF library so it
can use the NAT's Pref64 to fudge the interpretation of ip4 and ptr.

It looks like you could automate the entire thing -- when the library starts
up, do an AAAA query on ipv4only.arpa, and if you get plausible answers,
you know you're behind NAT64 and reinterpret ip4 and ptr terms appropriately.

R's,
John

v2.23.0 | Report a Bug | By Email