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

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.

Report New Errata