Re: Reducing the battery impact of ND

Lorenzo Colitti <> Wed, 22 January 2014 22:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2FBA1A04F9 for <>; Wed, 22 Jan 2014 14:48:57 -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 h_ESTAQmljzH for <>; Wed, 22 Jan 2014 14:48:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::22b]) by (Postfix) with ESMTP id C04EB1A04D3 for <>; Wed, 22 Jan 2014 14:48:55 -0800 (PST)
Received: by with SMTP id as1so266634iec.2 for <>; Wed, 22 Jan 2014 14:48:55 -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=IdzyrsDkQUZT0Wto9sx7I9lF7o5yF5EATuaVsAhGUOU=; b=nBlFxwuoLY1EDrw2ewqSTdRDRXSIT9pyV4H4Mx6Evy3aTOs8/dXOMhBJ90xcQB2OYz QeTXthsLsNDtU3AsrI3T4ZDApBAi4GvHu3z8pQAAv2fuTBHozWzejjyDx6wDTVSAHah/ CUHXTcp6kqS3UsXO7QLpkKUj1cPOaE2ppZ4Dit5FBZ4j6LrmpI2dWXE0yh4gvhDW1lbH gVbVjyk5467A69gxPIn+i+DcaMXfdRZd/SZ1D0BUspUCyKwE/NRDuDqAYRFbpLO0DQN9 meAm2FYJMS0VzyRRLAVEyNlA7hStjzi9rvdTdQGJCncankvvTv3lFjM/1ivJDlEQmZ9p nPTA==
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=IdzyrsDkQUZT0Wto9sx7I9lF7o5yF5EATuaVsAhGUOU=; b=gvw1SEsE91I2AiavhyRGl8pgxuQwrxcftVyBrrWu5av2DP5S08shbypHQ+mOarvp37 fWqyE9A3GIVeiO0A7v1DIxNj7DZevuTlkX0HtUzmyBw4elBbGOzFT43fm38PMlGpjYbg ueuyK4kyHVb/jg7CJgRVh3Vxgjq9uWTG8WqPG85Zy65qACO+EG7ulA6ZiVeVgNv54Dip I0R8y97Hj7I/Larxszz+xVCM4UQI4FeIygYg8GqOEqqrHWJ7wGyK9YE/Xn7ysGKiOXgD U7ZXo9nVrwD+0GqGmI6TjSlRrlM3+guihLwjJgxNOuBH0hB1F7pwcI2V9/UCL5inWWyQ Xg2Q==
X-Gm-Message-State: ALoCoQmCYZTkheoyGUr/ppdUxf7BRoHxFVVjMaGQG9hmWMQISQ7wAzTF8IQr2lC7+e8g18dRpiyAp+vfU0AFnNbQ6CwpiPi7/ObiCj9wKwhIZ7kONweTIqF32l7ZtvI7Om7BeBWMgfZxgrlaJ+UHFlcFA0/F8If1XmVnUAXlsoqvY/BwB6sgGnyWZuCOK/BTYCQDX6rXFcUY
X-Received: by with SMTP id ci9mr26406940igc.31.1390430934971; Wed, 22 Jan 2014 14:48:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Jan 2014 14:48:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Wed, 22 Jan 2014 14:48:34 -0800
Message-ID: <>
Subject: Re: Reducing the battery impact of ND
To: Erik Nordmark <>
Content-Type: multipart/alternative; boundary="089e0111e0daf6d82104f096ed2b"
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: Wed, 22 Jan 2014 22:48:58 -0000

On Wed, Jan 22, 2014 at 1:44 PM, Erik Nordmark <> wrote:

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

This can be tricky to implement, but in principle, the host has this
information already.

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

I agree that there are a lot of corner cases here.

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

Fair enough. That said - if that's what we want to do, then resilient-rs
should make it clear that it is only for initial solicitations and thus
does not specify or allow behaviour on multicast-capable links where there
are no periodic multicast RAs, because the IPv6 standards as written do not
work on such links.