Avoid announcing SLAAC addresses without privacy extention

[RubenKelevra]

SLAAC can provide two different types of IPv6-addresses.

Since the default profile is more geared towards end-users, and the server profile more geared towards server usage it's to be expected, that home users most likely run the default profile.

Currently, IPFS would announce all IPv6 addresses, (including private ones see #6926,) which also include the SLAAC-address without the privacy extension (defined in RFC4941).

Please add a filter that blocks the usage of all SLAAC-addresses which have no privacy extension activated to avoid leaking private information to the internet.

[Stebalien]

Wouldn't that break IPv6 for these nodes? This sounds like something that needs to be fixed elsewhere, unless I'm missing something.

[RubenKelevra]

The idea was, to not-announce the global static IPv6 from SLAAC when there's a temporary IP assigned. This should be portable.

Since go has no functionality build in to detect if an IPv6 is temporary, I think we should approach it this way:

• We get all available IPv6 addresses from all interfaces, then drop the fe80 and local addresses.
• Then we convert all IPv6 to binary and check if the bytes are set to "ff:fe" (which means it's an address from SLAAC which was generated from the mac).
• If there's another global IPv6 on this interface, we drop the SLAAC address from the list of addresses we announce.

---

The privacy extension IPv6-addresses have a temporary flag attached. It might be possible to get the flag from the socket, haven't looked into that.

ip addr shows them like this:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
 inet6 2001:4dd0:f90c:0:3:36f3:e3e4:99d3/64 scope global temporary dynamic
 valid_lft 7008sec preferred_lft 3408sec
 inet6 2001:4dd0:f90c:0:20c:29ff:fe36:e29d/64 scope global dynamic
 valid_lft 7008sec preferred_lft 3408sec
 inet6 fe80::20c:29ff:fe36:e29d/64 scope link
 valid_lft forever preferred_lft forever

[Stebalien]

Ah, I see.

• We do drop fe80 addresses.
• We don't yet drop localhost addresses because that would break localhost DHTs (issue [META] Private Addresses In Public #6932).

WRT SLAAC, we could look at the MAC address and match against that. If we have multiple addresses, we can exclude the stable one.

[RubenKelevra]

With 'local' addresses I was referring to IPv6 privat network addresses, not link-local, called unique local addresses within fc00::/7.

They shouldn't be announced either.

---

Sounds like a plan! :)

[RubenKelevra]

This can be closed as #6932 covers it. :)