RFC Errata
Found 2 records.
Status: Held for Document Update (1)
RFC 6147, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", April 2011
Source of RFC: behave (tsv)
Errata ID: 2975
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Libor Polcak
Date Reported: 2011-09-18
Held for Document Update by: Wes Eddy
Section 5.1.4 says:
An implementation SHOULD include the ::ffff/96 network in that range by default.
It should say:
An implementation SHOULD include the ::ffff:0:0/96 network in that range by default.
Status: Rejected (1)
RFC 6147, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", April 2011
Source of RFC: behave (tsv)
Errata ID: 3236
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2012-05-30
Rejected by: Wes Eddy
Date Rejected: 2012-09-13
Section 5.5 says:
An application that wants to perform validation on its own should use the CD bit.
It should say:
[Section 5.5 needs to be completely re analysed,]
Notes:
Section 5.5 is written around the assumption that a validating stub resolver will be setting CD=1 as well as DO=1. There is no such requirement RFC 4035 and in fact setting both CD=1 and DO=1 leaves the stub resolver vulnerable to answers from authoritative servers for the zone that are serving a stale copy of the zone and spoofed answers being sent to the DNS64 server.
Non CD=1 queries result in the DNS64 server in its recursive roll, filtering out, cryptographically bad answers.
DO=1 alone should disable synthesis.
--VERIFIER NOTES--
http://www.ietf.org/iesg/statement/errata-processing.html
says:
Changes that are clearly modifications to the intended consensus, or
involve large textual changes, should be Rejected.