Digging Coordinates; Gitmal; A Different Kind Of Packets For IPv6

This has been a week. My entire Thursday and Friday were consumed with React2Shell. If you have no idea what that is, don’t click the link. You are better off being in blissful ignorance of this most recent tech debacle. If, however, you like chaos, this is being updated a couple of times a day.

So, I’m chillin’ as much as possible this weekend, which leave plenty of time to make up for two missed Drops with what is hopefully a solid Bonus Drop.

---

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop. This week, I have been — for lack of a better word — forced into using Gemini, so today’s summary was provided by that model. Sigh.)

• The LOC DNS record, defined in RFC 1876 in 1996, allows for publishing the geographical coordinates (latitude, longitude, and altitude) of hosts, networks, and subnets, although its adoption is limited as most systems prefer IP geolocation databases for scale and privacy concerns (https://www.rfc-editor.org/rfc/rfc1876.html).
• Gitmal is a fast, theme-supported tool for self-hosting Git repositories that generates browseable file trees, nicely rendered markdown, and commit history pages, providing a much prettier alternative to the default rendered git pages (https://github.com/antonmedv/gitmal).
• A new IETF draft proposes allocating the IPv6 address block 44::/16 to the amateur radio (ham) community to replace their historical 44.0.0.0/8 IPv4 allocation, preserving their globally coordinated and routable address space for non-commercial and emergency communications (https://datatracker.ietf.org/doc/draft-ursini-44net-ipv6-allocation/).

---

Digging Coordinates

We Drop denizens loves us some RFCs, and way back in the before-times (in this case, January 1996), some smart, adorable technologists thought it would be a great idea to lay the foundations for our modern surveillance state by introducing a means of telling the world exactly where your “thing” was with a DNS record. Said record is LOC, and is intended to “describe a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. Such information for a small subset of hosts is currently contained in the flat-file UUCP maps. However, just as the DNS replaced the use of HOSTS.TXT to carry host and network address information, it is possible to replace the UUCP maps as carriers of location information.”

Thankfully, nobody really adopted use of LOC, since most systems that care about geography rely on IP geolocation databases (like MaxMind) instead of asking DNS for coordinates. It’s just easier to manage that data at scale and fits how routing and targeting are typically done. There’s also a real hesitation to publish precise latitude, longitude, and altitude in public DNS, since that can create privacy or security headaches. And for most services, exact physical coordinates just aren’t that useful anyway: CDNs and other geo-aware systems usually make decisions based on IP-derived signals, not “this server is at these coordinates.” One more practical detail is that the LOC record’s defining document, RFC 1876, was published as experimental rather than as an full internet standard, which tends to limit adoption. That said, LOC records do show up occasionally in niche situations, like internal network documentation and mapping, novelty “Easter egg” uses, or specialized cases where someone has a specific reason to publish precise location data in DNS.

There are a handful of them out there, and bo0tzz decided to map them all. One of them is even setup by my state (O_o):

Full source is available, and the folks working on it have even bothered to credit Claude (so, if “AI”-assisted coding and resultant apps are anathema to you, you can avoid tapping any of the links).

---

Gitmal

I’m seeing a very positive trend in the increasing number of clever folks abandoning GitHub. Many of them are going to Codeberg, with a smattering of others picking different new homes. However, we’ve noted on many an occasion that you can just use SSH to keep a remote Git repo up-to-date and rely solely on self-hosting. This puts more of a burden on you for things like CI/CD, but at least Git-proper comes with some tooling to generate websites so you and others can use a browser to introspect the source and other artifacts.

However, the default rendered git pages are not exactly easy on the eyes.

While there are many “git pages” generators to pick from if you want prettier output, Gitmal is a relatively recent one that is fast, has support for scads of themes, and focuses on the core problem to solve:

$ gitmal -h
Usage: gitmal [options] [path ...]
-branches string
Regex for branches to include
-default-branch string
Default branch to use (autodetect master or main)
-gzip
Compress all generated HTML files
-minify
Minify all generated HTML files
-name string
Project name
-output string
Output directory for generated HTML files (default "output")
-owner string
Project owner
-preview-themes
Preview available themes
-theme string
Style theme (default "github")

When you run the main command, it scans your local repository and automatically generates pages for everything: a browseable file tree, nicely rendered markdown for your READMEs, and syntax-highlighted code for all your source files. It even creates pages to walk through the commit history of the repository, making the whole timeline super easy to explore.

While it’s designed to work out of the box, you have plenty of ways to tailor the output to your specific needs (as evidenced by the help block, above). Say you want to make sure your site loads as fast as possible. You can use the -minify option to shrink the HTML files and the -gzip option to create compressed versions. For aesthetics, gitmal defaults to a familiar “github” style theme, but you can easily pick a different one using the -theme option, or even use the -preview-themes flag to see all the available looks before you decide (it’ll give you a localhost URL to hit to preview them).

Did I mention it’s fast?

$ time gitmal \
--default-branch=batman \
--output /tmp/ja4-mcp \
-minify \
-name "JA4 MCP Server" \
-owner "hrbrmstr" \
-theme=evergarden
> JA4 MCP Server: 1 branches, 0 tags, 2 commits
> [1/1] JA4 MCP Server@batman
[########################]   16/16   (100%) blobs for batman
[########################]    1/1    (100%) lists for batman
[########################]    1/1    (100%) commits for batman
> generating commits...
[########################]    2/2    (100%) commits
> post-processing HTML...
[########################]   23/23   (100%) minify

real    0.26s
user    0.53s
sys     0.27s

You can preview that at https://rud.is/gitmal/ja4-mcp/.

This is also a well-organized and well-crafted Golang project, so I also recommend poking at the source if you’re even just a tad Go-curious.

---

A Different Kind Of Packets For IPv6

Photo by Manuel Moutinho on Pexels.com

There’s a quiet corner of the Internet that’s built entirely on goodwill, volunteer effort, and radio waves. It’s the world of amateur radio, or ham radio, and its operators have been networking long before most folks ever heard the term. Back in the early 1980s, when the modern internet was just being stitched together, these pioneers were given a huge gift: the entire IPv4 address block of 44.0.0.0/8. That’s sixteen million addresses, known as 44Net, dedicated solely to non-commercial experimentation, education, and public service communications carried over radio links. It was a globally unified digital playground that helped the Internet grow up.

Fast forward four decades, and things quite different. We’ve run out of those original IPv4 addresses, and the internet has largely (I’m being generous) shifted to the much, much larger address space of IPv6. This shift has created a problem for the ham community. Their special, globally coordinated address space has no equivalent in the IPv6 world.

That’s where a new IETF draft proposal steps in. It asks for a specific allocation from the IPv6 global pool: the block known as 44::/16. Choosing the number 44 is a clear nod to their legacy, and provides a way of preserving the community’s identity as they transition into the future.

The idea is super straightforward: just as they had a single, recognizable address space for IPv4, they need one for IPv6. This is crucial because, unlike your home network, amateur radio networks often need to be globally routable and publicly reachable so they can interconnect, facilitate research, and provide crucial communications during emergencies or disasters. Isolating them onto non-routable, private addresses would defeat the whole purpose of their long-standing work.

But making this request today is complicated. The process for handing out addresses has changed drastically since the 1980s. Now, most allocations go through the Regional Internet Registries, or RIRs, which manage addresses in different parts of the world. The proposal doesn’t want to bypass the RIRs entirely; instead, it asks IANA, the global coordinator, to reserve the 44::/16 block and then distribute it through the RIRs under a common policy framework. This is their way of trying to maintain that global cohesion and consistency—a single block that means “amateur radio” everywhere—without undermining the current governance structure.

The request has definitely sparked some interesting conversations within the technical community. It brings up questions about whether an organization can ask for a block with such specific historical and social context when the modern system is designed for broad, regional distribution. However, the proposal’s heart is in the right place. Ensuring that a dedicated, non-commercial community of tinkerers, educators, and first-responders can continue their important work in the IPv6 era is, IMO, a worthy goal/mission.

If you’re interested in this effort or want to tap into it, just start following the working group comms and, perhaps, offer up some of your own opines.

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️