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

Dan Wing <dan@danwing.org> Thu, 17 September 2020 16:18 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 DF0213A0D6C for <behave@ietfa.amsl.com>; Thu, 17 Sep 2020 09:18:44 -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 ASbCrFQ7G-Et for <behave@ietfa.amsl.com>; Thu, 17 Sep 2020 09:18:42 -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 6CE033A0D4B for <behave@ietf.org>; Thu, 17 Sep 2020 09:18:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by rincewind.ksquared.net (Postfix) with ESMTP id 003C2CEBB8; Thu, 17 Sep 2020 09:18:42 -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 rPw+sGwPiv+Y; Thu, 17 Sep 2020 09:18:40 -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 05432CEAC6; Thu, 17 Sep 2020 09:18:39 -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: <5E1F59B5-6EEE-40F6-BB08-71517BC07FD3@isc.org>
Date: Thu, 17 Sep 2020 09:18:39 -0700
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "teemu.savolainen@nokia.com" <teemu.savolainen@nokia.com>, "dwing@cisco.com" <dwing@cisco.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, "dwing-ietf@fuggles.com" <dwing-ietf@fuggles.com>, Dave Thaler <dthaler@microsoft.com>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "behave@ietf.org" <behave@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CBF125A-354F-4013-A1A0-630EBB07EC50@danwing.org>
References: <20200901025348.AD36AF40771@rfc-editor.org> <fee7be373013243976d0dac30cf4f62db6d69fc1.camel@ericsson.com> <5E1F59B5-6EEE-40F6-BB08-71517BC07FD3@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/55Q6clAsN1fHdk1TMilfuXDRjbc>
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: Thu, 17 Sep 2020 16:18:45 -0000

But RFC7050 does not expect or require the DNS64 server to return two AAAA's in response to a single query.  If that is necessary, we need a revision to the document.

Appendix B of RFC7050 explains the benefit of two well-known IPv4 addresses to distinguish an NSP that matches one of those IPv4 addresses.  But the client is expected to query those separately.

-d


> On Sep 16, 2020, at 8:06 PM, Mark Andrews <marka@isc.org> wrote:
> 
> 
> 
>> On 16 Sep 2020, at 22:45, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>> 
>> Hi Mark and Authors,
>> 
>> 
>> I think this errata may be due to a missinterpretation of the example. 
>> 
>> Mark did you interpret that the second AAAA synthesised respond should be for
>> the second IPv4 address from the "A" response?
> 
> Yes.
> 
>> My interpretation is that the
>> DNS64 server has chosen to provide two different synthesized AAAA responses, one
>> for each of its Network Specific Prefix (NSP) for the first IPv4 address. 
> 
> If there are two prefixes then there should be 4 AAAA addresses returned, a pair for
> each prefix.  DNS64 prefix discovery requires that two AAAA address be returned for
> each prefix.  A DNS64 implementation that does not do that is broken.
> 
> To discover a prefix you need to be able to find a pair of AAAA records that match
> the first two entries in the table below when the given mask (3rd entry) is applied.
> The prefix length of the found prefix is the 4th entry.  The MBZ octet is enforced.
> 
> 	{ { 0, 0, 0, 0, 192, 0, 0, 170, 0, 0, 0, 0, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 192, 0, 0, 171, 0, 0, 0, 0, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 255, 255, 255, 255, 255, 0, 0, 0, 0, 0, 0, 0 },
> 	  32 },
> 	{ { 0, 0, 0, 0, 0, 192, 0, 0, 0, 170, 0, 0, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 192, 0, 0, 0, 171, 0, 0, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 255, 255, 255, 255, 255, 0, 0, 0, 0, 0, 0 },
> 	  40 },
> 	{ { 0, 0, 0, 0, 0, 0, 192, 0, 0, 0, 170, 0, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 0, 192, 0, 0, 0, 171, 0, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 0, 255, 255, 255, 255, 255, 0, 0, 0, 0, 0 },
> 	  48 },
> 	{ { 0, 0, 0, 0, 0, 0, 0, 192, 0, 0, 0, 170, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 0, 0, 192, 0, 0, 0, 171, 0, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 0, 0, 255, 255, 255, 255, 255, 0, 0, 0, 0 },
> 	  56 },
> 	{ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 192, 0, 0, 170, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 0, 0, 0, 0, 192, 0, 0, 171, 0, 0, 0 },
> 	  { 0, 0, 0, 0, 0, 0, 0, 0, 255, 255, 255, 255, 255, 0, 0, 0 },
> 	  64 },
> 	{ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 192, 0, 0, 170 },
> 	  { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 192, 0, 0, 171 },
> 	  { 0, 0, 0, 0, 0, 0, 0, 0, 255, 0, 0, 0, 255, 255, 255, 255 },
> 	  96 }
> 
> Without 2 AAAA records you can’t distinguish between 2000:0000:c000:00aa::/32
> and 2000:0000:c000:00aa:0000:0000::/96 in 2000:0000:c000:00aa:0000:0000:c000:00aa
> because it is perfectly legal to add a suffix of 0000:0000:c000:00aa to the /32
> prefix.  Before you say there are no DNS64 servers that support doing this BIND
> does.  Hopefully I’ve constructed the example correctly to show why 2 AAAA per
> prefix is a MUST.
> 
> There is no "The DNS64 server could also return synthetic addresses containing
> the IPv4 address 192.0.0.171.”
> 
> Mark
> 
>> Please review this and if necessary clarify the argument for what is wrong in
>> this example.
>> 
>> 
>> 
>>   Node                                           DNS64 server
>>     |          
>>                                     |
>>     |  "AAAA" query for
>> "ipv4only.arpa."             |
>>     |-------------------------------------------
>> ---->|"A" query for
>>     |                                                |"ipv4
>> only.arpa."
>>     |                                                |-------------
>> -->
>>     |                                                |
>>     |              
>>                                 | "A" response:
>>     |                        
>>                       | "192.0.0.170"
>>     |                                  
>>             | "192.0.0.171"
>>     |                                            
>>   |<---------------
>>     |                                +-------------------
>> ---------+
>>     |                                | "AAAA" synthesis using     |
>> 
>>    |                                | three Pref64::/n.          |
>>     |     
>>                          +----------------------------+
>>     |  "AAAA"
>> response with:                         |
>>     |  "2001:db8:42::192.0.0.170"     
>>              |
>>     |  "2001:db8:43::192.0.0.170"                    |
>>     | 
>> "64:ff9b::192.0.0.170"                        |
>>     |<----------------------
>> -------------------------|
>>     |                                               
>> |
>>  +----------------------------------------------+    |
>>  | If Pref64::/n
>> validation is not performed, a |    |
>>  | node can fetch prefixes from AAAA
>> responses  |    |
>>  | at this point and skip the steps below.      |    |
>>  +---
>> -------------------------------------------+    |
>>     |                        
>>                       |
>>     |  "PTR" query #1 for
>> "2001:db8:42::192.0.0.170  |
>>     |---------------------------------------------
>> -->|
>>     |  "PTR" query #2 for "2001:db8:43::192.0.0.170  |
>>     |-------------
>> ---------------------------------->|
>> 
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> On Mon, 2020-08-31 at 19:53 -0700, RFC Errata System 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://protect2.fireeye.com/v1/url?k=e308ec2d-bda82f84-e308acb6-86959e472243-426efe53988d5301&q=1&e=fd4e0ad5-a48f-4d30-8722-a34c5c3b9c79&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6270
>>> 
>>> --------------------------------------
>>> 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
>> -- 
>> Cheers
>> 
>> Magnus Westerlund 
>> 
>> 
>> ----------------------------------------------------------------------
>> Networks, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Mobile +46 73 0949079
>> Torshamnsgatan 23           |
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org