Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues
mohamed.boucadair@orange.com Thu, 10 February 2022 09:20 UTC
Return-Path: <mohamed.boucadair@orange.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 21C5C3A0912 for <behave@ietfa.amsl.com>; Thu, 10 Feb 2022 01:20:14 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 7EqSeBK4ih-F for <behave@ietfa.amsl.com>; Thu, 10 Feb 2022 01:20:09 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 DDBE73A095E for <behave@ietf.org>; Thu, 10 Feb 2022 01:20:07 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr25.francetelecom.fr (ESMTP service) with ESMTPS id 4JvWRp0GDgzCrKN; Thu, 10 Feb 2022 10:20:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1644484806; bh=jzAk1GqZAFol8ssft2xQ3XZinrp1lFNR5p4QL+GDsAk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hqtMHLQ4wYJOgfKmlLgpyTiDtmaDu7ihPnpMtyxkear0F7FD0GykpnvKq+HvC3BBB DsPE0pJxTKv8jUk3cFuCJPFWduGL88bW3mXuuI2zuBk4n8h2Lx1wa0MXV6O1qm0AEn INhOktkSnEDHblgpXgqfee5fotRAYVoERQlaEpmgBMMpPM4YXFQJMdzGizpdr7gx2K Ba3Uq3WNH6hjP9LadFTkOFwDutlvLNr1+fl+PDRjFE1p8L0mTVpLZSisQD9ckwnRMD PbiN7pJ/9vrX9VDSp+YUH1EMZBov+kkCVgpnGiv4Lhmmrkg+QxqtZ5y9HEXvAfZkaF plWqW4q+mhNzg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr01.francetelecom.fr (ESMTP service) with ESMTPS id 4JvWRn6W4yzDq86; Thu, 10 Feb 2022 10:20:05 +0100 (CET)
From: mohamed.boucadair@orange.com
To: marcelo bagnulo braun <marcelo@it.uc3m.es>, Christian Huitema <huitema@huitema.net>, "behave@ietf.org" <behave@ietf.org>
Thread-Topic: [BEHAVE] RFC6147 and RFC7208 interoperability issues
Thread-Index: AQHYHkzzoq8+owCSHUiBeg2IYB+owKyMdX+Q
Content-Class:
Date: Thu, 10 Feb 2022 09:20:04 +0000
Message-ID: <15932_1644484805_6204D8C5_15932_206_1_787AE7BB302AE849A7480A190F8B93303548F707@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <0f31d5ce-fae5-1673-3b9b-15341c8b052e@it.uc3m.es>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-10T08:34:48Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=4019a418-4d72-4a81-bc93-80f8068ed864; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/jVvofAgWyne9ahTcvYtwWJwoQTE>
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 09:20:14 -0000
Hi Marcelo, all, Please see inline. Cheers, Med > -----Message d'origine----- > De : Behave <behave-bounces@ietf.org> De la part de marcelo bagnulo > braun > Envoyé : jeudi 10 février 2022 08:08 > À : Christian Huitema <huitema@huitema.net>; behave@ietf.org > Objet : Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues > > 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. > [Med] Fully agree. The deployments I'm aware of (including ours) relies upon this model. RFC6889 insisted on this separation. > 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. [Med] The use of an external resolver does not break things if the host supports CLAT (and issues both A and AAAA queries) or if the external resolver is ... a DNS64. Please note that current available public DNS64 use distinct IP addresses vs. "normal" public resolver IP addresses. See for example, https://developers.google.com/speed/public-dns/docs/dns64#addresses Note also that in networks where NAT64/DNS64 are deployed, distinct DNS configuration is usually provided to IPv6-only vs dual-stock hosts. > > This works fine as long as the WKP is used. [Med] Agree, but there might be some issues that are already discussed in RFC8683. It is mainly about the delay to get connected vs IPv4-only host. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interop… Marc Blanchet
- [BEHAVE] RFC6147 and RFC7208 interoperability iss… Klaus Frank
- Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interop… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Dan Wing
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… marcelo bagnulo braun
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… marcelo bagnulo braun
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… marcelo bagnulo braun
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… marcelo bagnulo braun
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… David Conrad
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… David Conrad
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… David Conrad
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… JORDI PALET MARTINEZ
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Dan Wing
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Dan Wing
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interop… Hector Santos
- Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interop… Mark Andrews
- Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interop… Mark Andrews
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… marcelo bagnulo braun
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… marcelo bagnulo braun
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… mohamed.boucadair
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Keith Moore
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Christian Huitema
- Re: [BEHAVE] RFC6147 and RFC7208 interoperability… Klaus Frank