IPv6 connectivity

At this writing, the home network infrastructure has 2 ISP connections. One from Comcast/Xfinity, the other from Allo Communications. Comcast supplies IPv4 and IPv6. Allo only provides IPv4, and if it does have plans to provide IPv6, they have not been well communicated. Plans are in progress to shut down the Comcast service, meaning no more native IPv6 for the home network.

Comcast/Xfinity

Directly connected system (router/firewall) interface config

First time manual run of DHCPv6 client needs to request a prefix and give a prefix length hint. So do something like dhclient -6 -P --prefix-len 60 enp67s0. This will also initialize the default-duid parameter in the DHCP leases file. In order to get the same IPv6 prefix after a restart, saving this is important. It can be copied from one system to another in case of hardware replacement.

Add the following in the appropriate /etc/network/interfaces.d/interface file:

iface enp67s0 inet6 dhcp
    accept_ra           2
    autoconf            1
    dhcp                1
    privext             0
    request_prefix      1
    post-up             /usr/sbin/ip -6 rule add table ipv6-he-tunnel from 2001:470:3924::/48 table ipv6-he-tunnel || true
    post-up             /usr/sbin/ip -6 route add table ipv6-he-tunnel default nexthop via inet6 fe80::baca:3aff:fe5e:d848 dev bond0.1000 || true
    post-up             /usr/sbin/systemctl restart radvd || true
    post-down           /usr/sbin/ip -6 route del table ipv6-he-tunnel default nexthop via inet6 fe80::baca:3aff:fe5e:d848 dev bond0.1000 || true
    post-down           /usr/sbin/ip -6 rule del table-ipv6-he-tunnel from 2001:470:3924::/48 || true
    post-down           /usr/sbin/systemctl stop radvd || true

The routing rules and table stuff are related to policy routing, needed when multiple upstream ISPs are involved. request_prefix is important here to ask the upstream DHCP server for a number of subnets to share with the internal networks. The actual result is that the DHCPv6 client gets the "-P" flag when it is run.

Allo Communications

Allo is the preferred ISPs for a number of reasons: Fiber optic in the ground, better customer service than Comcast/Xfinity, better speeds than Comcast/Xfinity, lower cost than Comcast/Xfinity, no data cap. Unfortunately, they do not provide IPv6 connectivity. But there are workarounds:

Hurricane Electric

I have been using a Hurricane Electric's tunnelbroker.net service since January 2011, if my email archives are to be believed. They currently provide a /64 tunnel, a /64 routed network, and a /48 network prefix. Which is way more than I can make use of, but it is nice having a large playground. The tunnel itself is provisioned using the 6in4 (once known as "SIT") protocol. On Debian, /etc/network/interfaces.d/ files support this natively:

$ cat /etc/network/interfaces.d/tunl-he-ipv6 
auto tunl-he-ipv6
iface tunl-he-ipv6 inet6 v4tunnel
    address     2001:470:7b:db::2
    netmask     64
    endpoint    216.66.77.230
    # local       140.228.197.248
    ttl         255
    gateway     2001:470:7b:db::1
    post-up     /usr/sbin/ip -6 rule add table ipv6-comcast from 2601:282:8600:f9e0::/60 || true
    post-up     /usr/sbin/ip -6 route add table ipv6-comcast default nexthop via inet6 fe80::baca:3aff:fe5e:d448 dev bond0.1000 || true
    post-up     /usr/sbin/systemctl restart radvd || true
    post-down   /usr/sbin/ip -6 route del table ipv6-comcast default nexthop via inet6 fe80::baca:3aff:fe5e:d448 dev bond0.1000 || true
    post-down   /usr/sbin/ip -6 rule del table ipv6-comcast from 2601:282:8600:f9e0::/60 || true
    post-down   /usr/sbin/systemctl stop radvd || true

There is no authentication or privacy provided by the 6in4 protocol. Do not send sensitive traffic over the tunnel in the clear.

Route64

This provider is new to me. I discovered it in December 2025. They will transport a /56 prefix over an operating tunnel, and the tunnels themselves may be be encapsulated with GRE, L2TPv3, 6in4 (SIT), VxLAN, and Wireguard. This last option is one I find most interesting as it provides authentication and privacy to the tunneled traffic, as well as mobility of the "client" endpoint, meaning that if Allo changes my IPv4 address, the Wireguard tunnel needs no reconfiguration.

Wireguard is a fairly new (10 years as this is written) VPN solution. It is well regarded for both its cryptographic properties and its simplicity. So in here, we will do an route64.org IPv6 tunnel using wireguard as the transport.