[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ipv6 old addresses never deleted



Not strictly arm but this is the only debian list I'm subscribed too and I see this on 2 arm boxes, so....

I recently switched isp and this one has native ipv6 as well as ipv4. I configured nothing on any of those boxes (one running stretch, the other buster), just a static ipv4 address in /etc/network/interfaces.

I found out that, since the router has RA enabled, the boxes get an ipv6 globally routable address. The problem is, when the prefix changes (unfortunately it's not static, the isp assigns a new one on each PPPoE session), the new address is added but the old one is never deleted, e.g.:

$ /sbin/ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.6  netmask 255.255.255.0  broadcast 192.168.10.255
inet6 2a0c:5a84:3105:bd00:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global> inet6 2a0c:5a84:3107:7100:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global> inet6 2a0c:5a84:3307:5700:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global>
        inet6 fe80::ea94:f6ff:fe15:307a  prefixlen 64  scopeid 0x20<link>
inet6 2a0c:5a84:3508:f00:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global> inet6 2a0c:5a84:3605:7a00:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global> inet6 2a0c:5a84:3502:fb00:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global> inet6 2a0c:5a84:3306:9800:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global> inet6 2a0c:5a84:3507:8200:ea94:f6ff:fe15:307a prefixlen 64 scopeid 0x0<global>
        ether e8:94:f6:15:30:7a  txqueuelen 1000  (Ethernet)
        RX packets 24508155  bytes 35335176643 (32.9 GiB)
        RX errors 0  dropped 381074  overruns 0  frame 0
        TX packets 2908835  bytes 269299828 (256.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Only one of those is currently valid:

$ curl icanhazip.com
2a0c:5a84:3105:bd00:ea94:f6ff:fe15:307a


Is there a way to automatically flush the old addresses?

Bye
--
Luca


Reply to: