RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 19 records.

Status: Verified (8)

RFC 791, "Internet Protocol", September 1981

Note: This RFC has been updated by RFC 1349, RFC 2474, RFC 6864

Source of RFC: Legacy
Area 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

Errata ID: 7561
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Fernando Gont
Date Reported: 2023-07-10
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 3.2 says:

  Identification

    The choice of the Identifier for a datagram is based on the need to
    provide a way to uniquely identify the fragments of a particular
    datagram.  The protocol module assembling fragments judges fragments
    to belong to the same datagram if they have the same source,
    destination, protocol, and Identifier.  Thus, the sender must choose
    the Identifier to be unique for this source, destination pair and
    protocol for the time the datagram (or any fragment of it) could be
    alive in the internet.

    It seems then that a sending protocol module needs to keep a table
    of Identifiers, one entry for each destination it has communicated
    with in the last maximum packet lifetime for the internet.

    However, since the Identifier field allows 65,536 different values,
    some host may be able to simply use unique identifiers independent
    of destination.

It should say:

  Identification

    The choice of the Identification for a datagram is based on the need to
    provide a way to uniquely identify the fragments of a particular
    datagram.  The protocol module assembling fragments judges fragments
    to belong to the same datagram if they have the same source,
    destination, protocol, and Identification.  Thus, the sender must choose
    the Identification to be unique for this source, destination pair and
    protocol for the time the datagram (or any fragment of it) could be
    alive in the internet.

    It seems then that a sending protocol module needs to keep a table
    of Identification values, one entry for each destination it has communicated
    with in the last maximum packet lifetime for the internet.

    However, since the Identification field allows 65,536 different values,
    some host may be able to simply use unique identifiers independent
    of destination.

Notes:

The field is called "Identification", and not "Identifier" (please note the capitalization in the text).

Errata ID: 7560
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Simon Günther
Date Reported: 2023-07-04
Verifier Name: RFC Editor
Date Verified: 2023-07-06

Section 3.1, Line 904 says:

Bits   5:  0 = Normal Relibility, 1 = High Relibility.

It should say:

Bits   5:  0 = Normal Reliability, 1 = High Reliability.

Notes:

Typo

Status: Held for Document Update (8)

RFC 791, "Internet Protocol", September 1981

Note: This RFC has been updated by RFC 1349, RFC 2474, RFC 6864

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4752
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Markus Klemm
Date Reported: 2016-07-29
Held for Document Update by: Terry Manderson
Date Held: 2017-03-01

Section 3.1. says:

The Option Length is the number of octets 
in the option counting the type, length, 
pointer, and overflow/flag octets (maximum length 40).

It should say:

The Option Length is the number of octets 
in the option counting the type, length, 
pointer, overflow/flag octets 
and timestamp area (maximum length 40).

Notes:

The original version implies that the length is only the sum of the constant fields, in this case, 4. This is in conflict with
A) All prior statements that the length is variable
B) The pointer with it >=5 constraint, implies the timestamp area is always full, which is the case when pointer > length
C) Any need to know how much timestamps will follow

Errata ID: 578
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Yin Shuming
Date Reported: 2006-02-18
Held for Document Update by: ron bonica

Section 3.2 says:

Note that this is consistent with the the datagram total length field (of 
course, the header is counted in the total length and not in the 
fragments).

It should say:

Note that this is consistent with the datagram total length field (of 
course, the header is counted in the total length and not in the 
fragments).

Errata ID: 2295
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: ron bonica

Section Page 27 says:

For example, one could implement
a fragmentation procedure that repeatly divided large datagrams in
half until the resulting fragments were less than the maximum
transmission unit size.

It should say:

For example, one could implement
a fragmentation procedure that repeatedly divided large datagrams in
half until the resulting fragments were less than the maximum
transmission unit size.

Notes:

s/ repeatly/repeatedly/

Errata ID: 2294
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: ron bonica

Section Page 21 says:

If it is, it inserts its
own internet address as known in the environment into which this
datagram is being forwarded into the recorded route begining at
the octet indicated by the pointer, and increments the pointer
by four.

It should say:

If it is, it inserts its
own internet address as known in the environment into which this
datagram is being forwarded into the recorded route beginning at
the octet indicated by the pointer, and increments the pointer
by four.

Notes:

s/begining/beginning/g

Errata ID: 2519
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Yaakov (J) Stein
Date Reported: 2010-09-14
Held for Document Update by: ron bonica

Section 3.1 says:

Total Length is the length of the datagram, measured in octets,
including internet header and data.  

It should say:

Total Length is the length of the datagram or fragment, measured in octets,
including internet header and data.  

Notes:

Section 2.3 makes it clear that during fragmentation the total length field is corrected to the length of the fragment. Wording such as "break a datagram into an almost arbitrary number of pieces" implies that "datagram" means the entire original packet. Thus, without the proposed correction, one may be led to believe that the total length contains the length of the original datagram.

Errata ID: 3074
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: ChengYan Wang
Date Reported: 2012-01-04
Held for Document Update by: Brian Haberman

Section 3.1 Page 12 says:

Bits   5:  0 = Normal Relibility, 1 = High Relibility.

It should say:

Bits   5:  0 = Normal Reliability, 1 = High Reliability.

Notes:

Spelling error.

Errata ID: 4126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Federico do Pino
Date Reported: 2014-10-04
Held for Document Update by: Brian Haberman
Date Held: 2014-10-21

Section 2.3 says:

    If internet datagram marked don't fragment cannot be
    delivered to its destination without fragmenting it, it is to be
    discarded instead.

It should say:

    If an internet datagram marked don't fragment cannot be
    delivered to its destination without fragmenting it, it is to be
    discarded instead.

Notes:

Grammar mistake.

Errata ID: 5679
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Greg Skinner
Date Reported: 2019-03-30
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-04-03

Section 3.1 says:

The time is measured in units of seconds, but since every module that
processes a datagram must decrease the TTL by at least one even if it
process the datagram in less than a second, the TTL must be thought of
only as an upper bound on the time a datagram may exist.

It should say:

The time is measured in units of seconds, but since every module that
processes a datagram must decrease the TTL by at least one even if it
processes the datagram in less than a second, the TTL must be thought
of only as an upper bound on the time a datagram may exist.

Notes:

Grammar mistake (s/process/processes)

Status: Rejected (3)

RFC 791, "Internet Protocol", September 1981

Note: This RFC has been updated by RFC 1349, RFC 2474, RFC 6864

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3874
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Bo-Jhang Ho
Date Reported: 2014-01-23
Rejected by: Ted Lemon
Date Rejected: 2014-05-01

Section 3 says:

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

It should say:

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 516 octets plus 60 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

Notes:

It is not consistent that it first give an example which illustrates the header is 64 octets, but then explains the maximum header size is 60 octets.
--VERIFIER NOTES--
I believe that the discrepancy you are seeing is because in the one case the text is referring to the set of all headers, and in the other case it's referring to the IP header alone. The IP header does have a maximum size of 60 octets, but for example an IP header plus a UDP header would be 28 octets, and IP+TCP would be 40 octets, plus a timestamp header in current practice. Notice the "for example" at the beginning of the sentence that mentions 64 header octets.

Errata ID: 5038
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Prabhu K Lokesh
Date Reported: 2017-06-10
Rejected by: Suresh Krishnan
Date Rejected: 2020-03-25

Section 3.1 says:

The option begins with the option type code.  The second octet
        is the option length which includes the option type code and the
        length octet, the pointer octet, and length-3 octets of route
        data.

It should say:

The option begins with the option type code.  The second octet
        is the option length, measured in octets, including the option 
        type code octet, the length octet, the pointer octet, and the
        octets of route data.

Notes:

The way the second octet is defined, although readable to majority of the audience with no concern, will incorrectly equate to:
length = 'option type code octet' + 'length octet + 'pointer octet' + length - 3 octet of route data

So, what is the value of 'length' in 'length - 3'; when reader encounters 'length - 3', the term 'length' itself is not completely defined. Using the term 'length - 3' to define the term 'length' may not be very appropriate.

For better readability, we can simply write -
The second octet is the option length, measured in octets, including the option type code octet, the length octet, the pointer octet, and the octets of route data.

The same correction applies to the following sections -
3.1. Internet Header Format > Loose Source and Record Route
3.1. Internet Header Format > Strict Source and Record Route
3.1. Internet Header Format > Record Route
--VERIFIER NOTES--
While the text can be simplified as the submitter of the Erratum implies, the current text has been in use for close to 4 decades without any interoperability issues rising out of it. Hence this

Errata ID: 6677
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Øyvind Bolme Fredriksen
Date Reported: 2021-09-06
Rejected by: Erik Kline
Date Rejected: 2023-06-10

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.
--VERIFIER NOTES--
The description of the Protocol field states that it refers to the protocol "used in the data portion of the internet datagram". In the context of Figure 1, this cannot refer to a lower layer protocol.

Report New Errata



Advanced Search