RFC Errata
Found 7 records.
Status: Verified (6)
RFC 791, "Internet Protocol", September 1981
Source of RFC: LegacyArea Assignment: int
Errata ID: 716
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Damien Mattei
Date Reported: 2007-01-03
Verifier Name: Ralph Droms
Date Verified: 2010-12-06
Section 3.1 says:
+--------+--------+--------+--------+
|10001000|00000010| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4
It should say:
+--------+--------+--------+--------+
|10001000|00000100| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4
Rationale:
This number count the length which is 4 and not 2.
10 in binary is 2 in decimal, 100 in binary is 4 in decimal.
The option-length octet counts the option-type octet and the
option-length octet as well as the option-data octets.(see page 15)
The length is 4 for the Stream identifier option as we have 4 bytes and
it is well written in page 16 of RFC 791:
The following internet options are defined:
CLASS NUMBER LENGTH DESCRIPTION
----- ------ ------ -----------
0 0 - End of Option list. This option occupies only
1 octet; it has no length octet.
0 1 - No Operation. This option occupies only 1
octet; it has no length octet.
0 2 11 Security. Used to carry Security,
Compartmentation, User Group (TCC), and
Handling Restriction Codes compatible with DOD
requirements.
0 3 var. Loose Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 9 var. Strict Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 7 var. Record Route. Used to trace the route an
internet datagram takes.
0 8 4 Stream ID. Used to carry the stream
identifier.
2 4 var. Internet Timestamp.
Notes:
from pending
Errata ID: 6356
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Ni
Date Reported: 2020-12-15
Verifier Name: Eric Vyncke
Date Verified: 2021-01-04
Section 3.2 says:
(14) THEN TL <- TDL+(IHL*4)
It should say:
(14) THEN TL <- TDL+(IHL-Of-First-Fragment*4)
Notes:
IHL could be different between the first fragment and the rest. Only the first fragment's IHL is the same as the one in the original datagram before fragmentation
--- Verifier note ---
Updated the type of errata to technical from editorial.
Section 3.2 of RFC 791 clearly states that "When fragmentation occurs, some options are copied, but others remain with the first fragment only." so IHL varies from fragment to fragment. Therefore when copying the IP header of the F=0 fragment (step 11) all options are rightfully copied and must be counted in the re-assembled fragment total length on step 14 as noted by Patrick Ni.
Errata ID: 579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pavel Uvarov
Date Reported: 2004-06-16
On page 21, it says:
The intitial contents of the route data area must be zero.
It should say:
The initial contents of the route data area must be zero.
Errata ID: 583
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pavel Uvarov
Date Reported: 2004-06-16
On page 23, it says:
The intitial contents of the timestamp data area must be zero or internet address/zero pairs.
It should say:
The initial contents of the timestamp data area must be zero or internet address/zero pairs.
Notes:
Spelling error.
Errata ID: 5037
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Prabhu K Lokesh
Date Reported: 2017-06-10
Verifier Name: RFC Editor
Date Verified: 2017-06-12
Section GLOSSARY says:
NFB
The Number of Fragment Blocks in a the data portion of an
internet fragment. That is, the length of a portion of data
measured in 8 octet units.
It should say:
NFB
The Number of Fragment Blocks in the data portion of an
internet fragment. That is, the length of a portion of data
measured in 8-octet units.
Notes:
Extra article 'a' before the term 'data portion of an internet fragment'.
Errata ID: 6184
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ye Shu
Date Reported: 2020-05-21
Verifier Name: Erik Kline
Date Verified: 2020-05-21
Section 3.2 says:
fragmentation strategy is designed so than an unfragmented datagram has all zero fragmentation information
It should say:
fragmentation strategy is designed so that an unfragmented datagram has all zero fragmentation information
Notes:
typo: so than => so that
Status: Reported (1)
RFC 791, "Internet Protocol", September 1981
Source of RFC: LegacyArea Assignment: int
Errata ID: 6677
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Øyvind Bolme Fredriksen
Date Reported: 2021-09-06
Section 3.1 says:
Protocol: 8 bits
This field indicates the next level protocol used in the data
portion of the internet datagram. The values for various protocols
are specified in "Assigned Numbers" [9].
It should say:
Protocol: 8 bits
This field indicates the next upper level protocol used in the data
portion of the internet datagram. The values for various protocols
are specified in "Assigned Numbers" [9], section ASSIGNED INTERNET PROTOCOL NUMBERS.
Notes:
The word 'next' is ambiguous in the sense that it does not indicate whether the 'next' protocol is at the next LOWER or UPPER level (referring to Fig. 1). Although it may be obvious to people well versed in this domain that the next UPPER level protocol is meant, as a newcomer I had to think twice to reach at this conclusion.
Also, the reference to [9] could be more specific.