RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search