The ping-pong phenomenon with p2p links

Pekka Savola <pekkas@netcore.fi> Wed, 30 July 2008 20:27 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC083A6981; Wed, 30 Jul 2008 13:27:45 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD2B3A685C for <ipv6@core3.amsl.com>; Wed, 30 Jul 2008 13:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level:
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5J6dfr1Rhsc for <ipv6@core3.amsl.com>; Wed, 30 Jul 2008 13:27:43 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id C6C873A68D8 for <ipv6@ietf.org>; Wed, 30 Jul 2008 13:27:42 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m6UKRswJ030423 for <ipv6@ietf.org>; Wed, 30 Jul 2008 23:27:54 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6UKRr3b030419 for <ipv6@ietf.org>; Wed, 30 Jul 2008 23:27:53 +0300
Date: Wed, 30 Jul 2008 23:27:53 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: ipv6@ietf.org
Subject: The ping-pong phenomenon with p2p links
Message-ID: <alpine.LRH.1.10.0807302240130.29324@netcore.fi>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.93.1/7882/Tue Jul 29 22:06:54 2008 on otso.netcore.fi
X-Virus-Status: Clean
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

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
--------------------------------------------------------------------