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.