Bug 13208 - IPv6 Privacy extension doesn't
IPv6 Privacy extension doesn't
Status: RESOLVED DUPLICATE of bug 13221
Product: Networking
Classification: Unclassified
Component: IPV6
All Linux
: P1 normal
Assigned To: Hideaki YOSHIFUJI
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-29 12:27 UTC by Lukasz Stelmach
Modified: 2009-05-03 21:24 UTC (History)
0 users

See Also:
Kernel Version: 2.6.28.9
Tree: Mainline
Regression: No


Attachments
Don't inherit timestamps from a public adress. (1.00 KB, patch)
2009-05-01 21:25 UTC, Lukasz Stelmach
Details | Diff

Description Lukasz Stelmach 2009-04-29 12:27:14 UTC
Let the eth0 be configured as folows

# echo 2 > /proc/sys/net/ipv6/conf/eth0/use_tempaddr
# echo 700 > /proc/sys/net/ipv6/conf/eth0/temp_prefered_lft 
# echo 800 > /proc/sys/net/ipv6/conf/eth0/temp_valid_lft 

after ip link set down/up there are two global addresses. One of them is a temporary address.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>  inet6 2001:6a0:1a0:1:296c:6473:4e12:8794/64 scope global secondary dynamic 
       valid_lft 734sec preferred_lft 34sec
    inet6 2001:6a0:1a0:1:21e:8cff:feab:cdef/64 scope global dynamic 
       valid_lft 86334sec preferred_lft 14334sec
    inet6 fe80::21e:8cff:feab:cdef/64 scope link 
       valid_lft forever preferred_lft forever

After a no more than a minute (look at 2001:6a0:1a0:1:21e:8cff:feab:cdef/64 preferred_lft) there are two deprecated temporary adresses with *equal* both lifetimes.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>  inet6 2001:6a0:1a0:1:807a:a9b0:ada1:d2b5/64 scope global secondary deprecated dynamic 
       valid_lft 687sec preferred_lft 4294967283sec
>>  inet6 2001:6a0:1a0:1:296c:6473:4e12:8794/64 scope global secondary deprecated dynamic 
       valid_lft 687sec preferred_lft 4294967283sec
    inet6 2001:6a0:1a0:1:21e:8cff:feab:cdef/64 scope global dynamic 
       valid_lft 86287sec preferred_lft 14287sec
    inet6 fe80::21e:8cff:feab:cdef/64 scope link 
       valid_lft forever preferred_lft forever

When the next ten minutes passes and the valid_lft's of the temporary addresses expire no new temporary address is generated:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:6a0:1a0:1:21e:8cff:feab:cdef/64 scope global dynamic 
       valid_lft 86041sec preferred_lft 14041sec
    inet6 fe80::21e:8cff:feab:cdef/64 scope link 
       valid_lft forever preferred_lft forever

What I understand about temporary addresses is that there should always be at least one preferred and some valid and deprecated ones. A new address is generated every time the preferred becomes deprecated and all are available until they are valid.
Comment 1 Lukasz Stelmach 2009-05-01 21:25:15 UTC
Created attachment 21184 [details]
Don't inherit timestamps from a public adress.

This patch (created against 091438dd5668396328a3419abcbc6591159eb8d1) fixes only the problem described above, that is imporper aging and expiring of temporary addresses. There need to be yet another one or two to make everything work reliably. For details see Bug #13221.
Comment 2 Lukasz Stelmach 2009-05-03 21:24:45 UTC

*** This bug has been marked as a duplicate of bug 13221 ***

Note You need to log in before you can comment on or make changes to this bug.