+++ This bug was initially created as a clone of Bug #934067 +++

When RA arrives, the kernel is applying the RA flags (net/ipv6/ndisc.c):

        /*
         * Remember the managed/otherconf flags from most recently
         * received RA message (RFC 2462) -- yoshfuji
         */
        in6_dev->if_flags = (in6_dev->if_flags & ~(IF_RA_MANAGED |
                                IF_RA_OTHERCONF)) |
                                (ra_msg->icmph.icmp6_addrconf_managed ?
                                        IF_RA_MANAGED : 0) |
                                (ra_msg->icmph.icmp6_addrconf_other ?
                                        IF_RA_OTHERCONF : 0);

....

but sends NEWLINK only when ra_msg->retrans_timer or ra_msg->reachable_time
are set. Many routes send 0 here, what just means unspecified:

https://tools.ietf.org/html/rfc4861#section-4.2

      Reachable Time 32-bit unsigned integer.  The time, in
                     milliseconds, that a node assumes a neighbor is
                     reachable after having received a reachability
                     confirmation.  Used by the Neighbor Unreachability
                     Detection algorithm (see Section 7.3).  A value of
                     zero means unspecified (by this router).

      Retrans Timer  32-bit unsigned integer.  The time, in
                     milliseconds, between retransmitted Neighbor
                     Solicitation messages.  Used by address resolution
                     and the Neighbor Unreachability Detection algorithm
                     (see Sections 7.2 and 7.3).  A value of zero means
                     unspecified (by this router).

https://tools.ietf.org/html/rfc4861#section-6.3.4
6.3.4.  Processing Received Router Advertisements

   A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
   and Retrans Timer) may contain a value denoting that it is
   unspecified.  In such cases, the parameter should be ignored and the
   host should continue using whatever value it is already using.  In
   particular, a host MUST NOT interpret the unspecified value as
   meaning change back to the default value that was in use before the
   first Router Advertisement was received.  This rule prevents hosts
   from continually changing an internal variable when one router
   advertises a specific value, but other routers advertise the
   unspecified value.

IMO there is no reason to send RTM_NEWLINK only, when these values are
given and ignore other changes like the managed/other-config flags,
which are applied, just the event aren't sent.

Patches addressing this issue are accepted upstream:
  http://patchwork.ozlabs.org/patch/512486/
  http://patchwork.ozlabs.org/patch/512646/