Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
"Paul Hoffman" <paul.hoffman@vpnc.org> Wed, 30 September 2015 16:53 UTC
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F781A873C; Wed, 30 Sep 2015 09:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 Fdm9HM7YzxsX; Wed, 30 Sep 2015 09:53:52 -0700 (PDT)
Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 8A2211A7000; Wed, 30 Sep 2015 09:53:52 -0700 (PDT)
Received: from [10.32.60.140] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8UGrn9n038319 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2015 09:53:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.140]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Brian Haberman <brian@innovationslab.net>
Date: Wed, 30 Sep 2015 09:53:49 -0700
Message-ID: <98A9D0B3-C7B4-4F27-AF40-EE23DD1CD038@vpnc.org>
In-Reply-To: <560BFF18.3080100@innovationslab.net>
References: <20150930135306.9641.25056.idtracker@ietfa.amsl.com> <0021A0B0-DEA4-4492-8484-E47819117472@vpnc.org> <560BFBF0.6030001@innovationslab.net> <DDBEB203-5DD9-4AA3-BC32-CBD4D51BD243@vpnc.org> <560BFF18.3080100@innovationslab.net>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/uyvAUvv_Gpe5cci3wBKRMhmQVGg>
Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-root-loopback@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-root-loopback.ad@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dnsop-root-loopback.shepherd@ietf.org
Subject: Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 16:53:53 -0000
On 30 Sep 2015, at 8:26, Brian Haberman wrote: >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I can't decide if I should ballot Yes because this document does a >>>>> good >>>>> job of describing how to deploy this approach or Abstain because >>>>> the >>>>> fragility introduced in this approach appears to be untenable. >>>>> >>>>> In the meantime, can someone explain why this document is stating >>>>> a >>>>> requirement to deploy this approach with IPv4 only? >>>> >>>> Yes. Given that this is running on loopback, it doesn't matter if >>>> the >>>> service is running on either the v4 or v6 loopback address. Unless >>>> a >>>> system running this service has absolutely no v4 at all (it doesn't >>>> even >>>> need to be offering v4 service to customers), the v4 loopback >>>> address is >>>> sufficient. >>>> >>>> There seems to be wide disagreement about what is the v6 loopback >>>> address: some of these addresses exist on some v6 systems but not >>>> others, or so we were told. If there is a v6 loopback address that >>>> is >>>> universally deployed (as 127/8 is for v4), we can add it, although >>>> it >>>> won't actually make this more deployable. >>>> >>>> --Paul Hoffman >>> >>> I am not sure how much clearer the definition of IPv6 loopback could >>> be >>> (https://tools.ietf.org/html/rfc4291#section-2.5.3). Of course, if >>> it >>> is an implementation issue, there is not much the IETF can do. >>> >>> Thanks for the quick response. >> >> If the WG agrees that 0:0:0:0:0:0:0:1 is always present, we can >> certainly add that to the document. I now cannot find any on-list >> mention of why this isn't useful in all v6-capable systems, so it >> might >> have been a hallway conversation. > > > It seems like the WG can cover both address families by simply making > these changes: > > OLD: > > o The system MUST be able to run an authoritative server on one of > the IPv4 loopback addresses (that is, an address in the range > 127/8). > > NEW: > > o The system MUST be able to run an authoritative server on one of > the loopback addresses (that is, an address in the range > 127/8 for IPv4 or ::1 in IPv6). > > OLD: > > 2. Start the authoritative server with the root zone on a loopback > address that is not in use. This would typically be 127.0.0.1, > but if that address is in use, any address in 127/8 is > acceptable. > > NEW: > > 2. Start the authoritative server with the root zone on a loopback > address. This would typically be 127.0.0.1 in IPv4 or ::1 in > IPv6. > > Why does the document say that the address should not be in use? I'll add the v4/v6 wording to the post-IESG-review draft unless there is objection in the WG. John Levine just answered your question about why the address might already be in use, which was something that was brought up in the early discussion of this draft in the WG. It means that you can't run both this and some other DNS-listening task on ::1, whereas you can run both on different addresses in 127/8. We'll cover that in the new wording. --Paul Hoffman
- [DNSOP] Brian Haberman's No Record on draft-ietf-… Brian Haberman
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Paul Hoffman
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Brian Haberman
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Paul Hoffman
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Brian Haberman
- Re: [DNSOP] Brian Haberman's No Record on draft-i… John Levine
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Paul Hoffman
- Re: [DNSOP] Brian Haberman's No Record on draft-i… John Levine
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Joe Abley
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Robert Edmonds
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Evan Hunt
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Mark Andrews
- Re: [DNSOP] Brian Haberman's No Record on draft-i… John Levine
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Paul Vixie
- Re: [DNSOP] Brian Haberman's No Record on draft-i… joel jaeggli
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Evan Hunt
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Tony Finch
- Re: [DNSOP] Brian Haberman's No Record on draft-i… Darcy Kevin (FCA)
- Re: [DNSOP] Brian Haberman's No Record on draft-i… John Levine
- Re: [DNSOP] Brian Haberman's No Record on draft-i… David Conrad
- Re: [DNSOP] Brian Haberman's No Record on draft-i… John R Levine
- Re: [DNSOP] Brian Haberman's No Record on draft-i… George Michaelson