Bug 1000757 - Kernel adds IPv6 on-link prefix information when statically configuring an address
Kernel adds IPv6 on-link prefix information when statically configuring an ad...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: fedora-kernel-networking
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-24 19:03 EDT by markzzzsmith
Modified: 2013-10-08 12:11 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-08 12:11:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description markzzzsmith 2013-08-24 19:03:12 EDT
Description of problem:

When statically configuring an IPv6 address, with a /64 prefix length, the kernel also adds a route for the /64, pointing out the interface the IPv6 address was configured on. This means the host now considers all addresses within the /64 to be reachable via the interface. IPv4 may have worked this way, but IPv6 does not. A configured address's prefix length doesn't indicate that all other addresses are reachable via the interface, that information has to be supplied via some other mechanism, such as an RA Prefix Information Option with the O or on-link bit set, or separately via manual configuration.

RFC5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" describes the difference between IPv6 and IPv4 in this area, and updates RFC4861, "Neighbor Discovery for IP version 6".

" IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes

Abstract

   IPv6 specifies a model of a subnet that is different than the IPv4
   subnet model.  The subtlety of the differences has resulted in
   incorrect implementations that do not interoperate.  This document
   spells out the most important difference: that an IPv6 address isn't
   automatically associated with an IPv6 on-link prefix.  This document
   also updates (partially due to security concerns caused by incorrect
   implementations) a part of the definition of "on-link" from RFC 4861."


Specific to RFC5942, the kernel is not following rule number one of "4.  Host Rules":

   1.  The assignment of an IPv6 address -- whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
       or manual configuration -- MUST NOT implicitly cause a prefix
       derived from that address to be treated as on-link and added to
       the Prefix List.  A host considers a prefix to be on-link only
       through explicit means, such as those specified in the on-link
       definition in the Terminology section of [RFC4861] (as modified
       by this document) or via manual configuration.  Note that the
       requirement for manually configured addresses is not explicitly
       mentioned in [RFC4861].


Note that the kernel does the right thing when receiving RAs with a Prefix Information Option. If the O bit is switched on for the prefix, the kernel creates an on-link route for the prefix, in conjunction with an address, where as if the O bit is switched off, just the address is configured.

Version-Release number of selected component (if applicable):

F19

How reproducible:

Every time I manually configure an IPv6 address, a corresponding route for the prefix the address falls within is created.

Steps to Reproduce:
1. ip -6 addr add 2001:db8::1/64 dev em1
2. ip -6 route show | grep 2001:db8


Actual results:

[root@opy mark]# ip -6 route show | grep 2001:db8
2001:db8::/64 dev em1  proto kernel  metric 256 
[root@opy mark]#

It is also reproducible using the old ifconfig utility, which would seem to indicate it is the kernel creating this route, rather than the address configuration utility.


Expected results:

[root@opy mark]# ip -6 route show | grep 2001:db8
[root@opy mark]#

When using static addressing, the information that other addresses that fall within 2001:db8::/64 are present on the link needs to be supplied separately, via either an IPv6 Router Advertisement Prefix Information Option, with the O bit switched on, or via a separately configured static route.

Additional info:

Automatic configuration of a prefix route can cause communications failures, as described in section 5. "Observed Incorrect Implementation Behavior" of RFC5942.
Comment 1 Michele Baldessari 2013-09-03 17:46:50 EDT
Hi Mark,

The code for this was added a long time ago via:
commit 46d480468fd9d165513d96f5e545538425d6472d
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date:   Wed Feb 7 20:36:26 2007 +0900

    [IPV6] ADDRCONF: Manage prefix route corresponding to address manually added.
    
    It is more natural to manage prefix routes corresponding to address which is
    being added manually.
    
    With help from Masafumi Aramoto <aramoto@linux-ipv6.org>.
    
    Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>


The RFC came out in 2010 so most likely it has never been updated. 

The best course of action is probably bringing it up on netdev@vger.kernel.org directly.

cheers,
Michele
Comment 2 Josh Boyer 2013-09-18 16:51:06 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 3 Josh Boyer 2013-10-08 12:11:04 EDT
As noted above, please take this up with upstream.

Note You need to log in before you can comment on or make changes to this bug.