ping-pong phenomenon with p2p links & /127 prefixes

[Fernando Gont <[e-mail]>]

Folks,

draft-ietf-ipngwg-p2p-pingpong-00.txt proposes a solution to the
ping-pong problem with point-to-point links, which IMHO is elegant:

> Check the incoming/outgoing interface of the packet.  If the
> interface is the same, is a point-to-point interface and the
> destination address on the packet seems to be on-link (in terms of
> Neighbor Discovery) on the point-to-point interface, the forwarding
> router SHOULD NOT forward the packet.  Also, in this case, the router
> SHOULD NOT generate ICMPv6 redirect message even if the incoming
> packet meets conditions in RFC2461 section 8.2.  The router SHOULD
> generate an ICMPv6 error message instead, with the type field being 1
> (destination unreachable), and the code field being 3 (address
> unreachable).

Then incorporated into RFC 4443 as follows:

>    One specific case in which a Destination Unreachable message is sent
>    with a code 3 is in response to a packet received by a router from a
>    point-to-point link, destined to an address within a subnet assigned
>    to that same link (other than one of the receiving router's own
>    addresses).  In such a case, the packet MUST NOT be forwarded back
>    onto the arrival link.

However, this fix allegedly has big performance implications on routers.
Can anybody comment on this "claim"?

P.S.: This fix doesn't prevent the use of /127s (it's orthogonal), but
I'm wondering about the reasons for which this fix is not the "first
line of defense" for *this* (i.e., ping-pong) vulnerability. -- yes, the
Kohno et al I-D mentions other (additional) reasons for using /127
prefixes o p2p links.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1