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
One of the annoyances with #NAT64 is that when some site publishes an #IPv6 AAAA record, but their IPv6 server is down and the IPv4 server is up, there's no "happy eyeballs" fallback to IPv4. Because the AAAA record exists, #DNS64 doesn't provide a mapping to IPv4.
It can be worked around by manually adding an /etc/hosts entry for the broken site.
Today's broken site is www.fsf.org. Hey @fsf - your IPv6 server is refusing connections π
I got asked if I could create a #howto for creating a (public) #NAT64 service - just like I did recently for #BoxyBSD. With #DNS64 and #NAT64 you can also reach resource in the legacy internet (#IPv4) on #IPv6 only systems.
While this is based on #unbound and #tayga, thereβs also a solution by using the #OpenBSD's native way which is also running on the other gateway. Iβll share a second how to how to do this in OpenBSD and pf.
https://gyptazy.com/howto-create-a-public-dns64-nat64-gateway/
As part of my BoxyBSD project, which is designed to operate on IPv6 only network connectivity, I recently implemented and provided DNS64 and NAT64 gateway support to bridge the gap between IPv6 and the legacy IPv4 world. This solution ensures that users can easily access important resources, like GitHub, which - even in 2025 -