Finally trying to do something with IPv6. I want to have an internal IPv6 subnet for my tilde, with member devices able to reach each other on an opt-in basis, using Wireguard. I've done this with IPv4 in the past. Not having much luck with IPv6 yet. Trying to set routes on my OpenBSD laptop so it uses the Wireguard server as a gateway to reach the other device, my phone, but traceroute6 just gives me "Network is unreachable." Can reach the server, though. :/

Reading this book until I understand what I'm doing wrong: https://ipv6textbook.com/

Why do I even care about IPv6 in this context? I don't think this community can get big enough to stretch the bounds of an IPv4 subnet while still being manageable. My whole reason is basically to minimize the chance of colliding address spaces with whatever other networks members might be a part of, but it's a VPN. You can turn that shit on and off. Am I prematurely optimizing here? Maybe I am. Would be a lot easier to just use IPv4. OTOH, I *am* learning something that might be useful.

Okay, I'm burning more time than I should on this second-order task. I can give members 14 IP addresses each and have enough address space for 4,681 people, which is more than I foresee signing up for this. And should that happen, I can either spin up IPv6 then or just grab another IPv4 subnet.

I hate backing down without having figured this out, but this is also not a significant part of what I'm working on.

Should probably stick to blocks of 16 to simplify referring to member owned address ranges.

@lykso i assume opinions aren’t welcome, but from the perspective of someone who has lots of VPN tunnels and things on her desktop, I’d rather have a thousand v6-only VPNs than a single v4-only one, partially because properly-assigned v6 ULA prefixes are practically guaranteed not to collide with each other, but IPv4 both has no such guarantees and can be outgrown more easily

@h Yeah, this is exactly why I'd been trying to get IPv6 working in the first place.

Do you have any ideas why I might be having trouble getting Wireguard peers to connect to each other over IPv6? I'm running a hub and spoke model, with rad running on the hub's Wireguard interface. The spokes are connecting to the hub over the hub's public IPv4 address. The hub has IPv6 forwarding turned on and I've made the firewall maxmimally permissive. I added IPv4 addresses to all the 1/

@h Wireguard nodes, and they were all able to connect to each other over that. This is my first time working with IPv6, so there are good odds I'm missing something simple. 2/2

@h Oh shoot, I think I might have got it working.

@lykso is “rad” router advertisements? if so, that’s a pretty bad idea

@h Yeah, it's the daemon for router advertisements on OpenBSD. I only had it running on the Wireguard interface, so only Wireguard peers should have seen anything. Wound up turning it off because it didn't seem to help anything, and now I've got things working without it.

What are your concerns about router advertisements, if you don't mind my asking?

@lykso my concerns about it are that it simply won’t work over wireguard unless you either (a) have a tunnel per client and waste a /64 per client that the client isn’t even expected to be able to use or (b) have a tunnel per client and use DHCPv6 to hand out /128 addresses, and that even if you make it work, people will struggle to actually get IPs, being likely to set up a bad config on desktop platforms and being unable to whatsoever on mobile (not that people should be terminating wireguard tunnels meant for them to expose multiple hosts on their phone, but anyways).
To give a specific example of software that wouldn’t work, systemd-networkd only lets you use IPv6AcceptRA on interfaces with a layer 2/MAC address, and RA should, afaik, be mandatory for use of DHCPv6.
So, overall, it’d be a lot of pain for something that brings you no benefit over static IP assignments.

@lykso unrelatedly, idk if my opinion would be welcome, but, if you will be routing entire prefixes, I’d suggest maybe allowing multiple tunnels and doing BGP with users if they want, so that people can e.g. have traffic load balanced between different hosts of theirs so that in the event of an outage they don’t lose connectivity, maybe have direct links to others, etc
would be a bit overkill, but I’d think that it could be fun, if not useful, meow

@h Thanks for the feedback!

So, my plan has been to allot a /124 subnet to each user and allow them to assign Wireguard keys and IP addresses from those blocks to their devices. (More subnets will be available on request, but a /124 is what everyone gets by default.) They can also allow or block connections to those peers on a per-subnet/user basis.

I have no experience setting up BGP, but I'll look into it.

@lykso if it’d be okay to ask, why not assign a /80 or even /64 per user initially, to avoid people being too stingy with v6 and doing things like NAT because they’re shy? there are several billion possible /80s in a /48 (assumed used since it’s the usual ULA prefix size), and 65536 /64s in a /48, so I’d think that one could allocate quite a lot of users prefixes even with such large sizes, to the point that handling the traffic from all the VPN tunnels would probably become a bottleneck prior to IP exhaustion

@h I'd basically started from the assumption that the Wireguard peers would be personal devices logging in to a communications channel and gone from there.

@lykso I guess that makes sense, meow!
does that mean that you wouldn’t support people connecting several servers they operate and hosting services on the network?

@h Nah, I definitely have that use case idea in mind. The server itself is very limited: 1GB of RAM at the moment and 15GB of hard drive space free. I'll be expanding this eventually, but part of dealing with those limitations is definitely going to be hooking up personal servers to provide additional space and whatnot. I just did not anticipate 16 devices looking like a small number. Right now I'm hosting a /64 prefix because my whole reason for using IPv6 in the first place was to avoid 1/

@h collisions, and having a longer prefix definitely helps there. 2/2

@lykso about collisions: if you somehow get unlucky enough to get a one-in-a-trillion(? did mental math for that) ULA prefix collision with a /48 used by a user, at that point wouldn’t you have bigger issues? meow

@lykso silly suggestion, hope this is okay:
would think that it could be cool if you maybe let people give you small VMs all over the world to configure as VPN routers with a v6 address+a few v4 port forwards + had an internal routed mesh with BGP (would probably work best with a strict tunnel-per-peer policy), so that you could have people connect to the closest VPN endpoint to them, decreasing overall latency and allowing more traffic to be handled
meow
hides

@h Yeah, that sounds interesting, but I think this begins to put the cart ahead of the horse. What I'm putting together is more in line with a tilde than a global overlay network. What is it you have in mind that would require so much infrastructure?

@lykso afaik, tildes tend to be ideally communities, so I’d imagine that having the ability to handle e.g. internal servers people can sign up on once they get access to the main system or game servers without people having high latency if such systems are physically far away from them or there being a single point of failure for everything could be pleasant
meow, sorry for being an annoying creature
would point out that just having the ability to do fancy things wouldn’t mean much, and it could just be a “if it’s ever useful to add more hosts in the future, it can be done” thing, where there’s initially only hosts in Europe, North America, and maybe AU or something, or even just only one host, meow

@h I could see this being something the community spins off, but it's definitely not in scope for me right now. For now, I'm looking at having IRC, git hosting, internal and external static websites for members, and maybe something like "bulletin butter and jelly:" https://tildegit.org/bbj/bbj

The community I'm hoping to gather will be focused on figuring out what a post-FLOSS, post-capitalist world might look like, and creating without LLM involvement. https://careful.party

@lykso meow!
expresses interest in that, and hides

@lykso silly question
what kind of internal DNS, if any, do you anticipate having?

@h None at the moment, but it's something I've been considering.

@lykso would honestly really hope you’d permit entities to have DNS delegated to them hides
sorry for being rude and annoying

@h @lykso same

@lykso a /28 is 16 addresses in theory but practically 14-15 anyway (the last address is the broadcast address, and the zeroth address is reserved by an RFC because 4.2BSD had a buggy IP implementation that treated the zeroth address as the broadcast addresss, although I don't think this is an issue with any modern operating system) (but also you should just use IPv6)

@lykso @h what do you mean by "post-FLOSS"? I might be interested, but only if it does not involve non-free software

@noisytoot Technically it's not a real subnet, it's a bank of user-assignable IP addresses in the Wireguard subnet.

@h I'd probably want to acquire a short domain for the purpose, to avoid collisions, and allow users to set subdomains internally on it. I'd have to figure out how to handle namespacing and dividing up that space fairly, which I don't think I could do without some degree of community input.

Simplest route would be to just do [<user-chosen subdomain>.]<username>.<short>.<tld> I guess.

@lykso sorry for being annoying, but wonder why you wouldn’t just use a .internal domain (internal is explicitly defined as being reserved for internal use!), considering e.g. that you’d need to have some kind of internal DNS in order to have reverse DNS (which would be quite annoying not to have on IRC i’d think?)
meow
sorry :c

@noisytoot @h It involves non-free software. E.g., https://wiki.p2pfoundation.net/Peer_Production_License but, in my case, with the further stipulation that access to the source code and participation in production is limited to actual users and tilde members in good standing.

A couple pages where I elaborated my thoughts a bit more:
http://lyk.so/enclaves.html
http://lyk.so/collective.html

@h Because I'd have to assume that some members are ordinarily a part of networks which may use that TLD, and I guess I want to avoid any chance of confusion or spoofing, even if it's of, say, a page that would have otherwise been presented on a company LAN or by the member's router. It just seems to create unnecessary ambiguity, I guess.

@lykso would view people being part of networks that use that TLD to be completely normal and acceptable, and would consider not using it due to fears that it might already be used for its intended purpose to be irrational, given that the internal TLD is explicitly defined as that: a TLD, not a domain meant for direct use in and of itself, so that any case where an entity uses the entire internal zone without exceptions already can be considered to already be violating at least the spirit of how the TLD should be used and therefore unsupported

meow :c

@lykso @h oh, I see. I disagree that restricting access to software is necessary to end capitalism.

most commercial AGPL software, as far as I am aware, is using some sort of CLA to grant unequal rights to the company maintaining it and allow them to sell an alternative non-free commercial license. I would rather people just be more skeptical of contributing to projects with such CLAs (and fork them instead).

I don't like restricting access to software (or more generally, knowledge) and I don't believe it is necessary.

@h If I know another member uses an internal company system at, e.g., abc.internal, and I'm able to snag that domain, then I can get them to interact with my copy instead of the copy they'd intended if they ever attempt to access that system while connected to the wrong VPN. It's not a likely scenario, sure, but I can remove the possibility entirely if I just put everything behind something like "foo.io."

@lykso why would you even think to try to control all of the internal TLD?
if you only use a single domain, that problem shouldn’t exist, I’d think?
sure, people could theoretically have their DNS responses handled by an unintended resolver if they use your resolver for all queries rather than directly talking to your authoritative server or only sending specific queries your way, but that issue already exists whenever you’re dealing with non-public DNS zones, and can (and should!) be easily mitigated by users running their own DNS resolvers or forwarders (e.g. systemd-resolved) that know exactly what to send to what servers, meow
hides
sorry for being a nuisance :c

@noisytoot @h If CLAs were all I meant when I say that the FLOSS movement is doing free work for the capital class, I would agree.

I also think that anything we can manage to withhold from capitalism is to our advantage. Anything of value which it can access is something it can use to sustain itself. With it self-destructing via the use of LLMs, it's going to eventually need something not shot through with slop. I want to at least try to keep it from using what we're working on to save itself.