Posts on ForwardingPlane.net

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 .

Mikrotik wireguard optimization

Tue, 17 Feb 2026 00:00:00 +0000

Most modern mikrotik can handle reasonable wireguard performance, but it is a CPU based encryption model, so there are some tweaks that can be made to improve performance. The following can be used to optimize for better wireguard behavior. However, it should be noted that unlike the IPSec capabilities that are measured and reported on the Mikrotik product pages for each platform, wireguard limits are not published for any mikrotik platform. This can be translated into “you get what you get”, essentially, and as stated, wireguard is all CPU based, so perfornmance and scale will be limited by CPU.

Set the queuing for the WAN interface to `fq-codel` or `cake`

FQ-CoDel and CAKE are both modern queue management systems designed to reduce bufferbloat and ensure fair bandwidth distribution, but CAKE offers several enhancements:

1. Flow Hashing

FQ-CoDel: Uses a basic hash to assign packets to flows, which can lead to collisions under high flow counts.
CAKE: Uses an 8-way set-associative hash, drastically reducing collisions and improving flow isolation.

2. Fairness

FQ-CoDel: Fairness is per-flow—clients with more connections get more bandwidth.
CAKE: Adds per-host fairness (via Cobalt), so a client with 10 connections doesn’t dominate one with 1.

3. Shaping & Overhead Handling

FQ-CoDel: Often paired with a separate shaper (e.g., HTB), increasing CPU use.
CAKE: Includes an integrated shaper, is more CPU-efficient, and supports framing compensation (e.g., for PPPoE, ATM).

4. MSS & MTU Awareness

CAKE: Tracks packet sizes in bytes, not packets, avoiding issues with large GSO/GRO packets.
FQ-CoDel: Uses packet count, which can misrepresent memory usage.

5. Diffserv Support

CAKE: Built-in DiffServ mode for traffic class prioritization.
FQ-CoDel: No native Diffserv support.

/queue type
add kind=cake name=cake
/queue interface
set sfp-sfpplus1 queue=cake

Or, with fq_codel

/queue type
add kind=fq-codel name=fq-codel
/queue interface
set sfp-sfpplus1 queue=fq-codel

Disable fasttrack for the wireguard interface

/ip firewall raw add action=notrack chain=prerouting in-interface=wg1

Set the correct MTU and MSS in order to to account for encapsulation overhead. Clamp MSS on TCP traffic to prevent fragmentation.

/ip firewall mangle add protocol=tcp tcp-flags=syn action=change-mss new-mss=1400 chain=forward out-interface=wg1

The MTU and MSS are related but distinct values:

MTU (Maximum Transmission Unit) = 1420 bytes: This is the largest IP packet size the WireGuard interface can transmit, including all headers.
MSS (Maximum Segment Size) = 1400 bytes: This is the largest payload size for TCP data within that packet, excluding the TCP and IP headers.

The difference accounts for the 40-byte overhead of the TCP and IPv4 headers (20 bytes each). Explicitly:

MSS = MTU - 40
1400 = 1420 - 40

Setting MSS to 1400 ensures that when TCP adds its 40-byte header, the total packet size (1440 bytes) stays safely below the effective path MTU, preventing fragmentation. However, since WireGuard itself adds ~80 bytes of encapsulation overhead, the outer packet must be smaller — therefor setting the WireGuard interface MTU to 1420.

This combination avoids fragmentation and packet drops, especially on paths with lower MTU or blocked ICMP (which breaks Path MTU Discovery).

IPv6 address formatting

Fri, 06 Feb 2026 00:00:00 +0000

IPv6 has a monumental amount of flexibility. That flexibility flow over into the address format, which can be - in some cases - a bit frustrating. Since IPv6 address can be presented in several ways, and this can be frustrating for those writing code to suport IPv6 or engineers trying to create templates. It can also be painful during troubleshooting. In an effort to craft something that is similar to my mac address shell tool , I wanted something similar for IPv6 addresses.

Remembering that my programming skills are not teriffic, and all self-taught (ok, I leanred some Apple Basic in the 80s, some C in college, and used Perl in the “olden days”) This proved the rule that developing for all permutations of a valid IPv6 address can be somewhat daunting.

After a lot of attempts this is what works:

└─[$] v6fmt 3fff:0209:0001:0000:0000:0000:0000:0001                                                                                                                        [13:33:44]
Expanded:      3fff:0209:0001:0000:0000:0000:0000:0001
Compressed:    3fff:209:1::1
Uppercase:     3FFF:209:1::1
URL format:    [3fff:209:1::1]
Dotted:        3.f.f.f.0.2.0.9.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1
Binary:        0011111111111111:0000001000001001:0000000000000001:0000000000000000:0000000000000000:0000000000000000:0000000000000000:0000000000000001
Reverse DNS:   1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.9.0.2.0.f.f.f.3.ip6.arpa
Type:          Global Unicast

Compression permutations:
  3fff:209:1:0:0:0:0:1
  3fff:209:1::0:0:1
  3fff:209:1::0:1
  3fff:209:1::1
  3fff:209:1:0::0:1
  3fff:209:1:0::1
  3fff:209:1:0:0::1

Even this seemingly simple bit of text wrangling was painful. there are probably better ways to do this, and likely more simple tools, but I wanted this to be part of my operating shell, so here we are. Add this into your .zshrc and it should work. I am unsure if it works with bash, but I suspect because of the parameter expansion flags, globbing, and array work that is unique to zsh, it likely will not.

This is also available in as a web service on ipv6.army and as an update to ipv6utils .

v6fmt() {
  local ip="$1"

  [[ -z "$ip" ]] && { print -r -- "Usage: v6fmt <ipv6-address>[/prefix-length]" >&2; return 1 }

  # Normalize: lowercase, strip whitespace
  ip="${ip:l}"
  ip="${ip//[[:space:]]}"

  # Strip and save optional prefix length
  local prefix_len=""
  if [[ "$ip" == */* ]]; then
    prefix_len="${ip#*/}"
    ip="${ip%/*}"
  fi

  # Strip URL brackets and zone ID
  ip="${ip#\[}"
  ip="${ip%\]}"
  ip="${ip%%\%*}"

  # Handle embedded IPv4 (e.g., ::ffff:192.0.2.1)
  if [[ "$ip" == *:*.* ]]; then
    local v4="${ip##*:}"
    local v6pfx="${ip%:*}"
    if [[ "$v4" == *.*.*.* ]]; then
      local -a octs=(${(s:.:)v4})
      local h1 h2
      printf -v h1 '%02x%02x' "${octs[1]}" "${octs[2]}"
      printf -v h2 '%02x%02x' "${octs[3]}" "${octs[4]}"
      ip="${v6pfx}:${h1}:${h2}"
    fi
  fi

  # Basic validation
  if [[ ! "$ip" =~ ^[0-9a-f:]+$ ]]; then
    print -r -- "Error: Invalid IPv6 address" >&2
    return 1
  fi

  # Expand :: notation
  local prefix suffix zeros_needed full_ip i g
  if [[ "$ip" == *::* ]]; then
    prefix="${ip%%::*}"
    suffix="${ip#*::}"

    local pre_count=0 suf_count=0
    for g in ${(s.:.)prefix}; [[ -n "$g" ]] && ((pre_count++))
    for g in ${(s.:.)suffix}; [[ -n "$g" ]] && ((suf_count++))

    zeros_needed=$((8 - pre_count - suf_count))
    full_ip="$prefix"
    for ((i = 0; i < zeros_needed; i++)); do
      full_ip="${full_ip}:0000"
    done
    [[ -n "$suffix" ]] && full_ip="${full_ip}:${suffix}"
    full_ip="${full_ip#:}"
  else
    full_ip="$ip"
  fi

  # Split into 8 groups
  local groups=(${(s.:.)full_ip})
  while (( $#groups < 8 )); do groups+=('0000'); done
  (( $#groups > 8 )) && groups=("${(@)groups[1,8]}")

  # Pad each group to 4 hex digits
  local full_groups=() padded
  for g in $groups; do
    g="${g#0}"
    [[ -z "$g" ]] && g=0
    printf -v padded '%04x' "0x${g}"
    full_groups+=("$padded")
  done

  # Build expanded string
  local expanded="${full_groups[1]}"
  for ((i = 2; i <= 8; i++)); do
    expanded="${expanded}:${full_groups[i]}"
  done

  # Strip leading zeros per group
  local short_groups=()
  for g in $full_groups; do
    while [[ "$g" == 0?* && "$g" != "0" ]]; do g="${g#0}"; done
    short_groups+=("$g")
  done

  # Build no-compression form
  local nocompress="${short_groups[1]}"
  for ((i = 2; i <= 8; i++)); do
    nocompress="${nocompress}:${short_groups[i]}"
  done

  # Find longest run of consecutive zero groups (RFC 5952)
  local best_start=-1 best_len=0 cur_start=-1 cur_len=0
  for ((i = 1; i <= 8; i++)); do
    if [[ "${short_groups[i]}" == "0" ]]; then
      [[ "$cur_start" == -1 ]] && cur_start=$((i - 1))
      ((cur_len++))
    else
      if (( cur_len > best_len )); then
        best_len=$cur_len
        best_start=$cur_start
      fi
      cur_start=-1
      cur_len=0
    fi
  done
  if (( cur_len > best_len )); then
    best_len=$cur_len
    best_start=$cur_start
  fi

  # Build canonical (compressed) form per RFC 5952
  local canonical
  if (( best_len > 1 )); then
    canonical=""
    for ((i = 1; i <= 8; i++)); do
      if (( i == best_start + 1 )); then
        canonical="${canonical}::"
        ((i = best_start + best_len))
        continue
      fi
      [[ -n "$canonical" && "${canonical[-1]}" != ':' ]] && canonical="${canonical}:"
      canonical="${canonical}${short_groups[i]}"
    done
  else
    canonical="$nocompress"
  fi

  # === Derived formats ===

  # Suffix for prefix length display
  local sfx=""
  [[ -n "$prefix_len" ]] && sfx="/${prefix_len}"

  # Hex string (32 nibbles, no separators)
  local hex_str="${expanded//:/}"

  # Dotted notation (each nibble separated by dots)
  local dotted=""
  for ((i = 1; i <= ${#hex_str}; i++)); do
    (( i > 1 )) && dotted="${dotted}."
    dotted="${dotted}${hex_str[i]}"
  done

  # Binary representation (16-bit groups separated by :)
  local -A h2b=(
    0 0000 1 0001 2 0010 3 0011
    4 0100 5 0101 6 0110 7 0111
    8 1000 9 1001 a 1010 b 1011
    c 1100 d 1101 e 1110 f 1111
  )
  local binary=""
  for ((i = 1; i <= ${#hex_str}; i++)); do
    binary="${binary}${h2b[${hex_str[i]}]}"
    (( i % 4 == 0 && i < ${#hex_str} )) && binary="${binary}:"
  done

  # Reverse DNS (ip6.arpa)
  local rdns=""
  for ((i = ${#hex_str}; i >= 1; i--)); do
    (( i < ${#hex_str} )) && rdns="${rdns}."
    rdns="${rdns}${hex_str[i]}"
  done
  rdns="${rdns}.ip6.arpa"

  # Address type classification
  local addr_type
  if [[ "$expanded" == "0000:0000:0000:0000:0000:0000:0000:0001" ]]; then
    addr_type="Loopback"
  elif [[ "$expanded" == "0000:0000:0000:0000:0000:0000:0000:0000" ]]; then
    addr_type="Unspecified"
  elif [[ "$expanded" == 0000:0000:0000:0000:0000:ffff:* ]]; then
    addr_type="IPv4-Mapped"
  elif [[ "$expanded" == 0064:ff9b:0000:0000:0000:0000:* ]]; then
    addr_type="NAT64 Well-Known Prefix (RFC 6052)"
  elif [[ "$expanded" == 0064:ff9b:0001:* ]]; then
    addr_type="NAT64 Local-Use Prefix (RFC 8215)"
  elif [[ "$expanded" == 0100:0000:0000:0000:* ]]; then
    addr_type="Discard-Only (RFC 6666)"
  elif [[ "$expanded" == 2001:0db8:* ]]; then
    addr_type="Documentation (RFC 3849)"
  elif [[ "$expanded" == 2001:0000:* ]]; then
    addr_type="Teredo (RFC 4380)"
  elif [[ "$expanded" == 2002:* ]]; then
    addr_type="6to4 (RFC 3056)"
  elif [[ "${expanded[1,2]}" == "fe" ]]; then
    case "${expanded[3]}" in
      [89ab]) addr_type="Link-Local" ;;
      [cdef]) addr_type="Site-Local (Deprecated)" ;;
      *) addr_type="Unknown" ;;
    esac
  elif [[ "${expanded[1,2]}" == "fc" || "${expanded[1,2]}" == "fd" ]]; then
    addr_type="Unique Local Address (ULA)"
  elif [[ "${expanded[1,2]}" == "ff" ]]; then
    case "${expanded[4]}" in
      1) addr_type="Multicast (Interface-Local)" ;;
      2) addr_type="Multicast (Link-Local)" ;;
      4) addr_type="Multicast (Admin-Local)" ;;
      5) addr_type="Multicast (Site-Local)" ;;
      8) addr_type="Multicast (Organization-Local)" ;;
      e) addr_type="Multicast (Global)" ;;
      *) addr_type="Multicast" ;;
    esac
  elif [[ "${expanded[1]}" == [23] ]]; then
    addr_type="Global Unicast"
  else
    addr_type="Reserved"
  fi

  # === Output ===

  printf '%-14s %s\n' "Expanded:" "${expanded}${sfx}"
  printf '%-14s %s\n' "Compressed:" "${canonical}${sfx}"
  printf '%-14s %s\n' "Uppercase:" "${canonical:u}${sfx}"
  printf '%-14s %s\n' "URL format:" "[${canonical}]"
  printf '%-14s %s\n' "Dotted:" "$dotted"
  printf '%-14s %s\n' "Binary:" "$binary"
  printf '%-14s %s\n' "Reverse DNS:" "$rdns"
  printf '%-14s %s\n' "Type:" "$addr_type"

  # Compression permutations
  print ""
  print "Compression permutations:"
  print "  $nocompress"

  local start end sub_start sub_len out
  for ((start = 0; start < 8; )); do
    [[ "${short_groups[start+1]}" != "0" ]] && { ((start++)); continue }

    end=$start
    while (( end < 8 )) && [[ "${short_groups[end+1]}" == "0" ]]; do
      ((end++))
    done

    for ((sub_start = start; sub_start <= end - 2; sub_start++)); do
      for ((sub_len = 2; sub_len <= end - sub_start; sub_len++)); do
        out=""
        for ((i = 1; i <= sub_start; i++)); do
          [[ -n "$out" ]] && out="${out}:"
          out="${out}${short_groups[i]}"
        done
        out="${out}::"
        for ((i = sub_start + sub_len + 1; i <= 8; i++)); do
          [[ -n "$out" && "${out[-1]}" != ':' ]] && out="${out}:"
          out="${out}${short_groups[i]}"
        done
        print "  $out"
      done
    done

    ((start = end))
  done
}

IPB 193 - IPv6 Basics – Troubleshooting

Thu, 05 Feb 2026 00:00:00 +0000

Are you struggling to get IPv6 working, whether in a lab or even a pilot deployment? Ed, Nick, and Tom walk through the essentials of IPv6 troubleshooting, revealing the non-negotiable differences between IPv4 and IPv6 that can trip up even experienced network engineers. They break down why blocking all ICMP, like in v4, will instantly break your v6 network and why understanding multicast is critical to scalable IPv6.

Have a listen:

Episode Links:

IPB192 - IPv6 Lab Update

IPB 192 - IPv6 Lab Update

Thu, 22 Jan 2026 00:00:00 +0000

Thinking of setting up an IPv6 lab this year? Our hosts dive into a major update on building and testing modern IPv6 networks, focusing on the game-changing “IPv6-mostly” architecture. They break down the essential components you need to get this working, including DHCP Option 108 and the nitty gritty of client support.

In this episode, Tom incorrectly identifies Debian 13 as the platform he got IPv6-mostly working on when in reality it was CentOS 9 Stream. In his defense, Tom had been fixated all week on how cool he thinks Debian is generally (Debian, sadly, doesn’t feel the same way about him) and his old-man brain didn’t catch the error in real time (even after bringing up the EPEL repo). He sincerely regrets and is low-key mortified about the error but doesn’t want any listeners to labor under the misconception that CentOS is a no-go with IPv6-mostly.

Have a listen:

Show links:

IPB173: The IPv6 Test Pod Project

CLATD: a CLAT / SIIT-DC Edge Relay implementation for Linux

IPB 191 - IPv6 Predictions for 2026

Thu, 08 Jan 2026 00:00:00 +0000

Will Microsoft’s CLAT bring widespread adoption rates for IPv6? Will there be significant advancements in corporate and cloud adoption as well? Will this finally be the year we see the fix for the RFC 6724? Ed Horley, Tom Coffeen, and Nick Buraglio make their predictions for the new year in the first IPv6 Buzz of 2026.

Have a listen:

Episode Links:

IPv6.army

RFC6724 options picker

Hosted email options for 2026

Fri, 26 Dec 2025 00:00:00 +0000

Email. Possibly the most useful and least sexy of the core set of internet applictions. In past lives I ran Microsoft Exchange , Postfix , cc:Mail , and very, very large Sendmail installations. Since early 2005, though, I have outsourced my own personal email to Google. As an original “google Apps for Your Domain” tester, I had early access to the bevy of tools that Google had to offer, and at my favorite price - $0. Occasionally I’d look at other options, but I always come back to GSuite.

This time around I put some time into it, taking some notes and fully intending to try to move my primary domain away. I had a set of “must” requirements, but am willing to make some major concessions.

Must do:

Web Interface
Integrated calendar support
Vacation / Away message
Up to 10 users (negotiable - 6 would work)
Decent Spam control
Filtering / tagging with robust match criteria
Reasonably strong email search capabilities

Nice to have, no preference in weight:

Supports Email Alias
Supports multi-recepient aliases
Suports IPv6
Supports catch-all for domain
Drive / storage support
Office / Productivity suite included

Out of scope

Self Hosting.

I’ve tasted that pain and simply have no desire to do it again.

I will also add that I do, in fact, like gmail hosting. It’s worked for me for literally two decades. It has essentially everything I need and my requirements are fairly tightly tied to it. Coincidentally, one of the largest concerns I have for this potential move is that 1. I will miss something I truly need, and secondarily, but only slightly, that I will have a bear of a time de-coupling what I use “Login with Google” for. Ideally those things would all become passkeys, but we all know that process is slow. A looming, but not insignificant issue, too, is the mining of my data for advertising (kinda came to grips with that, sadly) and more concerningly AI. Google is all-in and I don’t necessarily want my personal email to be used for that even if it is largely inevitable due to the sheer footprint of gmail. I like privacy, and did move one of my mail domains to proton for about 8 months a few years ago.

This is obviously non-comprehensive and should be double checked as things chance and I can make mistakes.

Comprehensive Family Email Service Comparison (Q4 2025 / Q1 2026)

Google Workspace • Apple iCloud+ / Apple One Mail •

Proton Family; Referral Link • Microsoft 365 Family • Fastmail • Cloudflare Email Routing

This post makes an attemt to compare, to the best possible approxomation:

Google Workspace
Apple iCloud+ / Apple One Mail
Proton Family
Microsoft 365 Family
Fastmail
Cloudflare Email Routing

with emphasis on:

Custom domains
Aliases and groups
Hosting vs forwarding (Cloudflare)
Ecosystem / apps
Spam filtering
IPv6 and standards
Costs and typical use cases

Cloudflare email routing is fundamentally different from the other four: it provides routing/forwarding, not mailboxes or a hosted inbox, but it is powerful and could be used to simply move around an email address.

1. Overall positioning

Service	Type of service	Hosting vs forwarding	Ideal for
Google Workspace	Full email + productivity suite	Hosting: mailboxes + apps	Families / small orgs wanting Gmail + Docs/Drive/Meet
Apple iCloud+ / One	Consumer iCloud storage + mail	Hosting: mailboxes in Apple’s cloud	All‑Apple households
Proton Family	Privacy‑focused encrypted bundle	Hosting: encrypted mailboxes	Families prioritizing privacy and Swiss jurisdiction
Microsoft 365 Family	Consumer Office + Outlook + OneDrive	Hosting: Outlook mailboxes	Families needing Office apps + 1 TB/user storage
Fastmail	Independent email & calendar service	Hosting: mailboxes + calendar/contacts	Power users wanting flexible, standards-based email with custom domains
Cloudflare Email Routing	Email routing/forwarding layer only	Forwarding only: no inboxes, no sending	Using your own inbox elsewhere with free custom-domain addresses

Cloudflare Email Routing acts as an SMTP “traffic director”: it receives mail for your domain, then forwards it on to another mailbox you own (Gmail, Outlook, Proton, etc.). It does not store mail long‑term or provide an inbox, and you cannot send mail directly from Cloudflare’s addresses without pairing it with another outbound provider.

2. Custom domains, aliases, and groups

2.1 Core domain & family structure

Feature	Google Workspace	Apple iCloud+ / One	Proton Family	Microsoft 365 Family	Fastmail	Cloudflare Email Routing
Custom domain for email	Yes (first‑class)	Yes via iCloud+	Yes, multiple domains	Not in consumer; needs business	Yes (first‑class, up to 100 domains)	Yes (for routing only)
Who owns the mailbox?	Google	Apple	Proton	Microsoft	Fastmail (Australian, independent)	Your downstream provider (Gmail, etc.)
“Family plan” concept	Business plan used by family	iCloud Family Sharing	Dedicated family bundle	Family plan (up to 6 users)	Family plan options available	N/A (per domain; no user accounts)
Per‑user separation	Full accounts	Individual Apple IDs	Separate encrypted accounts	Separate Microsoft accounts	Full separate accounts	Not applicable (no mailboxes)

2.2 Aliases, groups, and catch‑all

Aspect	Google Workspace	Apple iCloud+	Proton Family	Microsoft 365 Family	Fastmail	Cloudflare Email Routing
Aliases per user	Many (up to ~30)	Several per iCloud mailbox	Multiple addresses/aliases per user	Multiple per Outlook.com account	600+ per account	Many routing rules per domain
Aliases serve inbox where?	Same user mailbox	Same Apple ID mailbox	Same Proton mailbox	Same Outlook mailbox	Same Fastmail mailbox	Forward to another provider’s mailbox
Shared/group email (e.g., support@)	First‑class groups, shared mailboxes	No true groups; manual forwarding	No multi‑user group inbox	No consumer distribution list	First‑class aliases and folder sharing	Can create `support@` → single destination mailbox
One address → multiple recipients	Yes (groups / distribution lists)	Not natively	No	Not in consumer tier	Not directly; use forwarding rules	One rule = one destination; fan‑out requires tricks
Catch‑all	Supported	No	Supported	No	Supported	Supported (catch‑all can forward anywhere)

Cloudflare difference:
Cloudflare can easily create many addresses and a catch‑all, but each routing rule forwards to one destination mailbox. A given support@domain.com rule goes to a single inbox, not multiple users directly. If you want fan‑out, you chain Cloudflare into another system (e.g., a list at your final provider, or use Workers for custom logic).

3. Hosting vs forwarding in practical terms

3.1 What “hosting” means (Google, Apple, Proton, Microsoft)

For Google Workspace, Apple iCloud+, Proton Family, Microsoft 365 Family:

They host:
- Mailboxes (inboxes, sent mail, etc.)
- IMAP/POP/SMTP or similar protocols
- Storage and indexing, search, spam filtering
You log in directly to them to read and send mail.

3.2 What “forwarding” means (Cloudflare Email Routing)

For Cloudflare Email Routing:

Cloudflare:
- Receives mail for your domain (MX records point to Cloudflare).
- Does light processing and authentication checks.
- Immediately forwards mail to another mailbox you own (e.g., you@gmail.com).
- Does not provide:
  - A mailbox UI,
  - Long‑term storage,
  - Native ability to send mail as that address.

To send mail as you@yourdomain.com when using Cloudflare:

You configure your final mail provider (Gmail/Outlook/Proton via SMTP, etc.) to send mail with that From address.
Cloudflare is invisible in the outbound path; it only affects inbound mail.

4. Cloud app ecosystems and integration

Category	Google Workspace	Apple iCloud+ / One	Proton Family	Microsoft 365 Family	Fastmail	Cloudflare Email Routing
Email client	Gmail web + apps, IMAP/POP	Mail apps + iCloud.com	Proton web/app + Bridge	Outlook desktop/web/mobile	Modern web client, full IMAP/SMTP/JMAP	None (uses your target provider’s client)
Documents/Office	Docs, Sheets, Slides	Pages, Numbers, Keynote	None (use external editors)	Word, Excel, PowerPoint, OneNote	None (use external editors)	None
Storage	Google Drive	iCloud Drive	Proton Drive (encrypted)	OneDrive (1 TB/user)	File storage (varies by plan)	None
Calendar	Google Calendar	Apple Calendar	Proton Calendar	Outlook Calendar	Fastmail Calendar (CalDAV)	None
Extra privacy tools	Admin + security tools	Private Relay (limited), Hide My Email	Encrypted Calendar/Drive, VPN, Pass	Defender, Family Safety	Masked Email, privacy-focused by default	Email security/analytics via routing rules

Cloudflare fits as a useful front‑door in front of whichever hosted mailbox solution you choose, rather than competing with them directly.

5. Spam filtering, rules, and quality

Aspect	Google Workspace	Apple iCloud+	Proton Family	Microsoft 365 Family	Fastmail	Cloudflare Email Routing
Spam filtering strength	Industry‑leading ML filtering	Good consumer filtering	Good, sometimes strict	Enterprise‑grade Exchange backend	Excellent, customizable filtering	Light filtering & auth checks; major filtering is at destination mailbox
Rules / filters	Powerful filters + labels	Basic rules	Powerful filtering & labels	Rich Outlook rules	Very powerful Sieve-based filtering	Routing rules; advanced scripting via Workers
Abuse protections	Mature anti‑abuse stack	Good enough for consumers	Strong, privacy‑centric	Enterprise‑grade protections	Strong anti-spam, manual learning	SPF /DKIM /DMARC ‑aware forwarding and SRS rewriting

Cloudflare’s main contribution is properly forwarding authenticated mail (SPF , DKIM , DMARC ) without breaking deliverability, not spam scoring. The downstream mailbox still does the heavy spam work.

6. IPv6 and standards

Network / Standard	Google Workspace	Apple iCloud Mail	Proton Mail / Family	Microsoft 365 Family	Fastmail	Cloudflare Email Routing
IPv6 on MX (inbound mail)	Yes (dual‑stack)	Yes (dual‑stack)	No (IPv4‑only MX)	Yes (dual‑stack)	No (IPv4‑only MX)	Yes: Cloudflare MX supports IPv6 for inbound
IPv6 on SMTP (outbound)	Yes	Yes	No (IPv4‑only)	Yes	No (IPv4‑only SMTP)	N/A (forwarding only)
Forwarding over IPv6	Will connect to upstream via IPv6 if destination MX has AAAA	Will connect to upstream via IPv6 if destination MX has AAAA	N/A	Will connect to upstream via IPv6 if destination MX has AAAA	N/A	Will connect to upstream via IPv6 if destination MX has AAAA
SPF /DKIM /DMARC	Fully supported	Supported, mostly automatic	Fully supported	Fully supported	Fully supported, easy setup	Preserves auth; uses SRS for envelope sender rewriting
DNS control	You manage domain DNS	Limited to Apple’s UI	You manage domain DNS	Full in business; fixed in consumer	Full DNS control	Cloudflare manages DNS if domain is on Cloudflare

Key points:

Cloudflare Email Routing:
- Provides IPv6‑capable MX endpoints.
- Forwards mail using IPv6 when the destination provider supports it; falls back to IPv4 otherwise.
Proton Mail:
- As of now, Proton’s MX records are IPv4‑only, so mail directly to Proton requires IPv4 connectivity.
- This limitation disappears if you place Cloudflare in front, since Cloudflare terminates on IPv4 and can still be dual‑stack at the outer edge. However, the web front ends are also IPv4-only, so Proton is functionally a single stacked solution as if now. They have slowly been rolling IPv6 out for things like VPN, so I do expect it “some day”.

7. Costs and typical usage patterns

Service	Plan type	Approx yearly cost (US)	Users	Storage headline	Notes
Google Workspace	Business Starter	~$72/user/year	Per user	30 GB/user (more in higher tiers)	Business product used by families
Apple iCloud+ Family	200 GB–2 TB tiers	~$36–$120/year total	Up to 6	200 GB–2 TB shared iCloud	Includes mail + Photos + Drive
Proton Family	Family bundle	~$240–$360/year total	~6	Hundreds of GB–few TB encrypted	Includes VPN + Pass
Microsoft 365 Family	Family plan	~$100/year total	Up to 6	1 TB OneDrive per user (6 TB total)	Includes Office apps
Fastmail	Standard/Professional	~$50–$120/user/year	Per user	30–100 GB/user (varies by plan)	Independent, standards-focused
Cloudflare Email Routing	Included with Cloudflare	Typically free for routing	Per domain	None (no mailbox storage)	You must still pay for a mailbox provider

Cloudflare Email Routing effectively reduces cost by letting you:

Use a free/cheap mailbox (Gmail, Outlook.com, etc.).
Put your custom domain branding in front via Cloudflare.
Avoid paying for separate hosted mail per domain when all you need is forwarding.

8. Choosing where Cloudflare fits in

Practical patterns:

Forwarding into Gmail/Outlook/Proton:
Use Cloudflare MX for your domain, route name@domain.com to a Gmail/Outlook/Proton mailbox. You manage spam and sending from that provider; Cloudflare only routes.
Alias and catch‑all front‑end:
Use Cloudflare to generate many aliases or a catch‑all, all forwarding into one or a few real mailboxes. This keeps your main mailbox provider simple and cheap.
Not a replacement for a real host:
Cloudflare does not replace Google Workspace, Proton, or Microsoft 365. You still need one of them (or some other host) for:
- Mailbox storage
- Search
- Calendars/contacts
- Sending mail

9. Quick “best use” summary including Cloudflare

Google Workspace – Best when you want full business‑grade email hosting, collaboration, and admin for a family or small group.
Apple iCloud+ – Best for an all‑Apple household that wants simple, integrated mail and storage.
Proton Family – Best for families that value privacy, encryption, and Swiss jurisdiction over convenience and integrations.
Microsoft 365 Family – Best for families wanting Office apps plus large personal storage (1 TB per user) with solid consumer email.
Fastmail – Best for power users and email enthusiasts who want a clean, standards-based email experience with excellent custom domain support, powerful filtering, and no ads or tracking from an independent provider.
Cloudflare Email Routing – Best as a free, DNS‑level front door to give your domain professional emails that forward into an existing mailbox; useful when you want:
- Custom domain addresses,
- No separate mail server,
- And are happy to keep a Gmail/Outlook/Proton mailbox behind it.

For me, google is probably still the clear winner, but it does come with the large pill of “if the product is free, you’re the product”. A very close tie for second is Proton and, presumably Fastmail. I have no experience with Fastmail but it looks very promising.

Last updated: December 29th, 2025, Added Fastmail.

PB190 - IPv6 in Kubernetes Deployments

Thu, 18 Dec 2025 00:00:00 +0000

Kubernetes is a popular container orchestration platform. Today’s IPv6 Buzz episode explores the benefits of using IPv6 in Kubernetes, and how Kubernetes uses IP addresses in both the control plane and data plane. We also address why the adoption rate is estimated to be so low, from default configurations to issues with non-IPv6-aware applications inside containers. Our guest to help cover this topic is Wim Henderickx , CTO of the IP Division at Nokia.

Kubernetes Dual stack

How to set up an IPv6-only Kubernetes cluster

Wim Henderickx’s Medium Blog

Take a listen here:

IETF v6ops Working Group on Software Gone Wild

Thu, 11 Dec 2025 00:00:00 +0000

In a triumphant return, Ivan Pepelnjak has resurected the Software Gone Wild podcast! As some may recall, I was a co-host on SGW for quite a while, eventually branching out into the MODEM.show in around 2020. Well, MODEM has concluded, and SGW has returned.

It was quite fun to “get the band back together” and record this one.

From the podcast post :

The first IPv6 specs were published in 1995, and yet 30 years later, we still have a pretty active IETF working group focused on “developing guidelines for the deployment and operation of new and existing IPv6 networks.” (taken from the old charter ; they updated it in late October 2025). Why is it taking so long, and what problems are they trying to solve?

Nick Buraglio, one of the working group chairs, provided some answers in Episode 203 of the Software Gone Wild podcast.

Listen here .

PB189 - RFC 9898 – Neighbor Discovery Considerations in IPv6 Deployments

Thu, 04 Dec 2025 00:00:00 +0000

The newly published RFC 9898 is the discussion of today’s podcast. The IPv6 Buzz crew explore the complexities of neighbor discovery and review solutions for both operators and architects. They share how this RFC serves as a single, detailed resource to improve your understanding of neighbor discovery and to reduce the potential attack surface in your IPv6 networks. Neighbor Discovery is one of the more complex pieces of IPv6 and this document aims to provide clarity on nearly all aspects of how it works. This ain’t your grandfathers ARP.

Full disclosure, I was one of the co-authors of this RFC =)

IPB188 - IPv6 Adoption for an Entire Country

Thu, 20 Nov 2025 00:00:00 +0000

What does it take for an entire country to adopt IPv6? Our guest today is Tenanoia (Noia) Simona , CEO of Tuvalu Telecommunications Corporation , the country’s sole telecommunications provider. She’s here to walk us through the difficulties of connecting the many islands of Tuvalu and their journey to achieving one of the world’s highest IPv6 adoption rates. This was a fin one where we roamed around into undesea fiber, long haul, satellite, and peering. Oh, and their strong support for IPv6.

IPB187 - IPv6 Adoption for an Entire Country

Thu, 06 Nov 2025 00:00:00 +0000

Today the IPv6 Buzz crew provides updates on the latest in IPv6 standards, RFCs, and best practices. They break down the recent discussions around RFC 6052, explore the options for RFC 8215, and share Nick’s spin on the now defunct testipv6.com site.

IPB186 - An Inside Look at RFC 9872 for Discovering v6 Prefixes

Thu, 23 Oct 2025 00:00:00 +0000

RFC 9872 makes recommendations for NAT64 prefix discovery for hosts supporting v4-to-v6 translation. Co-host Nick Buralgio is a co-author of this RFC, so we’re taking the opportunity to talk about it in detail. We discuss the problems RFC 9872 is addressing and why a new RFC was needed for operational guidance, not necessarily defining a protocol or standard. We learn the effects of this RFC on previous RFCs, specifically 7050 and 8781 . Lastly, we share the implications of RFC 9872 on listeners and recommend they do a little labbing to see what this really means for the networks they manage.

An alternative to test-ipv6.com

Mon, 13 Oct 2025 00:00:00 +0000

Many resources exist in order to test and report on IPv6 availability. One such site - test-ipv6.com - has been a staple for nearly 15 years. This site has a robust mirror network and has been proudly advertising free since its inception. However, running such resources can be costly in both time and money. Recently, the author and maintainer of the site had announce its retirement. This sent some shockwaves through the IPv6 community that eventually culminated in a realization that we rely on something that isn’t necessarily funded or permanent. since that announcement, someone has been able to take it over, however, the lingering feeling of “this could go away” still remains. To that end, I wrote a mediocre replacement for it and deployed it as the front page of ipv6.army . While not quite the same, it does provide an additional browser based test that may be useful to some, and just like this site, it is deployed on the netlify CDN.

IPB185 - When IPv6 VPN and DNS Do Not Cooperate

Thu, 09 Oct 2025 00:00:00 +0000

Sometimes weirdness occurs within DNS if you’re on an IPv4 network and you connect to a dual-stack or v6-only VPN. Maybe the browser doesn’t connect, but you can still send pings, or vice versa. Is the OS getting confused about which stack and which order of interfaces to request services? Is the weird behavior being caused by Happy Eyeballs? Is it something else? These occurrances can be infuriating and very difficult to troubleshot. On today’s IPv6 Buzz we dive into this weirdness to see if we can figure out the causes, and offer suggestions to get your remote access VPN and DNS to play nicely with mixed stacks.

Take a listen here

Posts on ForwardingPlane.net

Linkwarden with docker compose and nginx proxy manager

Mikrotik wireguard optimization

Set the queuing for the WAN interface to fq-codel or cake

Disable fasttrack for the wireguard interface

IPv6 address formatting

IPB 193 - IPv6 Basics – Troubleshooting

IPB 192 - IPv6 Lab Update

IPB 191 - IPv6 Predictions for 2026

Hosted email options for 2026

Must do:

Nice to have, no preference in weight:

Out of scope

Comprehensive Family Email Service Comparison (Q4 2025 / Q1 2026)

Proton Family; Referral Link • Microsoft 365 Family • Fastmail • Cloudflare Email Routing

1. Overall positioning

2. Custom domains, aliases, and groups

2.1 Core domain & family structure

2.2 Aliases, groups, and catch‑all

3. Hosting vs forwarding in practical terms

3.1 What “hosting” means (Google, Apple, Proton, Microsoft)

3.2 What “forwarding” means (Cloudflare Email Routing)

4. Cloud app ecosystems and integration

5. Spam filtering, rules, and quality

6. IPv6 and standards

7. Costs and typical usage patterns

8. Choosing where Cloudflare fits in

9. Quick “best use” summary including Cloudflare

PB190 - IPv6 in Kubernetes Deployments

IETF v6ops Working Group on Software Gone Wild

PB189 - RFC 9898 – Neighbor Discovery Considerations in IPv6 Deployments

IPB188 - IPv6 Adoption for an Entire Country

IPB187 - IPv6 Adoption for an Entire Country

IPB186 - An Inside Look at RFC 9872 for Discovering v6 Prefixes

An alternative to test-ipv6.com

IPB185 - When IPv6 VPN and DNS Do Not Cooperate

Set the queuing for the WAN interface to `fq-codel` or `cake`