Re: [76attendees] Rogue IPv6 RA

Arifumi Matsumoto <arifumi@nttv6.net> Tue, 10 November 2009 01:48 UTC

Return-Path: <arifumi@nttv6.net>
X-Original-To: 76attendees@core3.amsl.com
Delivered-To: 76attendees@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55D928C28C; Mon, 9 Nov 2009 17:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level:
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 Os5zM8Bp2okV; Mon, 9 Nov 2009 17:48:52 -0800 (PST)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 91E1F28C279; Mon, 9 Nov 2009 17:48:51 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nAA1nBfx023643; Tue, 10 Nov 2009 10:49:11 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset=us-ascii; format=flowed
From: Arifumi Matsumoto <arifumi@nttv6.net>
In-Reply-To: <2e8c64260911091743u2f33241h5988f3a97f80814a@mail.gmail.com>
Date: Tue, 10 Nov 2009 10:51:04 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <8447CD11-7EAB-44A6-BF0B-EC9A92ADD24D@nttv6.net>
References: <m24op4b94l.wl%sekiya@wide.ad.jp> <66346671-3773-4A08-94CB-7A777C105631@nttv6.net> <m2my2w9dda.wl%sekiya@wide.ad.jp> <9EC1CCE4-CB5C-4491-8339-A1497475A1D7@nttv6.net> <2e8c64260911091743u2f33241h5988f3a97f80814a@mail.gmail.com>
To: Erik Kline <ek@google.com>
X-Mailer: Apple Mail (2.1076)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:::1]); Tue, 10 Nov 2009 10:49:11 +0900 (JST)
Cc: ipv6@ietf.org, 76attendees@ietf.org
Subject: Re: [76attendees] Rogue IPv6 RA
X-BeenThere: 76attendees@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <76attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/76attendees>, <mailto:76attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/76attendees>
List-Post: <mailto:76attendees@ietf.org>
List-Help: <mailto:76attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/76attendees>, <mailto:76attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 01:48:52 -0000

Erik,

On 2009/11/10, at 10:43, Erik Kline wrote:

>> If the latter paragraph only should be executed, the address given
>> by rogue RA remains, right ?
>
> My reading would be that on receipt of a 0-lifetime RA that only the
> second paragraph would be executed (lifetime timeout).

Second to that.

>  However, all
> hosts receiving the 0-lifetime RA would then have to recompute the
> next-hop, which in /some/ cases may require sending a RS (which the
> rogue RA node would presumably hear and re-answer).  (Of course I
> haven't verified this against any implementation :)

I fail to get your point.
Requiring sending a RS leads to ... ?

Even if that RS fails, it does not have any effect on the given
addressby rogue RA, right ?