Reverse DNS IPv4 Map
reversedns.space
reversedns.space
There is also a presentation about it: https://presentations.clickhouse.com/meetup85/app/
Something to add, perhaps, is some sort of map marker and compass per zoom level? What part of the IPv4 space am I seeing, and what are the neighbours? Perhaps you've seen https://map.bgp.tools/ as well?
Small feature idea: "find my ip" which zooms to/selects the apparent ip of the current visitor.
For octets closer to the center of their highest order square it was quite easy by just trial and error. But for octets at the edge of their square like e.g. 149 I admit having used pen and paper...
It says the the intent was to make it similar to https://xkcd.com/195/ , i.e. with a space filling curve that preserves grouping, but actual implementation doesn't seem to do that. For example, the upper left squares are:
0 1
2 3
0 1
3 2
* Obviously for all of the same color it makes no difference
* For all 4 of different colors the pattern still does not change, it's just randomly colored
* In case of 2 colors it's highly likely that the first half will have one color and the second one another. Nothing changes.
* In the less likely case the 3 have one color and the remaining one is different the resulting pattern is a triangle. So the direction of the diagonal will flip. But I don't think the overall impression will change.
In higher level squares replace "color" by "pattern", still no significant changes in appearance. Of course the two lower squares always swap their location.
I have tried to rearrange the pixels to see if there is any resemblance, here:
https://gist.github.com/uguu-org/5dadec83394d9ba5ea88e0f6e25...
> Total size: 77.7 TB
biiiig daaaaaata
But is that huge allocation really extensively used in real life? How?
Or could a significant part just be reallocated for new unicast usage?
240.0.0.0/4 could conceivably be assigned. It's not really in use as it was actually reserved for "future use" from the beginning. That said, if you want to use that space publicly in any reliably usable form you've still got to convince near the entire internet to update their stuff to support/allow it. On this front I'm actually kind of against opening it up even just for internal use as it'd just create another headache to check for and not be particularly reliable. For "extra internal space" 0.0.0.0/8 was in a similar situation and already opened up. If that's not enough for you then you desperately need to move on from IPv4 already.
Was it 1.1.1.1 that had quite some problems in the beginning of their operation or some similar one? I vaguely remember reading a blog post at the time.
1.1.1.1 was never reserved but it was unassigned until 2010. By that point it had been used improperly so much it received massive amounts of garbage data when advertised (and still does to this day). It's just that "massive" turns to "quite tiny" in context of a giant CDN like Cloudflare so they were able to salvage it.
A lot of reserved ranges could've been made smaller, 127.0.0.0/8 is JUST loopback, that's over 16 million ips just for loopback! 0.0.0.0/8 is also just absurd
224.0.0.0/4 and 240.0.0.0/4 are also crazy... over 500 million ips.
I probably wouldn't care about it if we didn't have ipv4 exhaustion (which is in my opinion is at least partially the US govt's fault, because they're hoarding 200+ million ips)
Of course, we could've used /80 as the smallest possible prefix for auto-negotiation, leaving more room for playing with prefixes but it is what it is. Nobody sane will wait another 20-25 years before any kind of change is widespread in all the stacks. Even less people will care about the reserved/multicast space, 0/32 or 127.0.0.0/24 because it is so much work for little benefit as it will never be supported by all the legacy systems that care about IPv4 since for them there is no IPv6. We should all concentrate on IPv6 and get on with the colossal migration. Even HN supports IPv6 as of this year!
Only thing standing in our way is the IPv6 proponents who know address space exhaustion is the only thing that will drive adoption of an otherwise shitty idea.
In some cases, you can "just" add a reverse proxy in front of the legacy services or use some kind of NAT64/ DNS64 setup on the server side. Internal systems can expect IPv4 only for addresses for some kind of accounting, configuration etc. But internal systems that you cannot evolve to support current requirements are a burden anyway. There might be other debt that keeps getting postponed because of these things.
I have had a client tell me that some services cannot get a different IPv4 because they don't know about all the things that only know it by its IP instead of its DNS name. I am pretty sure that as a man made software system their system could definitely switch to a different address with some preparation but I am not going to push for it too hard. (It would allow improving the segmentation of their network in turn making it easier to firewall things in a simpler manner. Also, with L3 switches now commonplace it is no longer a question of performance.)
If your family is starving do you look over at a plate of sandwiches and say "we better not eat those, it is just a temporary relief" or do you use the available resources to solve the problem.
Even if we scan just the first address of each /64, it’s still about 2^56. Unlikely anyone is ever going to do it.
This is another thing I like about IPv6. Makes mass address scanning completely useless.
And that’s a detail, but SLAAC as in RFC4842 is deterministic. The randomization is introduced by the privacy extensions in RFC4941.
But in general devices using SLAAC are not typically the things you are looking for when scanning.