Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Christian Huitema <huitema@huitema.net> Mon, 07 February 2022 20:38 UTC

Return-Path: <huitema@huitema.net>
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 7F5A73A08C4 for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 12:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.603
X-Spam-Level:
X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 nmfbN9-thUWC for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 12:38:19 -0800 (PST)
Received: from mx36-out20.antispamcloud.com (mx36-out20.antispamcloud.com [209.126.121.68]) (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 ABE4F3A08B4 for <behave@ietf.org>; Mon, 7 Feb 2022 12:38:19 -0800 (PST)
Received: from xse52.mail2web.com ([66.113.196.52] helo=xse.mail2web.com) by mx257.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nHAm7-000FRS-0n for behave@ietf.org; Mon, 07 Feb 2022 21:38:17 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4Jsydb3WYMzBHj for <behave@ietf.org>; Mon, 7 Feb 2022 12:38:11 -0800 (PST)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nHAm3-00013z-B8 for behave@ietf.org; Mon, 07 Feb 2022 12:38:11 -0800
Received: (qmail 5119 invoked from network); 7 Feb 2022 20:38:10 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.46.218]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <drc@virtualized.org>; 7 Feb 2022 20:38:09 -0000
Message-ID: <56ecaebb-7a20-ea05-c203-a5f898d6fd21@huitema.net>
Date: Mon, 07 Feb 2022 12:38:10 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: David Conrad <drc@virtualized.org>
Cc: behave@ietf.org
References: <077D662F-5E6D-44F5-8DD3-B58D8B535C5D@network-heretics.com> <B6D6B4CC-AC1F-459C-952A-E9493E00FDB3@huitema.net> <7e53925e-46b0-29e4-6deb-47bcf389ff97@posteo.de> <3ff58733-ccd5-fe15-8b06-dd69bfad0c74@network-heretics.com> <59E4D416-0B86-46D3-BE0E-9C12881A07FD@virtualized.org>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <59E4D416-0B86-46D3-BE0E-9C12881A07FD@virtualized.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: 66.113.196.52
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zVVrN4oC+7+v6H1pDHwMpu42UuDhyzVYcwl2RB+0Aaeoio JmCg+hyCdEpGCTPKzEsh55uqY3MhMgFAHq5BxPxPXn36fLqvhISQ5ykyqUZqUd1jhnM/Mbva2XLV /LIEzaL2KoAZhJekBPedneT7f699iwgQ+2yl7BoDncKB+ziACIPAgTtUp75uqlx0KezvZHWM525h obRX+ccJ5ZEXtMPGWQaaSSaRcFTFxaRvADgOuFdAU5fRzM/QzQW9/IoH33AG8ECuCwECazCwODtO F78PiyQEs+dlGXUJLWZ+Gc08Nmllke3azHdKmySKNUVQl4ntlVxnbS8qIO7oudHyb2T1VQ58xe/l rqiRGalI3YPsxOTrFXToVyBmRCgQVX6zVyFUu8qzeMQP6uTHL0d9UjfY+eX5ZvcELCIKs663F/co VFYFvf25LVONYbYifH5OzZDcG6hsRQZiAIgw+z837AqgX7ewI8e1h7RITgN14BHmGVt/ReJ9Mfhz zmbKTH7wI9GEU1utNskUAORCV2WFZX0jMujG3f5uEi//7HghzjC/t6TeVLW3pB0Q/PTyowo5AfvR XKi04x2sEOTm6g3frHdBCFXoGKtafvOtcW/mP16bynTCOInfd76oq4RH5afpA3RRyBl07OVp2D/S 9ogT8aIXDk0/kYZFsrGHbQeDkWMukvaMBHm9cDkx8nzN7sttkq9UoFIvD3sIcP1fhJPM6B/8EMQE EUpDKcQ0sK4p7VbxpOJsbQ06fI17C+NYYI73oYM37Fo9Xqg2bQC831cpDah1knxffwp9P0T/rC39 SaHXB20AuXq0T17woJo3avKeADIsy647Mn0zwmGzAi3Zn+YdthRNgs7Ig4l/XErpYn3glZTKFuaT l19W3ISq9+1KiLsESGU+y+fjdgjudZxiTPi+MG1QP35nsYfP84c+RFK3KiZuZ5OAUoGBziSYFLZu u6zX3xxsmqT8l9ARlsTalAaf
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/pMfpPwDKxpigg2OhiBsTiQaj1go>
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 20:38:22 -0000

On 2/7/2022 9:18 AM, David Conrad wrote:
> As far as I can tell, Klaus has identified a specific issue in which existing IETF specifications are deficient in order to facilitate interoperability in a specific protocol when NAT64 is in use.

Yes.

We have an unresolved tension between recommending end-to-end solutions 
and recommending more processing in DNS64, which means the IETF will 
probably need to charter some work if we want to publish a consensus 
document. But the current discussion yielded both ideas and data.

According to Klaus, practical deployments of NAT64 in ISP use WKP, not 
NSP. That's interesting. I trust Klaus on that one, and it makes sense: 
ISP want to avoid breakage, and if using WKP is less likely to cause 
breakage than using NSP, they will use that. That also means that the 
job of the application writer becomes simpler: it is much easier to have 
a special case for WKP than to invent a way to learn the NSP. This could 
lead to an interesting feedback loop, in which more applications working 
with WKP means even less incentives for ISP to use NSP. This kind of 
loop is common and powerful. And maybe that's something that we can 
document.

-- Christian Huitema