Re: [Technical Errata Reported] RFC4443 (4445)

[Brian Haberman <[e-mail]>]

All,
     Looking for thoughts on this erratum.  Given my understanding of
the development of RFC 4443, I am inclined to reject this erratum.  It
appears to be making a retroactive change to the text to align with
current terminology and functionality.  That is not the function of the
errata system.

     Does anyone believe this is a valid erratum?

Regards,
Brian

On 8/15/15 8:01 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC4443,
> "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4443&eid=4445
> 
> --------------------------------------
> Type: Technical
> Reported by: Dennis Ferguson <[e-mail]>
> 
> Section: 3.1
> 
> Original Text
> -------------
>    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.
> 
> 
> Corrected Text
> --------------
>    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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC4443 (draft-ietf-ipngwg-icmp-v3-07)
> --------------------------------------
> Title               : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
> Publication Date    : March 2006
> Author(s)           : A. Conta, S. Deering, M. Gupta, Ed.
> Category            : DRAFT STANDARD
> Source              : IP Version 6 Working Group
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
>