Re: Reducing the battery impact of ND

Ole Troan <> Wed, 22 January 2014 23:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86BAA1A053A for <>; Wed, 22 Jan 2014 15:41:27 -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 OxWXlsGaHg2d for <>; Wed, 22 Jan 2014 15:41:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 076B41A0539 for <>; Wed, 22 Jan 2014 15:41:25 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAGVW4FKQ/khL/2dsb2JhbABbgwy8bYETFnSCJQEBAQMBeQULC0ZXBogQCMQpF44UaAeDJIEUBJA7mX+DLjs
X-IronPort-AV: E=Sophos; i="4.95,702,1384300800"; d="asc'?scan'208"; a="3366351"
Received: from ([]) by with ESMTP; 22 Jan 2014 23:41:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s0MNfN47024014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 23:41:24 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_C24D0E5A-E256-416D-A598-7FFAEFC055C1"; 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: Thu, 23 Jan 2014 00:41:22 +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 23:41:28 -0000


again, no hats.

>> not trying to speak for Lorenzo, but I don't think he is proposing replacing periodic RAs with periodic RSs.
> Ole,
> I think that is the effective result of what you two are cooking up.

I cannot claim credit for cooking up that dish.
aren't you proposing to do exactly that, replace periodic RAs with periodic RSs in:

>> 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).
> You are speculating about some particular failure or misfeature in the network that makes it (persistently? sometimes?) drop multicast RAs. It would be good to flesh out that particular failure mode to see
> - whether it is realistic, and
> - what impact it has elsewhere.

it's relatively trivial to reproduce, but I suppose you can argue that setting timers that way is a misconfiguration.
802.11 networks are multicast challenged, so I would expect drops to be somewhat common.
a more robust RS retransmit mechanism will help that somewhat.

> For instance, the failure could be that all ICMP packets to the host are dropped (due to some misconfigured security policy - we've seen those in IPv4). That would drop unicast RAs as well, and affect the old path MTU discovery protocol.
> Or it could be that link-local multicast is misconfigured or broken, resulting in DNSSD and other protocols breaking.
> Having every host on the planet send a RS every 30 seconds "just in case" doesn't sound helpful.

true, although it wouldn't be 'just in case'. I think you are making a good argument that the current RS/RA mechanism is designed quite well.