The ping-pong phenomenon with p2p links

Hi,

On the plenary tonight, Lorenzo Colitti from Google mentioned a 
looping problem with p2p interfaces and using non-/127 prefix length. 
He said they had asked the vendors to implement an RFC fix for this 
but vendors had refused (citing loss of forwarding performance).  I 
think this may call for more attention here.

The ICMPv6 spec (RFC4443) has the following new requirement (stemming 
from draft-ietf-ipngwg-p2p-pingpong) since its predecessor:

    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.

In the last sentence seems to mean the triggering packet. If so, 
making this kind of forwarding specification inside ICMP spec is 
interesting, and it is also interesting because the ICMP 
implementation must watch out for packets which aren't destined to the 
local node.

AFAIK, this issue is not touched in any other RFC (for v4 or v6).

This is more or less well-known behaviour on IPv4 side and as such 
long prefixes are not used on point-to-point links.

Based on my quick test with Juniper routers both IPv4 and IPv6 packets 
happily loop back and forth (no forwarding checks, ping shows "time to 
live exceeded"), and both ICMPv4 and ICMPv6 packets get originated 
just fine (traceroute shows looping behaviour). (Note: Juniper claims 
conformance to RFC2463, not RFC4443.)

I wonder how other _hardware-based_ implementations behave?  At least 
Cisco claims RFC4443 compliancy but I don't have p2p interfaces to 
test this. I wonder if there are other vendors who have found 
implementing RFC4443's apparent "thou shalt not forward back" 
unfeasible?

If that part in the implementation has widely been seen as a problem, 
given that IPv6 architecture (in paper) requires /64 addressing, and 
there are other reasons why /127 is broken (RFC3627), the IETF might 
need to do something.

Workarounds are at least using distinct /128 addresses and static 
routes or a routing protocol or just link-local addresses.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------