Bug 975020 - kernel does not send NEWLINK on changes caused by IPv6 RA
kernel does not send NEWLINK on changes caused by IPv6 RA
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 42.1
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Michal Kubeček
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-12 03:03 UTC by Marius Tomaschewski
Modified: 2018-04-13 15:15 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marius Tomaschewski 2016-04-12 03:03:37 UTC
+++ 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/
Comment 1 Tomáš Chvátal 2018-04-13 15:15:09 UTC
This is automated batch bugzilla cleanup.

The openSUSE 42.1 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or you can still observe it under openSUSE Leap 15.0, please
feel free to reopen this bug against that version (see the "Version"
component in the bug fields), or alternatively open
a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime