#nat64 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #nat64, aggregated by home.social.
-
Extending the Vector Packet Processing Engine
I've been building core networking components to leverage VPP more fully as a branch router. Here is an overview of that work.https://enigmatick.social/objects?uuid=b5cfe32e-e1ba-40da-80a1-e6f5bcfb6149
-
Extending the Vector Packet Processing Engine
I've been building core networking components to leverage VPP more fully as a branch router. Here is an overview of that work.https://enigmatick.social/objects?uuid=b5cfe32e-e1ba-40da-80a1-e6f5bcfb6149
-
I like the idea of global anycast NAT64 gateways.
Maybe we shouldn't invent another prefix for it.
https://datatracker.ietf.org/doc/draft-matolin-global-nat64-anycast/
-
An diesem langen Wochenende habe ich mal wieder mir Zeit genommen, um etwas an meinem Heimnetz herumzuspielen und den #RaspberryPi mal wieder anzuwerfen. #IPv6mostly war diesmal mein Testgebiet. Mit CoreDNS, Tayga und KEA DHCP-Server hat das ganze dann irgendwann doch recht gut funktioniert. Ich war überrascht wie stark an einem die KI (hier Gemini) weiterhelfen und ein Tutorial für ein doch spezielles Thema erstellen konnte. Nach etwas gebastel hat es dann doch funktioniert. #DNS64 #NAT64
-
still without the recent version of tayga
-
@tschaefer
1&1 with Roaming #VodafoneNL #Dualstack works. #IPv6only without #NAT64 works too. -
The #BoxyBSD project is taking a pause from provisioning completely free #vps instances / #vserver. For further questions, reach out to @gyptazy or in our Matrix chat.
After publishing the new self-service portal and making it easier to use and get a free VPS instance, we got a lot more new users who requested an instance than usual. We’re not out of resources but we want to provide a great and reliable service and have a buffer for upcoming things.
We’re already restocking the resources and adding new nodes to the project but temporary stop provisioning new instances. In the meantime, we will provide new services that will make the overall experience for users much better and easier.
We already started this with the new #NAT64 gateways and the new free #loadbalancing service that allows you to serve your website also on #IPv4, even your box is #IPv6 only.
We’re addicted to the #BSD community and hope to provide your quickly more #FreeBSD, #NetBSD, #OpenBSD, #DragonflyBSD and all the other bsd based systems again. In the meantime - have fun and #RUNBSD
#free #hosting #bhyve #zfs #firewall #networking #community #opensource #fediverse #services
-
We just added a free #loadbalancing service to #BoxyBSD!
This new feature got added by @gyptazy in addition to the newly introduced #NAT64 gateways to make your life easier and is currently tested with a few users! This provides you the ability to make your website also reachable by #IPv4 even your box is only running on #IPv6. This feature can be managed from your self-service portal and simply requires you to add a DNS name that should be balanced and to point the DNS A record to a given IPv4.
Making the legacy internet life easier, we hope for a higher #BSD adaption where people might be more motivated to try #FreeBSD, #NetBSD, #OpenBSD or even #opensolaris with #illumos.
#hosting #opensource #runbsd #hosting #free #service #saas #community #vps #vserver #server #vm
-
@alexhaydock Oh wow, I guess I know what I'll be doing during the holidays. I've wanted to play with #OpenBSD and also revamp my fairly fragile containerized #Jool #NAT64 setup that does questionable things with kernel versions.
I've long been comfortable with "ip" in Linux, but maybe the BSD world has even nicer things.
-
No NAT November: My Month Without IPv4
Link
📌 Summary: 本文探討了作者在11月的「無NAT十一月」挑戰中，關閉IPv4並僅使用IPv6的經歷。雖然在這段期間發現了許多挑戰和問題，特別是對於一些設備和應用程式的支持不佳，但作者認可轉向「IPv6-大多數」的概念，這樣可以同時利用IPv6和必要時仍然允許IPv4的路徑。最終，雖然作者的經驗顯示完全關閉IPv4還不成熟，但提議在未來的網路部署中考慮「IPv6-大多數」的方式，這將有助於平滑過渡。
🎯 Key Points:
- 作者接受了「無NAT十一月」的挑戰，評估僅依賴IPv6的可行性。
- 關閉IPv4時遇到許多技術問題，包括桌面操作系統與移動設備的支持情況。
- 一些嵌入式設備如Nintendo Switch未能在IPv6-only環境下正常工作。
- 討論了NAT64和DNS64等過渡技術，這些技術能幫助處理僅支持IPv4的服務。
- 最終建議推行「IPv6-大多數」的策略，以便在未來完全可行的情況下逐步淘汰IPv4。
🔖 Keywords: #IPv6 #NAT64 #DNS64 #無NAT #網路轉型 -
A good #dualstack network should still run #dns64 and #nat64, so that it can fully support #ipv6 only devices and allow them a way to connect to legacy (ipv4) internet sites. https://sgryphon.gamertheory.net/2022/12/running-nat64-in-a-dual-stack-network/
-
@issackelly @tyler I rather like #NAT64 ; it's clever. So is #DNS64. Even the custom Bowtie routing is rather neat in its operation. That said, putting all three together does seem to be a lot of moving parts.
There will indeed be situations where the need is to access a legacy private IP network, but there will also be cases when enabling #IPv6 for that private network would reduce complexity for all its users. Native IPv6 could still leverage the Bowtie routing for multiple disparate subnets.
-
I've tried to summarize the current state of the art for IPv6-First and IPv6-Only Access Networks in my blog post here: https://blog.daknob.net/do-you-really-need-ipv4-anymore/
Let me know how it went for you, what problems you may have ran into, and whether something is missing! I'm also happy to answer questions or help with ideas.
-
Rejoice, network operators. Windows 11 will be joining the rest of the world soon in supporting CLAT, #NAT64, and #DNS64 natively. (Currently, CLAT only works on cellular connections.)
Supporting two IP versions has been a pain we’ve had to live with for over a decade, but this will allow network operators to forcibly disable clients’ IPv4 stacks via DHCP/RA, finish #IPv6 switchovers, and run true #IPv6mostly or #IPv6only networks.
We’re one big step closer to killing “legacy IP” for good. :ipv6:
-
@ktims at the very least I would suspect this is going to start adding customer pressure for AWS to actually provide #IPv6 support to their services that are still IPv4-only, or are missing v4/v6 parity. Don't get me wrong: I'm here for the move and you just need to make the call at some point, but that doesn't mean it's not still a bit rude to present your customer with a lower and higher priced choice on the surface, but then simply remove the lower cost choice for a non-trivial subset of your products 😝
But, the market is definitely starting to normalize (source Hilco for this screenshot). It's definitely interesting to see how different forces and stakeholders are starting to interact.
I mean, we had the big content shops like Google, FB, Netflix etc. providing v6 at their edges for a good while, with mobile picking up a good amount on the client side. The CDNs are also in there with generally making it fairly easy to turn up dual stack on their edges.
Residential seems to be trucking along and gaining better adoption, where chunks of newer RGs and such seem to actually be getting to Just Works territory and residential users who don't and shouldn't have to care are getting v6 connectivity as well.Then you have your government forces like DoD and other US fed memos and mandates, and the recently-announced Czech timeline, with e.g. the US reqs starting to push some SaaS and enterprise app providers to get their house in order.
The laggards, imho, have been the large public cloud providers, the developer space in general, and enterprise. With AWS pushing v4 pricing, we now have a more concrete business driver, imho, that will start to push developers as well as infrastructure & platform types to get IPv6 familiarity, with a possible second order of creating more IPv6 demand in the enterprise space for those devs to be able to access as well as test against their now v6-enabled service edges.
It's definitely an interesting time.
Anecdotally I'm seeing the leading edge of the conversation shift away from the earlier v6 tunnels & experimentation, and even from just dual stack, to folks poking at #IPv6-only or #IPv6-mostly, with way more conversations around #NAT64, #DNS64, and #464XLAT popping up in enthusiast spaces.
-
Anyone have any ideas for squeezing a #CLAT into a container? My #homelab #k8s cluster is IPv6-only, and I've discovered this evening that steamcmd is not even asking for AAAA records, meaning my #NAT64 and #DNS64 setup is not effective here. I am not going to dual-stack the whole cluster network just to host one game server, so I'm looking for container-ed options.
IIRC, a requirement for CLAT is being able to carve out a /96 for translation, but k8s assigns a single #IPv6 per pod...
-
Introductory post: this is my public sub-account for #IPv6 content; my main account is linked in my profile.
I support the complete roll-out of IPv6, including intermediate efforts like dual-stack support and #NAT64 #DNS64 #CLAT, with the ultimate goal of native IPv6 support in all-new deployments, using RFC standards and best practices.
I support subnets no smaller than /64 (#SLAAC), ISPs should delegate prefixes of at least /56 or /48, and #ICMPv6 should be rate-limited, never blocked.
-
CW: Public NAT64 service
-
So far we have only deployed #IPv6 in dual-stack mode. I really want to push for IPv6-only now, but I'm not sure if we have all the necessary pieces in place. We can set up #DNS64 on our #Infoblox cluster, but I'm not sure if any of our Cisco routers are actually capable of doing #NAT64.
#CiscoLiveEMEA
