Re: draft-ietf-ipngwg-p2p-pingpong-00.txt vs RFC4443

Fernando Gont <fernando@gont.com.ar> Tue, 17 August 2010 11:54 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B96F3A6952 for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Aug 2010 04:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.246
X-Spam-Level:
X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 9bTnEF4-Rvoa for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Aug 2010 04:54:43 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12DA63A694E for <v6ops-archive@lists.ietf.org>; Tue, 17 Aug 2010 04:54:43 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1OlKko-000CDN-12 for v6ops-data0@psg.com; Tue, 17 Aug 2010 11:54:54 +0000
Received: from [209.85.213.194] (helo=mail-yx0-f194.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <fernando.gont.netbook.win@gmail.com>) id 1OlKkl-000CCu-MM for v6ops@ops.ietf.org; Tue, 17 Aug 2010 11:54:51 +0000
Received: by yxj4 with SMTP id 4so860554yxj.5 for <v6ops@ops.ietf.org>; Tue, 17 Aug 2010 04:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=xm8pGTEeShvxHKeJ3ympC1t+D7BD5RB37nwqOzZZYUQ=; b=xexEabA6jCBwzs8B80rHsjDewPi5aLBi00rr0vfXiWC2Al16BCuB77NGkQ2Bn8mehD 6DtKdfqx0omP8NRHlMGK0vF0i3hOUrD6vdasZJN2VgjgmtkL2+gYb/E4OL/mCdTbUL6o IQSCepXTjY0vgMMdHaV+6nYEsE0NRxQAwh0/o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=GgbCt/mln7kxhsSyOw2E7X7avF2HKA9BzVjIhDn3tgWXyxMpLXKew9i09ZlMb9cZzx Ll5DY9i/0Sr4ZK0mswzMmd603yfJfAJ+cyj/xS7DzkDo5WCrG0pPEEG/1Kl8JEkRY241 /zUfQbhhQw7HV0yYfzQ7xBh/rv9aI6uQNSJGs=
Received: by 10.100.109.13 with SMTP id h13mr7426382anc.193.1282046090825; Tue, 17 Aug 2010 04:54:50 -0700 (PDT)
Received: from [192.168.2.3] ([190.245.181.90]) by mx.google.com with ESMTPS id t30sm12172849ann.7.2010.08.17.04.54.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 04:54:49 -0700 (PDT)
Message-ID: <4C6A6C2F.1060409@gont.com.ar>
Date: Tue, 17 Aug 2010 08:02:07 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: Olivier Vautrin <ovautrin@juniper.net>, Jeroen Massar <jeroen@unfix.org>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: draft-ietf-ipngwg-p2p-pingpong-00.txt vs RFC4443
References: <4C68F1E1.2090003@gont.com.ar> <4C68FD84.80905@unfix.org> <4C6920F8.7010505@gont.com.ar> <84600D05C20FF943918238042D7670FD36D708817A@EMBX01-HQ.jnpr.net> <alpine.LRH.2.00.1008171116150.1433@netcore.fi>
In-Reply-To: <alpine.LRH.2.00.1008171116150.1433@netcore.fi>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi, Pekka,

>> It is clear that there is one more action done on the packet with 
>> RFC4443. But this has no impact on shipping ASIC based routers. It
>> is difficult to say though if some smaller routers could be
>> impacted.
> 
> This, and what Ole Troan wrote on interface lookup, is interesting.
> 
> RFC4443 requires checking that destination address matches the subnet
>  prefix.  Is this the hot issue?
> 
> Note that pingpong-00 document did not have this requirement;

AFAICT, it does. It says: "....and the destination address on the packet
seems to be on-link (in terms of Neighbor Discovery) on the
point-to-point interface". Or am I missing something?


> the
> specification was different (incoming/outgoing interface).  Does this
>  have different implications on the feasibility of implementation?

It seems that the point is not really that of reduced performance, but
rather that complying with this requirement would require a change in
the silicon?

If that's the case (i.e., no real performance implications), then it
looks like an appropriate fix for this issue. -- which does not
necessarily argue against /127 prefixes, as there are other reasons for
using them (or, put another way, let's not correlate *this* with the
fight over /127 prefixes).



> FWIW, "Packet may be forwarded back on the received interface" is 
> actually, AFAIK, used in certain PE routerscenarios where you ping 
> yourself over a p2p link.

Is the echo request/response really forwarded back on the received
interface? (isn't the *response* that is forwarded back on the received
interface?)

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1