I've been thinking about starting. My current ISP (Comcast) has native IPv6 but you can't get a static prefix (maybe if you are a business class customer, IDK). It would be nice to have a prefix which is statically assigned to me for stuff that I host at home, so I've looked at doing an HE tunnel instead. The main drawback seems to be that some networks still refuse to peer with them so not everything is reachable.
> The main drawback seems to be that some networks still refuse to peer with them so not everything is reachable.
A bigger drawback is that you end up in a bad neighborhood. 20 years ago, most traffic from tunnelbroker users were people excited about ipv6 with isps that didn't care about it. In 2026, nobody is excited about ipv6 anymore and tunnelbroker traffic is mostly abuse or trying to circumvent georestrictions... Expect to fill out so many captchas if you set it up.
Comcast has a very strict peering policy as well. They, like Deutsche Telekom, like to hold their proverbial customers hostage to make other networks pay to peer.
You don’t need your ISP to assign a static prefix just to have static addresses on your home network. Instead choose your own prefix inside the fd00::/8 block. There is a procedure using hashing that you can follow to help guarantee that your prefix is unlikely to be shared with anyone else, but you don’t actually need to use it. Configure your router to advertise that prefix in addition to any prefix assigned by your ISP and all of your computers will give themselves an address in both prefixes. If you set your servers to base their address on their mac address, then every one of your servers will have a single unique address. Your client machines can keep their privacy–aware addresses that change frequently.
> You don’t need your ISP to assign a static prefix just to have static addresses on your home network. Instead choose your own prefix inside the fd00::/8 block.
I do have a ULA network I chose for myself. But when I'm not at home I would like to be able to reach things I self host (e.g. my Navidrome server), and I need routable IPs for that. My /60 from Comcast is stable but not guaranteed to be static, and it would be nice to have a truly static allocation so I won't run into the need to redo my DNS records if Comcast ever changes my prefix. I know I could script something to do that, but static is a bit nicer.
Ah, of course. They probably want you to pay extra for that. :)
An HE.net tunnel has advantages, but they’re also quite bandwidth–constrained. If you need anything more than ~1MB/s then you should build something yourself instead.
I don't have statistics on that, but I can say that Verizon FIOS NG-PON2 service in the US (which is what I have) does not offer native V6, so yes, sadly I am forced to use a tunnel broker in 2026.
At home, my ISP gives me native IPv6. At work, we don't have IPv6 (or it's just disabled on the router), so I sometimes use one to test stuff (I use 6Project).
It's ashame that MythWeb isn't under active development anymore[0]. The MythWeb change log in the 0.33 release doesn't have any commits newer than June 4, 2022.
Maybe I'm weird but I use MythWeb exclusively even though I run MythTV on my office workstation. mythfrontend is nice but I find it easier (read: more window manager-friendly) to use mpv to play recordings.
There's now a built-in web frontend, which I guess let the sails out of mythweb. :/
I've never been interested in scheduling through the frontend, I just use it to playback recordings with a remote control. I find it much easier to search and browse the guide through a web browser.
I thought this, too, but it seems carriers in the USA are being /very/ selective about where they offer the service.
For example, my inlaws live in semi-rural South Carolina and a new cell tower was built about a mile away from their home ~2 years ago. T-Mobile's Home Internet product indicates there's no service at their address for even though I have what looks to be full signal strength indoors on their "5G UC" network (indicates mid-band & mmWave from what I can tell, but in this location it's likely just mid-band). Every speed test I've executed from my T-Mobile-connected phone (Galaxy S22) is in the 600-700Mbps range and it doesn't vary based on the time of day.
Verizon Wireless indicates that they're not in the service area either for their 5G home Internet product, although I don't have data points from any UE on their network in that area.
> You don't get rewarded for preventing bad things.
A few years ago I saw a promotion announcement e-mail come into my inbox for a colleague who sat a few steps from my desk. It was filled with the usual "did this, did that, made an impact, etc." statements but it also had a large section dedicated to the analysis this employee performed and presented to kill a huge initiative before the organization rolled it out. The initiative was very innovative but it ultimately wouldn't have achieved its goals. It was encouraging to see this in a promotion announcement and indicated to me that some organizations do explicitly reward for preventing bad things.
Might be an exception that proves the rule. Killing a major initiative might’ve been a boon for sibling initiatives m — no wonder those leads applaud an underling who usefully twisted the knife. Politics — is Amazon known for it?…
That’s not what exception that proves the rule means. “Parking allowed only on Tuesdays” is an exception that proves the rule. This is just an exception that disproves the rule, like most exceptions.
My experience matches with the GP. In my ~20-year professional life, I can't recall even one instance when I'd read a promotion announcement and saw that one of the person's accomplishments was that they prevented something bad from happening. Sure, it's possible I'm forgetting, but such a thing seems odd enough to me that it feels like something I'd notice and remember. I expect most people will have a similar experience.
It's also possible that people are getting praise for these sorts of "negative accomplishments" in private, or on performance reviews. Which is better than nothing, but I think it's still valuable and healthy to remind people that part of the job isn't just building stuff, it's also making sure the right things get built. And public praise for killing bad things is a good way to do that.
I've never seen it either but that's irrelevant. The original guy talked about someone blocking a crap project with good results. That's a positive.
So someone responds by assuming it's a negative: "...applaud an underling who usefully twisted the knife". I mean maybe, but quite possibly maybe not. But some people seem wired to find the worst.
It's a save-the-budget kind of thing. By showing that we don't need X or can delay buying Y for 1 year, saved the company from $ZZ million dollars of spend. It might not be stopping other people from working, but it is praised.
FWIW, when I lived in Seattle I found that Lumen's DSL service blocked it as well. It wasn't an obvious block, though. It was either some DPI or size-based filtering. I wrote it up here for posterity:
It worked just fine through Comcast's Xfinity service (although at the time, that service had other critical issues for me..) and I have no problem now with Verizon Fios.
I always figured that 4-digit and 5-digit ASNs were "cool" to a certain crowd but seeing them at the bottom of this auction page just seems like lunacy.
Sure, IPv4 blocks have reputation but I've never heard of the equivalent for ASNs, especially ones that have a small number of digits.
32-bit ASNs are very easy to come by from all registries and there are lots of them. Most all BGP implementations have supported them for a long time so there shouldn't be a reachability issue.
Am I missing something? Is this just plain vanity?
> Sure, IPv4 blocks have reputation but I've never heard of the equivalent for ASNs, especially ones that have a small number of digits.
tl/dr; ASN's are highly visible to network engineers, it's your identiy as a network. Lower/shorter numbers are "better", at least to some people.
All of the 4 digit ASN's were originally allocated in the 90's, during the initial ISP/dot com boom and are often viewed as a sign of being an established player, or just "cool". Almost all the major ISP's use 3 or 4-digit ASN's: 3356 = Level3/Centurylink/Lumen, 701 = Verizon, 174 = Cogent, 1299 = Telia (now Arelion), 2914 = NTT, 6453 = TATA, etc. Even Netflix snagged 2906 when ARIN suddenly recycled a bunch of 4-digit ASN's in 2009.
If you are an ISP, every one of your BGP customers and peers has to configure a BGP session with your ASN so it has maximal visibility in that use case. Even if you are just peering on public IX's, every peer will see your ASN when they configure the session or do "show bgp sum".
These days there is a similar effect though less dramatic for 5-digit ASN's, and that is reflected in the lower asking prices.
What surprises me is how fast the 5-digit ASN's were selling (look at recent sales). In the ARIN region you can get a 5-digit ASN just for asking when you apply, otherwise they assign a 6-digit by default most of the time. The takeaway from this is that people are paying for a definite, specific number that they like rather than take their chances with a random assignment from ARIN.
As someone that does run an ISP and helps run an IXP, it matters nothing to me if somebody has a 32-bit ASN vs a 16-bit ASN.
Sure, I can see 6939 or 701 and know instantly who that is, but in the end, it matters nothing for the other 98% of ASNs I don't recognize on sight and who they might be behind them.
Anybody that is paying money for a "vanity" ASN is just doing it for self-ego stroking. To the people doing the work, it doesn't matter one iota.
IPv4 blocks are actually useful. If you run a datacenter it makes sense that you'd try to get something bigger than a /24. Why you'd care about having a 4 digit ASN I don't understand... easier to remember?
Because BGP doesn't support ASN numbers larger than 16 bits; the 32-bit support is a pretty nasty hack, and for a long time, lots of equipment would not support it.
Running BGP with 4-byte ASN's is well supported by all major vendors by now. The issue is policies that use ASN:XXXXX communities which is 2-byte:2-byte.
There is an RFC to extend this to 4-byte for the ASN part but that is not widely supported yet.
For small enterprises/end users (that might not define their own communities at all) this is usually not a problem but for larger networks or ISP's you end up with a compromise where you are truncating the 6-digit ASN or using a private ASN, neither of which are desirable. Arin let's you request a 2-byte ASN and if they have one in inventory (they usually do) you can get it.
I honed on this as well. I can't speak much to running FreeBSD as a server, but can say that using it as a router is not a great experience compared to Linux. I can't even get the latest ECMP (ROUTE_MPATH) feature working with FRR (or even by hand).
