netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Haller <thaller@redhat.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
	netdev@vger.kernel.org, stephen@networkplumber.org,
	dcbw@redhat.com
Subject: Re: [patch iproute2 v2 0/2] add support for IFA_F_MANAGETEMPADDR
Date: Mon, 06 Jan 2014 16:41:49 +0100	[thread overview]
Message-ID: <1389022909.23397.4.camel@weing> (raw)
In-Reply-To: <20140104113543.GC25828@order.stressinduktion.org>

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-01-06 15:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-02 15:34 [patch iproute2 v2 0/2] add support for IFA_F_MANAGETEMPADDR Jiri Pirko
2014-01-02 15:34 ` [patch iproute2 v2 1/2] add support for extended ifa_flags Jiri Pirko
2014-01-02 15:34 ` [patch iproute2 v2 2/2] add support for IFA_F_MANAGETEMPADDR Jiri Pirko
2014-01-02 15:50   ` [PATCH 1/1] fixup! " Thomas Haller
2014-01-04 10:44     ` Jiri Pirko
2014-01-02 17:29 ` [patch iproute2 v2 0/2] " Hannes Frederic Sowa
2014-01-04 10:43   ` Jiri Pirko
2014-01-04 10:55     ` Hannes Frederic Sowa
2014-01-04 11:05       ` Jiri Pirko
2014-01-04 11:15         ` Hannes Frederic Sowa
2014-01-04 11:21           ` Thomas Haller
2014-01-04 11:35             ` Hannes Frederic Sowa
2014-01-06 15:41               ` Thomas Haller [this message]
2014-01-06 16:01                 ` Hannes Frederic Sowa
2014-01-06 17:29                   ` [PATCH 1/1] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes Thomas Haller
2014-01-06 17:38                     ` Jiri Pirko
2014-01-07  9:39                       ` Hannes Frederic Sowa
2014-01-07 12:01                     ` Hannes Frederic Sowa
2014-01-07 12:14                       ` Thomas Haller
2014-01-07 12:22                         ` Hannes Frederic Sowa
2014-01-07 14:39                     ` [PATCH v2 0/2] " Thomas Haller
2014-01-07 14:39                       ` [PATCH v2 1/2] " Thomas Haller
2014-01-07 14:39                       ` [PATCH v2 2/2] ipv6 addrconf: don't cleanup route prefix for IFA_F_NOPREFIXROUTE Thomas Haller
2014-01-07 16:28                         ` Hannes Frederic Sowa
2014-01-07 18:32                           ` Thomas Haller
2014-01-07 19:01                             ` Hannes Frederic Sowa
2014-01-07 22:54                               ` Thomas Haller
2014-01-07 23:09                                 ` Hannes Frederic Sowa
2014-01-07 16:03                       ` [PATCH v2 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes Hannes Frederic Sowa
2014-01-07 21:42                         ` Thomas Haller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1389022909.23397.4.camel@weing \
    --to=thaller@redhat.com \
    --cc=dcbw@redhat.com \
    --cc=hannes@stressinduktion.org \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).