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