| Message ID | 1389022909.23397.4.camel@weing |
|---|---|
| State | Superseded, archived |
| Delegated to: | stephen hemminger |
| Headers | show |
On Mon, Jan 06, 2014 at 04:41:49PM +0100, Thomas Haller wrote: > On Sat, 2014-01-04 at 12:35 +0100, Hannes Frederic Sowa wrote: > > On Sat, Jan 04, 2014 at 12:21:51PM +0100, Thomas Haller wrote: > > > > > >Also, I saw that NetworkManager switched to install autoconf addresses > > > > > >as /128, doesn't this break with IFA_F_MANAGETEMPADDR, as you expect a /64 > > > > > >prefixlen? > > > > > > > > > > /64 is required > > > > > > > > Ok, currently NM seems to "violate" that as it installs autoconf addresses > > > > with 128 prefixlen, so IFA_F_MANAGETEMPADDR should not work on them. > > > > (currently observed on Fedora 20). > > > > > > True, I noticed that too. I think that is a bug in NM to add the > > > addresses as /128. Probably, we will fix that soon. > > > > The change could be valid. Otherwise currently NM could not correctly handle > > prefix information in RAs in some cases: > > > > It is possible to let the client generate an autonomously address in a > > prefix which is actually not on-link (L=0). Kernel would automatically > > create prefix route by mistake, if NM tries to install such an address > > with /64 prefix. This does not happen if the prefix address uses 128 > > prefixlen. > > > > Would be great to have feedback on this, as this could be easily solved by an > > additional ifa_flag. > > > > Greetings, > > > > Hannes > > > > > Hi Hannes, > > > good point. I think, the user-space application (NetworkManager) should > add the autoconf addresses as /64. But the kernel should not generate > any routes in that case. It's up to the application to add them > (depending on the on-link flag). > > > What do you think about something like: I would introduce a new flag for that and also make it accessible via iproute, maybe later. Otherwise IFA_F_MANAGETEMPADDR is overloaded and doesn't do justice to its name. And since Jiri made new room in ifa_flags, it shoud be no problem. ;) Btw. while just reviewing anycast changes, I noticed a funny thing: Kernel does allocate an anycast address which is the same as the autoconf address, if NM installs /128 address and you have ipv6 forwarding enabled (fedora 20 install + ipv6 forwarding because of libvirt). You can see the addresses pop up in /proc/net/anycast6. I currenlty don't know if that is problematic. Everything seems to work here for me. ;) In the end, I don't think we should install anycast for /128, but I am not sure, yet. Greetings, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git i/net/ipv6/addrconf.c w/net/ipv6/addrconf.c index 6c16345..5a4c382 100644 --- i/net/ipv6/addrconf.c +++ w/net/ipv6/addrconf.c @@ -2433,8 +2433,11 @@ static int inet6_addr_add(struct net *net, int ifindex, valid_lft, prefered_lft); if (!IS_ERR(ifp)) { - addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev, - expires, flags); + if (ifa_flags & IFA_F_MANAGETEMPADDR == 0) { + addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev, + expires, flags); + } + /* * Note that section 3.1 of RFC 4429 indicates * that the Optimistic flag should not be set for