Re: [BEHAVE] [Technical Errata Reported] RFC7050 (6270)

Mark Andrews <marka@isc.org> Fri, 18 September 2020 02:07 UTC

Return-Path: <marka@isc.org>
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 116673A0B0F for <behave@ietfa.amsl.com>; Thu, 17 Sep 2020 19:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 SEUXp-y1YAQ4 for <behave@ietfa.amsl.com>; Thu, 17 Sep 2020 19:07:45 -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 4E7623A0A9F for <behave@ietf.org>; Thu, 17 Sep 2020 19:07:44 -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 101013AB0CC; Fri, 18 Sep 2020 02:07:44 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DE89216006C; Fri, 18 Sep 2020 02:07:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B59D3160067; Fri, 18 Sep 2020 02:07:43 +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 wmpKNCuiY1_5; Fri, 18 Sep 2020 02:07:43 +0000 (UTC)
Received: from [172.30.42.67] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id D8FFB16003E; Fri, 18 Sep 2020 02:07:41 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <5CE83ABE-FA71-415A-8620-A06EA9539DEE@danwing.org>
Date: Fri, 18 Sep 2020 12:07:37 +1000
Cc: Jouni <jouni.nospam@gmail.com>, RFC Errata System <rfc-editor@rfc-editor.org>, dwing-ietf@fuggles.com, Magnus Westerlund <magnus.westerlund@ericsson.com>, behave@ietf.org, tsavo@kotiposti.net, Martin Duke <martin.h.duke@gmail.com>, Dave Thaler <dthaler@microsoft.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA5A1584-0FAB-4BE7-9558-035BF85C37F6@isc.org>
References: <20200901025348.AD36AF40771@rfc-editor.org> <E7035A63-CF71-4DBE-AC9C-C551B373863F@gmail.com> <C9BFCE03-4568-48CF-99E6-17A148554F03@isc.org> <5CE83ABE-FA71-415A-8620-A06EA9539DEE@danwing.org>
To: Dan Wing <dan@danwing.org>
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/FCATwobotNeS4U0Z_AYuh5u920E>
Subject: Re: [BEHAVE] [Technical Errata Reported] RFC7050 (6270)
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: Fri, 18 Sep 2020 02:07:47 -0000

I would also be tempted to state that a DNS64 server MUST set the suffix bits to zero for these addresses.
We have old servers that don’t do this, but ensuring that new servers don’t make discover harder than it
needs to be is good.

> On 18 Sep 2020, at 11:45, Dan Wing <dan@danwing.org> wrote:
> 
> Cisco's client implementation didn't care about two A's unless the first was at an unexpected place, then it looked for the other (to ensure the location was right).  The heuristics for the client aren't well described in the RFC; perhaps that can be improved.
> 
> -d
> 
> 
>> On Sep 17, 2020, at 6:17 PM, Mark Andrews <marka@isc.org> wrote:
>> 
>> As a DNS64 server developer I’m quite willing to override the user and always return 2 AAAA records for this name by
>> hard coding the addresses into the conversion algorithm.   Additionally this is the default.  Every A gets mapped to a AAAA unless it is in the exclude list and the default exclude list doesn’t include these two addresses.  Also any DNS64 server would be insane to only return one AAAA record as that defeats the redundancy of multiple addresses in the first place.  I’m sure if you polled the other DNS64 server developers they would have the same opinion.  We want the discover mechanism to work.
>> 
>> Then there is also RFC 8880 which also says return 2 AAAA records.
>> 
>>> On 18 Sep 2020, at 05:50, Jouni <jouni.nospam@gmail.com> wrote:
>>> 
>>> I don't agree with the errata. We cannot imho dictate what policy a DNS64 server is using an _example_ flow. 
>>> The text in Section 3.4 it actually states "The DNS64 server could also return synthetic addresses containing the IPv4 address 192.0.0.171." so it is not a copy-paste error.
>>> 
>>> - Jouni
>>> 
>>>> On 1 Sep 2020, at 5.53, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>>> 
>>>> The following errata report has been submitted for RFC7050,
>>>> "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis".
>>>> 
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid6270
>>>> 
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Mark Andrews <marka@isc.org>
>>>> 
>>>> Section: 3.4
>>>> 
>>>> Original Text
>>>> -------------
>>>> "PTR" query #2 for "2001:db8:43::192.0.0.170
>>>> 
>>>> Corrected Text
>>>> --------------
>>>> "PTR" query #2 for "2001:db8:43::192.0.0.171
>>>> 
>>>> Notes
>>>> -----
>>>> The second PTR query should be for the reverse of the DNS64 mapped well known address 192.0.0.171.  This looks like a cut-and-paste error where 170 was not changed to 171.
>>>> 
>>>> 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. 
>>>> 
>>>> --------------------------------------
>>>> RFC7050 (draft-ietf-behave-nat64-discovery-heuristic-17)
>>>> --------------------------------------
>>>> Title               : Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
>>>> Publication Date    : November 2013
>>>> Author(s)           : T. Savolainen, J. Korhonen, D. Wing
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Behavior Engineering for Hindrance Avoidance
>>>> Area                : Transport
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>> 
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> 
>> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org