RFC Errata
Found 13 records.
Status: Verified (6)
RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989
Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293
Source of RFC: LegacyArea Assignment: int
Errata ID: 559
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Grzegorz R. Gryczka
Date Reported: 2002-10-19
Section 1.1.3 incorrectly implies that all support protocols are at the Application layer. In particular, it mentions that support protocol RARP (Reverse ARP), which is not an application-layer protocol.
Errata ID: 618
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Braden
Date Reported: 2007-10-25
Verifier Name: Bob Braden
Date Verified: 2007-11-12
Section 4.2.5 says:
OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x| Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | |
It should say:
OPEN to broadcast/multicast IP Address |4.2.3.10| | | | |x| Silently discard seg to bcast/mcast addr |4.2.3.10|x| | | | |
Errata ID: 4446
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marek Perny
Date Reported: 2015-08-16
Verifier Name: RFC Editor
Date Verified: 2015-08-18
Section 1.1.1 says:
A host is generally said to be multihomed if it has more than
one interface to the same or to different networks. See
Section 1.1.3 on "Terminology".
It should say:
A host is generally said to be multihomed if it has more than
one interface to the same or to different networks. See
Section 1.3.3 on "Terminology".
Notes:
"Section 1.1.3" should be "Section 1.3.3".
Errata ID: 6468
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10
Section 3.3.1.4 says:
acknowleged data must have been transmitted
It should say:
acknowledged data must have been transmitted
Notes:
Misspelled "acknowledged".
Errata ID: 6469
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10
Section 4.1.3.5 says:
application layer (e.g, so that the application can later
It should say:
application layer (e.g., so that the application can later
Notes:
Missing full stop.
Errata ID: 6470
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10
Section 4.2.3.4 says:
(1) if a maximum-sized segment can be sent, i.e, if:
It should say:
(1) if a maximum-sized segment can be sent, i.e., if:
Notes:
Missing full stop.
Status: Held for Document Update (6)
RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989
Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293
Source of RFC: LegacyArea Assignment: int
Errata ID: 1740
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hannes Hennig
Date Reported: 2009-03-24
Held for Document Update by: Brian Haberman
Section 2.5 says:
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--
It should say:
| | | | |S| |
| | | | |H| |
| | | | |O|M|F
| | |S| |U|U|o
| | |H| |L|S|o
| |M|O| |D|T|t
| |U|U|M| | |n
| |S|L|A|N|N|o
| |T|D|Y|O|O|t
FEATURE |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--
Same on section 3.5 and 4.2.5.
Notes:
Footnote instead of "Footnotte" in eighth column.
Errata ID: 1936
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-30
Held for Document Update by: Brian Haberman
Section 4.2.3.5 says:
(d) TCP SHOULD inform the application of the delivery
problem (unless such information has been disabled by
the application; see Section 4.2.4.1), when R1 is
reached and before R2. This will allow a remote login
(User Telnet) application program to inform the user,
for example.
It should say:
(e) TCP SHOULD inform the application of the delivery
problem (unless such information has been disabled by
the application; see Section 4.2.4.1), when R1 is
reached and before R2. This will allow a remote login
(User Telnet) application program to inform the user,
for example.
Notes:
The paragraph numbering got out of sequence. Letter (d) was used twice.
Errata ID: 4464
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Welzl
Date Reported: 2015-09-04
Held for Document Update by: Brian Haberman
Date Held: 2015-09-14
Section 4.2.4.2 says:
It not required, but the application SHOULD be able to
change the TOS during the connection lifetime. TCP SHOULD
It should say:
It is not required, but the application SHOULD be able to
change the TOS during the connection lifetime. TCP SHOULD
Notes:
just a typo (missing "is" as second word)
Errata ID: 4778
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sanjeev Ranot
Date Reported: 2016-08-18
Held for Document Update by: Martin Duke
Date Held: 2021-01-08
Section 4.2.3.4 says:
(3) or if at least a fraction Fs of the maximum window
can be sent, i.e., if:
[SND.NXT = SND.UNA and]
min(D.U) >= Fs * Max(SND.WND);
It should say:
(3) or if at least a fraction Fs of the maximum window
can be sent, i.e., if:
[SND.NXT = SND.UNA and]
min(D,U) >= Fs * Max(SND.WND);
Notes:
correct min(D.U) to min(D,U)
Errata ID: 5033
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Gray
Date Reported: 2017-06-08
Held for Document Update by: Eric Vyncke
Date Held: 2024-01-12
Section 2.3.2 says:
Section 2.3.2, and subsections 2.3.2.1 and 2.3.2.2, do not belong where they are in this RFC.
It should say:
Move the text in this section either under section 2.4, or in section 3.
Notes:
ARP is a protocol used by Internet devices for the purpose of mapping Internet Addresses to MAC addresses. Link layer devices and associated protocols will only support and/or use ARP to the extent that they are also Internet devices (for example if participating in management protocols developed to operate between IP addressed devices).
Hence referring to ARP as a Link Layer Protocol will only continue to confuse the industry.
Because the number of references to ARP refering to Link.2, perhaps it would be easiest to move the text to section 2.4, adding a new subsection header 2.4.1 for the text currently in section 2.4, and renumbering current section 2.3.2 to 2.4.2 (as well as renumbering subsections 2.3.2.1 and 2.3.2.2 to 2.4.2.1 and 2.4.2.2, respectively).
Refering to ARP as a part of the Link/Internet Layer Interface is more accurate.
-- Verifier Note (EV) --
The erratum is correct, i.e., ARP is not a layer-2 protocol. The erratum reflects more the modern thinking though of ARP position in the OSI stack and does not impact the protocol itself.
Therefore, the status if "held for document update" even of RFC 1122 will probably never be updated in the world of NDP and IPv6.
Errata ID: 7507
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonio Cota
Date Reported: 2023-05-04
Held for Document Update by: Eric Vyncke
Date Held: 2023-08-03
Section 1.2 says:
There are two important lessons that vendors of Internet host software have learned and which a new vendor should consider seriously.
It should say:
There are four important lessons that vendors of Internet host software have learned and which a new vendor should consider seriously.
Notes:
I'm suggesting to replace "two" with "four" because below the 1.2 section there are 4 subsections (1.2.1, 1.2.2, 1.2.3 and 1.2.4) which lead to think that there are 4 "important lessons".
Status: Rejected (1)
RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989
Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293
Source of RFC: LegacyArea Assignment: int
Errata ID: 6381
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Ni
Date Reported: 2021-01-07
Rejected by: Martin Duke
Date Rejected: 2021-01-08
Section 4.2.2.6 says:
Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
It should say:
Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize
Notes:
In Section 3.3.3 Fragmentation: MMS_S = EMTU_S - <IP header size> .... Note that <IP header size> in this equation will be 20, unless the IP reserves space to insert IP options for its own purposes in addition to any options inserted by the transport layer
IPoptionsize was already subtracted once when calculating MMS_S. It is being subtracted again upon calculating Eff.snd.MSS when MMS_S is smaller than sendMSS+20. In other words, if IP options are in use, its size is subtracted twice.
--VERIFIER NOTES--
In Section 3.3.3, it says "Note that <IP header size> in this equation will be 20, unless
the IP reserves space to insert IP options for its own purposes
in addition to any options inserted by the transport layer."
4.2.2.6 defines IPoptionsize as "IPoptionsize is the size of any IP options that TCP
will pass to the IP layer with the current message."
So MMS_S incorporates IP options from the IP layer, but IPoptionsize counts options coming from TCP. The terminology is a little confusing but careful reading of the definitions indicates that the math is correct.