Posts on ForwardingPlane.net

IPB 207 - Flying Blind: Monitoring Might Not See IPv6

Thu, 03 Sep 2026 00:00:00 +0000

Is your current network monitoring infrastructure capable of seeing IPv6 traffic or are you flying blind in a dual-stack environment? Today Ed, Nick, and Tom explore the critical challenges surrounding IPv6 visibility such as the limitations of vendor tools and the complexities of maintaining observability as networks evolve.

Have a listen:

Podcast link: IPB207: Flying Blind: Monitoring Might Not See IPv6

IPB 206 - Do IPv6 Mandates Work?

Thu, 20 Aug 2026 00:00:00 +0000

Nick Buraglio and Tom Coffeen discuss a Reddit post that had what appeared to be new federal guidance on IPv6 adoption. While it seems the timelines and guidelines haven’t changed, the post raises questions about the effectiveness of mandates in driving IPv6 adoption. They posit that enabling IPv6 is not just a technical requirement but a strategic necessity for future-proofing infrastructure as organizations adopt zero trust and AI.

Have a listen:

Podcast link: IPB206: Do IPv6 Mandates Work?

Show links:

September Deadline Looms as U.S. Federal Government Pushes Toward 60% IPv6 Deployment

Internet Protocol Version 6 (IPv6) Policy

Beyond the legacy trap: why IPv6 only is the inevitable future of Vietnam’s internet

IPv6-mostly Networks: Deployment and Operations Considerations

IPB 205 - Moving to Disable IPv4

Thu, 06 Aug 2026 00:00:00 +0000

Franck Martin returns to the show to discuss the practical challenges of retiring IPv4 with hosts Ed, Nick, and Tom. Together they break down key strategies, how to work effectively with vendors, and how to mitigate potential outages during the transition. They also explore the cultural shifts necessary for successful IPv6 adoption and the importance of engaging security teams early in the process.

Have a listen:

Podcast link: IPB205: Moving to Disable IPv4

Show links:

PeachyMango

Franck Martin’s LinkedIn Post

HTTP Signaling of Planned IPv4 Unavailability

Deploying IPv6 in Data Centers

IPv6 in the Enterprise: Lessons from the Trenches

piccolo-perf - a perfSONAR-lite for routers and SBCs

Sun, 02 Aug 2026 00:00:00 +0000

I have a soft spot for perfSONAR . It’s the gold standard for research and education network performance measurement, and if you run a network that touches ESnet, Internet2, or any of the big R&E backbones, you’ve probably got a perfSONAR node (or ten) somewhere. The problem is that perfSONAR is heavy. It wants a full OS, a stack of services, and real resources. That’s fine for a dedicated measurement box and that has served perfSonar well for 20 years, but it’s a non-starter for a router, a Raspberry Pi at a remote site, or anything else you’d call “constrained.”

That gap is exactly what piccolo-perf is going after. It’s a single static Go binary, no runtime dependencies, that gives you TWAMP-Light, TCP bandwidth, traceroute, MTU discovery, and DNS latency measurements, plus an agent mode that turns a fleet of these into a lightweight distributed mesh - InfluxDB and Prometheus included. Dual stack throughout, which matters to me more than it probably should. Honestly, I have been working on this for 15+ years, from trying to run OWAMP on a rpi1, to helping distribute mac minis for perfSonar tools into campuses, to even running lightweight versions of the toolkit on actual L3 switchines in the early days of virtualized NOSs'. This project has been a labor of love and with my recent endeavor to teach myself golang, I thought “why not give it a try with this”? The results are surprisingly useful.

The measurement set:

twamp - RTT, jitter, and packet loss via TWAMP-Light (RFC 5357 §5). No TCP control session, pure UDP test packets, so it’s cheap to run and interoperable with other TWAMP-Light endpoints.
bw - TCP throughput, either a native Go implementation or iperf3 if it’s present on the box.
trace - per-hop RTT and path topology via ICMP TTL/HopLimit probing, IPv4 and IPv6.
mtu - effective path MTU via ICMP binary search (DF-bit on v4, Packet Too Big on v6). Useful for finding where a WireGuard tunnel or a double-encapsulated path quietly knocked your MTU down - very common in managed-service-paths.
dns - A successor to DNS test resolver latency and success rate, independent of the system resolver.
agent - runs all of the above on a schedule, reflects TWAMP for peers, and ships results to InfluxDB and/or exposes them as Prometheus metrics.

Anything that needs raw sockets (mtu, trace) degrades gracefully without CAP_NET_RAW rather than failing outright - it just reports skipped=true. That’s a small detail, but it’s the kind of thing that tells you someone has actually run this on a box they don’t have root on. I’d be open to better ways to handle that.

Getting it running is a one-liner:

/bin/sh -c "$(curl -fsSL https://raw.githubusercontent.com/retecolo/piccolo-perf/main/install.sh)"

and a one-shot test looks like this:

piccolo-perf twamp -mode client -server 2001:db8::1

[TWAMP-Light-Client] Starting TWAMP-Light test to 2001:db8::1 (count=10 interval=1s timeout=5s padding=0)
[TWAMP-Light-Client] seq=1 RTT=0.823ms
...
[TWAMP-Light-Client] === TWAMP-Light Test Statistics ===
[TWAMP-Light-Client] Packets sent:     10
[TWAMP-Light-Client] Packets received: 10
[TWAMP-Light-Client] Packet loss:      0.0%
[TWAMP-Light-Client] RTT min/avg/max:  0.778 / 0.812 / 0.857 ms
[TWAMP-Light-Client] Mean jitter:      0.018 ms

The part I find more interesting than the one-shot CLI use is agent mode, and this harkens back to the inspiration for this peoject, perfSonar. Point a handful of hosts at a config server serving a JSON topology file, and each host stands up a TWAMP reflector, a bandwidth sink, and per-measurement schedulers, then pushes results upstream:

┌─────────────────────────────────────────┐
│            Each Probe Host              │
│  piccolo-perf agent                     │
│  ├── TWAMP-Light reflector (UDP)        │
│  ├── BwServer (TCP sink, port 5201)     │
│  ├── Per-measurement schedulers         │
│  ├── Config poller (HTTP, live-reload)  │
│  ├── InfluxDB writer                    │
│  ├── Prometheus /metrics                │
│  └── Local JSONL resilience store       │
└──────────┬──────────────────┬───────────┘
           │ pull config      │ push metrics
           ▼                  ▼
  ┌──────────────┐    ┌──────────────┐
  │ Config Server│    │   InfluxDB   │◀─── Grafana
  └──────────────┘    │  Prometheus  │
                       └──────────────┘

Topology can be full mesh (every host probes every other host) or hub-and-spoke, which is the more realistic shape for most of us - a handful of spokes reporting back to a hub instead of an N² mesh. There’s also a local JSONL ring buffer for intermittently-connected edge devices, so a probe that loses its uplink keeps measuring and replays results once connectivity comes back instead of just dropping data on the floor.

Where this actually fits

A few use cases jump out:

IPv6 test pods and lab networks. If you listened to IPB173 or any of the recent IPv6 Buzz episodes on lab builds, this is a natural fit for exactly that kind of environment - dual-stack RTT, jitter, and MTU measurement without standing up a perfSONAR node for every pod. Hey James, lets test this out =)
CPE and branch office monitoring. Since it compiles to a static binary across amd64, arm64, arm, mips, ppc64le, and riscv64, it’ll run on the kind of small router or SBC that lives at a remote site where you have no business installing a full measurement stack.
VPN and tunnel path MTU troubleshooting. The mtu subcommand’s binary search is a fast way to confirm whether a WireGuard or other tunnel is silently truncating your effective MTU, without reaching for tcpdump and doing the math by hand.
A perfSONAR-adjacent mesh on a budget. Agent mode with hub-and-spoke topology and Grafana on top gets you a reasonable approximation of a perfSONAR mesh dashboard for a fraction of the deployment overhead, which is appealing if you want visibility into a network that doesn’t justify (or fit) the full perfSONAR toolkit.

It’s early days for the project, but the design choices - graceful degradation without root, IPv6 treated as a first-class citizen rather than an afterthought, and a resilience store for flaky links - suggest someone building this against real constraints rather than a whiteboard. Worth a look if smokeping and perfSONAR are two ends of a spectrum you’ve been missing the middle of.

IPB 204 - Tayga and IPv6 Translation

Thu, 23 Jul 2026 00:00:00 +0000

Andrew Palardy joins the hosts to discuss how Tayga, the open-source NAT64 daemon for Linux, is being updated to ensure it is up to date with all the current RFCs. The discussion covers RFC compliance updates and UDP checksum fixes for resolving connectivity problems, plus new eBPF CLAT support arriving in NetworkManager to provide automatic CLAT functionality.

Have a listen:

Podcast link: IPB204: Tayga and IPv6 Translation

Show links:

Tayga (GitHub)

Andrew Palardy on YouTube

Andrew Palardy’s Website

IPv6 - Why You Should Care

Wed, 22 Jul 2026 00:00:00 +0000

I had the opportunity to speak at the Chicago Network Operators Group conference for CHI-NOG 13. As one may imagine, I talked about IPv6, and why folks should care. Now, you’re probably thinking “yeah, yeah, IPv6 has been almost here for 20 years”, and I’d move along and not try to convince you otherwise. However, this talk was slightly different - the whole point was to acknoledge that yes, it’s taking a long time. Yes, enterprises are the long pole in the tent. But no, it’s not almost here. It’a already here, and it’s been here for a decade. Where it isn’t is in the enterprise - and that’s not really a surprise. the talk was very well received, garnering probably the most flattering write up of any talk I have ever given, and by a highly technical author that was in the front row of the talk. you can read that here , which I highly encourage you to do.

If you’re interested, the talk is available on youtube . It’s 30 minutes and I would argue that it makes a pretty compelling argument, if i do say so myself =)

IPB 203 - The Death of NAT

Thu, 25 Jun 2026 00:00:00 +0000

Network Address Translation (NAT), a foundational element of IPv4, faces critical reassessment as IPv6 deployment shifts the landscape. Ed and Tom evaluate the evolving role of NAT, questioning whether traditional translation models remain necessary when stateful packet inspection offers more robust, transparent security solutions.

Have a listen:

Podcast link: IPB203: The Death of NAT

Show links:

“Fanboy” series – IPv6 and NATs

IPB 202 - How to Get Hands-On IPv6 Deployment Experience

Thu, 11 Jun 2026 00:00:00 +0000

The episode explores gaining practical IPv6 experience through hands-on deployment. Guest John Osmon discusses setting up a personal IPv6 lab environment, including low-cost home lab options and how this experience has increased his confidence in tackling IPv6 projects.

Have a listen:

Podcast link: IPB202: How to Get Hands-On IPv6 Deployment Experience

Show links:

“Where in the contract does it say you can’t NAT IPv6?"

“So, you want to try IPv6?"

IPB 201 - The Never-Ending Prefix Debate: Revisiting Best Current Practices

Thu, 28 May 2026 00:00:00 +0000

Today’s conversation centers around a new Best Current Practices (BCP) RFC draft written by Jordi Palet Martinez. Our hosts explore the document for service providers and enterprises, including prefix sizing for point-to-point links, the pros and cons of numbering choices, and best practices for prefix pool allocation.

Have a listen:

Podcast link: IPB201: The Never-Ending Prefix Debate: Revisiting Best Current Practices

Show links:

IPv6 Prefix Assignment to End-Sites

IPB 200 - Yes, IPv6 Is Complicated. IPv8 Won't Help

Thu, 14 May 2026 00:00:00 +0000

Why is IPv6 so much more complicated than IPv4? Could a newer version such as IPv8 be the solution? Guest Brian Carpenter joins our hosts to explain that many of IPv6’s complications are mathematical necessities. They point out that IPv6 has a 30 year head start on any IPv8 proposal that would struggle with many of the same issues. They also discuss features like automatic address configuration and the slow but inevitable global adoption of IPv6.

Have a listen:

Podcast link: IPB200: Yes, IPv6 Is Complicated. IPv8 Won’t Help

Show links:

“Why is IPv6 so complicated?"

Book6 – An open source book on IPv6

IPB 199 - Developing IPv6-Friendly Code

Thu, 30 Apr 2026 00:00:00 +0000

Tom Coffeen and Nick Buraglio welcome Fern Cummings to talk about developing code for IPv6. Fern argues that moving to IPv6 restores end-to-end connectivity, which reduces complexity for developers without the need for “ridiculous hacks” caused by IPv4 NAT. The discussion offers practical advice on avoiding common developer traps, and covers financial benefits such as reduced logging costs and improved security.

Have a listen:

Podcast link: IPB199: Developing IPv6-Friendly Code

IPB 198 - IPv6 Privacy and Temporary Addresses

Thu, 16 Apr 2026 00:00:00 +0000

Today our hosts discuss IPv6 Privacy and Temporary Addresses to clarify how address provisioning can potentially work for host operating systems. The discussion covers the difference between permanent and temporary privacy addresses, their uses, and how interface identifiers are assigned to hosts.

Have a listen:

Podcast link: IPB198: IPv6 Privacy and Temporary Addresses

IPB 197 - SLAAC and the End of DHCP?

Thu, 02 Apr 2026 00:00:00 +0000

Today our hosts discuss the essential role of Stateless Address Autoconfiguration (SLAAC) in successfully deploying an IPv6-mostly network. SLAAC is required to assign a unique IPv6 address to the Customer-side Translator (CLAT), which allows devices to operate on IPv6. However, enterprise operators might prefer using DHCPv6 for network tracking and accountability, potentially trapping them in complex dual-stack environments.

Have a listen:

Podcast link: IPB197: SLAAC and the End of DHCP?

Show links:

RFC 9686: Registering Self-Generated IPv6 Addresses Using DHCPv6

IPB 196 - Is End-to-End Connectivity the Right Goal?

Thu, 19 Mar 2026 00:00:00 +0000

One of the early design principles of the Internet was end-to-end connectivity: that is, every device on the Internet would be publicly addressable, and every device could share its resources or provide services. The hosts examine whether this foundational principle remains realistic for IPv6, discussing its historical erosion in IPv4 and the IETF’s continued adherence to it.

Have a listen:

Podcast link: IPB196: Is End-to-End Connectivity the Right Goal?

Linkwarden with docker compose and nginx proxy manager

Thu, 12 Mar 2026 00:00:00 +0000

[Linkwarden(https://github.com/linkwarden/linkwarden) is a tool for better managing bookmarks. If you’re nything like me, you keep 1000 browser tabs open across a series of profiles, with full intention of revisiting them later, and then never do. A colleague shpoed me linkwarden and I was interested straight away. I did have a few hangups, however:

I don’t want to rely on a cloud service if I don’t have to
I prefer to control my own content
I am not a big fan of docker, which is required for self hosting

I got over the docker hangup since it wasn’t really an option to do any other way and got straight to it. Very quickly I ran into the near-universal issues I have with docker:

poor understanding or lack of attention of networking by the developers (this needs to run over IPv6 for me to use it)
spotty documentation for running this securely via a SSL enabled web service

As I have done with other services that require docker, I went to nginx proxy manager. This container is a nice front end for proxying services via SSL / NGINX, and is far easier to wrestle than something like Traefik.

After much fighting of the docker compose file I ended up with this, which works.

services:
  postgres:
    image: postgres:16-alpine
    env_file: .env
    restart: always
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    networks:
      - linkwarden-network
  linkwarden:
    env_file: .env
    environment:
      - DATABASE_URL=postgresql://postgres:${POSTGRES_PASSWORD}@postgres:5432/postgres
    restart: always
    # build: . # uncomment to build from source
    image: ghcr.io/linkwarden/linkwarden:latest # comment to build from source
    ports:
      - 3000:3000
    volumes:
      - ./data:/data/data
    depends_on:
      - postgres
      - meilisearch
    networks:
      - linkwarden-network
  meilisearch:
    image: getmeili/meilisearch:v1.12.8
    restart: always
    env_file:
      - .env
    networks:
      - linkwarden-network
    volumes:
      - ./meili_data:/meili_data
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    container_name: npm
    ports:
      - "81:81"    # Admin interface
      - "80:80"    # HTTP
      - "443:443"  # HTTPS
    volumes:
      - ./npm/data:/data
      - ./npm/letsencrypt:/etc/letsencrypt
    networks:
      - linkwarden-network
networks:
  linkwarden-network:
    driver: bridge
    enable_ipv6: true

This configuration will work with NPM front ending the https pieces, and will also work behind cloudflare. You’ll need to find the address of the container to put into the NPM proxy manager. This can be found with the following command:

sudo docker inspect <container ID> | grep IP

The output should look similar to

buraglio@dockhost1:/opt/linkwarden$ sudo docker inspect af8e7a6c4edd | grep IP
                "RSS_SUBSCRIPTION_LIMIT_PER_USER=",
                "PIPEDRIVE_CUSTOM_NAME=",
                "NEXT_PUBLIC_PIPEDRIVE_ENABLED=",
                "PIPEDRIVE_CLIENT_ID=",
                "PIPEDRIVE_CLIENT_SECRET=",
                    "IPAMConfig": null,
                    "IPAddress": "172.19.0.4",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "fd64:b2a0:6eac:1::1",
                    "GlobalIPv6Address": "fd64:b2a0:6eac:1::4",
                    "GlobalIPv6PrefixLen": 64,

for anyone who would rather not deal with this amount of complexity, linkwarden has a very reasonable hosted option .