RFC Errata
Found 6 records.
Status: Reported (1)
RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006
Note: This RFC has been updated by RFC 4884
Source of RFC: ipv6 (int)
Errata ID: 6153
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Töma Gavrichenkov
Date Reported: 2020-05-01
Section 3.1 says:
3.1. Destination Unreachable Message [..] If the reason for the failure to deliver is that the destination is beyond the scope of the source address, the Code field is set to 2. This condition can occur only when the scope of the source address is smaller than the scope of the destination address (e.g., when a packet has a link-local source address and a global-scope destination address) and the packet cannot be delivered to the destination without leaving the scope of the source address.
It should say:
3.1. Destination Unreachable Message
[..]
If the reason for the failure to deliver is that the destination is
beyond the scope zone of the source address, the Code field is set to
2. The scope zone of the destination address is determined by the
scope of the address and arrival interface of the packet, as specified
in [IPv6-SCOPE, Section 9]. Similarly, the scope zone of the source
address is determined by the scope of the address and arrival
interface of the packet. This condition can occur only when
transmitting the packet on the chosen next-hop interface would cause
the packet to leave the zone of the source address, i.e., cross a zone
boundary of the scope of the source address.
7.1. Normative References
[..]
[IPv6-SCOPE] Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
and B. Zill, "IPv6 Scoped Address Architecture", RFC
4007, March 2005.
Notes:
https://tools.ietf.org/html/rfc4007#section-9
Scope zone is not scope.
Consider a case when the source IP is link-local and the destination is global, yet the routing happens in the same VLAN. Per RFC 4007, the packet should be transmitted; however, RFC 4443 allows for an ambiguity which is already causing vendors to reject packets in this case.
Status: Held for Document Update (4)
RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006
Note: This RFC has been updated by RFC 4884
Source of RFC: ipv6 (int)
Errata ID: 88
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-04-19
Held for Document Update by: Brian Haberman
(1) text omission ???
I suspect that something went wrong in the publication process
for RFC 4443, leading to significant text omission.
Symptoms:
o Text on top of page 5 apparently *continues* specifications
that are not in the published text;
o Appendix A contains the change item:
- Added specification that all ICMP error messages shall have exactly
32 bits of type-specific data, so that receivers can reliably find
the embedded invoking packet even when they don't recognize the
ICMP message Type.
I could not find any text in the body of the RFC corresponding
to this statement.
Therefore, I suspect that general specifications for ICMPv6 error
messages have been dropped inadvertently from the end of Section
2.1, at the bottom of page 4 in the published text, or that even
a subsection dealing with the peculiar requirements for ICMPv6
error messages has been dropped, just leaving in the published text
the single sentence at top of page 5.
I expect the missing text to depict the general structure of the
Message Body of ICMPv6 error messages with all related explanations,
according to the above mentioned change note.
Appendix A also states:
- Removed the general packet format from Section 2.1. It refers to
Sections 3 and 4 for packet formats now.
This is not literally true. The general format *is* in Section 2.1.
But in fact, it would be logical to have the (missing) specifications
for error messages -- including the 4 lines of test on top of page 5 --
incorporated into (the start of) Section 3 (*before* the heading for
Section 3.1.) instead of the end of Section 2.1.
(2) possible textual improvement
in the lower third of page 3, Section 2.1 says:
The code field depends on the message type. It is used to create an
additional level of message granularity.
It should perhaps better say:
The code field depends on the message type. It is used to create an
additional level of message type granularity.
^^^^^^
(3) reference to old IPsec Architecture document
Section 5.1, at the bottom of page 15, has been updated to point
to the new IPsec Architecture document, RFC 4301, via the reference
tag [SEC-ARCH]. But immediately below, in the first paragraph of
Section 5.2, on top of page 16, the RFC text says:
ICMP messages may be subject to various attacks. A complete
discussion can be found in the IP Security Architecture [IPv6-SA].
[...]
It remains unclear why the reference is made to the previous IPsec
Architecture document, RFC 2401, in this case.
In fact, RFC 4301 has simplified ICMP handling by the introduction
of ICMP Type+Code as a Traffic Selector for the SPD, and therefore
contains restructured text on ICMP message processing.
Nevertheless, as far as I can see, RFC 4301 has not removed
significant ICMP security related material from RFC 2401.
Thus, IMHO there is no reason to explicitely refer to the obsoleted
specification, RFC 2401 [IPv6-SA], instead of the current one,
RFC 4301 [SEC-ARCH].
(4) more issues with references
According to Appendix A, RFC 4443 has
- Separated References into Normative and Informative.
The latest RFC Authoring Internet draft revisions
(cf. draft-rfc-editor-rfc2223bis-xx
and draft-hoffman-rfc-author-guide-01)
all have included the definition:
Normative references specify documents that must be read
to understand or implement the technology in the document,
or whose technology must be present for the technology in
the new RFC to work. [...] an informative reference might
provide background or historical information to the reader.
[...]
The separation performed does not match this definition.
(4a)
RFC 4443 refers to RFC 792 and RFC 1122 to point out the analogy
to ICMP[v4], but it is a self-contained specification, and ICMPv6
does not rely on the implementation of ICMP[v4] -- IPv6 only nodes
are possible and even expected for the (far?) future.
Therefore, the references [RFC-792] and [RFC-1122] should better
have been placed into section 7.2, Informative References, instead
of Section 7.1, Normative References.
(4b)
RFC 4443 also lists in Section 7.1, Normative References, the
reference to its obsoleted predecessor, RFC 2463 [RFC-2463].
This is a fatal lock on the Standards Track for RFC 4443:
RFC 4443 can *not* be advanced above the level of RFC 2463,
if the written procedures are taken literally !
(Also, RFC 4443 contains all material from RFC 2463, and thus
RFC 2463 is not needed to understand and/or implement RFC 4443.)
Therefore, all references to obsoleted documents should be
named Informative, and in the case of RFC 4443, [RFC-2463]
should have been moved into Section 7.2 as well.
(4c)
The old IPv6 Addressing Architecture document, RFC 3513, has been
replaced by RFC 4291, published more than 5 weeks before RFC 4443.
Therefore, in Section 7.2 of RFC 4443, the Informative Reference
[IPv6-ADDR] should be have been changed to point to RFC 4291
instead of the obsolete RFC 3513.
(4d)
When following my recommendations in item (3) above, the
Informative Reference [IPv6-SA] is not needed any more;
its role has been taken over by the Reference [SEC-ARCH].
(5) misleading change note
The second bulleted item in Appendix A,
- Corrected typos in Section 2.4, where references to sub-bullet e.2
were supposed to be references to e.3.
apparently is not correct; it must have been introduced in the
draft history, referring to a change in the draft.
The references in RFC 2463 to sub-bullet (e.2) were correct.
RFC 4443 has inserted a new item (e.2) into the list, incrementing
the numbers of the previous sub-bullet (e.2) and all subsequent
sub-bullets, thus making it necessary to increment the references.
Perhaps, the latter had not been done in an early draft revision,
and has then been corrected in a later one.
Thus, the above change note should not have been included in RFC 4443.
Notes:
from pending
Errata ID: 1918
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-19
Held for Document Update by: Brian Haberman
Section 7.2 says:
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4203, December 2005.
It should say:
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
Errata ID: 1926
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-23
Held for Document Update by: Brian Haberman
Section 7.2 says:
[IPv6-ADDR] Hinden, R. and S. Deering, "Intpernet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
It should say:
[IPv6-ADDR] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
Errata ID: 3201
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Gräff
Date Reported: 2012-04-25
Held for Document Update by: Brian Haberman
Section 7.2 says:
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4203, December 2005.
It should say:
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
Notes:
Wrong RFC reference.
Status: Rejected (1)
RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006
Note: This RFC has been updated by RFC 4884
Source of RFC: ipv6 (int)
Errata ID: 4445
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dennis Ferguson
Date Reported: 2015-08-15
Rejected by: Brian Haberman
Date Rejected: 2015-09-15
Section 3.1 says:
ICMPv6 Fields:
Type 1
Code 0 - No route to destination
[...]
5 - Source address failed ingress/egress policy
6 - Reject route to destination
[...]
If the reason for the failure to deliver is lack of a matching entry
in the forwarding node's routing table, the Code field is set to 0.
(This error can occur only in nodes that do not hold a "default
route" in their routing tables.)
[...]
If the reason for the failure to deliver is that the route to the
destination is a reject route, the Code field is set to 6. This may
occur if the router has been configured to reject all the traffic for
a specific prefix.
Codes 5 and 6 are more informative subsets of code 1.
It should say:
ICMPv6 Fields:
Type 1
Code 0 - No route to destination
[...]
5 - Source address failed ingress/egress policy
6 - Destination address failed ingress/egress policy
[...]
If the reason for the failure to deliver is lack of an entry in the
forwarding node's routing table that can be used to reach the
destination, the Code field is set to 0. This error may be reported
by nodes that lack a default route or are the origin of an aggregate
route
[...]
If the reason for the failure to deliver is that the packet with this
destination address is not allowed due to ingress or egress filtering
policies, the Code field is set to 6.
Codes 5 and 6 are more informative subsets of code 1.
Notes:
A router that is the explicit or implicit origin of an aggregate
route prefix in routing must not forward messages to destinations
matching the aggregate prefix using a route with a prefix less specific
than the aggregate route it originated (e.g. a defaut route). This
constraint is necessary to produce correct, loop-free routing. The
parenthetical comment in the current description of the Code 0 error
overlooks the fact that such nodes may lack a route which may be used to
reach a destination matching an aggregate prefix, and may be the only
nodes which could report this lack, even if they do have routes to less
specific matching prefixes. The suggested change to the Code 0
description attempts to correct this.
Concerning Code 6, the earliest definition of a "reject route" I've
found in writing is in the RFC 2096 IP Forwarding Table MIB (though
4.3BSD-Reno kernels supported them in 1990 and there may well be earlier
uses). The updated description of inetCidrRouteType in RFC 4292 says this:
reject(2) refers to a route that, if matched, discards
the message as unreachable and returns a notification
(e.g., ICMP error) to the message sender. This is used
in some protocols as a means of correctly aggregating
routes.
In the MIB a reject route is a generic mechanism to indicate that packets
with matching destinations won't be forwarded using less specific routes,
but instead will be discarded if no more specific matching route to use
to forward the packet is known with an error being returned to the
message sender. The reason no specific error is associated with this is
that while the presence of the reject route describes how messages are
forwarded, or not forwarded (i.e. the mechanism), it does not describe why
they are being forwarded like that (i.e. the policy); to know the latter
requires knowing why the reject route was added. Knowing which error
will be reported hence requires knowing the purpose that is being
implemented by the reject route.
The original use of the mechanism, as indicated above, was to produce
correct forwarding on routers originating aggregate routes. Another use
of the mechanism, to prevent packets with Local IPv6 destination addresses
from being forwarded beyond a site's administrative boundary, was suggested
in Section 4.3 of RFC 4193 (I believe this can only be understood as a
suggestion, rather than an implementation requirement, since the policy
it requires could be indistinguishably implemented with a firewall filter
instead).
The current definition of Code 6 describes the error being reported
as "Reject route to destination", that is it ascribes the reason for
the error to the mechanism itself rather than the policy the mechanism
was employed to implement. If this was the intent then its discription
is technically inaccurate. A reject route does not necessarily implement
an administrative prohibition nor is its function necessarily to "reject
all traffic for a specific prefix"; the original use of reject routes
for aggregation is inconsistent with both of these. What I believe is
that the intent of Code 6 is to report the error associated with the
RFC 4193 border patrol policy, independent of how that is implemented, and
so I've changed the text to better reflect that.
--VERIFIER NOTES--
The changes proposed go beyond the level of fixing an error. Some of the changes are explicitly changing the consensus of the working group that developed the specification. If these changes are warranted, an internet-draft should be written and discussion started within the working group.