# orderedItems[].object.content
#FritzBox #Rebind

TIL Die FritzBox macht auch eine #DNS Rebind Protection für FQDNs mit GUAs aus dem eigenen Subnet.

#IPv6 #Homelab

# orderedItems[].object.content
IPv6 in the boardroom

By Terry Sweetser on 13 May 2026

https://blog.apnic.net/2026/05/13/ipv6-in-the-boardroom/

#ipv6 #blog #apnic

# orderedItems[].object.ephemeral.metadata[].description
Guest Post: IPv6 can be seen as an infrastructure refresh, rather than an organizational responsibility tied to governance, risk, and compliance. Reframe it in those terms, and it shifts from a network discussion to a board-level obligation.

# orderedItems[].object.ephemeral.metadata[].ogDescription
Guest Post: IPv6 can be seen as an infrastructure refresh, rather than an organizational responsibility tied to governance, risk, and compliance. Reframe it in those terms, and it shifts from a network discussion to a board-level obligation.

# orderedItems[].object.ephemeral.metadata[].twitterDescription
Guest Post: IPv6 can be seen as an infrastructure refresh, rather than an organizational responsibility tied to governance, risk, and compliance. Reframe it in those terms, and it shifts from a network discussion to a board-level obligation.

# orderedItems[].object.content
Omg, I came across the totalitarian fever dream that is called #IPv8. Why is it even reported on? Takes 2 mins to realise:

- Website is 100% AI
- Vast portions of the proposal most probably too
- Everyone can propose an Internet Draft and have it published on ietf.org
- Author is called "veteran network architect" but has no track record and hides behind entity registered in Bermuda

What real experts say
https://seclists.org/nanog/2026/Apr/99
https://openfactory.net/the-ipv8-propo sal-and-a-bit-of-an-opinion-on-it/
https://shitwolfymakes.substack.com/p/we-need-to-talk-about-the-ipv8-draft

#networking #ipv6

# orderedItems[].object.ephemeral.metadata[].ogDescription
I read the IPv8 draft, and there are a lot of thoughts coming out. The short version: I like that there is a proposal thinking about the routing table, addressing, management, authentication and operational complexity as one bigger problem. That part might be good, but the proposal already then has accumulated a lot of complexity, […]

# orderedItems[].object.ephemeral.metadata[].ogTitle
The IPv8 Proposal and a bit of an opinion on it - Openfactory

# orderedItems[].object.content
@tschaefer für Dich getestet:

#Telekom #Roaming in der Schweiz mit #Salt =
#DualStack

#IPv6 #LegacyProtocol

# orderedItems[].object.content
Meine erste richtig große Pull Request gegen OPNsense, weil ich daran glaube:

Bei o2 und 1&1 VDSL/FTTH bekommt man prima Routing, auch IPv6, aber immer noch 24h-Zwangstrennung mit dynamischem IPv6-Präfix.

Und wenn man da die Präfixe nicht richtig deprecated verhalten sich diverse Geräte anders doof, daran führt kein Weg vorbei.

https://github.com/opnsense/core/pull/10261

#ipv6

CC: @tschaefer

Hoffentlich sagt sich @openfactory nicht, jetzt machen wir auch dynamische Präfixe.

# orderedItems[].object.ephemeral.metadata[].twitterTitle
radvd: improve stale prefix cleanup #9261 by max-foss · Pull Request #10261 · opnsense/core

# orderedItems[].object.ephemeral.metadata[].description
OPNsense GUI, API and systems backend. Contribute to opnsense/core development by creating an account on GitHub.

# orderedItems[].object.ephemeral.metadata[].ogDescription
Important notices
Before you submit a pull request, we ask you kindly to acknowledge the following:

 I have read the contributing guidelines at https://github.com/opnsense/core/blob/master/CONTRIB...

# orderedItems[].object.ephemeral.metadata[].ogTitle
radvd: improve stale prefix cleanup #9261 by max-foss · Pull Request #10261 · opnsense/core

# orderedItems[].object.ephemeral.metadata[].twitterDescription
Important notices
Before you submit a pull request, we ask you kindly to acknowledge the following:

 I have read the contributing guidelines at https://github.com/opnsense/core/blob/master/CONTRIB...

# orderedItems[].object.content
Using the #hotel #wifi powered by m3connect. What is not working is the current Internet protocol. #IPv6
Therefore I cannot access most of the services I would like to use.

#hotelwifi #fail

# orderedItems[].object.attachment[].name
Herzlich willkommen im ... Hotel.
kostenloses Premium WLAN

powered by m3connect

# orderedItems[].object.content
I borrowed a Ecoflow Stream Ultra to try to connect it to my wifi. And of course it failed. The app tells me I should make sure the network of my phone works. Well, it does. Because my phone can handle an #ipv6 only wifi, unlike the crappy Ecoflow device. So I guess I have to look for something else...

# orderedItems[].object.content
The lack of RDNSS support in the @alpinelinux installer is becoming an issue for my environment. Having to manually enter DNS resolvers to bootstrap any packages to read them from the network is extremely annoying.

In a previous thread someone suggested that I should just set up DHCPv6 information only. I have a number of issues with this, but mostly we already spent years fighting the 600 lb gorilla in the room (Android). As much as it irks me that they won, every other operating system can do RDNSS out-of-the-box now, and it is The Way for most non-enterprise networks.

The simplest fix would be to make rdnssd available in the installer environment. Then all of the components (udhcpc6, rdnssd, kernel autoconf) would be present. However, this means the user would then have to make the decision about which to use based on knowledge of the network. This ignores all of the necessary information provided in the Router Advertisement.

The other issue is that you now potentially have multiple entities trying to manage resolv.conf, necessitating openresolv.

Thus I feel the correct solution is to use dhcpcd in lieu of the busybox widgets. This gives DHCP(v6), SLAAC, and RDNSS all in one tool. It's not as light as the busybox versions, but light enough for the balance of the extra functionality you get IMHO. ifupdown-ng already has plumbing for it.

I wrote all this out to make sure I have all my thoughts in order. I realize I'm new to the Alpine world, so how do I start the conversation about this?

#ipv6

# orderedItems[].object.content
https://blog.apnic.net/2026/04/28/goog le-hits-50-ipv6/

#blog #ipv6 #internet #Apnic #statistics #google

# orderedItems[].object.content
I might experiment with RFC 8925 tomorrow night to signal to clients on my #IPv6 preferred subnet to disable their IPv4 stacks altogether. That might take another patch to the #VPP router advertisement process.

I can disable IPv4 on my Macs and they engage the CLAT based on the PREF64 and RDNSS flags. But Android seems to be stubborn. It won't stay connected without DHCP (v4) on the network. Maybe RFC 8925 will help.

# orderedItems[].object.source.content
I might experiment with RFC 8925 tomorrow night to signal to clients on my #IPv6 preferred subnet to disable their IPv4 stacks altogether. That might take another patch to the #VPP router advertisement process.

I can disable IPv4 on my Macs and they engage the CLAT based on the `PREF64` and `RDNSS` flags. But Android seems to be stubborn. It won't stay connected without DHCP (v4) on the network. Maybe RFC 8925 will help.

# orderedItems[].object.name
Extending the Vector Packet Processing Engine

# orderedItems[].object.summary
I've been building core networking components to leverage VPP more fully as a branch router. Here is an overview of that work.

# orderedItems[].object.content
Within the last couple of years, I spent some time working with a small regional ISP as CTO. We were focused on building out FTTP for our local community both to rural dwellings and to multi-dwelling units (MDUs).

One of the challenges that we had as a bootstrapped technology company was the cost of enterprise networking equipment. The founder of the company made the strategic decision to focus on delivering active Ethernet to our subscribers (no GPON). This allowed us to stick to the type of networking solutions that might be deployed in an enterprise campus rather than the proprietary solutions that drive more common FTTP deployments.

We also wanted more direct control over our network fabric. That led us to explore open networking solutions like SONiC and #VPP. VPP in particular found a home in our MDU deployments, allowing us to build very capable routing platforms using #OSS and no proprietary ASICs or other traditionally pipelined solutions.

There are some challenges with VPP, however. The system has a number of plugins (e.g., nat44-ed, ct6, nat64, acl-plugin, etc.) that were useful for our deployments. But some plugins interacted poorly with others (e.g., routing through an interface and using NAT together doesn't work well, using NAT64 and anything else doesn't work well, etc.) I came up with some tortured solutions to those problems that involved ACL-based forwarding, memif interfaces, and multiple VPP processes. But they weren't ideal.

Within the last month, I decided to take a stab at solving a problem in my home lab with ct6: ostensibly designed for #IPv6 connection tracking, it really didn't do much of anything. It's mostly a stub for future work that has never been completed. I decided to complete it and submitted a merge request upstream.

But in that process, I realized that I could do a lot more. Rather than just patch ct6, I could build a plugin from whole cloth that handled all of my translation needs from a common state table. And I could perform access control decisions with the state maintained as part of that capability. That became: https://github.com/justindthomas/sfw:

sfw zone internal interface lan
sfw zone external interface wan
sfw policy outbound from-zone internal to-zone external
sfw policy outbound default-action permit-stateful-nat
sfw policy inbound from-zone external to-zone internal
sfw policy inbound default-action deny
sfw nat64 pool add x.x.x.x/32 prefix 64:ff9b::/96

Along the way, I realized that I could take things further. I had been using Free Range Router (FRR) to handle things like BGP and OSPF. But it integrates with VPP via a shim called the Linux Control Plane. As the name implies, that only works on Linux, and I want to be flexible enough to support FreeBSD as well.

So I wrote https://github.com/justindthomas/vcl-rs to allow for Rust daemons to bind into VPP directly without going through the host stack. Then I created: ribd, bgpd, ospfd, and dnsd.

These daemons all have common characteristics; they each read a dedicated section from a YAML file (i.e., one file can be used to control all of them), they're designed to reload configuration on a SIGHUP, and they avoid using the host networking stack in favor of either vcl-rs or punt sockets (e.g., for OSPF).

That last daemon (dnsd) has me excited today. I'm very interested in facilitating the transition to IPv6. So things like #464XLAT, #NAT64, and #DNS64 are in my sights. But support for each of those protocols is challenging; VPP does not support router advertisements for #PREF64 (for NAT64) or for #RDNSS (to communicate IPv6 DNS information to clients).

To deal with that, I added in a couple of patches as part of sfw that hook into VPP's existing router advertisement functions. That expands the advertisements to include PREF64 and RDNSS:

00:00:00.000000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104)
    fe80::dcad:ff:fe00:64 > ff02::1: [icmp6 sum ok] ICMP6, router
    advertisement, length 104
  hop limit 64, Flags [managed], pref medium, router lifetime 600s,
      reachable time 0ms, retrans timer 0ms
    source link-address option (1), length 8 (1): de:ad:00:00:00:64
      0x0000: dead 0000 0064
    mtu option (5), length 8 (1):&nbsp; 1500
      0x0000: 0000 0000 05dc
    prefix info option (3), length 32 (4): xxxx:xxxx:10::/64,
          Flags [onlink, auto], valid time 2584092s, pref. time 596892s
      0x0000: 40c0 0027 6e1c 0009 1b9c 0000 0000 xxxx
      0x0010: xxxx 0010 0000 0000 0000 0000 0000
    unknown option (38), length 16 (2):
      0x0000: 0708 0064 ff9b 0000 0000 0000 0000
    rdnss option (25), length 24 (3):&nbsp; lifetime 90s,
          addr: xxxx:xxxx:10:0:ffff:ffff:ffff:fffe
      0x0000: 0000 0000 005a xxxx xxxx 0010 0000 ffff
      0x0010: ffff ffff fffe

This has enabled me to have a client network that is purely IPv6. My Mac clients see the router advertisements and enable their clat46 functionality:

en0: flags=88e3<UP,BROADCAST,SMART,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
    options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
    ether 16:59:1d:c2:0d:c7
    inet6 fe80::1841:489:85ff:916f%en0 prefixlen 64 secured scopeid 0xb
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf secured
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf temporary
    inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 clat46
    nat64 prefix 64:ff9b:: prefixlen 96
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active

Interactions with IPv4 servers is automatically translated into 64:ff9b::/96 addresses and passed along to the servers over the router's IPv4 stack.

These daemons - even individually - constitute a formidable code base. And obviously I used an LLM to help create the tens of thousands of lines of code in total. The effort has been informed heavily by RFCs, industry-standard conformance testing, and integration testing against other routing platforms. And for some (like dnsd) a lot of iterations just to get performance to a solid level (I think DNS is more complex than we give it credit for - especially when DNSSEC is considered). And the fact that I'm avoiding the host networking stack complicates matters, because I have to handle the translation between Rust code and the C code that exposes the VCL capabilities in VPP.

I'm using the end product daily (pulled together in a larger router framework that I haven't released yet) and tweaking as issues reveal themselves. If you'd like to participate, please feel free to drop me a line.

# orderedItems[].object.source.content
Within the last couple of years, I spent some time working with a small regional ISP as CTO. We were focused on building out FTTP for our local community both to rural dwellings and to multi-dwelling units (MDUs).

One of the challenges that we had as a bootstrapped technology company was the cost of enterprise networking equipment. The founder of the company made the strategic decision to focus on delivering active Ethernet to our subscribers (no GPON). This allowed us to stick to the type of networking solutions that might be deployed in an enterprise campus rather than the proprietary solutions that drive more common FTTP deployments.

We also wanted more direct control over our network fabric. That led us to explore open networking solutions like SONiC and #VPP. VPP in particular found a home in our MDU deployments, allowing us to build very capable routing platforms using #OSS and no proprietary ASICs or other traditionally pipelined solutions.

There are some challenges with VPP, however. The system has a number of plugins (e.g., `nat44-ed`, `ct6`, `nat64`, `acl-plugin`, etc.) that were useful for our deployments. But some plugins interacted poorly with others (e.g., routing through an interface and using NAT together doesn't work well, using NAT64 and anything else doesn't work well, etc.) I came up with some tortured solutions to those problems that involved ACL-based forwarding, `memif` interfaces, and multiple VPP processes. But they weren't ideal.

Within the last month, I decided to take a stab at solving a problem in my home lab with `ct6`: ostensibly designed for #IPv6 connection tracking, it really didn't do much of anything. It's mostly a stub for future work that has never been completed. I decided to complete it and submitted a merge request upstream.

But in that process, I realized that I could do a lot more. Rather than just patch `ct6`, I could build a plugin from whole cloth that handled all of my translation needs from a common state table. And I could perform access control decisions with the state maintained as part of that capability. That became: [https://github.com/justindthomas/sfw](https://github.com/justindthomas/sfw):

```
sfw zone internal interface lan
sfw zone external interface wan
sfw policy outbound from-zone internal to-zone external
sfw policy outbound default-action permit-stateful-nat
sfw policy inbound from-zone external to-zone internal
sfw policy inbound default-action deny
sfw nat64 pool add x.x.x.x/32 prefix 64:ff9b::/96
```

Along the way, I realized that I could take things further. I had been using Free Range Router (FRR) to handle things like BGP and OSPF. But it integrates with VPP via a shim called the Linux Control Plane. As the name implies, that only works on Linux, and I want to be flexible enough to support FreeBSD as well.

So I wrote [https://github.com/justindthomas/vcl-rs](https://github.com/justindthomas/vcl-rs) to allow for Rust daemons to bind into VPP directly without going through the host stack. Then I created: [ribd](https://github.com/justindthomas/ribd), [bgpd](https://github.com/justindthomas/bgpd), [ospfd](https://github.com/justindthomas/ospfd), and [dnsd](https://github.com/justindthomas/dnsd).

These daemons all have common characteristics; they each read a dedicated section from a `YAML` file (i.e., one file can be used to control all of them), they're designed to reload configuration on a `SIGHUP`, and they avoid using the host networking stack in favor of either `vcl-rs` or `punt` sockets (e.g., for OSPF).

That last daemon (dnsd) has me excited today. I'm very interested in facilitating the transition to IPv6. So things like #464XLAT, #NAT64, and #DNS64 are in my sights. But support for each of those protocols is challenging; VPP does not support router advertisements for #PREF64 (for NAT64) or for #RDNSS (to communicate IPv6 DNS information to clients).

To deal with that, I added in a couple of patches as part of `sfw` that hook into VPP's existing router advertisement functions. That expands the advertisements to include `PREF64` and `RDNSS`:

```
00:00:00.000000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104) 
    fe80::dcad:ff:fe00:64 > ff02::1: [icmp6 sum ok] ICMP6, router 
    advertisement, length 104 
  hop limit 64, Flags [managed], pref medium, router lifetime 600s, 
      reachable time 0ms, retrans timer 0ms
    source link-address option (1), length 8 (1): de:ad:00:00:00:64
      0x0000: dead 0000 0064
    mtu option (5), length 8 (1):  1500
      0x0000: 0000 0000 05dc
    prefix info option (3), length 32 (4): xxxx:xxxx:10::/64, 
          Flags [onlink, auto], valid time 2584092s, pref. time 596892s
      0x0000: 40c0 0027 6e1c 0009 1b9c 0000 0000 xxxx
      0x0010: xxxx 0010 0000 0000 0000 0000 0000
    unknown option (38), length 16 (2):
      0x0000: 0708 0064 ff9b 0000 0000 0000 0000
    rdnss option (25), length 24 (3):  lifetime 90s,
          addr: xxxx:xxxx:10:0:ffff:ffff:ffff:fffe
      0x0000: 0000 0000 005a xxxx xxxx 0010 0000 ffff
      0x0010: ffff ffff fffe
```
This has enabled me to have a client network that is purely IPv6. My Mac clients see the router advertisements and enable their `clat46` functionality:

```
en0: flags=88e3<UP,BROADCAST,SMART,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
    options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
    ether 16:59:1d:c2:0d:c7
    inet6 fe80::1841:489:85ff:916f%en0 prefixlen 64 secured scopeid 0xb
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf secured
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf temporary
    inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 clat46
    nat64 prefix 64:ff9b:: prefixlen 96
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
```
Interactions with IPv4 servers is automatically translated into `64:ff9b::/96` addresses and passed along to the servers over the router's IPv4 stack.

These daemons - even individually - constitute a formidable code base. And obviously I used an LLM to help create the tens of thousands of lines of code in total. The effort has been informed heavily by RFCs, industry-standard conformance testing, and integration testing against other routing platforms. And for some (like `dnsd`) a lot of iterations just to get performance to a solid level (I think DNS is more complex than we give it credit for - especially when DNSSEC is considered). And the fact that I'm avoiding the host networking stack complicates matters, because I have to handle the translation between Rust code and the C code that exposes the VCL capabilities in VPP.

I'm using the end product daily (pulled together in a larger router framework that I haven't released yet) and tweaking as issues reveal themselves. If you'd like to participate, please feel free to drop me a line.

# orderedItems[].object.content
#Nigeria #ipv6

https://techcabal.com/2026/04/24/niger ia-launches-three-year-plan-to-upgrade-internet-system/

🙏

# orderedItems[].object.ephemeral.metadata[].description
The NCC plans to overhaul its Internet infrastructure over the next three years as demand for connectivity outgrows the current Internet system.

# orderedItems[].object.ephemeral.metadata[].ogDescription
The NCC plans to overhaul its Internet infrastructure over the next three years as demand for connectivity outgrows the current Internet system.

# orderedItems[].object.ephemeral.metadata[].ogTitle
Nigeria launches three-year plan to upgrade Internet system

# orderedItems[].object.content
The last 24 hours have been a nostalgia roller coaster. Seeing ax25 getting removed from the Linux kernel led me to finally poking at linbpq. I ran BPQ under DOS back in the mid 90s before I switched to JNOS and learning TCP/IP, setting me on my career path. Finding out linbpq supports #ipv6 absolutely made my day! The old meets the modern in such a comfortable way.

#hamradio

# orderedItems[].object.content
Time to fall asleep to comforting fantasy - IPv6 adoption lectures #IPv6

# orderedItems[].object.content
RE: https://infosec.exchange/@SecurityWrit er/116441509361345057

This makes the trend among #IPv6 folk of referring to IPv4 as "legacy IP" seem downright quaint.

# orderedItems[].object.ephemeral.metadata[].description
I’ve just witnessed a horrific LinkedIn trend in person.

There’s an increasing contingent of cultists saying:

“We should refer to the field of IT as ‘AI’ because that’s what the future is”

I’m not sure what podcast they heard it on, but some guy just said to me:

“You work in AI, don’t you?”

Um… no? Security and IT

“Yeah, AI”

This person made a choice to attend a major tech conference and be this stupid.

Stop the planet, I’m disembarking.

# orderedItems[].object.ephemeral.metadata[].ogDescription
I’ve just witnessed a horrific LinkedIn trend in person.

There’s an increasing contingent of cultists saying:

“We should refer to the field of IT as ‘AI’ because that’s what the future is”

I’m not sure what podcast they heard it on, but some guy just said to me:

“You work in AI, don’t you?”

Um… no? Security and IT

“Yeah, AI”

This person made a choice to attend a major tech conference and be this stupid.

Stop the planet, I’m disembarking.

# orderedItems[].object.content
I could have sworn pinafore.social had #IPv6 at one point. Oh well. Trying out phanpy.social from an IPv6-only network. So far so good, though my instance's CDN reachability on IPv6 is still spotty.

# orderedItems[].object.content
Something to consider about all of the efforts to sustain #IPv4 so far beyond its original shelf life. #NAT and #IPv6 were thought out at roughly the same time. NAT was a tactical move to stave off IPv4 exhaustion (at the cost of limiting the peer-to-peer nature of the Internet) and IPv6 was the strategic answer for scalable growth. The obsession human beings have to find any excuse to avoid change was highly underestimated. IPv6 took 22 years to become an Internet Standard and NAT became so entrenched that peer-to-peer networking became mostly unnecessary as long as we could continue to laugh at cat memes on our favourite platforms.

This brings us to #platforms. It’s getting harder to host anything ourselves anymore without paying a (usually foreign) IaaS/SaaS platform to do it for us. We now live in an age where data sovereignty and privacy are at the forefront of our thinking and maybe, just maybe, we want other options.

Is our obsession with IPv4 tying us unhealthily to platforms and sacrificing our freedoms?

#SaturdayMorningThoughts

# orderedItems[].object.content
"Why is #IPv6 so complicated?" It isn't. It's different, but it's not inherently more complicated.

# orderedItems[].object.content
Google's #ipv6 stats page ( https://www. google.com/intl/en/ipv6/statis tics.html ) was not updating for a bit and I stopped checking it regularly. Finally took a look today and it appears there was a new record high on March 28th.

50.10% !!!!!!

# orderedItems[].object.attachment[].name
Google's IPv6 stats page showing 50.10% of the traffic being IPv6 on March 28, 2026.

# orderedItems[].object.content
New version of https://check-tls.akamai.io/ now checks H2, H3, and if the key exchange used PQC, in addition to TLS version and IPv6 support. It's a good way to test agents, thumbnailers, search engines, etc. Perhaps for a future version I'll replace the image.

Using https://check-tls.akamai.io/v1/tlsinfo.json will give some more raw data and can be usable for other types of agents.

#IPv6 #PQC #TLS

# orderedItems[].object.ephemeral.metadata[].ogDescription
Check TLS - (SNI=present,https,tls1.3,ipv4,h2,) - test results with searchtokenPDXTXRFLK from og:description