valid_lft and active connections
Subsystems (2)
Hi,
I have the following problem:
If I use ipv6 addresses with valid_lft != forever, the ipv6 addresses are removed from the interface if the valid_lft expires, even if there're established connection which use with address.
Would it be possible keep the address until the last active connection is closed? Otherwise the usable of the privacy extensions will make very long living tcp connections impossible.
It would be also ok to add a new special value "used" similar to "forever", which triggers the modified behavior.
metze
Hello.
Quoted 8 lines · Stefan (metze) Metzmacher
If I use ipv6 addresses with
valid_lft!= forever, the ipv6 addresses are removed from the interface if thevalid_lftexpires, even if there're established connection which use with address.Would it be possible keep the address until the last active connection is closed? Otherwise the usable of the privacy extensions will make very long living tcp connections impossible.
I cannot imagine why you do not hear RAs before the address expires.
And well, I don't think it is a good idea because it is not what "valid lifetime" means.
We have 3 states:
1) time <= preferred lifetime
2) preferred lifetime < time <= valid lifetime
3) valid lifetime < lifetime
You can make new connection during the period of 1 and you can continue using that connection during the period of 1 and 2.
Ask network administrator to advertise longer "valid" lifetime, if needed, and you may want to make net.ipv6.conf.*.max_addresses larger.
Quoted 2 lines
It would be also ok to add a new special value "used" similar to "forever", which triggers the modified behavior.
???
--yoshfuji
Am 14.06.2011 13:41, schrieb YOSHIFUJI Hideaki:
Quoted 7 lines
Hello.
Quoted 4 lines · Stefan (metze) Metzmacher
If I use ipv6 addresses with
valid_lft!= forever, the ipv6 addresses are removed from the interface if thevalid_lftexpires, even if there're established connection which use with address.
Quoted 6 lines
Quoted 4 lines
Would it be possible keep the address until the last active connection is closed? Otherwise the usable of the privacy extensions will make very long living tcp connections impossible.
I cannot imagine why you do not hear RAs before the address expires.
They do not reset the valid lifetime counter for temporary addresses.
And I think that valid_lft and preferred_lft should work with a manual configured setup in a similar way.
Quoted 11 lines
And well, I don't think it is a good idea because it is not what "valid lifetime" means.
We have 3 states:
1) time <= preferred lifetime
2) preferred lifetime < time <= valid lifetime
3) valid lifetime < lifetimeYou can make new connection during the period of 1 and you can continue using that connection during the period of 1 and 2.
But it means tcp connection can not last longer than the valid lifetime of a temporary address, which is very ugly as the application layer will run into
timeouts instead of getting an immediate error when the kernel drops the related ip.
Quoted 2 lines
Ask network administrator to advertise longer "valid" lifetime, if needed, and you may want to make net.ipv6.conf.*.max_addresses larger.
My aim is to have a preferred lifetime of say 4 hours, in order to have no limit
on the lifetime of tcp connections, I'd have to set valid lifetime to forever,
which means that I'll have about 180 addresses on an interface after a month (8760 after a year) which are mostly all unused.
I think there should be some autocleanup based on the usage of addresses, maybe there's a different solution for the problem.
Maybe RAs should reset the valid_lft of temporary addresses (from autoconfiguration)
if the ip is in use? In which case I would accept that I need to do the cleanup
in user space via cron, if I assign dynamic addresses also via cron.
Quoted 2 lines
Quoted 2 lines
It would be also ok to add a new special value "used" similar to "forever", which triggers the modified behavior.
ip -6 addr add $addr valid_lft used preferred_lft 14400 would be nice to have.
It will add $addr which will be used for new connections for the next 4 hours,
if it's unused then it gets deleted, if not it stays until the last connection went away.
But I would preferr if such a bahavior would be the default, so that I can use:
ip -6 addr add $addr valid_lft 28800 preferred_lft 14400, which mean that $addr will be used for new connections during the next 4 hours,
$addr will stay at least for the next 8 hours, if they're still active connections
and the same interface has an other ip with the same prefix it stays until the last connection went away.
And the same logic would apply to addresses assigned via autoconfiguration.
Do you know a better solution?
metze
Quoted 13 lines · Stefan (metze) Metzmacher
Am 14.06.2011 13:41, schrieb YOSHIFUJI Hideaki:
Quoted 12 lines
Hello.
Quoted 8 lines · Stefan (metze) Metzmacher
If I use ipv6 addresses with
valid_lft!= forever, the ipv6 addresses are removed from the interface if thevalid_lftexpires, even if there're established connection which use with address.Would it be possible keep the address until the last active connection is closed? Otherwise the usable of the privacy extensions will make very long living tcp connections impossible.
Quoted 6 lines
Quoted 1 line
I cannot imagine why you do not hear RAs before the address expires.
They do not reset the valid lifetime counter for temporary addresses.
And I think that
valid_lftandpreferred_lftshould work with a manual configured setup in a similar way.
This is because of RFC3041 Section 3.3:
| 1) Process the Prefix Information Option as defined in [ADDRCONF], | either creating a public address or adjusting the lifetimes of | existing addresses, both public and temporary. When adjusting the | lifetimes of an existing temporary address, only lower the | lifetimes. Implementations must not increase the lifetimes of an | existing temporary address when processing a Prefix Information | Option.
It would be make sense to allow extending valid lifetime of non-deprecated addresses, but not sure.
Quoted 9 lines
Quoted 9 lines
And well, I don't think it is a good idea because it is not what "valid lifetime" means.
We have 3 states:
1) time <= preferred lifetime
2) preferred lifetime < time <= valid lifetime
3) valid lifetime < lifetime
Quoted 9 lines
Quoted 2 lines
You can make new connection during the period of 1 and you can continue using that connection during the period of 1 and 2.
But it means tcp connection can not last longer than the valid lifetime of a temporary address, which is very ugly as the application layer will run into
timeouts instead of getting an immediate error when the kernel drops the related ip.
Valid lifetime represents administrative "hard" lifetime. If it expired, all address must be gone.
Quoted 9 lines
Quoted 2 lines
Ask network administrator to advertise longer "valid" lifetime, if needed, and you may want to make net.ipv6.conf.*.max_addresses larger.
My aim is to have a preferred lifetime of say 4 hours, in order to have no limit
on the lifetime of tcp connections, I'd have to set valid lifetime to forever,
which means that I'll have about 180 addresses on an interface after a month (8760 after a year) which are mostly all unused.
This is how it works.
How can you determine if one address is not unused at all? For UDP, applications only know, for example.
In fact, RFC3041 Section 3.4 says:
| As an optional optimization, an implementation may wish to remove a | deprecated temporary address that is not in use by applications or | upper-layers. For TCP connections, such information is available in | control blocks. For UDP-based applications, it may be the case that | only the applications have knowledge about what addresses are | actually in use. Consequently, one may need to use heuristics in | deciding when an address is no longer in use (e.g., the default | TEMP_VALID_LIFETIME suggested above).
Of course, we could have some sysctl (but default must be off (or moderate; do it if the number addresses exceeds some limit).
Quoted 1 line
Do you know a better solution?
Ask your administrator to advertise larger valid lifetime. Otherwise, other implementation will have similar issues, anyway.
We could have above "optimization" with sysctl.
And, please note that if you want to change address preference in an application, consider using IPV6_ADDR_PREFERENCES socket option.
--yoshfuji