RFC Errata
Found 5 records.
Status: Held for Document Update (4)
RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", December 1998
Note: This RFC has been obsoleted by RFC 8200
Note: This RFC has been updated by RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112
Source of RFC: ipngwg (int)
Errata ID: 2541
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2010-10-03
Held for Document Update by: Ralph Droms
Section 6 says:
(Nothing about this omission.)
It should say:
Compared to RFC 1883, this specification reduces the size of the flow label field to 20 bits. The references to a 24 bit flow label field on pages 87 and 88 of RFC 2205 are updated accordingly.
Notes:
RFC 2460 updates RFC 2205.
Errata ID: 4279
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2015-02-24
Held for Document Update by: Brian Haberman
Date Held: 2015-03-09
Section 3 says:
Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero.
It should say:
TBD
Notes:
The original text overlooks the case that a node receives a packet which already has a hop limit of zero (eg, coming from a misbehaving node, or malicious traffic). Following the instructions in that case would result in decrementing the hop limit from 0 to -1 (so, 255), then forwarding the packet.
The text also doesn't state what a non-forwarding node (ie, a host) should do upon reception of a packet which already has a hop limit of zero: should the packet be accepted or dropped?
* While the above issues are worth discussing, they are beyond the scope of an erratum. Discussion on updating the text to handle Hop Limits from malicious or misbehaving nodes should be taken up within the working group. *
Errata ID: 4657
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2016-04-07
Held for Document Update by: Suresh Krishnan
Date Held: 2017-01-29
Section 4 says:
It should say:
Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473].
Notes:
This is being handled in the 2460bis work.
Errata ID: 4662
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2016-04-11
Held for Document Update by: Suresh Krishnan
Date Held: 2017-01-29
Section 4 says:
With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
It should say:
With one exception, extension headers are not examined, processed, modified, inserted or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
Notes:
This is being handled in the 2460bis work.
Status: Rejected (1)
RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", December 1998
Note: This RFC has been obsoleted by RFC 8200
Note: This RFC has been updated by RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC 6935, RFC 6946, RFC 7045, RFC 7112
Source of RFC: ipngwg (int)
Errata ID: 2843
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2011-06-24
Rejected by: Brian Haberman
Date Rejected: 2012-06-01
Section 5 says:
In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used.
It should say:
(delete paragraph)
Notes:
This requirement makes it impossible to offer services over IPv6 without keeping per-flow state in the server node. There is no reason why IPv4 fragmentation cannot be used after translation to IPv4.
--VERIFIER NOTES--
This would be a fundamental change to the IPv6 protocol specification. Such a proposal would need to be formally proposed as an internet draft.