How to Configure Routed IPv6 (/64), Gateway fe80::1, rDNS & Docker IPv6 on Netcup

Log in to the Netcup Server Control Panel (servercontrolpanel.de) → Select Server → Network. You will see your network interface’s hardware MAC address, your IPv4 address/gateway, and your routed IPv6 /64 subnet—for example, 2a03:4000:60:1234::/64 with Gateway fe80::1. Unlike residential ISPs or basic shared-L2 cloud networks that rely on Stateless Address Autoconfiguration (SLAAC) via multicast ICMPv6 Router Advertisements (RA), Netcup’s AS197540 KVM network routes your entire /64 prefix directly to your virtual machine’s tap port via the host hypervisor’s link-local router address (fe80::1).

Understanding why Netcup uses a static link-local gateway (fe80::1) rather than multicast SLAAC broadcasts is essential for maintaining uninterrupted uptime. On a multi-tenant KVM hypervisor bridge, suppressing periodic multicast Router Advertisement floods prevents Layer-2 neighbor-table exhaustion and enforces strict MAC/IP anti-spoofing filters (ebtables / nftables bridge rules) at the host virtual switch. Your VM can only originate packets from its assigned /32 IPv4 address and its assigned /64 IPv6 prefix; any packet carrying a spoofed source address outside your prefix is dropped immediately at the hypervisor port.

At Layer 2, IPv6 completely replaces IPv4’s ARP broadcast mechanism with the Neighbor Discovery Protocol (NDP, RFC 4861) operating over ICMPv6. When your Linux kernel needs to forward an outbound IPv6 packet to the default gateway fe80::1, or when the Netcup host router needs to deliver an inbound packet to 2a03:4000:60:1234::1, they exchange ICMPv6 Neighbor Solicitation (Type 135) and Neighbor Advertisement (Type 136) messages to resolve the destination MAC address. Consequently, if you ever block ICMPv6 types 133 through 136 in UFW, ip6tables, or the Netcup SCP Firewall, your IPv6 neighbor cache will expire within minutes and blackhole all IPv6 traffic.

Before editing any network configuration file on Linux, inspect your current active virtio-net interface name (eth0 or ens3) and hardware MAC address so you can pin the interface deterministically:

# Show interface names, MAC addresses, and current IPv4/IPv6 bindings
ip -br link
ip -br addr

# Inspect current IPv6 routing table
ip -6 route show

lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             22:54:00:ab:cd:ef <BROADCAST,MULTICAST,UP,LOWER_UP>

The most common IPv6 failure on Netcup Ubuntu and Debian servers occurs when administrators configure a static IPv6 address (2a03:4000:60:1234::1/64) and a static default route (via: fe80::1), but leave accept-ra at its kernel default (1 / true). When accept-ra remains enabled alongside a static configuration, systemd-networkd or the Linux kernel IPv6 stack periodically processes link-state or RA lifetime timers and purges or overrides your default route—causing IPv6 to work for 5 to 15 minutes after a reboot before failing with connect: Network is unreachable.

Equally critical in Netplan v2 is including on-link: true inside the default route stanza (to: "::/0", via: "fe80::1"). Because fe80::1 is an RFC 4291 link-local address (fe80::/10) rather than an address inside your global 2a03:4000:60:1234::/64 prefix, systemd-networkd needs explicit confirmation that the next-hop gateway is directly reachable on the attached Layer-2 segment (eth0) without requiring an intermediate route lookup.

Because Netcup routes the entire /64 block to your NIC, you are not limited to a single ::1 address. You can bind multiple static IPv6 addresses to the same interface to isolate services—for example, binding 2a03:4000:60:1234::1/64 for your primary Nginx web proxy, 2a03:4000:60:1234::2/64 exclusively for outbound Postfix SMTP delivery (smtp_bind_address6), and 2a03:4000:60:1234::10/64 for an authoritative DNS or WireGuard daemon. In Linux, the last-added or first-listed non-deprecated /64 address becomes the default outbound source IP unless an application explicitly binds a socket IP.

Finally, if your Netcup image was deployed with Cloud-Init, remember that Cloud-Init may overwrite /etc/netplan/50-cloud-init.yaml on subsequent reboots unless you create /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg containing network: {config: disabled}. Below are the complete, production-verified configuration files for Ubuntu 24.04 LTS (Netplan v2) and Debian 12 (/etc/network/interfaces):

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      match:
        macaddress: "22:54:00:ab:cd:ef"
      set-name: eth0
      dhcp4: true
      dhcp6: false
      accept-ra: false
      addresses:
        - "2a03:4000:60:1234::1/64"
        - "2a03:4000:60:1234::2/64"
      routes:
        - to: "::/0"
          via: "fe80::1"
          on-link: true
      nameservers:
        addresses:
          - 46.38.225.230
          - 46.38.252.230
          - 2a03:4000:0:1::e1e6
          - 2606:4700:4700::1111

iface eth0 inet6 static
    address 2a03:4000:60:1234::1
    netmask 64
    gateway fe80::1
    accept_ra 0
    autoconf 0
    up ip -6 addr add 2a03:4000:60:1234::2/64 dev eth0 || true

Once sudo netplan try succeeds and you confirm the configuration, verify both your kernel route table (ip -6 route show default) and live ICMPv6 reachability across Netcup’s AS197540 backbone. Using curl -6 --interface allows you to explicitly test each secondary IPv6 address bound to eth0 (::1, ::2), confirming that the hypervisor virtual switch routes return traffic cleanly to every address in your /64 block.

Before enabling IPv6 on any mail transfer agent (Postfix, Exim, Mailcow, Stalwart), you must configure Forward-Confirmed Reverse DNS (FCrDNS) in the Netcup Server Control Panel. Major mailbox providers—especially Gmail (mx.google.com) and Microsoft 365—enforce strict RFC 5321 / IPv6 anti-spam policy checks: if your Postfix daemon connects to Gmail over IPv6 from 2a03:4000:60:1234::2 and that exact /128 IPv6 address lacks a matching ip6.arpa PTR record, Gmail immediately rejects the message with 550-5.7.25 The IP address sending this message does not have a PTR record setup. Inside SCP → Select Server → Network → Reverse DNS, add a dedicated PTR entry mapping 2a03:4000:60:1234::2 to mail.example.com (and ensure mail.example.com has a matching AAAA record).

If you run Docker Engine on your Netcup server, remember that Docker’s default bridge network is IPv4-only unless you explicitly enable IPv6 in /etc/docker/daemon.json. Rather than attempting complex Neighbor Discovery Proxy (ndppd) setups to bridge fragments of your public /64 into containers, the cleanest and safest architecture on Docker 26/27+ is Unique Local Address (ULA) IPv6 NAT (NAT66).

By adding "ipv6": true, "fixed-cidr-v6": "fd00:dead:beef::/48", "experimental": true, and "ip6tables": true inside /etc/docker/daemon.json, Docker assigns deterministic internal ULA IPv6 addresses to containers and automatically masquerades outbound IPv6 container traffic behind your host’s primary 2a03:4000:...::1 address—preserving full host firewall isolation while giving every container native outbound IPv6 connectivity. Run the verification commands below to confirm end-to-end routing and PTR resolution:

# 1. Ping Cloudflare IPv6 DNS and trace the AS197540 IPv6 path
ping6 -c 4 2606:4700:4700::1111

# 2. Test outbound HTTP over IPv6 using specific source addresses from your /64 subnet
curl -6 --interface 2a03:4000:60:1234::1 https://ifconfig.co
curl -6 --interface 2a03:4000:60:1234::2 https://ifconfig.co

# 3. Verify that your SCP Reverse DNS (PTR) record resolves cleanly
dig -x 2a03:4000:60:1234::1 +short

2a03:4000:60:1234::1
2a03:4000:60:1234::2
prod-nc-01.example.com.