IETF Logo Mail Archive

Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Klaus Frank <klaus.frank@posteo.de> Mon, 07 February 2022 00:47 UTC

Return-Path: <klaus.frank@posteo.de>
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 1C13F3A0834 for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 16:47:54 -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, RCVD_IN_DNSWL_BLOCKED=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=posteo.de
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 17tOiZXB2huQ for <behave@ietfa.amsl.com>; Sun, 6 Feb 2022 16:47:48 -0800 (PST)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 3E3093A1086 for <behave@ietf.org>; Sun, 6 Feb 2022 16:47:47 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9D144240026 for <behave@ietf.org>; Mon, 7 Feb 2022 01:47:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1644194865; bh=BWTOd/nNKfMkQxAMcUb/pDJ61YXWKEvGMSFLC/cvYgo=; h=Date:Subject:To:From:From; b=rwDPhdhZCiSkSeiNuEeaNxF7Tgrc4ha4RGx9/ep8vBFmTdDUP/RrFQEyusyFXQJi1 CuCzGGHbs6Uip0bjb04xusAWovxqh1h1EZILE5sZXtByHVt45kY2ZxCMApt8VXf5LV 3fzgdPRyfDe77S7ybGm1NoJ8dw9gTQT1GXsLKWv6zSCQl2890DsQ8Je2Xvbg39T225 zq8fGkSTeU60CDaQq1PGJLZjK2wOUq7TiKxlTuM5JRjzoWwbQOeUopEacdMmDyz9Ro 2nW/w1tK0K1IM23ljQ3qvF2Zkqf68TkA8uDANLc1rz+SihJ1nb1pAMsNcURuMxZUA1 ZALDD1z7Vs+Uw==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JsSD124Pkz6tm5 for <behave@ietf.org>; Mon, 7 Feb 2022 01:47:44 +0100 (CET)
Message-ID: <ee760818-a3c4-3755-6bdf-afcec6fcaaad@posteo.de>
Date: Mon, 07 Feb 2022 00:47:43 +0000
MIME-Version: 1.0
Content-Language: en-US
To: behave@ietf.org
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>
From: Klaus Frank <klaus.frank@posteo.de>
In-Reply-To: <7a008cc2-e8a3-f91d-c782-96866c36a9db@network-heretics.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080004020402080003070402"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/JCQyr9OgOa9xAQqSvZFpVMyoId4>
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:47:54 -0000

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

v2.23.0 | Report a Bug | By Email