[alanfranz]

…and they did really guess an ipv6 address? Full scans of the ipv6 address space looks infeasible. Or did the sbc reach out to the internet thus having its address exposed?

Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.

[MobiusHorizons]

I don’t have any idea how they got the ip, it could certainly have been making outbound connections, though. I think it had NTP, although I might have pointed it at a local server we had for that.

[vaylian]

Another possible explanation is that the IP was not random enough. For example: network_prefix::1

[eqvinox]

> I don’t have any idea how they got the ip,

You might've been using DHCPv6 assigning sequential addresses starting at 1?

Remember: friends don't let friends use DHCPv6[*]. Help out, uninstall DHCPv6 today.

[*] in IA_NA mode (address assignment). PD and stateless info-only are fine.

[basilikum]

What's so bad about DHCPv6?

[eqvinox]

In IA_NA mode, you're at the mercy of the DHCPv6 server for any kind of address privacy. And good luck getting a second address if you want to run a CLAT for 464. You don't want this in a home network.

As for servers, you mostly won't want it either, considering (a) you might rather configure things statically, and (b) it's easier to just deal out whole /64s per server, especially since that gives space for VMs.

So where's the niche for DHCPv6? Maybe assigning addresses for telco or OOB equipment… idk.

And just to be clear: DHCPv6 information-only ("stateless") and DHCPv6 prefix delegation modes are perfectly fine. It's the individual address assignment (IA_NA) mode that should just never have been invented.

[commandersaki]

More useless crap to remember for a useless protocol.

[john01dav]

I don't know how much impact this has in practice, but you do not need to scan the entirety of the ipv6 address space because you can just look at the IPs that are registered to known ISPs/ASs.

[jeroenhd]

You're gonna need to scan 2^64 addresses once you've located the IPv6 network assigned to my connection before you find my phone. 2^56 if you don't get lucky guessing the network prefix it happens to be on at that moment.

Assuming a scan with a minimum 4 byte ICMP packet, that's about 73786 petabytes of network traffic for that /64. You'll need to shove it down the pipe within a day because IPv6 privacy extensions means the IPv6 address used changes after 24 hours. With only 1gbps fiber, I don't think the deanonimysation is the problem at that kind of traffic level.

[doubled112]

I'm also not sure how much it helps, but a friend and I were just talking about how big the numbers get today.

My ISP provides my house a /56 allocation. There are 4,722,366,482,869,645,213,696 addresses. I should have enough for a couple of years, at least.

I guess you could scan it. The IPs for most devices are chosen randomly within a /64 subnet, or they're based on MAC address, but they're not sequential by any means. A /64 is still 18,446,744,073,709,551,616 possible IPs.

[globular-toast]

Unfortunately I think one of the problems with v6 is people are just unable to apply intuition to numbers this big. The minimum number of /64s an ISP will have is around 4 billion. They generally give subscribers a /56 which is 256 /64s. It's all simple power-of-2 arithmetic. Computer people used to get how big 2^64 is.

[doubled112]

I agree. Writing out the whole number is intentional.

How many digits is that? Woah, I can barely count the commas!

[jcalvinowens]

Most of the time it's going to be a /64, so even if you know the prefix you're still never going to guess a random address. But a lot of older clients will use a deterministic address based on their MAC, searching the space of MACs for known sbcs would be a lot more tractable.

[wiredpancake]

There was a report a few years back about people running NTP servers to harvest IPv6 addresses.

Security via obscurity will only get you so far.

[Dagger2]

That will only give the NTP server the IP you use for outbound connections. If you use privacy extensions, they'll get a temporary address.

If you don't configure your firewall to allow inbound connections to the temporary address, knowing your temporary address doesn't help them connect back to you. (Also, it's temporary, so their logs of IPs will be useless after a small window.)

Compare this to v4, where connecting out to someone gives them enough information to exhaustively port scan your whole network and trivially find every server you're running.

[dunder_cat]

In theory, IPv6 Privacy Extensions (https://datatracker.ietf.org/doc/html/rfc4941) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.

That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.

[aidenn0]

It's a pain in the ass to configure the /128 setup, particularly when your ISP can change your /64 at any point in time.

[jeroenhd]

If you have a shitty ISP that rotates prefixes like it's 2005, hosting anything public is a massive pain already. DDNS works just as well on IPv6, though.

Internally, a ULA will keep things reachable even if you move ISPs. You could even set up a NAT66 setup to translate your changing prefix to your stable ULA so you don't need to update any firewall rules, but that's a pretty terrible workaround for a problem that shouldn't be on you to fix in the first place.