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

Dan Wing <dan@danwing.org> Fri, 18 September 2020 01:45 UTC

Return-Path: <dan@danwing.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 94F223A0913 for <behave@ietfa.amsl.com>; Thu, 17 Sep 2020 18:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FRiBSv2xEHYW for <behave@ietfa.amsl.com>; Thu, 17 Sep 2020 18:45:31 -0700 (PDT)
Received: from rincewind.ksquared.net (rincewind.ksquared.net [65.19.169.220]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3740C3A08D7 for <behave@ietf.org>; Thu, 17 Sep 2020 18:45:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by rincewind.ksquared.net (Postfix) with ESMTP id D4DF3CD156; Thu, 17 Sep 2020 18:45:29 -0700 (PDT)
Received: from rincewind.ksquared.net ([127.0.0.1]) by localhost (rincewind.ksquared.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fER+HGiFbK3Y; Thu, 17 Sep 2020 18:45:28 -0700 (PDT)
Received: from [192.168.1.60] (47-208-190-34.trckcmtc01.res.dyn.suddenlink.net [47.208.190.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dwing) by rincewind.ksquared.net (Postfix) with ESMTPSA id F01B7CB27B; Thu, 17 Sep 2020 18:45:27 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Dan Wing <dan@danwing.org>
In-Reply-To: <C9BFCE03-4568-48CF-99E6-17A148554F03@isc.org>
Date: Thu, 17 Sep 2020 18:45:27 -0700
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: <5CE83ABE-FA71-415A-8620-A06EA9539DEE@danwing.org>
References: <20200901025348.AD36AF40771@rfc-editor.org> <E7035A63-CF71-4DBE-AC9C-C551B373863F@gmail.com> <C9BFCE03-4568-48CF-99E6-17A148554F03@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/bQCfuQWpd1vnwLaJ4oF7H0vAgWY>
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 01:45:33 -0000

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
> 
>