jcgl

> So I don't bother with ipv6 - it's a toy.

Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.

Well performance really isn't something I would point to at all. While I believe it can become problematic with great scale (e.g. those expensive CGNAT boxes), it's more the architectural and connectivity aspects that are problems:

Architecturally, dealing with two different address spaces is a complication. A flat address space is easier to reason about and more flexible. This is amplified by the fact that IPv4's RFC1918 address space is very small. Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.

Connectivity-wise, stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used (without rendezvous servers).

Yep, agreed on pretty much all counts. The end goal is obviously the same for both dual-stack and translation technologies. But the latter makes things so much lower risk and gives you (the network operator) actual progress and a chance to simplify along the way. Providing IPv4-as-a-service is an actual plausible thing, compared to dual stack's now-draw-the-rest-of-the-owl vision.

> If ISP would have deployed IPv6 early enough in time, like deutsche Telekom had a properly IPv6 network ready in 2012 or even before.

I think you forgot half a sentence here. What was your point?

> And dual stack is no issue.

How can that possibly be so? Having enough address space to comfortably architect gives you room for far superior topologies, meaning that running dual stack at the bare minimum means that either your IPv6 topology is being compromised to map cleanly to your v4 topology, or that you're running two different topologies altogether. You need two times the sets of firewall rules, two times the number of address configurations...everything in your infra roughly 2x.

> All these transitions methods are far to expensive and an unnecessary overhead.

How so? Running 464XLAT on a device with a proper CLAT has minimal overhead, and the PLAT is no worse than running a NAT for IPv4.

Very much agreed with you that IPv6 is indeed fine. I think it’s even good, even beyond the necessary feature of providing an appropriate number of prefixes.

But I do narrowly agree with GP that CLAT should’ve been a goal from the beginning. Dual stack is such a losing proposition for any org that doesn’t substantially benefit from deploying IPv6. Adding in CLATs with a plan to go 464XLAT from almost day one would have massively changed the calculus.

Ah great, thanks for the link! A very clearly-written RFC.

Adding on to what others say about printenv, various diagnostic tools (e.g. crash reporting stuff) will capture the environment. Env vars are just categorically so easy to accidentally leak that it can’t even be classed as an insecurity.

I’ve never even heard of the DHCP option for this. How widely adopted is it? It’s surprising to hear it called “the right way” when it wouldn’t work for a single-stack IPv6 (or IPv6-mostly, probably) network.

I’ve seen website.com/z/{initiative} before, and it worked quite well.

Could put pressure on data center margins, but not revenue, and not necessarily gross profit.

This point applied to normal NAT as well as CGNAT specifically.

And hole punching gets a lot simpler when you’re behind NAT since you don’t need any kind of rendezvous server to determine port mappings.

In other words, IPv6 does help substantially—the same hole punching techniques are not needed.

Agreed. And throw in some Bayesian thinking too (like the Farmer and the Librarian).

Yes, exactly—the concept of Brand means hardly anything anymore. Certainly due partly to outsourcing like you say, but I think even more generally due to financialization. In a financialized world, brands become purely assets, which can be swiftly created and destroyed on (digital) paper, or packaged and sold to the highest bidder. The brand’s products aren’t the product any longer—it’s the brand itself.

Dynamic DNS is fine for many use-cases.

As far as I understand, there are numerous different kinds of meditation, even within just single traditions. Different kinds with different goals and techniques.

I’d be careful about talking about “the point” of meditation.

MTA-STS really is a drag. Baking in dependencies on a web server and web PKI is a true drag. Such web infrastructure has different operational profiles/modes of resilience that it’s a real impedance mismatch for those who can’t or don’t want to manage a highly-available web server.

But that doesn't work if the indentation carries semantic meaning; you can't change the indentation without changing the meaning. Maybe you can correct syntactically-incorrect spacing (e.g. change 3 spaces to 4 spaces), but not much beyond that.

Edit: s/economics/ergonomics/

Agreed. DNS is, afaik, the very best naming system we've got. But there's plenty left to do to make it better for human beings. Legally encoded rights to DNS names paired with easy-to-use GUIs for non-technical users would be near the top of my list.

And greater zone diversity like you say too. Kinda related to that, something like increased pinning of non-root DNSSEC keys so that the root isn't so all-powerful.

Tightly coupling identity to cryptosystems should be entirely dismissed for anything that is supposed to have broad adoption.

First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system.

Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not.

Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity.

In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).

Thanks for trying to summarize.

> - you and other guy believe non-technical people can't build technical things because its still too hard and you need to know the technical things

Pretty much. Though maybe I should more softly phrase it as "you still need to have some idea about technical things." Even more importantly, you still need to have some idea about decomposing problems in a technical way.

What you said:

> the samples I showed are that we are moving in that direction

> and its possible now...its an awareness and comfort problem

So which is it? Are we there, or are we only moving in that direction? Core to my position is the idea that there is a long tail of competences that technical and "product" people have or can fill in the gaps with. Other people don't have these things that are needed to smooth out what AI misses.

Said another way, even if AI has made it 90% of the way there, that still leaves the remaining 90%[0]. Long tails are long, and smoothing everything out such that a truly average person would feasibly whip up a bespoke, reliable backup solution really relies conquering so many edges that technical and product people would never even notice.

[0] https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule

And I'm glad that works well for you! But this is the context of the thread:

>> most people don't need cloud backups

> What world do you live in?

As put by another commenter:

> Most People™ do not have the technical knowledge to set up a self-owned backup system, and/or will not realize how badly their future selves will wish they had backups if the setup friction for a self-owned solution is too high to conveniently do it right this second.

So, okay, if you're just saying Some Small Percentage of People™ can vibe up a long-term backup solution, then, sure, I grant that.

I just don't think it's a useful or interesting point in the context of this thread, even if it's true.

Even just by narrowing to some definition of "product people," you've cut out the vast majority of the population.

> Why does someone who says “I pay -$x for Google Drive, how much can we make our own clone for?” need to know what a server is? The natural language doesn’t necessitate the technical jargon.

My point wasn't specifically that they need to know what servers are. Rather, the point is that the average person who needs backups doesn't have the faintest inkling of the smallest fraction of what goes into a backup solution. For these people (the vast majority of the population), you'd need a truly new level of vibing than what exists today.

Looking at Lovable's homepage, their tagline is "Create apps and websites by chatting with AI." Your average person probably doesn't even understand that "apps and websites" are primary components of a backup solution.

https://xkcd.com/2501/

Technical people, maybe. Even if we hypothetically grant that vibe-coded backup systems can be trusted, deploying, using, and maintaining are still hurdles. And there’s absolutely no way that’s all tractable for the vast, vast majority of the population.

Mind you, an average person probably doesn’t even really know what a server is. And these average people need backups just as much as (probably more than) people technical enough to vibe-and-deploy.

Not my area, but isn't it really only because glibc doesn't maintain stable interfaces across versions? If it did, you absolutely could use the same ld.so with different glibc versions. But it doesn't, so here we are.

First of all, techy nerdy people like things to be easy too. They're just somewhat more likely than other people (on average) to overcome not-easiness.

Second of all, how long is IndieWeb supposed to cook for before it's supposed to be ready for a broader audience? This is no shade on the IW folks if they like what they're building. But if what they're building is supposed to catch on somewhat, what's the path supposed to be? The project seems to be 15 years old already: https://indieweb.org/IndieWebCamps#

What Linux distros do you think would exclude on the basis of closed door/cathedral-style development? I’ve never heard of this.

You mean a few customers? Yes, I think that’s perfectly reasonable to expect that changes made to a very expensive product are well-documented for those customers to whom that matters.

This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?

What's the history and status of ASPA? As far as I can see, it's a fairly active draft with the IETF: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-ver...

It says it's on the standards track, but it's clearly quite new. How well has it been proven out? This page from Hurricane Electric shows <3% adoption: https://bgp.he.net/report/rpki_and_aspa