RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 6555, "Happy Eyeballs: Success with Dual-Stack Hosts", April 2012

Note: This RFC has been obsoleted by RFC 8305

Source of RFC: v6ops (ops)

Errata ID: 3502
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elle Plato
Date Reported: 2013-02-27
Verifier Name: Benoit Claise
Date Verified: 2013-03-10

Section 6 says: 

   1.  Call getaddinfo(), which returns a list of IP addresses sorted by
       the host's address preference policy.

It should say:

   1.  Call getaddrinfo(), which returns a list of IP addresses sorted by
       the host's address preference policy.

Notes:

The r appears to be missing from the getaddrinfo() call. This may vary by language but C, POSIX and Perl seem to expect the r. I would think this is a trivial change, and would fall into the category of "Hold for Document Update".

Errata ID: 4728
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Winter
Date Reported: 2016-07-05
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 1 says: 

However, this does not scale well (to the number of DNS servers
worldwide or the number of content providers worldwide) and does
react to intermittent network path outages.

It should say:

However, this does not scale well (to the number of DNS servers
worldwide or the number of content providers worldwide) and does
not react to intermittent network path outages.

Notes:

The introduction makes a case against a whitelist of DNS servers because it does not scale well and is not flexible.
DNS server whitelists indeed to not react to intermittent network outages, so the only logical sentence to form is to state that they do not.
The "not" has been omitted, reversing the logical meaning of the sentence.

Status: Rejected (1)

RFC 6555, "Happy Eyeballs: Success with Dual-Stack Hosts", April 2012

Note: This RFC has been obsoleted by RFC 8305

Source of RFC: v6ops (ops)

Errata ID: 6745
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Menke
Date Reported: 2021-11-19
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2024-01-15

Section 5.6 says: 

   Web browsers implement a same-origin policy [RFC6454] that causes
   subsequent connections to the same hostname to go to the same IPv4
   (or IPv6) address as the previous successful connection.  This is
   done to prevent certain types of attacks.

   The same-origin policy harms user-visible responsiveness if a new
   connection fails (e.g., due to a transient event such as router
   failure or load-balancer failure).  While it is tempting to use Happy
   Eyeballs to maintain responsiveness, web browsers MUST NOT change
   their same-origin policy because of Happy Eyeballs, as that would
   create an additional security exposure.

It should say:

<This section should be removed>

Notes:

This entire section should be deleted. Same-Origin policy has nothing to do with what IP connections to the same hostname go to. Two connections to the same host are same origin even if they're using different IPs. Happy Eyeballs is free to use whatever IP for a hostname it wants for an origin, and Same-Origin policy will not be violated.


[ Edit (WK) ]: I am rejecting this Errata because this RFC has been Obsoleted by RFC8305 - "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", which does not contain this text.
--VERIFIER NOTES--

Report New Errata



Advanced Search