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