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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Sep 2020 12:45:22 +0000

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

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 <[email-masked]>
> 
> 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: [email-masked]
----------------------------------------------------------------------

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Sep 2020 13:06:08 +1000

> On 16 Sep 2020, at 22:45, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Mark and Authors,
> 
> 
> the second IPv4 address from the "A" response?

Yes.

> My interpretation is that the

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Thu, 17 Sep 2020 09:18:39 -0700

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 <[email-masked]> wrote:
> 
> 
>

---

From: Jouni <[email-masked]>
Date: Thu, 17 Sep 2020 22:50:28 +0300

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 <[email-masked]> wrote:
> 
> https://www.rfc-editor.org/errata/eid6270
> 
> 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:
> -------------
> Title               : Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Sep 2020 11:17:44 +1000

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 <[email-masked]> wrote:
>

---

From: Dan Wing <[email-masked]>
Date: Thu, 17 Sep 2020 18:45:27 -0700

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 <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Sep 2020 12:07:37 +1000

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 <[email-masked]> wrote:
>