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

[Mark Andrews <[e-mail]>]

> On 16 Sep 2020, at 22:45, Magnus Westerlund <[e-mail]> 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 <[e-mail]>
>> 
>> 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 [phone]
> Torshamnsgatan 23           |
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]