AdvRASolicitedUnicast: unicast RA response to RS.

RFC 7772 section 2.1 describes a network flooded with multicast RA at
the maximum 3 second interval due a high client turnover.

The mitigation described in RFC 7772 section 5.1.1 states that a unicast
RA response can be sent, but SHOULD be a configurable option
(AdvRASolicitedUnicast), and that networks containing tens or hundreds
of battery-powered devices SHOULD enable the option.

The new option is defaulted to on, as it has very few downsides, and
represents significent battery life improvements for many clients.

We do differ from the RFC in that we do not require the SLLA option to
be set in the RS, as testing shows many clients are not setting it.

See TODO for further possible improvements to AdvRASolicitedUnicast.

Fixes: https://github.com/reubenhwk/radvd/issues/63
Fixes: https://github.com/reubenhwk/radvd/pull/69
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>

CHANGES

@@ -1,3 +1,5 @@
+2017/03/15	Implement RFC 7772 Section 5.1.1, 5.1.2, defaulted to on. <Robin H. Johnson>
+
 2017/02/04	clang-format the code
 
 2017/02/01	Release v2.16

TODO

@@ -58,3 +58,20 @@ Known problems (probably can't do anything about these):
    Ethernet frames with the old MAC until interface is flapped.
    More: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508466
 
+AdvRASolicitedUnicast: Further improvement is possible.
+- If we get a RS and are about to send a multicast RA, then we can further save
+  battery on the client device by NOT sending a unicast response, and just
+  letting the client wait for the multicast response. This should be
+  implemented as a new time value, specifying the maximum amount of time
+  remaining to as a deciding factor between send-solicited-RA-now vs
+  wait-for-next-multicast.
+- The above can also form part of rate-limiting of unicast RA responses when
+  network topology has recently changed.
+
+The following parts of RFC7222 are not yet implemented:
+- Section 5.1.3: Networks that serve battery-powered devices SHOULD NOT send
+  multicast RAs too frequently (see Section 4) unless the information in the RA
+  packet has substantially changed.  If there is a desire to ensure that hosts
+  pick up configuration changes quickly, those networks MAY send frequent
+  Router Advertisements for a limited period of time (e.g., not more than one
+  minute) immediately after a configuration change.

defaults.h

@@ -46,6 +46,8 @@
 #define DFLT_MinDelayBetweenRAs MIN_DELAY_BETWEEN_RAS
 #define DFLT_AdvDefaultPreference 0
 #define DFLT_AdvRAMTU RFC2460_MIN_MTU
+#define DFLT_UnicastOnly 0
+#define DFLT_AdvRASolicitedUnicast 1
 
 /* Options sent with RA */
 

gram.y

@@ -92,6 +92,7 @@
 %token		T_Base6Interface
 %token		T_Base6to4Interface
 %token		T_UnicastOnly
+%token		T_AdvRASolicitedUnicast
 
 %token		T_HomeAgentPreference
 %token		T_HomeAgentLifetime
@@ -332,6 +333,10 @@ ifaceval	: T_MinRtrAdvInterval NUMBER ';'
 		{
 			iface->UnicastOnly = $2;
 		}
+		| T_AdvRASolicitedUnicast SWITCH ';'
+		{
+			iface->AdvRASolicitedUnicast = $2;
+		}
 		| T_AdvMobRtrSupportFlag SWITCH ';'
 		{
 			iface->mipv6.AdvMobRtrSupportFlag = $2;

interface.c

@@ -31,6 +31,8 @@ void iface_init_defaults(struct Interface *iface)
 	iface->AdvSourceLLAddress = DFLT_AdvSourceLLAddress;
 	iface->MinDelayBetweenRAs = DFLT_MinDelayBetweenRAs;
 	iface->MinRtrAdvInterval = -1;
+	iface->UnicastOnly = DFLT_UnicastOnly;
+	iface->AdvRASolicitedUnicast = DFLT_AdvRASolicitedUnicast;
 
 	iface->ra_header_info.AdvDefaultPreference = DFLT_AdvDefaultPreference;
 	iface->ra_header_info.AdvDefaultLifetime = -1;

process.c

@@ -122,6 +122,34 @@ void process(int sock, struct Interface *interfaces, unsigned char *msg, int len
 
 static void process_rs(int sock, struct Interface *iface, unsigned char *msg, int len, struct sockaddr_in6 *addr)
 {
+	/* RFC 7772, section 5.1:
+	 * 5.1.  Network-Side Recommendations
+	 *    1.  Router manufacturers SHOULD allow network administrators to
+	 *        configure the routers to respond to Router Solicitations with
+	 *        unicast Router Advertisements if:
+	 *        *  The Router Solicitation's source address is not the
+	 *           unspecified address, and:
+	 *        *  The solicitation contains a valid Source Link-Layer Address
+	 *           option.
+	 *
+	 * However, testing shows that many clients do not set the SLLA option:
+	 * https://github.com/reubenhwk/radvd/issues/63#issuecomment-287172252
+	 * As of 2017/03/16:
+	 * - macOS 10.12.3 sierra - sends SLLA 2 times out of 4
+	 * - iOS 10.2.1 (iPhone 5s) - no SLLA
+	 * - Android 7.0 (sony xperia phone) - sends SLLA
+	 * - Android 5.1 (nexus 7 tablet) - sends SLLA
+	 * - Ubuntu 16.04.2 LTS w/ Network Manager, running 4.9 kernel (dell laptop) - no SLLA
+	 * - Windows 10 (dell laptop) - no SLLA
+	 *
+	 * We decide to ignore the SLLA option for now, and only require the
+	 * unspecified address check. Clients that did not set the SLLA option will
+	 * trigger a neighbour solicit to the solicited-node address trying to
+	 * resolve the link-local address to, this would still be less traffic than
+	 * the all-nodes multicast.
+	 */
+	int rfc7772_unicast_response = iface->AdvRASolicitedUnicast && !IN6_IS_ADDR_UNSPECIFIED(&addr->sin6_addr);
+
 	/* validation */
 	len -= sizeof(struct nd_router_solicit);
 
@@ -158,7 +186,7 @@ static void process_rs(int sock, struct Interface *iface, unsigned char *msg, in
 
 	double const delay = (MAX_RA_DELAY_SECONDS * rand() / (RAND_MAX + 1.0));
 
-	if (iface->UnicastOnly) {
+	if (iface->UnicastOnly || rfc7772_unicast_response) {
 		send_ra_forall(sock, iface, &addr->sin6_addr);
 	} else if (timespecdiff(&ts, &iface->times.last_multicast) / 1000.0 < iface->MinDelayBetweenRAs) {
 		/* last RA was sent only a few moments ago, don't send another immediately. */

radvd.conf.5.man

@@ -93,7 +93,7 @@ DNSSL (DNS Search List) definitions are of the form:
 .B };
 .fi
 
-By default radvd will send route advertisements so that every node on the link can use them.
+By default radvd will send multicast route advertisements so that every node on the link can use them.
 The list of clients (IPv6 address) to advertise to, and accept route solicitations from can be configured.
 If done, radvd does not send send messages to the multicast addresses but
 to the configured unicast addresses only.  Solicitations from other addresses are refused.
@@ -172,6 +172,19 @@ multiple-access links, such as ISATAP.
 
 Default: off
 
+.TP
+.BR AdvRASolicitedUnicast " " on | off
+
+Indicates that router solicitations will be responded to with unicast
+router advertisements, as recommended by RFC7772. Large networks with a
+high concentration of mobile devices might experience like battery
+depletion, when solicited Router Advertisement messages are multicast.
+
+This corresponds to the Cisco IOS option
+.B ipv6 nd ra solicited unicast
+
+Default: on
+
 .TP
 .BR "MaxRtrAdvInterval " seconds
 

radvd.h

@@ -59,6 +59,7 @@ struct Interface {
 	double MinDelayBetweenRAs;
 	int AdvSourceLLAddress;
 	int UnicastOnly;
+	int AdvRASolicitedUnicast;
 	struct Clients *ClientList;
 
 	struct state_info {

scanner.l

@@ -79,6 +79,7 @@ AdvHomeAgentFlag	{ return T_AdvHomeAgentFlag; }
 AdvIntervalOpt		{ return T_AdvIntervalOpt; }
 AdvHomeAgentInfo	{ return T_AdvHomeAgentInfo; }
 UnicastOnly		{ return T_UnicastOnly; }
+AdvRASolicitedUnicast	{ return T_AdvRASolicitedUnicast; }
 
 Base6Interface		{ return T_Base6Interface; }
 Base6to4Interface	{ return T_Base6to4Interface; }