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

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the discussion on this errata. Although some possible
improvements to the specification on certain aspects that could be done if a
replacement specification would be developed.

However, looking at the errata I do agree with Dan and Jouni that the example is
not in conflict with what the RFC specifies when it comes to procedure. Thus, I
am rejecting it. 

Cheers

Magnus Westerlund


On Fri, 2020-09-18 at 12:07 +1000, Mark Andrews wrote:
> 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 <[e-mail]> wrote:
> > 
> > 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 <[e-mail]> wrote:
> > > 
> > > 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://protect2.fireeye.com/v1/url?k=2e6171b8-70c1b3fd-2e613123-8692dc8284cb-d73a39e62ff1e92d&q=1&e=4af65926-372f-48ef-b5ac-d63abee92eab&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
> > > 
> > > -- 
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: [phone]              INTERNET: [e-mail]
> > > 
> > > 
> 
>