netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] IPV6 address management
@ 2009-01-08 17:34 Stephen Hemminger
  2009-01-08 19:24 ` David Miller
  0 siblings, 1 reply; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-08 17:34 UTC (permalink / raw)
  To: David Miller, 吉藤英明; +Cc: netdev

I notice that with IPV6 when interface is brought down, all addresses
are removed. This looks like intentional behaviour but means the
administrator (or daemon) must reinsert addresses. Since this is not
what the users expect it does lead to confusion.

Maybe the kernel should do this?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 17:34 [RFC] IPV6 address management Stephen Hemminger
@ 2009-01-08 19:24 ` David Miller
  2009-01-08 20:12   ` Stephen Hemminger
  0 siblings, 1 reply; 15+ messages in thread
From: David Miller @ 2009-01-08 19:24 UTC (permalink / raw)
  To: shemminger; +Cc: yoshfuji, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 8 Jan 2009 09:34:30 -0800

> I notice that with IPV6 when interface is brought down, all addresses
> are removed. This looks like intentional behaviour but means the
> administrator (or daemon) must reinsert addresses. Since this is not
> what the users expect it does lead to confusion.
> 
> Maybe the kernel should do this?

After we've had this behavior for as long as we have, I doubt we can
safely change it.

I do agree it is unintuitive, and it also disagrees with ipv4 as you
already know.

There are several crucial areas where our behavior deviates between
ipv4 and ipv6, including this case.  And as more people start making
real use of ipv6 we will see these complaints pop up over and over
again from users.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 19:24 ` David Miller
@ 2009-01-08 20:12   ` Stephen Hemminger
  2009-01-08 20:58     ` David Miller
  0 siblings, 1 reply; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-08 20:12 UTC (permalink / raw)
  To: David Miller; +Cc: yoshfuji, netdev

What about this?

If it works (still testing), I'll submit it.

---
 Documentation/networking/ip-sysctl.txt |    8 ++++++
 include/linux/ipv6.h                   |    2 +
 net/ipv6/addrconf.c                    |   38 +++++++++++++++++++++-----------
 3 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index e2b2894..fa05b06 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -937,6 +937,14 @@ dad_transmits - INTEGER
 	The amount of Duplicate Address Detection probes to send.
 	Default: 1
 	
+delete_address_ifdown - BOOLEAN
+	Delete all addresses on device down
+	Default: TRUE
+
+	When network device is disabled: 
+	  FALSE - only delete temporary addresses (similar to IPV4)
+	  TRUE  - delete all addresses
+
 forwarding - BOOLEAN
 	Configure interface-specific Host/Router behaviour.  
 
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 641e026..b2d219a 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -166,6 +166,7 @@ struct ipv6_devconf {
 #endif
 	__s32		disable_ipv6;
 	__s32		accept_dad;
+	__s32		delete_address_ifdown;
 	void		*sysctl;
 };
 #endif
@@ -200,6 +201,7 @@ enum {
 	DEVCONF_MC_FORWARDING,
 	DEVCONF_DISABLE_IPV6,
 	DEVCONF_ACCEPT_DAD,
+	DEVCONF_DELETE_ADDRESS_IFDOWN,
 	DEVCONF_MAX
 };
 
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2635fa2..9133c20 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -186,6 +186,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
 	.accept_source_route	= 0,	/* we do not accept RH0 by default. */
 	.disable_ipv6		= 0,
 	.accept_dad		= 1,
+	.delete_address_ifdown  = 1,
 };
 
 static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -220,6 +221,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
 	.accept_source_route	= 0,	/* we do not accept RH0 by default. */
 	.disable_ipv6		= 0,
 	.accept_dad		= 1,
+	.delete_address_ifdown  = 1,
 };
 
 /* IPv6 Wildcard Address and Loopback Address defined by RFC2553 */
@@ -2673,19 +2675,20 @@ static int addrconf_ifdown(struct net_device *dev, int how)
 		write_lock_bh(&idev->lock);
 	}
 #endif
-	while ((ifa = idev->addr_list) != NULL) {
-		idev->addr_list = ifa->if_next;
-		ifa->if_next = NULL;
-		ifa->dead = 1;
-		addrconf_del_timer(ifa);
-		write_unlock_bh(&idev->lock);
-
-		__ipv6_ifa_notify(RTM_DELADDR, ifa);
-		atomic_notifier_call_chain(&inet6addr_chain, NETDEV_DOWN, ifa);
-		in6_ifa_put(ifa);
-
-		write_lock_bh(&idev->lock);
-	}
+	if (idev->cnf.delete_address_ifdown)
+		while ((ifa = idev->addr_list) != NULL) {
+			idev->addr_list = ifa->if_next;
+			ifa->if_next = NULL;
+			ifa->dead = 1;
+			addrconf_del_timer(ifa);
+			write_unlock_bh(&idev->lock);
+
+			__ipv6_ifa_notify(RTM_DELADDR, ifa);
+			atomic_notifier_call_chain(&inet6addr_chain,
+						   NETDEV_DOWN, ifa);
+			in6_ifa_put(ifa);
+			write_lock_bh(&idev->lock);
+		}
 	write_unlock_bh(&idev->lock);
 
 	/* Step 5: Discard multicast list */
@@ -3693,6 +3696,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
 #endif
 	array[DEVCONF_DISABLE_IPV6] = cnf->disable_ipv6;
 	array[DEVCONF_ACCEPT_DAD] = cnf->accept_dad;
+	array[DEVCONF_DELETE_ADDRESS_IFDOWN] = cnf->delete_address_ifdown;
 }
 
 static inline size_t inet6_if_nlmsg_size(void)
@@ -4268,6 +4272,14 @@ static struct addrconf_sysctl_table
 			.proc_handler	=	&proc_dointvec,
 		},
 		{
+			.ctl_name	=	CTL_UNNUMBERED,
+			.procname	=	"delete_address_ifdown",
+			.data		=	&ipv6_devconf.delete_address_ifdown,
+			.maxlen		=	sizeof(int),
+			.mode		=	0644,
+			.proc_handler	=	&proc_dointvec,
+		},
+		{
 			.ctl_name	=	0,	/* sentinel */
 		}
 	},
-- 
1.5.6.3


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 20:12   ` Stephen Hemminger
@ 2009-01-08 20:58     ` David Miller
  2009-01-08 21:11       ` Ben Greear
  2009-01-08 21:44       ` Stephen Hemminger
  0 siblings, 2 replies; 15+ messages in thread
From: David Miller @ 2009-01-08 20:58 UTC (permalink / raw)
  To: shemminger; +Cc: yoshfuji, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 8 Jan 2009 12:12:20 -0800

> What about this?
> 
> If it works (still testing), I'll submit it.

So what is your plan?

Make the routing daemons depend upon the non-default
behavior in order to act correctly?

Or is it to gradually get people to use the non-default
(via distribution sysctl settings etc.) and eventually
make it the default?

I disagree with both plans, and with that the facility
is basically useless.

We absolutely have to live with the behavior we have now,
and for a long time if not forever.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 20:58     ` David Miller
@ 2009-01-08 21:11       ` Ben Greear
  2009-01-08 21:44       ` Stephen Hemminger
  1 sibling, 0 replies; 15+ messages in thread
From: Ben Greear @ 2009-01-08 21:11 UTC (permalink / raw)
  To: David Miller; +Cc: shemminger, yoshfuji, netdev

David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 8 Jan 2009 12:12:20 -0800
> 
>> What about this?
>>
>> If it works (still testing), I'll submit it.
> 
> So what is your plan?
> 
> Make the routing daemons depend upon the non-default
> behavior in order to act correctly?

They could check and take corrective action or tell the user
to set it one way or another.  Robust and complex apps already
have to check all sorts of things anyway.

> Or is it to gradually get people to use the non-default
> (via distribution sysctl settings etc.) and eventually
> make it the default?
> 
> I disagree with both plans, and with that the facility
> is basically useless.
> 
> We absolutely have to live with the behavior we have now,
> and for a long time if not forever.

It could be argued we need to have the default behaviour stay
the same, but that's no reason to keep things difficult for
people/programs flexible enough to deal with change.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 20:58     ` David Miller
  2009-01-08 21:11       ` Ben Greear
@ 2009-01-08 21:44       ` Stephen Hemminger
  2009-01-08 21:51         ` David Miller
  1 sibling, 1 reply; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-08 21:44 UTC (permalink / raw)
  To: David Miller; +Cc: yoshfuji, netdev

On Thu, 08 Jan 2009 12:58:30 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 8 Jan 2009 12:12:20 -0800
> 
> > What about this?
> > 
> > If it works (still testing), I'll submit it.
> 
> So what is your plan?
> 
> Make the routing daemons depend upon the non-default
> behavior in order to act correctly?
routing daemons don't deal with addresses directly now,
and getting them to do it would be painful.

> Or is it to gradually get people to use the non-default
> (via distribution sysctl settings etc.) and eventually
> make it the default?
No plan to ever change the default. Just ship with sysctl.conf
setting.

> I disagree with both plans, and with that the facility
> is basically useless.
> 
> We absolutely have to live with the behavior we have now,
> and for a long time if not forever.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 21:44       ` Stephen Hemminger
@ 2009-01-08 21:51         ` David Miller
  2009-01-08 21:56           ` Stephen Hemminger
  0 siblings, 1 reply; 15+ messages in thread
From: David Miller @ 2009-01-08 21:51 UTC (permalink / raw)
  To: shemminger; +Cc: yoshfuji, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 8 Jan 2009 13:44:02 -0800

> On Thu, 08 Jan 2009 12:58:30 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
> 
> > Or is it to gradually get people to use the non-default
> > (via distribution sysctl settings etc.) and eventually
> > make it the default?
> No plan to ever change the default. Just ship with sysctl.conf
> setting.

If the distributions all ship with the sysctl changed
to the non-default, our "default" is pretty meaningless
wouldn't you say?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 21:51         ` David Miller
@ 2009-01-08 21:56           ` Stephen Hemminger
  2009-01-08 21:58             ` David Miller
  0 siblings, 1 reply; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-08 21:56 UTC (permalink / raw)
  To: David Miller; +Cc: yoshfuji, netdev

On Thu, 08 Jan 2009 13:51:25 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 8 Jan 2009 13:44:02 -0800
> 
> > On Thu, 08 Jan 2009 12:58:30 -0800 (PST)
> > David Miller <davem@davemloft.net> wrote:
> > 
> > > Or is it to gradually get people to use the non-default
> > > (via distribution sysctl settings etc.) and eventually
> > > make it the default?
> > No plan to ever change the default. Just ship with sysctl.conf
> > setting.
> 
> If the distributions all ship with the sysctl changed
> to the non-default, our "default" is pretty meaningless
> wouldn't you say?

It seems the only logical way to undo a poor choice
in the original design

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 21:56           ` Stephen Hemminger
@ 2009-01-08 21:58             ` David Miller
  2009-01-08 22:01               ` Stephen Hemminger
  0 siblings, 1 reply; 15+ messages in thread
From: David Miller @ 2009-01-08 21:58 UTC (permalink / raw)
  To: shemminger; +Cc: yoshfuji, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 8 Jan 2009 13:56:14 -0800

> On Thu, 08 Jan 2009 13:51:25 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Thu, 8 Jan 2009 13:44:02 -0800
> > 
> > > On Thu, 08 Jan 2009 12:58:30 -0800 (PST)
> > > David Miller <davem@davemloft.net> wrote:
> > > 
> > > > Or is it to gradually get people to use the non-default
> > > > (via distribution sysctl settings etc.) and eventually
> > > > make it the default?
> > > No plan to ever change the default. Just ship with sysctl.conf
> > > setting.
> > 
> > If the distributions all ship with the sysctl changed
> > to the non-default, our "default" is pretty meaningless
> > wouldn't you say?
> 
> It seems the only logical way to undo a poor choice
> in the original design

If the dists can do it so unilaterally, why can't we?

Everything about these proposals is a contradiction.
That's why I don't like them at all.

I say we keep the behavior, we don't change or break
anything, and people need to learn how to cope with it.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 21:58             ` David Miller
@ 2009-01-08 22:01               ` Stephen Hemminger
  2009-01-08 22:03                 ` David Miller
  0 siblings, 1 reply; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-08 22:01 UTC (permalink / raw)
  To: David Miller; +Cc: yoshfuji, netdev

On Thu, 08 Jan 2009 13:58:19 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 8 Jan 2009 13:56:14 -0800
> 
> > On Thu, 08 Jan 2009 13:51:25 -0800 (PST)
> > David Miller <davem@davemloft.net> wrote:
> > 
> > > From: Stephen Hemminger <shemminger@vyatta.com>
> > > Date: Thu, 8 Jan 2009 13:44:02 -0800
> > > 
> > > > On Thu, 08 Jan 2009 12:58:30 -0800 (PST)
> > > > David Miller <davem@davemloft.net> wrote:
> > > > 
> > > > > Or is it to gradually get people to use the non-default
> > > > > (via distribution sysctl settings etc.) and eventually
> > > > > make it the default?
> > > > No plan to ever change the default. Just ship with sysctl.conf
> > > > setting.
> > > 
> > > If the distributions all ship with the sysctl changed
> > > to the non-default, our "default" is pretty meaningless
> > > wouldn't you say?
> > 
> > It seems the only logical way to undo a poor choice
> > in the original design
> 
> If the dists can do it so unilaterally, why can't we?
> 
> Everything about these proposals is a contradiction.
> That's why I don't like them at all.
> 
> I say we keep the behavior, we don't change or break
> anything, and people need to learn how to cope with it.

Fine, it won't be the first or last vendor specific kernel patch.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 22:01               ` Stephen Hemminger
@ 2009-01-08 22:03                 ` David Miller
  2009-01-08 22:56                   ` Stephen Hemminger
  2009-01-09  1:14                   ` [PATCH] ipv6: address preservation on link down Stephen Hemminger
  0 siblings, 2 replies; 15+ messages in thread
From: David Miller @ 2009-01-08 22:03 UTC (permalink / raw)
  To: shemminger; +Cc: yoshfuji, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 8 Jan 2009 14:01:22 -0800

> Fine, it won't be the first or last vendor specific kernel patch.

You're just supporting my argument even more.

If all the dists ship it and turn it on, then logically we should
include it and have it on by default.

But you know we can't do that.

Therefore, it's detrimental for the dists to ship it too because it
does break things.

I know you want to shove this in, via some avenue, but it is really
so undesirable to cope with existing behavior?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] IPV6 address management
  2009-01-08 22:03                 ` David Miller
@ 2009-01-08 22:56                   ` Stephen Hemminger
  2009-01-09  1:14                   ` [PATCH] ipv6: address preservation on link down Stephen Hemminger
  1 sibling, 0 replies; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-08 22:56 UTC (permalink / raw)
  To: David Miller; +Cc: yoshfuji, netdev

On Thu, 08 Jan 2009 14:03:39 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 8 Jan 2009 14:01:22 -0800
> 
> > Fine, it won't be the first or last vendor specific kernel patch.
> 
> You're just supporting my argument even more.
> 
> If all the dists ship it and turn it on, then logically we should
> include it and have it on by default.
> 
> But you know we can't do that.
> 
> Therefore, it's detrimental for the dists to ship it too because it
> does break things.
> 
> I know you want to shove this in, via some avenue, but it is really
> so undesirable to cope with existing behavior?

Reading back in the archives, this has come up before. The real problem
is that when link goes down and comes back the address needs to be
reverified for DAD. Maybe instead of deleting addresses they should
be moved to another list for restart.

It is a real problem for routing daemons like hostapd and zebra since
the kernel address deletion looks a lot like a user address deletion.
Since Vyatta has the luxury of a configuration/scripting layer, this
means the state space is contained (we know what the address was),
I'll just hack around it there for now until a better solution arises.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH] ipv6: address preservation on link down
  2009-01-08 22:03                 ` David Miller
  2009-01-08 22:56                   ` Stephen Hemminger
@ 2009-01-09  1:14                   ` Stephen Hemminger
  2009-01-09  8:02                     ` Rémi Denis-Courmont
  1 sibling, 1 reply; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-09  1:14 UTC (permalink / raw)
  To: David Miller, yoshfuji; +Cc: netdev

When an interface goes down, IPV6 deletes all addresses unlike IPV4. This
is a problem since it can break routing protocols and other applications.
It looks like this was done to handle DAD, but is a big stick solution when
other code is possible.

The following patch changes the behaviour to delete link local addresses
but keep all configured addresses and restart DAD when interface comes back up.

See also: https://kerneltrap.org/mailarchive/linux-netdev/2008/3/25/1252064/thread

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>


--- a/net/ipv6/addrconf.c	2009-01-08 16:43:04.921305933 -0800
+++ b/net/ipv6/addrconf.c	2009-01-08 16:47:04.000301344 -0800
@@ -2678,18 +2678,26 @@ static int addrconf_ifdown(struct net_de
 		write_lock_bh(&idev->lock);
 	}
 #endif
-	while ((ifa = idev->addr_list) != NULL) {
-		idev->addr_list = ifa->if_next;
-		ifa->if_next = NULL;
-		ifa->dead = 1;
-		addrconf_del_timer(ifa);
-		write_unlock_bh(&idev->lock);
-
-		__ipv6_ifa_notify(RTM_DELADDR, ifa);
-		atomic_notifier_call_chain(&inet6addr_chain, NETDEV_DOWN, ifa);
-		in6_ifa_put(ifa);
-
-		write_lock_bh(&idev->lock);
+	/* clear regular address list on removal */
+	bifa = &idev->addr_list;
+	while ((ifa = *bifa) != NULL) {
+		if (how || (ipv6_addr_type(&ifa->addr) & IPV6_ADDR_LINKLOCAL)) {
+			*bifa = ifa->if_next;
+			ifa->if_next = NULL;
+			ifa->dead = 1;
+			addrconf_del_timer(ifa);
+			write_unlock_bh(&idev->lock);
+
+			__ipv6_ifa_notify(RTM_DELADDR, ifa);
+			atomic_notifier_call_chain(&inet6addr_chain, NETDEV_DOWN, ifa);
+			in6_ifa_put(ifa);
+
+			write_lock_bh(&idev->lock);
+		} else {
+			/* Force duplicate address detection when link resumes */
+			ifa->flags |= IFA_F_TENTATIVE;
+			bifa = &ifa->if_next;
+		}
 	}
 	write_unlock_bh(&idev->lock);
 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ipv6: address preservation on link down
  2009-01-09  1:14                   ` [PATCH] ipv6: address preservation on link down Stephen Hemminger
@ 2009-01-09  8:02                     ` Rémi Denis-Courmont
  2009-01-09 17:31                       ` Stephen Hemminger
  0 siblings, 1 reply; 15+ messages in thread
From: Rémi Denis-Courmont @ 2009-01-09  8:02 UTC (permalink / raw)
  To: ext Stephen Hemminger; +Cc: David Miller, yoshfuji, netdev

On Friday 09 January 2009 03:14:15 ext Stephen Hemminger, you wrote:
> When an interface goes down, IPV6 deletes all addresses unlike IPV4. This
> is a problem since it can break routing protocols and other applications.
> It looks like this was done to handle DAD, but is a big stick solution when
> other code is possible.
>
> The following patch changes the behaviour to delete link local addresses
> but keep all configured addresses and restart DAD when interface comes back
> up.

Let alone the backward compatibility problem for a minute. I have two _other_ 
problems with this:

1/ If DAD should fail when the interface is brought back up, wouldn't all the 
EAU-64 autoconfigured address become invalid, rather than just the link-local 
one?

2/ In some case the link-local address is assigned by userland, no different 
from the other ones. At least miredo is behaving this way.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ipv6: address preservation on link down
  2009-01-09  8:02                     ` Rémi Denis-Courmont
@ 2009-01-09 17:31                       ` Stephen Hemminger
  0 siblings, 0 replies; 15+ messages in thread
From: Stephen Hemminger @ 2009-01-09 17:31 UTC (permalink / raw)
  To: Rémi Denis-Courmont; +Cc: David Miller, yoshfuji, netdev

On Fri, 9 Jan 2009 10:02:06 +0200
"Rémi Denis-Courmont" <remi.denis-courmont@nokia.com> wrote:

> On Friday 09 January 2009 03:14:15 ext Stephen Hemminger, you wrote:
> > When an interface goes down, IPV6 deletes all addresses unlike IPV4. This
> > is a problem since it can break routing protocols and other applications.
> > It looks like this was done to handle DAD, but is a big stick solution when
> > other code is possible.
> >
> > The following patch changes the behaviour to delete link local addresses
> > but keep all configured addresses and restart DAD when interface comes back
> > up.
> 
> Let alone the backward compatibility problem for a minute. I have two _other_ 
> problems with this:
> 
> 1/ If DAD should fail when the interface is brought back up, wouldn't all the 
> EAU-64 autoconfigured address become invalid, rather than just the link-local 
> one?
> 
> 2/ In some case the link-local address is assigned by userland, no different 
> from the other ones. At least miredo is behaving this way.
> 

1: The address DAD path is same as the initial setup. I.e. it is same as if
   the address was added manually (after ifup)
2: New patch honors the permanent flag. Another alternative would be to add a new
   IFA_F_DYNAMIC flag

Updated patch that combines earlier efforts..
---

By default, IPV6 deletes all addresses when an interface is deconfigured.
This behaviour is different the IPV4 and confusing, so make it optional.
Add a new sysctl /proc/sys/net/ipv6/conf/ethX/address_flush that controls this.

The new behaviour that happens only if address_flush is set to zero is:
  * all addresses are flushed on device deletion
  * linklocal addresses are flushed unless the permanent flag is set
  * other addresses are saved but duplicate address detection is restarted
    unless nodad flag has been set.



---
 Documentation/networking/ip-sysctl.txt |    9 +++++
 include/linux/ipv6.h                   |    2 +
 net/ipv6/addrconf.c                    |   50 ++++++++++++++++++++++++++-------
 3 files changed, 51 insertions(+), 10 deletions(-)

--- a/Documentation/networking/ip-sysctl.txt	2009-01-09 08:48:56.701039688 -0800
+++ b/Documentation/networking/ip-sysctl.txt	2009-01-09 09:23:13.208788522 -0800
@@ -925,6 +925,15 @@ accept_source_route - INTEGER
 
 	Default: 0
 
+address_flush - BOOLEAN
+	Flush all addresses when link goes down
+	Default: TRUE
+
+	When network device is set to admin down:
+	  TRUE  - Delete all addresses
+	  FALSE - Only addresses that are temporary or linklocal and not permanent
+	          are deleted. Other addresses restart DAD (if configured).
+
 autoconf - BOOLEAN
 	Autoconfigure addresses using Prefix Information in Router 
 	Advertisements.
--- a/include/linux/ipv6.h	2009-01-09 08:49:14.170039111 -0800
+++ b/include/linux/ipv6.h	2009-01-09 08:57:33.592912530 -0800
@@ -166,6 +166,7 @@ struct ipv6_devconf {
 #endif
 	__s32		disable_ipv6;
 	__s32		accept_dad;
+	__s32		address_flush;
 	void		*sysctl;
 };
 #endif
@@ -200,6 +201,7 @@ enum {
 	DEVCONF_MC_FORWARDING,
 	DEVCONF_DISABLE_IPV6,
 	DEVCONF_ACCEPT_DAD,
+	DEVCONF_ADDRESS_FLUSH,
 	DEVCONF_MAX
 };
 
--- a/net/ipv6/addrconf.c	2009-01-09 08:48:48.184789198 -0800
+++ b/net/ipv6/addrconf.c	2009-01-09 09:15:53.288788798 -0800
@@ -186,6 +186,7 @@ static struct ipv6_devconf ipv6_devconf 
 	.accept_source_route	= 0,	/* we do not accept RH0 by default. */
 	.disable_ipv6		= 0,
 	.accept_dad		= 1,
+	.address_flush  = 1,
 };
 
 static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -220,6 +221,7 @@ static struct ipv6_devconf ipv6_devconf_
 	.accept_source_route	= 0,	/* we do not accept RH0 by default. */
 	.disable_ipv6		= 0,
 	.accept_dad		= 1,
+	.address_flush  = 1,
 };
 
 /* IPv6 Wildcard Address and Loopback Address defined by RFC2553 */
@@ -2678,18 +2680,37 @@ static int addrconf_ifdown(struct net_de
 		write_lock_bh(&idev->lock);
 	}
 #endif
-	while ((ifa = idev->addr_list) != NULL) {
-		idev->addr_list = ifa->if_next;
-		ifa->if_next = NULL;
-		ifa->dead = 1;
-		addrconf_del_timer(ifa);
-		write_unlock_bh(&idev->lock);
+	/* clear regular address list on removal */
+	bifa = &idev->addr_list;
+	while ((ifa = *bifa) != NULL) {
+		if (how || idev->cnf.address_flush ||
+		    ((ipv6_addr_type(&ifa->addr) & IPV6_ADDR_LINKLOCAL)
+		     && !(ifa->flags & IFA_F_PERMANENT))) {
+			*bifa = ifa->if_next;
+			ifa->if_next = NULL;
+			ifa->dead = 1;
+			addrconf_del_timer(ifa);
+			write_unlock_bh(&idev->lock);
+
+			__ipv6_ifa_notify(RTM_DELADDR, ifa);
+			atomic_notifier_call_chain(&inet6addr_chain, NETDEV_DOWN, ifa);
+			in6_ifa_put(ifa);
 
-		__ipv6_ifa_notify(RTM_DELADDR, ifa);
-		atomic_notifier_call_chain(&inet6addr_chain, NETDEV_DOWN, ifa);
-		in6_ifa_put(ifa);
+			write_lock_bh(&idev->lock);
+			continue;
+		}
 
-		write_lock_bh(&idev->lock);
+		bifa = &ifa->if_next;
+		if (ifa->flags & IFA_F_NODAD)
+			continue;
+
+		/* Retain address but force DAD */
+		ifa->flags |= IFA_F_TENTATIVE;
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+		if (idev->cnf.optimistic_dad &&
+		    !dev_net(idev->dev)->ipv6.devconf_all->forwarding)
+			ifa->flags |= IFA_F_OPTIMISTIC;
+#endif
 	}
 	write_unlock_bh(&idev->lock);
 
@@ -3697,6 +3718,7 @@ static inline void ipv6_store_devconf(st
 #endif
 	array[DEVCONF_DISABLE_IPV6] = cnf->disable_ipv6;
 	array[DEVCONF_ACCEPT_DAD] = cnf->accept_dad;
+	array[DEVCONF_ADDRESS_FLUSH] = cnf->address_flush;
 }
 
 static inline size_t inet6_if_nlmsg_size(void)
@@ -4271,6 +4293,14 @@ static struct addrconf_sysctl_table
 			.proc_handler	=	proc_dointvec,
 		},
 		{
+			.ctl_name	=	CTL_UNNUMBERED,
+			.procname	=	"address_flush",
+			.data		=	&ipv6_devconf.address_flush,
+			.maxlen		=	sizeof(int),
+			.mode		=	0644,
+			.proc_handler	=	&proc_dointvec,
+		},
+		{
 			.ctl_name	=	0,	/* sentinel */
 		}
 	},

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2009-01-09 17:31 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-08 17:34 [RFC] IPV6 address management Stephen Hemminger
2009-01-08 19:24 ` David Miller
2009-01-08 20:12   ` Stephen Hemminger
2009-01-08 20:58     ` David Miller
2009-01-08 21:11       ` Ben Greear
2009-01-08 21:44       ` Stephen Hemminger
2009-01-08 21:51         ` David Miller
2009-01-08 21:56           ` Stephen Hemminger
2009-01-08 21:58             ` David Miller
2009-01-08 22:01               ` Stephen Hemminger
2009-01-08 22:03                 ` David Miller
2009-01-08 22:56                   ` Stephen Hemminger
2009-01-09  1:14                   ` [PATCH] ipv6: address preservation on link down Stephen Hemminger
2009-01-09  8:02                     ` Rémi Denis-Courmont
2009-01-09 17:31                       ` Stephen Hemminger

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).