Re: Reducing the battery impact of ND

Ole Troan <> Tue, 21 January 2014 22:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8A9B1A02DC for <>; Tue, 21 Jan 2014 14:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SjCd1WAa5J3P for <>; Tue, 21 Jan 2014 14:35:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5A0AF1A0256 for <>; Tue, 21 Jan 2014 14:35:04 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAG/13lKQ/khN/2dsb2JhbABagwu8fYEWFnSCJQEBAQMBeQULC0ZXBogQCMJ3F44XaAeDJIEUBJA7mX+DLjs
X-IronPort-AV: E=Sophos; i="4.95,697,1384300800"; d="asc'?scan'208"; a="3307181"
Received: from ([]) by with ESMTP; 21 Jan 2014 22:35:03 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s0LMZ1hK013436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jan 2014 22:35:02 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_9F3780C8-0CDB-4861-A049-AEAFAF75C4EB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Reducing the battery impact of ND
From: Ole Troan <>
In-Reply-To: <>
Date: Tue, 21 Jan 2014 23:35:01 +0100
Message-Id: <>
References: <> <> <> <> <>
To: Lorenzo Colitti <>
X-Mailer: Apple Mail (2.1827)
Cc: 6man Chairs <>, Erik Nordmark <>, Andrew Yourtchenko <>, 6man WG <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2014 22:35:06 -0000


>     One of your "yes please" below is a change to ND - Andrew's b) about
>     restarting RS would require a (small) standards update.
> We should try to get that into draft-6man-resilient-rs.
> It seems to be out of scope for the problem resilent-rs set out to solve which was loss issues for the initial RS. It might not be wise to expand that drafts scope to also cover (part of) efficient-nd.

the abstract has the following text:
   "Furthermore, on some links, unsolicited multicast
   Router Advertisements are never sent and the mechanism in this
   document is intended to work even in such scenarios."

> To my mind, sending an RS when the RA lifetime is about to expire is a robustness fix, not an efficiency fix. In a world where IPv6 is optional and IPv4 is the main protocol, just having your IPv6 address expire is not necessarily a problem. But in a world where IPv6 is the main protocol, then hosts will probably want to try harder to keep their IPv6 address around.

I believe you have found a bug in the resilient-rs draft.
could you reply to the WGLC thread for that document and notify the authors?