Re: Reducing the battery impact of ND

Lorenzo Colitti <> Tue, 21 January 2014 20:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 521341A0245 for <>; Tue, 21 Jan 2014 12:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2yFADImmZ4Zm for <>; Tue, 21 Jan 2014 12:34:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::232]) by (Postfix) with ESMTP id 507121A0221 for <>; Tue, 21 Jan 2014 12:34:56 -0800 (PST)
Received: by with SMTP id x13so10775426ief.9 for <>; Tue, 21 Jan 2014 12:34:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H1y6RhmA6KlLxS5SMaehutfIudoiE36OvSaU5FgFWPk=; b=meWOJTQI1YpR5X7hgPGk/WoOygTNyC5QeD7/9s6UnmSLyj53r1g7L86MdWg5XUZUWu Y6TKmV31oHAW2UYHGQHF9UTKX6AxCl34VOr+UlPe6VSczFqeUhsqSuu81ovcIf0vtXON dw7gsLdnGNzpfg5/QVZN/6bWUpOlGr82RZinVdkokogEYMNuvRRM7Zd8fHTWPQCmYxV2 nJcVPqZ4UZWlT/RmKNdU3uaqdZ3EuF02r3ylDmaF8hVGVZIA+81sLJrDtCBbuOkm1bwi DgXrixZwLgVz8IdhxYROSirO8N+vHYmJUG750vej9LdW03ZDPFZD8RBuMV8rx6roxzjI SB6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H1y6RhmA6KlLxS5SMaehutfIudoiE36OvSaU5FgFWPk=; b=S2j6tGgYtYkl962SYnP03LgLCtJ70qSw3xST3Goi8GJvmvOoYbf5yciPPB0l9iPVQR r3ZGxQh51omYWHiUk2Dws8H8xI0cw5S4tdNkmRl5fBKuGnviB4KxJfu6QIuuD0n2gWYS XShhqKgW1A8u9nBVJd1jiwo192xFtffeicspsnAKv4f2LlTrfK6hNgFtyofrny8JqcY/ KVNqT1c5n+BRe7BMPaGC4jRuMy6vvYqPSVFiS0OWwmJsJQijNHaQC97zGab5dXjKgH4P +EMAPkuPiM/P0X0hor2vzzcWZoxCGSLr3lHOQCTdd/TUe0zXqk+N+mD3ir+AsN9Bp6sy 9H6g==
X-Gm-Message-State: ALoCoQlPKqzh++nnAao8TPJJM0eSqThzMeI9JnV67ginB3VPq5A2jL1LJVqsVuWkuiqzqJmtwhkOGlm6UkldJYO1ZruTdU8aoVTFr+xpMgR2UOMiC08Knq5IUEp1GyUMoa3tcBGXdJ12U/exQwcdHRrXXC8/Q0XJ3D2IgT6aR09VONlkoinOIi1ARnkeiMrHI3iGdAAdDBcb
X-Received: by with SMTP id y8mr11607029icw.25.1390336496024; Tue, 21 Jan 2014 12:34:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Jan 2014 12:34:35 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Lorenzo Colitti <>
Date: Tue, 21 Jan 2014 12:34:35 -0800
Message-ID: <>
Subject: Re: Reducing the battery impact of ND
To: Erik Nordmark <>
Content-Type: multipart/alternative; boundary="90e6ba2121f5f6ef3604f080f0f5"
Cc: 6man Chairs <>, 6man WG <>, Andrew 👽 Yourtchenko <>
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 20:34:59 -0000

On Fri, Jan 17, 2014 at 9:01 PM, Erik Nordmark <> wrote:

>>     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.

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.

> 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.