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

Mark Andrews <marka@isc.org> Thu, 17 September 2020 03:06 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 96D113A0DE6 for <behave@ietfa.amsl.com>; Wed, 16 Sep 2020 20:06:21 -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 7wnTjB_eAlfs for <behave@ietfa.amsl.com>; Wed, 16 Sep 2020 20:06:18 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 5D02F3A0DE1 for <behave@ietf.org>; Wed, 16 Sep 2020 20:06:18 -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 5A1353AB26C; Thu, 17 Sep 2020 03:06:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3F0A516003E; Thu, 17 Sep 2020 03:06:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 21BA516006D; Thu, 17 Sep 2020 03:06:15 +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 mixZ3AuvOYBE; Thu, 17 Sep 2020 03:06:15 +0000 (UTC)
Received: from [172.30.42.67] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 10AC016003E; Thu, 17 Sep 2020 03:06:12 +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: <fee7be373013243976d0dac30cf4f62db6d69fc1.camel@ericsson.com>
Date: Thu, 17 Sep 2020 13:06:08 +1000
Cc: "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>, "dthaler@microsoft.com" <dthaler@microsoft.com>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "behave@ietf.org" <behave@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E1F59B5-6EEE-40F6-BB08-71517BC07FD3@isc.org>
References: <20200901025348.AD36AF40771@rfc-editor.org> <fee7be373013243976d0dac30cf4f62db6d69fc1.camel@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/jcTgf10FxOh_ksleXOICma7YaFs>
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 03:06:22 -0000


> 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