This is a Linux-specific way of generating link-locals. It is a bit wrong in one sense, but correct in another. Translate them and you will understand how they are generated. I cheat a bit here, by converting the address to a '6to4' format and then converting them, you can also just take the last 32bits and translate those though: fe80::600e:acf0/64 -> 2002:600e:acf0:: $ ipv6calc -i 2002:600e:acf0:: No input type specified, try autodetection...found type: ipv6addr No output type specified, try autodetection...found type: ipv6addr Address type: unicast, 6to4, global-unicast, productive Address type is 6to4 and included IPv4 address is: 96.14.172.240 .... This is the IPv4 address of one of the interfaces on your host, most likely the Internet facing one. fe80::c0a8:5201/64 -> 2002:c0a8:5201:: $ ipv6calc -i 2002:c0a8:5201:: No input type specified, try autodetection...found type: ipv6addr No output type specified, try autodetection...found type: ipv6addr Address type: unicast, 6to4, global-unicast, productive Address type is 6to4 and included IPv4 address is: 192.168.82.1 .... And that is most likely the one on your local interface, RFC1918, thus behind your NAT. The trick here is that you haven't configured the "local" part of the tunnel device (the sixxs interface), thus the kernel can expect proto-41 packets targeted at both your IPv4 addresses, which is why it generates link-locals for both.