could use more info.
Largest subnet on ipv4:
2^24
16777216
SMALLEST subnet in ipv6:
2^64
18446744073709551616
1 Like
Just to really emphasise the difference between those two numbers:
16777216 seconds is 0.53 years
18446744073709551616 seconds is 584,542,046,090 (or 584 billion) years.
2 Likes
Funny that if I look at how e.g. EUI-64s are constructed I can clearly see that they will have far less "entropy" than 64 bit implies, so depending on the way the interfaceID is choosen no full search is necesarry, while in IPv4 full scans of all public IPv4 addresses apparently can be done in 45 minutes. My point is that IPv4 scan used to be out of scope as well.
But the IETF has this coved already: RFC7707
similar for the question why interface IDs are 64 bit: RFC7421
Yes, it's certainly possible to use strategies to scan subsections of the address space. Which is a good reason for stable privacy addresses and that brings us back to something like on-topic. By default I think OpenWrt should use stable privacy addresses (or simply randomly generated strings) on its LAN and WAN interfaces rather than just ::1 tokens
Also interestingly enough, my Android phone doesn't use EUI-64 addresses, i'm not sure if they're stable privacy or just random. My Fire Tablets use EUI-64 + rotating privacy addresses. Network Manager on Linux uses stable privacy by default. My servers are Tokenized / manually configured. My HP Printer uses EUI-64... TP-Link Jetstream switch uses EUI but could be manually configged.
According to this at least: https://binblog.info/2017/09/21/ipv6-privacy-stable-addressing-roundup/
stable privacy addresses have been default on MacOS and Windows for a while now.
1 Like
Mmmh in WAN I currently see:
inet6 2a01:c23:8e01:d969:60d2:46db:3897:ed6a/64 scope global dynamic noprefixroute
valid_lft 258518sec preferred_lft 172118sec
I can ping this from the outside just fine.
172118/(606024) = 1.99 days
258518/(606024) = 2.99 days
while br-lan shows:
inet6 2a01:c23:8dd9:6b00::1/60 scope global dynamic noprefixroute
valid_lft 192861sec preferred_lft 106461sec
which I can also ping from the outside....
106461/(606024) = 1.23 days
192861/(606024) = 2.23 days
(life times are actually 24 hours)
In my case WAN seems okay, but br-lan is indeed a bit easy to guess/probe.
Now, I have a bunch of static dhcp leases for IPv4, and I just noticed that these show up in the respective nodes IPv6 addresses:
inet 192.168.42.200/24 brd 192.168.42.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a01:c23:8dd9:6b00::200/64 scope global dynamic noprefixroute
valid_lft 191858sec preferred_lft 105458sec
(24h PPPoE reconnect will exchange my prefix soon, and all my machines are fire-walled, so I accept posting globally reachable IPv6 addresses here has some risk, that I am willing to accept).
That my apparent IPv4-only static leases also show up as IPv6 addresses is somewhat unexpected... I probably should have checked that earlier....
Yeah, definitely, and accessible externally. There's really no need for this super simple tokenized address, since openwrt runs the LAN DNS and can easily hand out its ipv6 via DNS request for openwrt.lan or whatever you call your router hostname. So I think this should be a randomly generated token.
ip6ifaceid option on the lan interface can be set to random instead of the default ::1 token. Not sure how this would impact the LAN clients using the routerâs ULA address for DNS. I assume both the global and the ULA address would both change. Canât test at the moment myself.
Yeah, I'd assume so as well. It seems like that should be the default, though does it do a random one different at each boot? That would be annoying, whereas if it just one time generates a random one and stays the same after that, it'd be good.
In that case, the user can just assign a fixed value in the config, derived from a random number generator, or take the first value provided by random and set it as the fixed value.
Yeah, I'm thinking this should be the default and be done on first boot though.
Itâs done on first boot for the ULA prefix, so it shouldnât be hard to do it for the IPv6 suffix. Any others cons to consider?
I mean, it seems like we know it works already right? it's just a matter of what do we use as the default?
So, I will do a bit more testing, but I am not terribly concerned about the br-lan address being easy to predict, as I consider it a firewall issue mainly... and I am totally fine with ICMPv6 going through the firewall. I also like that I get static DHCPv6 leases (need to research though how to get more than ::::${lat ipv4 octet} as interface
Id for those}. It is just that I had not expected that....
I tried finding it but couldn't, however this was discussed on this forum previously.
In the event a hostid is not specified, odhcpd attempts to use the last octet of the ipv4. If that causes a collision, it then goes back to random assignment.
I feel like I've seen it in an init script rather than in any C code but I'm not sure.
1 Like
I think we should make the distinction between individual protection and "community" protection. It's a little like vaccines. Sure, once you get the vaccine you're at much reduced risk of disease personally. But an additional benefit is that the illness doesn't spread. In this case, setting up an ecosystem where scanning for easily guessable suffixes gets you somewhere is inviting a future where people bother to try scanning for easily guessable prefixes. If, on the other hand, almost nothing has a guessable suffix, then no one will bother in the first place. So while it doesn't really change the security of your router, it does promote a kind of ecology where there aren't a lot of bot-scanning activities going on.
I disagree here, relying on IPv6 addresses being unguessable seems much less reliable than making sure relevant machines are properly firewalled. I have zero trust that run-of-mill IoT devices (if they actually use IPv6) will have get anything right, including generation of privacy addresses. So IMHO the clear message should be "consider all your routed IP addresses exposed" and act to limit/control the fall-out.
To get back to your analogy, trying to maintain a germ free environment is harder than having an immune system to deal with invaders (we fully agree that vaccinations are great 
)
I don't disagree that individual devices need to be firewalled. That's given. If they're firewalled then you might just say "we're done here, as an individual I'm protected" but what we'd like is that there is essentially zero incentive to scan for vulnerable addresses, for various reasons. It's like saying "I have an immune system and hence I don't need to clean my commercial kitchen" keeping the environment clean means less chance of needing to rely 100% on the immune system. Nevertheless, keeping your commercial kitchen clean doesn't mean that you can let heavily immunocompromised people eat there, they should stay in their sterile tent until they can get a transplant (firmware upgrade?)
But then the rest is not necessary any more...
That is IMHO not a realistically feasible goal (there will be sufficiently high numbers of devices where a having a memorable IPv6 address trumps entropy considerations, and so IP scanning will not go away). I also consider it unfortunate if we would perpetually invest 128 bits (the IIDs of the source and the destination) in each IP packet on obfuscation... Kudos for clever planning in a reserve pool of bits for the future (also kudos for currently filling that space with random numbers to avoid premature ossification and firewall heuristics).
Anything less than a /64 breaks SLAAC, and many devices (such as Android phones) are SLAAC-only.