Hugo Slabbert ⚠️

K, need the #ipv6 gang. I'm hanging on the edge of being That Guy here. The k8s network model always seemed to me to map really nicely onto a simple /64 per worker. Containers in a pod share a network namespace, not allocating discrete IP addresses to individual containers. But, reading the proposed draft for DC v6 deployment, and specifically the section at https://www.ietf.org/archive/id/draft-martin-deploying-ipv6-data-center-02.html#name-prefix-allocation-for-hosts re container hosts, and taking some pause here: A common data center pattern assigns a /56 to each physical host (or rack entity), providing 256 /64 subnets --- one /64 for the host itself and up to 255 /64 prefixes for containers, virtual machines, or Kubernetes pods. Does it? Like, is that actually "common"? I don't want to just port IPv4 thinking over here, but I honestly struggle to think of scenarios where I would specifically want a /64 per pod. Assigning only a /64 per host (or per rack entity without further delegation) is often insufficient when multiple containers each need their own address space. Eh? That...seems to run counter to the common k8s network model? How often are folks finding this "insufficient"? Are we running a bunch of weird VNF workloads I'm not yet encountering? In a closed data center with explicit routing and no SLAAC on container segments, some designs assign one /64 per physical host and carve /72 (or longer) subnets from that host prefix for container tiers. That pattern is not suitable on the public Internet or where hosts expect standard /64 semantics; use it only with operator-wide agreement and tested CNI or orchestrator support. Maybe I'm missing something, but any CNI patterns I've come across so far seem to basically expect an address per pod, not a prefix per pod with multiple discrete container addresses within that. Who's running SLAAC between the worker and containers? Are we the exception here with "explicit routing"? Honestly I was originally perhaps a bit conservative with just an address for the worker itself in a rack-local uplink /64, and then a /64 per worker for pods. Perhaps a /64 or two for the worker itself and then a /64 for its pods is more suitable. But a /56 per worker to support a /64 per pod seems...a bit much? A /52 podCIDR supernet gives us 4,096x /64s, so 4k workers at a /64 per worker. That's still a good chunk to work with if we have big clusters. Shifting to a /56 per worker would put us at a /44 podCIDR supernet for a 4k node cluster limit. I know we should work from our base address needs and then work out way up rather than trying to "fit" within a predefined sizing. But this seems like a good chunk of hierarchy bits that don't actually fit with my understanding of the intended (k8s) network model. Are folks really out here dropping a /64 per k8s pod?

@mttaggart it is also staggeringly infuriating that they call out energy competition with China, and then pivot to talking almost exclusively about ways to gut environmental policy, crank natural gas, etc., when China's lead in new energy capacity is specifically being led by solar and wind. We're apparently somehow both in an existential fight for dominance while also doing it in the stupidest way imaginable in order to appease ideologues.

@dgar I especially appreciate the "two copies of Outlook" reference in this.

@SimonCHulse the packaging designers

@zwol@masto.hackers.town @unsafelyhotboots@sharkey.world maybe https://minitruckdepot.com ? Or https://minitruckcanada.com north of the border.

@tschaefer in general I've been responding with https://datatracker.ietf.org/doc/draft-meow-mrrp/ when people point to the "IPv8 draft"

@deFractal@infosec.exchange isn't HarbourAir working on that class of hop? https://harbourair.com/going-electric/

live view of Hugo waiting for his meshcore kit

@ghostinthenet it is completely unserious. Lump it in the same group as http://bill.herrin.us/network/ipxl.html (maybe was a serious attempt at one point, but that ship has sailed), https://datatracker.ietf.org/doc/html/draft-tang-ipv4plus-06 https://datatracker.ietf.org/doc/html/draft-omar-ipv10-06.html and to a lesser extent https://github.com/schoen/unicast-extensions (as that doesn't propose a new protocol, just a whole bunch of software changes to keep ipv4 on life support).

@arichtman @litchralee_v6 😜

@litchralee_v6 Got a delivery notice! Looks like it should be here in about another week now. 🤞

@arichtman@eigenmagic.net @uep@timeloop.cafe @futzle@old.mermaid.town yea, but how do you inject/update site B updated GUAs into site A's peer config for site B, and vice versa? But, wait: If you're not punching a hole in the firewall to make the service at site B accessible from the public Internet, then why DDNS the address to a public DNS or against the GUA anyway? If the service should only ever be internally accessible, just pin the DNS record to the ULA and be done with it?

@arichtman@eigenmagic.net @uep@timeloop.cafe @futzle@old.mermaid.town Circling back: Diving into all of this also starts to shed some light on what "value add" Tailscale provides for folks in these circumstances, e.g. providing "app connectors" to do exactly this, with injecting DNS-based routing through the Tailscale overlay into the mix. They can do that, though, because they're running an agent that's "more than just wireguard" and interacts with a coordination layer.

@arichtman@eigenmagic.net @uep@timeloop.cafe @futzle@old.mermaid.town To be clear: You should still land the GUA prefix on the site B subnet, so your machines get both GUA as well as ULA. But, just point the DNS at the ULA (and optionally bind the service to the ULA only, not the GUA).

@arichtman@eigenmagic.net @uep@timeloop.cafe @futzle@old.mermaid.town Now, if you have a service that you do want publicly accessible, so you run it on a GUA and point DDNS at that, but you also access that service from within your local site, then things can get interesting. I have a few cases like that. To be clear: just accessing from the same site as where the service is running, from other clients in that site, I mean. The trouble is v6 access if/when my Internet service is out. I will start to lose the more ephemeral v6 GUA prefix, and also if I'm accessing the service via a public name with DDNS on it, I start being unable to resolve that name as I want to keep the TTL on the DDNS name short. For that, I ended up creating an ingress. child zone, with things like a.ingress., and b, and c, and so forth, corresponding to the machines running or fronting the actual services. I run a split DNS auth zone for that ingress. locally, and my local resolvers are configured with that as a stub zone to forward to those local auth services. Those a and b and c etc records on the ingress zone then actually have the (stable) ULA addresses of the machines in there. Public users get the DDNS public GUA names; internal users on my own resolvers get shunted over to that internal auth zone via the stub zone config and get the ULAs back as the AAAA records. So, I can still access those local services (that are also publicly available) even if my public Internet connectivity is down.

@arichtman@eigenmagic.net @futzle@old.mermaid.town I missed replying to this: Or does Wireguard just...not do that without WG configs on each machine as well? You don't need wireguard running on individual machines (Machine 1 and 2) in this setup; just bank the subnets through the routers.

For the idea of encoding lat/lon in addressing: Eh, tbh that starts to lean a bit too much into numerology or significance of numbers for my taste. How often are you really going to examine network address bits and try to decode a geographical location from it? If you really want site type information, encode it in DNS zones somewhere in the name hierarchy, imho.

@arichtman@eigenmagic.net err, what? Wireguard is peer to peer. Do you mean from which block you number the wg interface itself? Pick a discrete network range that is independent of the sites, and number all of the sites' wg interfaces from that. It's an overlay network: it's not bound to any one particular site.

@BillySmith@social.coop a few hours ago would've been great https://www.msn.com/en-us/money/economy/cloudflare-stock-sinks-18-after-earnings-as-company-cuts-1-100-employees-due-to-ai-changes/ar-AA22E2k9

@cadey@pony.social is "Copy Fail 2: Electric Boogaloo" one and the same here as Dirty Frag, with them both pointing to the same patch? IOW is "Copy Fail 2" the "unrelated third party" that broke the embargo?

@baldur@toot.cafe They're more constrained than they're letting on. Capacity and engineering resources are reserved for "AI" so corners are being cut Part of this, tbh, is prioritization, yea. E.g. take the Merge Queue issue. That was a software change. Quite possibly, though, that software change was made as part of scaling efforts, putting a more scalable system in place there. So, there is effort being placed into scaling, but those changes that trigger incidents are that's happening because of the increased demand from the AI wave. At the end of the day, there is a conscious decision, imho, to invest in AI features over other demands of operating and improving the system, and directing resources to those AI features then fuels even greater scaling demands. Based on business objectives, you're investing in things that make your other problems worse. It was a business decision of what to prioritize, and it's biting them.

@neirbowj we can give them the wifi cable

@arichtman I think I may just have attacked myself with my own words...

@snowfox tbh I'd always considered this along the same lines as "assistant" voices in software being given feminine tones, whereas voices in recordings for directives ("proceed to the emergency exit immediately") being given male. IOW this all just being a continuation of the accommodating and subservient assistant being framed as female.

@arichtman basic Meshcore flash done with OTA Fix and EasySkyMesh power saving. Confirmed DMs between devices, private channel chats, and selective location sharing. Repeaters out here are sparse because we're up in a narrow valley. I can hear some sporadic chatter out in the field, but it's dicey. I'll likely do some wardriving when I head into the office tomorrow, but other than that I'll now have to anxiously await the repeater I have on back order before we can get better coverage.

@Thoreau in Afrikaans & Dutch, "ons" is "we" or "us". So, "Us and Eons" I could get behind. Like, "Our stories across the ages". ...except I just realized that basically can be extended to "these are the Days of Our Lives"!

@arichtman yea, I'm talking here even at the level of "what is a token," but maybe to a degree I'm also frustrated at broader pieces like even a cursory understanding of the economics or especially the psychological factors being actively exploited in the business models. A hobbyist who got curious one afternoon knows more about these topics than people tasked with wielding massive amounts of dollars and setting business direction that impacts thousands of people. I understand that the higher up the chains you go, the greater the scope of possible topics and the greater the degrees of abstraction involved as well as the dependency on purported subject matter experts to summarize it for you. But there is just such a massive gap between the level of understanding of the topics, and the "urgency" and scope of impact and change being imposed. If you're going to be leveling this amount of upheaval, does not that warrant even an afternoon's or, heck, a week's focused attention on a subject? I understand that the whole industry is just a giant hype train firehose of opinions and shifting sands (supercharged in no small part by the information overload that LLMs themselves enable), but do you not owe it to the people whose lives you will be directly affecting to take a beat? Is it not your job to apply the requisite amount of due diligence commensurate to the possible impact of your decisions? It's just so frustrating when the same people that go on about "data driven decisions" will turn around and launch an absolute wrecking ball decision founded on nothing more than vibes, hearsay, and institutional fomo.

@arichtman@eigenmagic.net @uep@timeloop.cafe that sounds about right. tbh, this sounds like the GUIs or distribution-specific (opnsense, openwrt) abstractions are confusing things. Daniel has it above. Each node has: their own interface / listening address & private key configa list of peers Where each peer is configured with: an address to reach them on (Endpoint)their pubkeythe AllowedIPs that can be reached through that peer That requirement is the same in both directions. Router A has its own Interface / address / private key, and a peer for router B, which lists router B's endpoint address, pubkey, and the AllowedIPs to reach through router B. Router has its own Interface / address / private key, and a peer for router A, which lists router A's endpoint address, pubkey, and the AllowedIPs to reach through router A. If you also add site C, you would add a peer and endpoint + pubkey + allowedips entry for site C to both A and B's config, and then in site C's configuration add its interface / address / private key, and peer configs for routers A and B with their endpoint addresses, pubkeys, and the AllowedIPs to reach through each respective peer. Client-server abstractions here add more confusion than helpful, imho, for this type of setup. That can possibly be a helpful lens for a road warrior setup that's a more traditional client-server view, but for interconnecting sites through routers running wg in a site-to-site setup it just confuses things, imho.

Sorry, on terminology: Yes, fair it can be used as either client server or site to site, but those denotations are a bit limiting anyway, imho. By peer to peer here I meant the traffic model with wg as effectively being a mesh topology. You can manipulate it to be hub and spoke etc, but the label is just...well, it doesn't seem to really be very useful. Anyhow: Just slap the full /48 ULAs in there, and use a fully discrete range for the actual wg overlay supernet.

@arichtman@eigenmagic.net aye, you can absolutely do that, but: There is no reason to limit the AllowedIPs to just a /64The wg interfaces don't need to be numbered from within any individual site's ULA /48 You kind of see this in the v4 equivalent guidance in those OPNSense docs: You will connect Site A LAN Net 172.16.0.0/24 to Site B LAN Net 192.168.0.0/24 using the Wireguard Transfer Net 10.2.2.0/24. The "Wireguard transfer net" is a fully discrete and separate network from the site A and B networks. If you have sites A and B, and you want to connect them through wireguard: Generate a /48 ULA for site AGenerate a separate /48 ULA for site BGenerate a separate /48 ULA again for wireguardPick a /64 from the wg ULA /48 to use for the wireguard overlay network, and number the wireguard interfaces at both sites A and B from that. This is the "wireguard transfer network". At site A's eg config when configured the site B peer, add site B's wg interface address to the peer AllowedIPs and also add the full site B /48 ULA to AllowedIPs as wellAt site B's wg config, do the inverse They may mention "just add the /64," but there is nothing preventing you from adding the full /48. You would then still control access to a given site using the firewall config at that site, for what is permitted in across the wg interface.

@ktims huzzah! Verbose, but dense ftw!

@karafuto@mas.to yea. I was planning on messing with ffmpeg for the time sliced version; thinking about it, there might be a way to get it to do vertical slice thing as well. Good point re: number of images. Probably I'd need to sample it down to 1 in every 10 or 20 images or such, at which point it might start to miss out on some key differences. Part of the fun in the big "year lapse," though, is definitely things like different cloud patterns, seeing the colours in the field change, etc; all things that would show up much better in full images versus vertical slices. Good things to think about, thx.

@glyph I think there is something in the middle. AI psychosis for is in the realm of a full mental episode, with delusions, visions of god or hidden, secret discoveries, etc. Beyond your "vibesick" definition, though, are individuals who seem somewhat obsessed. They'll talk about all night sessions, continually "researching" until 3 AM, "doing incredible things" or "insane output" etc. It's closer to an addiction. This is not just the gambling aspects that have been raised elsewhere, as this form doesn't seem to exhibit the behaviour of "one more pull and then it will all work out" as they do believe they're on this ongoing productivity high, but it definitely does have some sense of spiralling loss of self control or regulation. It's almost like a "token bender," where people just can't step away and continually tending bots takes over their every waking moment. There is an undercurrent of anxiety in it as well, where they feel this is an existential moment, which seems to drive this obsession of not being able to stop. Honestly it seems like some form of mania, even if it doesn't seem like all out psychosis where people have lost touch with reality completely.

@neauoire@merveilles.town Japan: "I will metricate your system whether you like it or not"

@karafuto@mas.to okay now you have my interest piqued. I'm trying to do a "photo a day" view of a spot on our property looking down a field towards the other side of a valley. I was planning on stitching it together into a "year lapse" at a few hundred milliseconds per frame, but this vertical slice composition could also be quite neat.

@megabyteghost@masto.hackers.town @zwol@masto.hackers.town @unsafelyhotboots@sharkey.world lol, yea....

@baldur@toot.cafe I wonder if it's less that you'll be first against the wall and more that it won't save you from going up against the wall. Presumably in an "anti-AI revolution," the actual architects of the system would be first, though "moderates" would presumably be close behind as quisling collaborators and class traitors. In a "pro-AI revolution," though, my thinking is it's less that moderates would face specific targeting as "opponents" so much as the system simply doesn't care about you and you're still right down there in the ash and ruins. If there is any retribution in this scenario, presumably active opponents would still be "first"? My general read is that the "centrists" are hoping this just fizzles out (bubble collapses, some tech remains but the "big AI labs" and the hype wave are gone) rather than landing as a revolution in either direction.

@jtk@infosec.exchange So..."we know what the right decision is, but it's harder, so we not only decided to apply yet another kludged hack layer but also wrote a glossy post bragging about that kludge"? I, too, have had to resort to terrible NAT hacks, but my response was a mix of resignation, sadness, shame, and yet more ammunition that I managed to leverage for an actual IPv6 adoption plan, not writing a vendor-collab "use case" post bragging about it?