[PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.

[PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.

[Glenn Wurster]

There is a bug in the interaction between ipv6_create_tempaddr and 
addrconf_verify.  Because ipv6_create_tempaddr uses the cstamp and tstamp 
from the public address in creating a private address, if we have not 
received a router advertisement in a while, tstamp + temp_valid_lft might be 
< now.  If this happens, the new address is created inside 
ipv6_create_tempaddr, then the loop within addrconf_verify starts again and 
the address is immediately deleted.  We are left with no temporary addresses 
on the interface, and no more will be created until the public IP address is 
updated.  To avoid this, set the expiry time to be the minimum of the time 
left on the public address or the config option PLUS the current age of the 
public interface.

Version 2, now with 100% fewer line wraps.  Thanks to David Miller for
pointing out the line wrapping issue.

Signed-off-by: Glenn Wurster <gwurster@scs.carleton.ca>
---
 net/ipv6/addrconf.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cfee6ae..9c74454 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -836,7 +836,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i
 {
 	struct inet6_dev *idev = ifp->idev;
 	struct in6_addr addr, *tmpaddr;
-	unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp;
+	unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp, age;
 	unsigned long regen_advance;
 	int tmp_plen;
 	int ret = 0;
@@ -886,12 +886,13 @@ retry:
 		goto out;
 	}
 	memcpy(&addr.s6_addr[8], idev->rndid, 8);
+	age = (jiffies - ifp->tstamp) / HZ;
 	tmp_valid_lft = min_t(__u32,
 			      ifp->valid_lft,
-			      idev->cnf.temp_valid_lft);
+			      idev->cnf.temp_valid_lft + age);
 	tmp_prefered_lft = min_t(__u32,
 				 ifp->prefered_lft,
-				 idev->cnf.temp_prefered_lft -
+				 idev->cnf.temp_prefered_lft + age -
 				 idev->cnf.max_desync_factor);
 	tmp_plen = ifp->prefix_len;
 	max_addresses = idev->cnf.max_addresses;
-- 
1.5.6.5

Re: [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.

[David Miller]

From: Glenn Wurster <gwurster@scs.carleton.ca>
Date: Mon, 27 Sep 2010 13:10:10 -0400

> There is a bug in the interaction between ipv6_create_tempaddr and 
> addrconf_verify.  Because ipv6_create_tempaddr uses the cstamp and tstamp 
> from the public address in creating a private address, if we have not 
> received a router advertisement in a while, tstamp + temp_valid_lft might be 
> < now.  If this happens, the new address is created inside 
> ipv6_create_tempaddr, then the loop within addrconf_verify starts again and 
> the address is immediately deleted.  We are left with no temporary addresses 
> on the interface, and no more will be created until the public IP address is 
> updated.  To avoid this, set the expiry time to be the minimum of the time 
> left on the public address or the config option PLUS the current age of the 
> public interface.
> 
> Version 2, now with 100% fewer line wraps.  Thanks to David Miller for
> pointing out the line wrapping issue.
> 
> Signed-off-by: Glenn Wurster <gwurster@scs.carleton.ca>

This can only happen if we apply your other patch, which I showed
was incorrect as per RFCs.

We only create temporary address when public addresses are created,
and this is the point where we are handling a router advertisement
with non-zero Valid Lifetime.

Therefore I'm not applying this patch either.

Re: [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.

[Glenn Wurster]

On September 29, 2010 02:30:28 am David Miller wrote:
> From: Glenn Wurster <gwurster@scs.carleton.ca>
> Date: Mon, 27 Sep 2010 13:10:10 -0400
> 
> > There is a bug in the interaction between ipv6_create_tempaddr and
> > addrconf_verify.  Because ipv6_create_tempaddr uses the cstamp and tstamp
> > from the public address in creating a private address, if we have not
> > received a router advertisement in a while, tstamp + temp_valid_lft might
> > be < now.  If this happens, the new address is created inside
> > ipv6_create_tempaddr, then the loop within addrconf_verify starts again
> > and the address is immediately deleted.  We are left with no temporary
> > addresses on the interface, and no more will be created until the public
> > IP address is updated.  To avoid this, set the expiry time to be the
> > minimum of the time left on the public address or the config option PLUS
> > the current age of the public interface.
> > 
> > Version 2, now with 100% fewer line wraps.  Thanks to David Miller for
> > pointing out the line wrapping issue.
> > 
> > Signed-off-by: Glenn Wurster <gwurster@scs.carleton.ca>
> 
> This can only happen if we apply your other patch, which I showed
> was incorrect as per RFCs.
> 
> We only create temporary address when public addresses are created,
> and this is the point where we are handling a router advertisement
> with non-zero Valid Lifetime.
> 
> Therefore I'm not applying this patch either.

No, the first patch was to create a temporary address if none exists.  Like 
Brian Haley pointed out, that patch accommodates the case where we set 
use_tempaddr to a non-zero value after the interface had been brought up.

This patch accommodates the case where the router is only broadcasting 
advertisements every x seconds, and yet the user has set the valid_lft to be 
something less than x.  In this setup, the condition I mentioned in the patch 
description happens, where the new temporary address is created, but the last 
modification time on that temporary address is set to the time of the last 
router advertisement, which was more than valid_lft seconds ago.  In this 
case, the temporary address is immediately deleted, and we are left with no 
temporary address on the interface.  Furthermore, because all temporary 
addresses get deleted by the time the next router advertisement arrives, we 
are left with not being able to use temporary addresses until we move 
networks.

I tested this patch alone, and it works as intended, allowing temporary 
addresses to continue to be created and deleted between received router 
advertisements.

You can easily test the bug by setting tmp_valid_lft to 60 and then running 
radvd.  The defaults for radvd seem to be a minimum retransmit on unsolicited 
router advertisements of 200 seconds (http://linux.die.net/man/5/radvd.conf), 
much higher than the 60 seconds it is going to take for the temporary address 
to expire. 

Glenn.

Re: [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.

[David Miller]

From: Glenn Wurster <gwurster@scs.carleton.ca>
Date: Sat, 16 Oct 2010 14:42:17 -0400

> This patch accommodates the case where the router is only broadcasting 
> advertisements every x seconds, and yet the user has set the valid_lft to be 
> something less than x.  In this setup, the condition I mentioned in the patch 
> description happens, where the new temporary address is created, but the last 
> modification time on that temporary address is set to the time of the last 
> router advertisement, which was more than valid_lft seconds ago.  In this 
> case, the temporary address is immediately deleted, and we are left with no 
> temporary address on the interface.  Furthermore, because all temporary 
> addresses get deleted by the time the next router advertisement arrives, we 
> are left with not being able to use temporary addresses until we move 
> networks.

Thanks for the information, I'll look into this some more.

Re: [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.

[David Miller]

From: Glenn Wurster <gwurster@scs.carleton.ca>
Date: Sat, 16 Oct 2010 14:42:17 -0400

> No, the first patch was to create a temporary address if none exists.  Like 
> Brian Haley pointed out, that patch accommodates the case where we set 
> use_tempaddr to a non-zero value after the interface had been brought up.
> 
> This patch accommodates the case where the router is only broadcasting 
> advertisements every x seconds, and yet the user has set the valid_lft to be 
> something less than x.

Ok, thanks for your patience.

I've applied both of your patches, thanks.