Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Christian Huitema <huitema@huitema.net> Thu, 10 February 2022 07:27 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 7C2F93A14DB for <behave@ietfa.amsl.com>; Wed, 9 Feb 2022 23:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.602
X-Spam-Level:
X-Spam-Status: No, score=-7.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, 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 TY2Ex1TWtMZp for <behave@ietfa.amsl.com>; Wed, 9 Feb 2022 23:27:24 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 A81ED3A0988 for <behave@ietf.org>; Wed, 9 Feb 2022 23:27:24 -0800 (PST)
Received: from xse.mail2web.com ([66.113.192.6]) by mx258.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nI3rN-0004UL-JS for behave@ietf.org; Thu, 10 Feb 2022 08:27:23 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4JvSxf1Pm0zCDp for <behave@ietf.org>; Wed, 9 Feb 2022 23:27:18 -0800 (PST)
Received: from [10.5.2.14] (helo=xmail04.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 1nI3rK-0006tn-1h for behave@ietf.org; Wed, 09 Feb 2022 23:27:18 -0800
Received: (qmail 11780 invoked from network); 10 Feb 2022 07:27:17 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.46.218]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <marcelo@it.uc3m.es>; 10 Feb 2022 07:27:17 -0000
Content-Type: multipart/alternative; boundary="------------SiFNQzOxJZL2cBxB4YWzHB07"
Message-ID: <c38f50da-8a0f-c15e-2938-1d33c3620e50@huitema.net>
Date: Wed, 09 Feb 2022 23:27:16 -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: marcelo bagnulo braun <marcelo@it.uc3m.es>, 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> <ee760818-a3c4-3755-6bdf-afcec6fcaaad@posteo.de> <B7DFC369-E7B7-4171-9C85-F75986B5AEF6@gmail.com> <6123a322-e9a7-7f90-391f-9b4c4461ce45@network-heretics.com> <e95993e4-4166-4b3d-1637-8ca451b093b6@huitema.net> <7b7cf541-3387-6d0b-0fbe-273a08fd37ed@posteo.de> <0d18c171-f713-4590-d9a6-3c5729a3384c@huitema.net> <a4dbfa8c-abb4-e4e7-e53c-d7f54a2e5bf9@posteo.de> <50b919ba-22e5-cfd0-5e44-b905d42c50b7@it.uc3m.es> <8c10d7d6-ad60-2373-c809-1b75b8d1448c@huitema.net> <0f31d5ce-fae5-1673-3b9b-15341c8b052e@it.uc3m.es>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <0f31d5ce-fae5-1673-3b9b-15341c8b052e@it.uc3m.es>
X-Originating-IP: 66.113.192.6
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.192.0/27
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.0/27@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+0Aaeig1 M6KRLRJSe4ggdwluIQwh55uqY3MhMgFAHq5BxPxPXn36fLqvhISQ5ykyqUZqUd1jhnM/Mbva2XLV /LIEzaL2KoAZhJekBPedneT7f699iwgQ+2yl7BoDncKB+ziACIPAgTtUp75uqlx0KezvZHU8jaTA 4gvoN3cy3ZS3bc6iWQaaSSaRcFTFxaRvADgOuFdAU5fRzM/QzQW9/IoH33AG8ECuCwECazCwODtO F78PiyQEs+dlGXUJLWZ+Gc08Nmllke3azHdKmySKNUVQl4ntlVxnbS8qIO7oudHyb2T1t0DNtlpu 9/j54C+9KfQPluPQHHIQ/hjX8s5UcsOm8JZqy4TFaO7Oawv4tcQOp8LxvCrJPmnnTHzVkpybMK7Z Te2KiOojQ29oDb9/XiQyH3UVmM65ILKePxcrIG9nD1eCC/9N3HswhrQ+2bGrjQGyzqsQ8ZpR+9NA PyZNieblXJv94Hfpe9sG4LVTWytPhXFwGplHcpVCCoX989hgB8R+yD+yTi42FDvxkqlBDtU2wzhW d7UpviVdtrZ5nWYIu4WZMOXUe6s0960ka4Si1dzG2NsAtxpLrx2sBi3aTxN1Q/yLprWZ5Uei0Mqj P90aC1IsxMwwlmJT37b8CHOVqIzTPPdjzQ6YC7Heg3Xf7O1TOd7yRPSWrTD+JXvVFjfX3WbD9Az4 FIDMsF11U3JKOGzWMl4aTQ0gQSiOnmI7rC6yMyOfKli4HDOd0ZYCWSrVBcYB7F/jc062mAlvdags Z2Hg03Bd5uytpg9oN0bVA08rQSN+pvlHhV6a5QjptwQBGybQKGkK5SrT50KM4tfY9j0AaMYorHWj 7X5mKUwTCmkcSUboUcANK3ozfA8QTMT8tMkmVgW9/bktU41htiJ8fk7NkI9yYjkgur7cbmMvzASy KBFiofMD9zY3KwIpwmXDmPc3eysRNwBGloDYkqoHVp6kQw==
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/uJKtM40V1NLEOJFb6Yeg2d5najQ>
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: Thu, 10 Feb 2022 07:27:28 -0000

On 2/9/2022 11:07 PM, marcelo bagnulo braun wrote:

> El 7/2/22 a las 19:03, Christian Huitema escribió:
>>
>>
>> On 2/6/2022 10:34 PM, marcelo bagnulo braun wrote:
>>> El 7/2/22 a las 3:48, Klaus Frank escribió:
>>>> The DNS64 server could be this secure DNS.
>>>
>>> This would consistent with the deployment scenario presented in 
>>> section 7.1 of RFC6147. 
>>
>>
>> Maybe. But the situation has changed since April 2011. ISPs cannot 
>> any more assume that all hosts will be using the resolver embedded in 
>> the NAT64 gateway -- some hosts, or some applications, may very well 
>> use some alternate encrypted DNS service, e.g., using DoH and connect 
>> to Quad9, Cloudflare or Google. The cases describe in section 6 of 
>> RFC6147 are going to be more and more frequent. We should make them 
>> work, and we should tell application developers about that.
>>
> DNS64 doesnt have to be collocated withthe NAT64 box.
>
> The scenario 7.1 still holds in case the user is using an external 
> reoslver, such as cloudflare. The thing is that the external resolver 
> must then implement the DNS64.

How does the external resolver know when it should implement DNS64 and 
when it shouldn't?

> This works fine as long as the WKP is used. 

Lot's of stuff will work better if the WKP is used...

-- Christian Huitema