From nobody Sun Jul 1 06:45:59 2018 Return-Path: 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 8262A12785F for ; Sun, 1 Jul 2018 06:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 PdxF7pqDcaHg for ; Sun, 1 Jul 2018 06:45:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB351277CC for ; Sun, 1 Jul 2018 06:45:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0E7B2B80CCA; Sun, 1 Jul 2018 06:45:49 -0700 (PDT) To: congxiao@cernet.edu.cn, huitema@microsoft.com, marcelo@it.uc3m.es, mohamed.boucadair@orange-ftgroup.com, xing@cernet.edu.cn, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, dwing@cisco.com, dthaler@microsoft.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: worley@ariadne.com, behave@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180701134549.0E7B2B80CCA@rfc-editor.org> Date: Sun, 1 Jul 2018 06:45:49 -0700 (PDT) Archived-At: Subject: [BEHAVE] [Technical Errata Reported] RFC6052 (5415) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 13:45:58 -0000 The following errata report has been submitted for RFC6052, "IPv6 Addressing of IPv4/IPv6 Translators". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5415 -------------------------------------- Type: Technical Reported by: Dale R. Worley Section: 2.2 Original Text ------------- Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero. When using a /96 Network-Specific Prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero. A simple way to achieve that is to construct the /96 Network-Specific Prefix by picking a /64 prefix, and then adding 4 octets set to zero. [and other parts of the text] Corrected Text -------------- [This paragraph should be removed and corresponding changes made to the rest of section 2.2.] Notes ----- Section 2.2 says that bits 64 to 71 of the Ipv6 address MUST be set to zero and references RFC 4291 as the authority. However, RFC 7136 says: In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly. Thus, the text I've referenced in RFC 6052 is to enforce a requirement that was not correctly applied, and RFC 6052's statement about bits 64 to 71 should be removed. In addition, there are consequent changes in other parts of RFC 6052, including Figure 1, where the "u" field should be removed from the address formats. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6052 (draft-ietf-behave-address-format-10) -------------------------------------- Title : IPv6 Addressing of IPv4/IPv6 Translators Publication Date : October 2010 Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From nobody Thu Jul 5 02:27:27 2018 Return-Path: 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 14E83130DEF for ; Thu, 5 Jul 2018 02:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 oH8wzmnsjDio for ; Thu, 5 Jul 2018 02:27:24 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0966130DF2 for ; Thu, 5 Jul 2018 02:27:23 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 41LsvZ43qdz8tvF; Thu, 5 Jul 2018 11:27:22 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 41LsvZ1GLlzCqkb; Thu, 5 Jul 2018 11:27:22 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0399.000; Thu, 5 Jul 2018 11:27:20 +0200 From: To: RFC Errata System , "congxiao@cernet.edu.cn" , "huitema@microsoft.com" , "marcelo@it.uc3m.es" , BOUCADAIR Mohamed IMT/OLN , "xing@cernet.edu.cn" , "spencerdawkins.ietf@gmail.com" , "ietf@kuehlewind.net" , "dwing@cisco.com" , "dthaler@microsoft.com" CC: "worley@ariadne.com" , "behave@ietf.org" Thread-Topic: [BEHAVE] [Technical Errata Reported] RFC6052 (5415) Thread-Index: AQHUEUHkYOVKg+6YCESC57ED0TtRCaSAXrKQ Date: Thu, 5 Jul 2018 09:27:20 +0000 Message-ID: <80aeee21-d6b8-446d-a5a0-c4e728f39586@OPEXCLILM41.corporate.adroot.infra.ftgroup> References: <20180701134549.0E7B2B80CCA@rfc-editor.org> In-Reply-To: <20180701134549.0E7B2B80CCA@rfc-editor.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5415) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 09:27:26 -0000 Dear Dale,=20 Thank you for formally raising the point.=20 I do think that the u byte makes things complex and is not justified any mo= re. Nevertheless, that artificially boundary was provisioned for "historica= l" reasons that were clarified in RFC 7136. =20 The community considered in the past updating RFC6052 to reflect that. For = example, you may refer to=20 https://www.ietf.org/mail-archive/web/softwires/current/msg05508.html, but = even at that time, the consensus of the softwire wg was to follow RFC6052 a= s it is (https://tools.ietf.org/html/rfc7599).=20 I suggest to maintain RFC6052 as it is. The harm is behind us given the ins= talled deployment base: RFC6052-based implementations are widely deployed. = It is key for all IPv6-only deployments in cellular networks over the world= .=20 There is more harm in updating its vs. maintain it because of interoperabil= ity issue. =20 Cheers, Med > -----Message d'origine----- > De=A0: Behave [mailto:behave-bounces@ietf.org] De la part de RFC Errata S= ystem > Envoy=E9=A0: dimanche 1 juillet 2018 15:46 > =C0=A0: congxiao@cernet.edu.cn; huitema@microsoft.com; marcelo@it.uc3m.es= ; > mohamed.boucadair@orange-ftgroup.com; xing@cernet.edu.cn; > spencerdawkins.ietf@gmail.com; ietf@kuehlewind.net; dwing@cisco.com; > dthaler@microsoft.com > Cc=A0: worley@ariadne.com; behave@ietf.org; rfc-editor@rfc-editor.org > Objet=A0: [BEHAVE] [Technical Errata Reported] RFC6052 (5415) >=20 > The following errata report has been submitted for RFC6052, > "IPv6 Addressing of IPv4/IPv6 Translators". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5415 >=20 > -------------------------------------- > Type: Technical > Reported by: Dale R. Worley >=20 > Section: 2.2 >=20 > Original Text > ------------- > Bits 64 to 71 of the address are reserved for compatibility with the > host identifier format defined in the IPv6 addressing architecture > [RFC4291]. These bits MUST be set to zero. When using a /96 > Network-Specific Prefix, the administrators MUST ensure that the bits > 64 to 71 are set to zero. A simple way to achieve that is to > construct the /96 Network-Specific Prefix by picking a /64 prefix, > and then adding 4 octets set to zero. >=20 > [and other parts of the text] >=20 >=20 > Corrected Text > -------------- > [This paragraph should be removed and corresponding changes made to > the rest of section 2.2.] >=20 > Notes > ----- > Section 2.2 says that bits 64 to 71 of the Ipv6 address MUST be set to ze= ro > and references RFC 4291 as the authority. However, RFC 7136 says: >=20 > In particular, RFC 4291 defines a method by which the > Universal and Group bits of an IEEE link-layer address are mapped > into an IPv6 unicast interface identifier. This document clarifies > that those two bits are significant only in the process of deriving > interface identifiers from an IEEE link-layer address, and it updates > RFC 4291 accordingly. >=20 > Thus, the text I've referenced in RFC 6052 is to enforce a requirement th= at > was not correctly applied, and RFC 6052's statement about bits 64 to 71 > should be removed. In addition, there are consequent changes in other pa= rts > of RFC 6052, including Figure 1, where the "u" field should be removed fr= om > the address formats. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC6052 (draft-ietf-behave-address-format-10) > -------------------------------------- > Title : IPv6 Addressing of IPv4/IPv6 Translators > Publication Date : October 2010 > Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Sun Jul 15 10:21:21 2018 Return-Path: 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 7B9DC130E4B for ; Sun, 15 Jul 2018 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 uHhsvvL2IAR1 for ; Sun, 15 Jul 2018 10:21:16 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B6EA51294D0 for ; Sun, 15 Jul 2018 10:21:15 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id t6-v6so29600602wrn.7 for ; Sun, 15 Jul 2018 10:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CcvhFNQ6KXZlZtK8fejmW/AHhbEa/HiXG3+Sf+1auNc=; b=aRAlpzudvuRVOHFhqJFky/0pJ9bGJPxVnuRQQaPmkRLd4qT9MY2hqd9AEypxIzd25d +mYiFwFI2JyR1TIXvxnRI8THW/BhbkzizwR9cLT1MSV3kVgq7aAhza6FIhJeCAMHpKhf uvCK+5+1rGfuZLArnUaeZijdbQPmkzLfBIsxaTdDMFqQWRfN9wGbCZkj0yeAtTkEmSjw P7LaCJ8chBg+827ZLFyY3BeBkcrhzpmd5qS+1ZkZJO17ObqI2ps1DnS/Wj3ssqssnAlf r6vLOjn5atm1kKFbbARUr0uspdh1PpOHMLoMteYZzXMdbXpTDnUt0s0zYh2uG47UGqna NQwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CcvhFNQ6KXZlZtK8fejmW/AHhbEa/HiXG3+Sf+1auNc=; b=Z3J1ab8bgOPxHSCOvug7xHfnuusdP1rWTmOxZeJgE+9crEynAmDqXTkF2w0k4T6da2 dR9e9yobjh/Zcsx6p0V9MOhdFTvAFO12BnP2zQEJyCrjPHYo2bBlwS+KYJ0lv/qz5JV6 CD7rEswM6eBqKqWUM4YGKsomB5x2+97wulufqCkFTBweH687LxjmjdWSzgI++MxQ50kP LAJfLeosHB3p5bxu9jcXOElCjXSXwD8ct/pIIn26G135CGUdZ+c2nP8eecKjtqHdSIdS YY9ReoecF0V3dCGKn+cmt4SbvTh7TwyEygfyJOf32SDd7SYrqSgtR+R2yKkCy4WK77ti ut+Q== X-Gm-Message-State: AOUpUlESUKAHDMNgn4YThub9DDougUYEGpXd05m+A3jTvPoSlmoVfijg n4kgXd0Sd6fA5v8dnlw9DM/VbrCertUGArh6Y5sG5MBZ X-Google-Smtp-Source: AAOMgpckChG1SJqviA4mJDRmzAZ0y+45jaYNPS8x5oltiU2Gy0l1crfxx1vi/6rbLJ25yg0OpsaZybNJ7s1EjSI5+Hc= X-Received: by 2002:adf:ba12:: with SMTP id o18-v6mr10531462wrg.249.1531675273620; Sun, 15 Jul 2018 10:21:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Sun, 15 Jul 2018 13:20:37 -0400 Message-ID: To: behave@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 17:21:20 -0000 Dear BEHAVE, I sent this to DNSOP a while back, but didn't think to send it to behave as well - sorry. Please see below, and if you have comments, please comment in the DNSOP list (so that we don't have overlapping discussions)... Thank you! W ---------- Forwarded message --------- From: Warren Kumari Date: Wed, Jul 4, 2018 at 4:26 PM Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa To: dnsop Dear DNSOP, Stuart Cheshire & David Schinazi have asked me to AD sponsor the draft-cheshire-sudn-ipv4only-dot-arpa document [0] . >From the document: "The specification for how a client discovers its network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but declares it to be a non-special name in that specification Domain Name Reservation Considerations section. Consequently, despite the well articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties. This document formally declares the actual special properties of the name, and adds similar declarations for the corresponding reverse mapping names." RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") is worth reading before reading this. If you are mainly a DNS person, this may be...surprising. When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things worth keeping in mind: 1: This is a fairly specialized function - it is used by NAT64 clients to discover the prefix used for synthesis ("normal" people / applications never need to resolve this). The main people who will deal with this are mobile / stack vendors, and NAT64 providers. 2: RFC7050 has a large amount of text around DNSSEC, what to do with DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 device*, not the ipv4only.arpa name. 3: Devices use this mechanism to discover the IPv6 prefix used for IPv6 address synthesis - different interfaces (e.g cellular and wifi) will have different prefixes. This means that clients must do this query using the resolver learned on / appropriate for that interface. This is the main bit which is weird for a DNS person - the response from the resolver for your cellular interface connected to T-Mobile contains T-Mobile's NAT64 prefix; the response from the resolver learnt over your wifi connection to the IETF network contains the NAT64 prefix you use on the IETF network. DNS isn't really being used here for resolving names, rather DNS is being used a signalling mechanism (a rude t-shirt springs to mind here). What this draft does is: 1: record this in the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't actually ask the IANA to update the registry. 2: requests that the IANA make ipv4only.arpa be an insecure delegation (see #2 above) - this removes some special handling and complexity. 3: specifies that you have to use the resolvers learn on an interface for these queries. The whole purpose of these queries is to learn the *local* NAT64 prefix - asking a public recursive isn't going to help you here. 4: This is under .arpa (and is already in wide use) - it doesn't have the sticky policy problems that many SUD names have. I've agreed to AD sponsor this, but would really appreciate your review and input. RFC7050 is deployed - this improves / clarifies things. 1: The authors have previously presented this document at DNSOP meetings - there was some discussion, but no real interest in adopting or shouts of outrage about it. 2: I've asked the DNSOP chairs if I can use the DNSOP list for discussion of this (and they agreed) 3: This was originally a product of the (now closed) BEHAVE WG - I've spoken with Spencer (the BEHAVE AD) who has no objections. 4: I've asked the IESG and there were no objections either. 5: As this touches .arpa I'm also asking the IAB for input. 6: Dave Thaler (who was the document shepherd for RFC7050) has kindly agreed to be shepherd for this document too. W [0]: note that they asked this before the current "ipv4only.arpa's delegation should be insecure." thread - https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Jul 16 13:15:33 2018 Return-Path: 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 4AF7A131192 for ; Mon, 16 Jul 2018 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 lSuXys3yeO9a for ; Mon, 16 Jul 2018 13:15:28 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 CEA3D130EE7 for ; Mon, 16 Jul 2018 13:15:27 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ff9tt-0002hX-Bq for behave@ietf.org; Mon, 16 Jul 2018 22:15:26 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ff9tl-0000am-HG for behave@ietf.org; Mon, 16 Jul 2018 16:15:13 -0400 Received: (qmail 14479 invoked from network); 16 Jul 2018 20:15:05 -0000 Received: from unknown (HELO [192.168.100.102]) (Authenticated-user:_huitema@huitema.net@[80.13.34.254]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Jul 2018 20:15:05 -0000 To: Warren Kumari , behave@ietf.org References: From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <76d00a46-72b1-c270-9984-c2a5357348a7@huitema.net> Date: Mon, 16 Jul 2018 22:15:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.16) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rR7reLNO1zJqcI9I5X00tJ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO0VmU7heoGtPbmnM2lug8e3TV/3OdXD2Xdo8CfrY5CQSKAQWFZJf9TLRjccBANEotYyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1Sd2ZrHrUfFcPN5PXBq6ur6Xe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtP/UPTAAMnNuB6/0WWjH77oh6ijzwzq5HGxV3pRhOdYuobeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80D4WY7xWSn pVjQVprFFOt2hDWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SMPepZn00xVXQbuUt1pns FwEiRQv+PVjjwa+Z5RFCOMTwcD+deSsUec2uUy1l2Ykm/SkjHuYQDxaU4XDpGsg0T9tCZ9RmVnHJ UdzwofXZM+bUdLWq1MCLe4uzYlSTS/YzOILorw8hkXvCsQxELmff7J1gP4HWZlfj1ueWMBAfk0cY VXicmMOpI2clI133E9HJAWCpsuwwFLcJK7RNhb8o8+4jeF7MIDAd/+68q5OewVOs9/WClZ8hMz61 hUh2QVHbskSXyRGWD2l446GdcdNgAoQKSK3P4ypiY56j+sEW5bQ+tU38SL4vC8Dk71a0SIWgTAz/ vUCXk3dj4MGE7pxybpLXQPUO8H9CpGtFZ7WIonLNTt/aVJj3FpzwJHlTKBf4P5hMT+A79/UQxSgW IabEpmvDK3PKrieG7T6bf9hS7hSjMM96sV7dcXymT/Bh/IEEdD/a7oKc1xB6o1ApfCO9+GHf4ys4 4rg2B8/9FmK9a1M2fwlGUBjVgiQQJUTeFgMs X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:15:31 -0000 I have never been a great fan of the DNS64 hacks. The DNS64 specification, and RFC7050, are making a set of assumptions about the DNS infrastructure, the way stub resolvers are configured, and the possibility for intermediate resolvers to spoof AAAA records on the fly. One of these assumptions was already on shaky ground when the spec was written. It is only OK to spoof DNS records if the clients do not insist on DNSSEC. I don't have good numbers on clients, by I see measurements showing that over 90% of clients are served by recursive DNS resolvers that request DNSSEC validation (setting the DNSSEC OK option flage to 1), and over 50% of clients are served by recursive DNS resolvers that perform DNSSEC validation. Another assumption is that clients use DNS resolvers that are under the control of the network provider. Again, current measurement show that more than 25% of clients are server by third party DNS resolvers. That number is actually growing steadily. New DNS transports like DNS over TLS or DNS over HTTPS ensure that the exchanges between clients and third party resolvers will be pretty much immune to hacking by on-path middleboxes. Yet another assumption is that clients expect DNS responses to vary depending on the interface over which the DNS queries are sent. Again, this is incompatible with the current trend of using third party resolvers. That assumption might have worked when applications were only using DNS resolvers provided by the operating system. But then, we see a solid trend of moving transport services out of the kernel and into application libraries. QUIC is an example of that. These numbers and these trends tell me that technologies like DNS64 will be very hard to deploy, and also very unreliable when deployed. These technologies make a number of unwarranted assumptions about the nature of the DNS service. I don't think that attempting yet another patch like ipv4only.arpa will help all that much. In fact, I would much prefer to let 7050 die a deserved death, and maybe hasten that death by deprecating its status. -- Christian Huitema On 7/15/2018 7:20 PM, Warren Kumari wrote: > Dear BEHAVE, > > I sent this to DNSOP a while back, but didn't think to send it to > behave as well - sorry. > > Please see below, and if you have comments, please comment in the > DNSOP list (so that we don't have overlapping discussions)... > > > Thank you! > W > > > ---------- Forwarded message --------- > From: Warren Kumari > Date: Wed, Jul 4, 2018 at 4:26 PM > Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa > To: dnsop > > > Dear DNSOP, > > Stuart Cheshire & David Schinazi have asked me to AD sponsor the > draft-cheshire-sudn-ipv4only-dot-arpa document > [0] > .. > > >From the document: > "The specification for how a client discovers its network's NAT64 > prefix [RFC7050] defines the special name 'ipv4only.arpa' for this > purpose, but declares it to be a non-special name in that > specification Domain Name Reservation Considerations section. > Consequently, despite the well articulated special purpose of the > name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names > registry as a name with special properties. > This document formally declares the actual special properties of the > name, and adds similar declarations for the corresponding reverse > mapping names." > > RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address > Synthesis") is worth reading before reading this. If you are mainly a > DNS person, > this may be...surprising. > > > When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few thin= gs > worth > keeping in mind: > > 1: This is a fairly specialized function - it is used by NAT64 clients > to discover the prefix used for synthesis ("normal" people / > applications never need to resolve this). The main people who will > deal with this are mobile / stack vendors, and NAT64 providers. > 2: RFC7050 has a large amount of text around DNSSEC, what to do with > DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 > device*, not the ipv4only.arpa name. > 3: Devices use this mechanism to discover the IPv6 prefix used for > IPv6 address synthesis - different interfaces (e.g cellular and wifi) > will have different prefixes. This means that clients > must > do this query using the resolver learned on / appropriate for that > interface. This is the main bit which is weird for a DNS person - the > response from the resolver for your cellular interface connected to > T-Mobile contains T-Mobile's NAT64 prefix; the response from the > resolver learnt over your wifi connection to the IETF network contains > the NAT64 prefix you use on the IETF network. DNS isn't really being > used here for resolving names, rather DNS is being used a signalling > mechanism (a rude t-shirt springs to mind here). > > What this draft does is: > 1: record this in > the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't > actually ask the IANA to update the registry. > 2: requests that the IANA make ipv4only.arpa be an insecure delegation > (see #2 above) - > this removes some special handling and complexity. > > 3: specifies that you have to use the resolvers learn on an interface > for these queries. The whole purpose of these queries is to learn the > *local* NAT64 prefix - asking a public recursive isn't going to help > you here. > 4: This is under .arpa (and is already in wide use) - it doesn't have > the sticky policy problems that many SUD names have. > > I've > agreed > to AD sponsor this, but would really appreciate your review and > input. RFC7050 is deployed - this improves / clarifies things. > > 1: The authors have previously presented this document at DNSOP > meetings - there was some discussion, but no real interest in adopting > or shouts of outrage about it. > 2: I've asked the DNSOP chairs if I can use the DNSOP list for > discussion of this > (and they agreed) > 3: This was originally a product of the (now closed) BEHAVE WG - I've > spoken with Spencer (the BEHAVE AD) who has no objections. > 4: I've asked the IESG and there were no objections either. > 5: As this touches .arpa I'm also asking the IAB for input. > 6: Dave Thaler (who was the document shepherd for RFC7050) has kindly > agreed to be shepherd for this document too. > > W > > [0]: note that they asked this before the current "ipv4only.arpa's > delegation should be insecure." thread - > https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY= > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Mon Jul 16 14:34:53 2018 Return-Path: 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 516DC130DDC for ; Mon, 16 Jul 2018 14:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Xrtfk98bVMOa for ; Mon, 16 Jul 2018 14:34:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 B8BCD13121D for ; Mon, 16 Jul 2018 14:34:47 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9DA683AB03C; Mon, 16 Jul 2018 21:34:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 67EBD160066; Mon, 16 Jul 2018 21:34:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 58148160085; Mon, 16 Jul 2018 21:34:47 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SBFl1FUaAYqb; Mon, 16 Jul 2018 21:34:47 +0000 (UTC) Received: from [IPv6:2001:67c:370:1998:2856:54ae:51e4:e024] (nat64-a7.meeting.ietf.org [31.130.238.167]) by zmx1.isc.org (Postfix) with ESMTPSA id CD01B160066; Mon, 16 Jul 2018 21:34:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <76d00a46-72b1-c270-9984-c2a5357348a7@huitema.net> Date: Tue, 17 Jul 2018 07:34:44 +1000 Cc: Warren Kumari , behave@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <76d00a46-72b1-c270-9984-c2a5357348a7@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:34:52 -0000 We can make ipv4only.arpa work better while promoting alternative prefix discover mechanism. The two concepts are not mutually exclusive. I think RFC7050 is a kludge but we have a large number of clients that use this RFC7050 to find the prefix. We need to keep RFC7050 working as well as possible while those clients age out of the system. Much of this draft is instructing IANA to configure the ipv4only.arpa only zone better that it currently is. The rest is stuff individual vendors can do today to make things better. Mark > On 17 Jul 2018, at 6:15 am, Christian Huitema wrote: > > I have never been a great fan of the DNS64 hacks. The DNS64 > specification, and RFC7050, are making a set of assumptions about the > DNS infrastructure, the way stub resolvers are configured, and the > possibility for intermediate resolvers to spoof AAAA records on the fly. > > One of these assumptions was already on shaky ground when the spec was > written. It is only OK to spoof DNS records if the clients do not insist > on DNSSEC. I don't have good numbers on clients, by I see measurements > showing that over 90% of clients are served by recursive DNS resolvers > that request DNSSEC validation (setting the DNSSEC OK option flage to > 1), and over 50% of clients are served by recursive DNS resolvers that > perform DNSSEC validation. > > Another assumption is that clients use DNS resolvers that are under the > control of the network provider. Again, current measurement show that > more than 25% of clients are server by third party DNS resolvers. That > number is actually growing steadily. New DNS transports like DNS over > TLS or DNS over HTTPS ensure that the exchanges between clients and > third party resolvers will be pretty much immune to hacking by on-path > middleboxes. > > Yet another assumption is that clients expect DNS responses to vary > depending on the interface over which the DNS queries are sent. Again, > this is incompatible with the current trend of using third party > resolvers. That assumption might have worked when applications were only > using DNS resolvers provided by the operating system. But then, we see a > solid trend of moving transport services out of the kernel and into > application libraries. QUIC is an example of that. > > These numbers and these trends tell me that technologies like DNS64 will > be very hard to deploy, and also very unreliable when deployed. These > technologies make a number of unwarranted assumptions about the nature > of the DNS service. I don't think that attempting yet another patch like > ipv4only.arpa will help all that much. In fact, I would much prefer to > let 7050 die a deserved death, and maybe hasten that death by > deprecating its status. > > -- Christian Huitema > > > > On 7/15/2018 7:20 PM, Warren Kumari wrote: >> Dear BEHAVE, >> >> I sent this to DNSOP a while back, but didn't think to send it to >> behave as well - sorry. >> >> Please see below, and if you have comments, please comment in the >> DNSOP list (so that we don't have overlapping discussions)... >> >> >> Thank you! >> W >> >> >> ---------- Forwarded message --------- >> From: Warren Kumari >> Date: Wed, Jul 4, 2018 at 4:26 PM >> Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa >> To: dnsop >> >> >> Dear DNSOP, >> >> Stuart Cheshire & David Schinazi have asked me to AD sponsor the >> draft-cheshire-sudn-ipv4only-dot-arpa document >> [0] >> .. >> >>> From the document: >> "The specification for how a client discovers its network's NAT64 >> prefix [RFC7050] defines the special name 'ipv4only.arpa' for this >> purpose, but declares it to be a non-special name in that >> specification Domain Name Reservation Considerations section. >> Consequently, despite the well articulated special purpose of the >> name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names >> registry as a name with special properties. >> This document formally declares the actual special properties of the >> name, and adds similar declarations for the corresponding reverse >> mapping names." >> >> RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address >> Synthesis") is worth reading before reading this. If you are mainly a >> DNS person, >> this may be...surprising. >> >> >> When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things >> worth >> keeping in mind: >> >> 1: This is a fairly specialized function - it is used by NAT64 clients >> to discover the prefix used for synthesis ("normal" people / >> applications never need to resolve this). The main people who will >> deal with this are mobile / stack vendors, and NAT64 providers. >> 2: RFC7050 has a large amount of text around DNSSEC, what to do with >> DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 >> device*, not the ipv4only.arpa name. >> 3: Devices use this mechanism to discover the IPv6 prefix used for >> IPv6 address synthesis - different interfaces (e.g cellular and wifi) >> will have different prefixes. This means that clients >> must >> do this query using the resolver learned on / appropriate for that >> interface. This is the main bit which is weird for a DNS person - the >> response from the resolver for your cellular interface connected to >> T-Mobile contains T-Mobile's NAT64 prefix; the response from the >> resolver learnt over your wifi connection to the IETF network contains >> the NAT64 prefix you use on the IETF network. DNS isn't really being >> used here for resolving names, rather DNS is being used a signalling >> mechanism (a rude t-shirt springs to mind here). >> >> What this draft does is: >> 1: record this in >> the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't >> actually ask the IANA to update the registry. >> 2: requests that the IANA make ipv4only.arpa be an insecure delegation >> (see #2 above) - >> this removes some special handling and complexity. >> >> 3: specifies that you have to use the resolvers learn on an interface >> for these queries. The whole purpose of these queries is to learn the >> *local* NAT64 prefix - asking a public recursive isn't going to help >> you here. >> 4: This is under .arpa (and is already in wide use) - it doesn't have >> the sticky policy problems that many SUD names have. >> >> I've >> agreed >> to AD sponsor this, but would really appreciate your review and >> input. RFC7050 is deployed - this improves / clarifies things. >> >> 1: The authors have previously presented this document at DNSOP >> meetings - there was some discussion, but no real interest in adopting >> or shouts of outrage about it. >> 2: I've asked the DNSOP chairs if I can use the DNSOP list for >> discussion of this >> (and they agreed) >> 3: This was originally a product of the (now closed) BEHAVE WG - I've >> spoken with Spencer (the BEHAVE AD) who has no objections. >> 4: I've asked the IESG and there were no objections either. >> 5: As this touches .arpa I'm also asking the IAB for input. >> 6: Dave Thaler (who was the document shepherd for RFC7050) has kindly >> agreed to be shepherd for this document too. >> >> W >> >> [0]: note that they asked this before the current "ipv4only.arpa's >> delegation should be insecure." thread - >> https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jul 19 10:38:49 2018 Return-Path: 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 62A95130EAF for ; Thu, 19 Jul 2018 10:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 etkEUCSQAmfp for ; Thu, 19 Jul 2018 10:38:39 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 D31B8120049 for ; Thu, 19 Jul 2018 10:38:38 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id z13-v6so7226122wma.5 for ; Thu, 19 Jul 2018 10:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YaWIWD146MQ8bUD3eKuK8u++4wXx+oUZalILhq/RWr8=; b=yZgW3f+aEPc0uWbizsEpyTu2Vostfu4F39sQ8gQowSQhqstXQk93UB33nw6l0uyHEd TzbPJA2shjUeMNANA+4ju47yVF0iKAAdyWXvDjGUQbps70ArUhYK66caDz6tctjQIm2P o3cy/XztiVnXVgFMktThq3x5SdHi/PPapgDzabyi8DFeK2d3M3wAyAcXxqZNjh3B2Z7G xiVCqchlNP/imEQ6oHiV2UIws7ColOEBqBRwhhqWS3DjBxyM5bSddGZMQLg/Wcq9nel8 W4zckc4GVN5rWJX2Z/qv84iDUh5CJvM9X4orJ/4P77GkI/YGysY6KjjR3tB36g2XTfn6 N5XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YaWIWD146MQ8bUD3eKuK8u++4wXx+oUZalILhq/RWr8=; b=cLPppbmqsWaMc+gjzrnw3e6ak7xXfpnWwoAMwV+6LaHH+PxsHSiOF1AA8C3UoA8tso ojAU4QxbjRbuxqjNpEuZ0eNR/J2PjKiKFVqJhRgZnJLAK8QqTuMxiNiRWqnlP60Cosuj ioRwrFn05WLJX4RhL4RnhXqq4n3ancfkmexcNL3dCjmPZiZPgQEgggT0aNbLiZXB49Lz yAAc1HDlKurFfsyRgWI9kttB/3BE+Kyba5Jye4OmhVVfyONP010MibVyKsaoDvXNs/8d mdiqGzw8b+1mSOIAEiPuS/g0YXPMGb7L34u3iqJ4+lKwZ5io3RzaY2pYdcv+GSahAeoU nQbQ== X-Gm-Message-State: AOUpUlH0GiVaJtH+qfEkpnzM15UR7elQOzvEv69RuPD0xpODHhBRrEkE jDmzBrqREI6f7eR2eM+bzdJl6Fyj2ilBjxKB7hyC+A== X-Google-Smtp-Source: AAOMgpfbTye6MGqeAiP+cG2qfgcU/tW0/SepLEGWksrh7mkigAqgF8D4KIHUVUsL7524FjAmce1fP9qM8CkV3RvbGXo= X-Received: by 2002:a1c:87c9:: with SMTP id j192-v6mr4501131wmd.71.1532021917081; Thu, 19 Jul 2018 10:38:37 -0700 (PDT) MIME-Version: 1.0 References: <76d00a46-72b1-c270-9984-c2a5357348a7@huitema.net> In-Reply-To: <76d00a46-72b1-c270-9984-c2a5357348a7@huitema.net> From: Warren Kumari Date: Thu, 19 Jul 2018 13:38:01 -0400 Message-ID: To: Christian Huitema Cc: behave@ietf.org, dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:38:44 -0000 [ + DNSOP ] On Mon, Jul 16, 2018 at 4:15 PM Christian Huitema wrote: > > I have never been a great fan of the DNS64 hacks. The DNS64 > specification, and RFC7050, are making a set of assumptions about the > DNS infrastructure, the way stub resolvers are configured, and the > possibility for intermediate resolvers to spoof AAAA records on the fly. > > One of these assumptions was already on shaky ground when the spec was > written. It is only OK to spoof DNS records if the clients do not insist > on DNSSEC. I don't have good numbers on clients, by I see measurements > showing that over 90% of clients are served by recursive DNS resolvers > that request DNSSEC validation (setting the DNSSEC OK option flage to > 1), and over 50% of clients are served by recursive DNS resolvers that > perform DNSSEC validation. > > Another assumption is that clients use DNS resolvers that are under the > control of the network provider. Again, current measurement show that > more than 25% of clients are server by third party DNS resolvers. That > number is actually growing steadily. New DNS transports like DNS over > TLS or DNS over HTTPS ensure that the exchanges between clients and > third party resolvers will be pretty much immune to hacking by on-path > middleboxes. > > Yet another assumption is that clients expect DNS responses to vary > depending on the interface over which the DNS queries are sent. Again, > this is incompatible with the current trend of using third party > resolvers. That assumption might have worked when applications were only > using DNS resolvers provided by the operating system. But then, we see a > solid trend of moving transport services out of the kernel and into > application libraries. QUIC is an example of that. > > These numbers and these trends tell me that technologies like DNS64 will > be very hard to deploy, and also very unreliable when deployed. These > technologies make a number of unwarranted assumptions about the nature > of the DNS service. I don't think that attempting yet another patch like > ipv4only.arpa will help all that much. In fact, I would much prefer to > let 7050 die a deserved death, and maybe hasten that death by > deprecating its status. RFC7050 is already widely deployed -- I must admit that I personally also view it as a hack, but I'd much rather that, as it will continue to be used, it is at least well described, and has less pointy edges on it.... W > > -- Christian Huitema > > > > On 7/15/2018 7:20 PM, Warren Kumari wrote: > > Dear BEHAVE, > > > > I sent this to DNSOP a while back, but didn't think to send it to > > behave as well - sorry. > > > > Please see below, and if you have comments, please comment in the > > DNSOP list (so that we don't have overlapping discussions)... > > > > > > Thank you! > > W > > > > > > ---------- Forwarded message --------- > > From: Warren Kumari > > Date: Wed, Jul 4, 2018 at 4:26 PM > > Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa > > To: dnsop > > > > > > Dear DNSOP, > > > > Stuart Cheshire & David Schinazi have asked me to AD sponsor the > > draft-cheshire-sudn-ipv4only-dot-arpa document > > [0] > > .. > > > > >From the document: > > "The specification for how a client discovers its network's NAT64 > > prefix [RFC7050] defines the special name 'ipv4only.arpa' for this > > purpose, but declares it to be a non-special name in that > > specification Domain Name Reservation Considerations section. > > Consequently, despite the well articulated special purpose of the > > name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names > > registry as a name with special properties. > > This document formally declares the actual special properties of the > > name, and adds similar declarations for the corresponding reverse > > mapping names." > > > > RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address > > Synthesis") is worth reading before reading this. If you are mainly a > > DNS person, > > this may be...surprising. > > > > > > When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things > > worth > > keeping in mind: > > > > 1: This is a fairly specialized function - it is used by NAT64 clients > > to discover the prefix used for synthesis ("normal" people / > > applications never need to resolve this). The main people who will > > deal with this are mobile / stack vendors, and NAT64 providers. > > 2: RFC7050 has a large amount of text around DNSSEC, what to do with > > DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 > > device*, not the ipv4only.arpa name. > > 3: Devices use this mechanism to discover the IPv6 prefix used for > > IPv6 address synthesis - different interfaces (e.g cellular and wifi) > > will have different prefixes. This means that clients > > must > > do this query using the resolver learned on / appropriate for that > > interface. This is the main bit which is weird for a DNS person - the > > response from the resolver for your cellular interface connected to > > T-Mobile contains T-Mobile's NAT64 prefix; the response from the > > resolver learnt over your wifi connection to the IETF network contains > > the NAT64 prefix you use on the IETF network. DNS isn't really being > > used here for resolving names, rather DNS is being used a signalling > > mechanism (a rude t-shirt springs to mind here). > > > > What this draft does is: > > 1: record this in > > the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't > > actually ask the IANA to update the registry. > > 2: requests that the IANA make ipv4only.arpa be an insecure delegation > > (see #2 above) - > > this removes some special handling and complexity. > > > > 3: specifies that you have to use the resolvers learn on an interface > > for these queries. The whole purpose of these queries is to learn the > > *local* NAT64 prefix - asking a public recursive isn't going to help > > you here. > > 4: This is under .arpa (and is already in wide use) - it doesn't have > > the sticky policy problems that many SUD names have. > > > > I've > > agreed > > to AD sponsor this, but would really appreciate your review and > > input. RFC7050 is deployed - this improves / clarifies things. > > > > 1: The authors have previously presented this document at DNSOP > > meetings - there was some discussion, but no real interest in adopting > > or shouts of outrage about it. > > 2: I've asked the DNSOP chairs if I can use the DNSOP list for > > discussion of this > > (and they agreed) > > 3: This was originally a product of the (now closed) BEHAVE WG - I've > > spoken with Spencer (the BEHAVE AD) who has no objections. > > 4: I've asked the IESG and there were no objections either. > > 5: As this touches .arpa I'm also asking the IAB for input. > > 6: Dave Thaler (who was the document shepherd for RFC7050) has kindly > > agreed to be shepherd for this document too. > > > > W > > > > [0]: note that they asked this before the current "ipv4only.arpa's > > delegation should be insecure." thread - > > https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf