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

[Mark Andrews <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]> 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://www.rfc-editor.org/errata/eid6270
>> 
>> --------------------------------------
>> 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
> 

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