Re: Reducing the battery impact of ND

Ole Troan <> Wed, 22 January 2014 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1FEAA1A0493 for <>; Wed, 22 Jan 2014 13:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K7BVyUoFECsY for <>; Wed, 22 Jan 2014 13:57:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8CC541A0487 for <>; Wed, 22 Jan 2014 13:57:20 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id E47CA5FE0; Wed, 22 Jan 2014 13:57:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=K3QoL/T875OFMaR/aRfdx TwqVaY=; b=Nv8IqQSe5jQlse8mlV5cVWoCnuWZudjenuiIqd/abMEK7tEKuGfMP iGdNkKTYdyd68pvd59x1cftwQnTOTxOpm67igxFrq4HoDzEsMbSERFnmJK04pQIX 5slRMALfH3UMUO3+PNHnnsyGWzbJkpCfnPTMDeWOxOLL/JdMkd55Tw=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=krKTmU2q45w8w12 /g7tzHdq3MJwGXk/gfWXbvN/YWH0lsZhAW200g88K1mgdG7JpuH4AoH/zeQAUEru E/BXnbdIyLOJqhxChSvyKdfDMjErKvptafltABkHeJQJzDw7IOET0x1VwBF3ZJXZ PD5mUs5yylD/E6fsCtRQPJrsfX4o=
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 3CF0D60A9; Wed, 22 Jan 2014 13:57:16 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B3BADBED-8AD5-485E-A768-547DF363A025"; 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: Wed, 22 Jan 2014 22:57:13 +0100
Message-Id: <>
References: <> <> <> <> <> <>
To: Erik Nordmark <>
X-Mailer: Apple Mail (2.1827)
Cc: 6man Chairs <>, 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: Wed, 22 Jan 2014 21:57:22 -0000


>> 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.
> Lorenzo,
> Whether you call it "efficiency" or "robustness" doesn't make much difference from a technical or a process perspective.
> The approach you advocate is insufficient to ensure better robustness for at least two reasons:
> - the lifetime(s) of the prefixes are independent of the lifetimes of the default routers. Hence in this approach a host can have default routers but no prefixes.
> - the reachability state in the NCEs is independent of the default router list - per RFC 4861 the router stays in the default router list even if it is unreachable. Thus your last router might be unreachable but with remaining lifetime - it was the next-to-last router in the list that was reachable.
> Solving those without risking hosts sending lots of RSs during failure events or resulting in a steady state of RSs from hosts seems tricky.
>>    FWIW I don't have a problem with an opt-in update to 4861. I even
>>    think efficient-nd is the way to go because it reduces overall ND
>>    multicast traffic and not just your narrow focus on mobile phone
>>    battery life.
>> The tradeoff is that efficient ND adds more state to the network about
>> host addresses and changes a pretty core part of the IPv6 specs. I think
>> that if we can reduce the battery impact of multicast traffic, we will
>> have fixed most of the problem without doing either of those, and to my
>> mind, that's a much better tradeoff.
> Changing from periodic RAs to (effectively) periodic RSs as you propose would change RFC 4861 is a very fundamental way.
> It may or may not be the right thing to do for the future, but I think that requires a bit more work then forcing some edits into a document which has almost completed the WG process. I think resilient-rs has significant benefits in its current form and scope.

not trying to speak for Lorenzo, but I don't think he is proposing replacing periodic RAs with periodic RSs.
example: a host successfully does router discovery. RA lifetime is relatively short, e.g. 3 * router advertisement interval.
host doesn't receive any of the multicast RAs (network drops them or whatever).

what would be the best behaviour for the end-user?
a) host sits quietly and waits for a periodic RA
b) host restarts the initial router discovery