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

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Wed, 18 August 2010 09:43 UTC

Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
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 D33913A68E1 for <ipv6@core3.amsl.com>; Wed, 18 Aug 2010 02:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.672
X-Spam-Level:
X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 ABdKmcxme4N6 for <ipv6@core3.amsl.com>; Wed, 18 Aug 2010 02:43:24 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id DFEEE3A6A68 for <ipv6@ietf.org>; Wed, 18 Aug 2010 02:43:23 -0700 (PDT)
Received: from 219-90-255-65.ip.adam.com.au ([219.90.255.65] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1OlfBO-0004ES-5s; Wed, 18 Aug 2010 19:13:42 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 40D263B325; Wed, 18 Aug 2010 19:11:03 +0930 (CST)
Date: Wed, 18 Aug 2010 19:11:02 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: draft-ietf-ipngwg-p2p-pingpong-00.txt vs RFC4443
Message-ID: <20100818191102.536b1faf@opy.nosense.org>
In-Reply-To: <alpine.LRH.2.00.1008171116150.1433@netcore.fi>
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>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Olivier Vautrin <ovautrin@juniper.net>
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: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 18 Aug 2010 09:43:25 -0000

On Tue, 17 Aug 2010 11:20:56 +0300 (EEST)
Pekka Savola <pekkas@netcore.fi> wrote:

> Hi,
> 
> I changed the subject, because the original intent was lost in the 
> weeds.
> 
> On Mon, 16 Aug 2010, Olivier Vautrin wrote:
> > 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; the 
> specification was different (incoming/outgoing interface).  Does this 
> have different implications on the feasibility of implementation?
> 
> 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.
> 

Would that mechanism be described in -

RFC5881 - "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6
(Single Hop)"

?

I'm aware of a proposal to use it for CPE to test for the
absence/presence of a remote BRAS, which in the case of PPP virtual
circuits, would avoid the BRAS control plane having to respond to LCP
Echo Requests. That's quite attractive with BRASes now being able to
carry multiple 10s of 1000s of subscribers.

Regards,
Mark.