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

[Dan Wing <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
>> 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]