From patchwork Mon Jan 6 15:41:49 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Haller X-Patchwork-Id: 307353 X-Patchwork-Delegate: shemminger@vyatta.com Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 69ADB2C00CA for ; Tue, 7 Jan 2014 02:42:11 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755327AbaAFPmG (ORCPT ); Mon, 6 Jan 2014 10:42:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55010 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755218AbaAFPmF (ORCPT ); Mon, 6 Jan 2014 10:42:05 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s06FfwGE008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jan 2014 10:41:59 -0500 Received: from [10.36.116.106] (ovpn-116-106.ams2.redhat.com [10.36.116.106]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s06FfrqU027105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jan 2014 10:41:56 -0500 Message-ID: <1389022909.23397.4.camel@weing> Subject: Re: [patch iproute2 v2 0/2] add support for IFA_F_MANAGETEMPADDR From: Thomas Haller To: Hannes Frederic Sowa Cc: Jiri Pirko , netdev@vger.kernel.org, stephen@networkplumber.org, dcbw@redhat.com Date: Mon, 06 Jan 2014 16:41:49 +0100 In-Reply-To: <20140104113543.GC25828@order.stressinduktion.org> References: <1388676879-2603-1-git-send-email-jiri@resnulli.us> <20140102172949.GF22494@order.stressinduktion.org> <20140104104331.GB9295@minipsycho.orion> <20140104105515.GA25828@order.stressinduktion.org> <20140104110557.GD9295@minipsycho.orion> <20140104111546.GB25828@order.stressinduktion.org> <1388834511.7407.5.camel@weing> <20140104113543.GC25828@order.stressinduktion.org> Organization: Red Hat Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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: 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