Geroutetes IPv6 (/64), Gateway fe80::1, rDNS & Docker-IPv6 auf Netcup konfigurieren

Melden Sie sich im Netcup Server Control Panel (servercontrolpanel.de) → Server auswählen → Network an. Dort sehen Sie die Hardware-MAC-Adresse Ihrer Netzwerkkarte, Ihre IPv4-Adresse samt Gateway sowie Ihr geroutetes IPv6-/64-Subnetz – beispielsweise 2a03:4000:60:1234::/64 mit dem Standard-Gateway fe80::1. Notieren Sie sich sowohl die MAC-Adresse als auch die ersten vier Heptets Ihres /64-Präfixes.

Warum routet Netcup Ihr /64-Subnetz statisch über die Link-Local-Adresse fe80::1, anstatt auf dem KVM-Bridge-Netzwerk kontinuierliche SLAAC-Router-Advertisements (RA) auszusenden? In großen Multi-Tenant-Rechenzentren wie AS197540 würden ungerichtete Multicast-Router-Advertisements auf gemeinsam genutzten Layer-2-Segmenten unnötiges Broadcast-Rauschen verursachen und es einzelnen Gast-VMs erschweren, deterministische Sub-Präfixe zu verwalten. Stattdessen terminiert der virtuelle Switch jedes KVM-Hostknotens auf fe80::1 und leitet den gesamten Datenverkehr für Ihr /64-Präfix gezielt an die MAC-Adresse Ihrer virtio-net-Netzwerkkarte weiter.

Auf Layer 2 übernimmt dabei das Neighbor Discovery Protocol (NDP, RFC 4861) die Aufgabe, die bei IPv4 das ARP-Protokoll erfüllt: Wenn der Netcup-Gateway-Router fe80::1 ein Paket für 2a03:4000:60:1234::1 zustellen möchte, sendet er ein ICMPv6 Neighbor Solicitation (Typ 135) an die Solicited-Node-Multicast-Adresse Ihrer VM. Ihr Linux-Kernel antwortet mit einem ICMPv6 Neighbor Advertisement (Typ 136), das Ihre MAC-Adresse enthält. Blockieren Sie daher in ip6tables, nftables oder der Netcup SCP Firewall niemals die ICMPv6-Typen 133 bis 136 – andernfalls bricht die IPv6-Nachbarschaftserkennung nach Ablauf des NDP-Caches sofort zusammen.

Prüfen Sie vor dem Anpassen der Netzwerkkonfiguration mit ip -br link und ip -6 route show, welchen Interface-Namen (eth0 oder ens3) Ihr Gast-Kernel vergeben hat und welche Routen aktuell aktiv sind:

# Interface-Namen, MAC-Adressen und aktuelle IPv4/IPv6-Bindungen anzeigen
ip -br link
ip -br addr

# Aktuelle IPv6-Routing-Tabelle inspizieren
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>

Unter Ubuntu 24.04 LTS übersetzt Netplan v2 Ihre YAML-Definition in /etc/netplan/ in native Konfigurationsdateien für den Daemon systemd-networkd. Beim Einrichten der statischen IPv6-Default-Route to: "::/0" über via: "fe80::1" ist das Attribut on-link: true zwingend erforderlich: Da fe80::1 eine Link-Local-Adresse außerhalb Ihres globalen 2a03:4000:...-Präfixes ist, teilt on-link: true dem Kernel mit, dass das Gateway direkt auf demselben Layer-2-Link (eth0) erreichbar ist, ohne dass zuvor eine separate Subnetz-Route zum Gateway gesucht werden muss.

Gleichzeitig müssen Sie accept-ra: false setzen. Bleibt accept-ra auf dem Standardwert true, akzeptiert der Linux-Kernel sporadische Router-Advertisements mit begrenzter Lifetime (Router Lifetime = 1800s). Sobald dieser Timer abläuft, löscht der Kernel die Default-Route, und Ihr Server verliert plötzlich nach 10 bis 30 Minuten jegliche ausgehende und eingehende IPv6-Verbindung (Network is unreachable). Mit accept-ra: false bleibt Ihre statische Route über fe80::1 dauerhaft und unverrückbar in der Kernel-Routingtabelle bestehen.

Weil Ihr komplettes /64-Subnetz auf Ihre Netzwerkkarte geroutet wird, können Sie problemlos mehrere IPv6-Adressen gleichzeitig im Array addresses: eintragen – zum Beispiel 2a03:4000:60:1234::1/64 für Ihren primären Nginx-Webserver, 2a03:4000:60:1234::2/64 exklusiv für Ihren Postfix/Dovecot-Mailserver und 2a03:4000:60:1234::10/64 für ausgehende Monitoring- oder API-Anfragen. In Nginx oder Postfix binden Sie den jeweiligen Dienst dann gezielt an seine eigene IPv6-Adresse.

Wichtiger Hinweis für Cloud-Init-Images: Damit Cloud-Init Ihre angepasste /etc/netplan/50-cloud-init.yaml bei einem späteren Server-Reboot nicht wieder überschreibt, legen Sie die Datei /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg mit dem Inhalt network: {config: disabled} an. Testen Sie Änderungen an Netplan immer zuerst mit sudo netplan try, das bei Verbindungsverlust nach 120 Sekunden automatisch ein Rollback durchführt:

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

Sobald sudo netplan try erfolgreich bestätigt wurde, prüfen Sie mit ping6 die ausgehende ICMPv6-Konnektivität und testen mit curl -6 --interface, ob Sie jede gebundene Adresse Ihres /64-Subnetzes gezielt als Quelladresse auswählen können. Standardmäßig nutzt der Linux-Kernel die zuletzt hinzugefügte IPv6-Adresse eines Interfaces als bevorzugte ausgehende Quelladresse (Source Address Selection, RFC 6724), sofern Sie sekundäre Adressen nicht mit preferred_lft 0 markieren oder in der jeweiligen Anwendung explizit binden.

Wenn Sie auf Ihrem Netcup-Server einen eigenen Mailserver (Postfix, Mailcow, Stalwart oder Docker-Mailserver) betreiben, ist die Einrichtung eines IPv6-Reverse-DNS-Eintrags (PTR) im Netcup SCP unter Network → Reverse DNS (rDNS) zwingend erforderlich. Große E-Mail-Provider wie Gmail, Microsoft 365 und T-Online prüfen bei jeder eingehenden SMTP-Verbindung über IPv6 die sogenannte Forward-Confirmed Reverse DNS (FCrDNS)-Kette: Die sendende IPv6-Adresse (2a03:4000:60:1234::2) muss per PTR auf Ihren Mail-Hostnamen (mail.example.com) auflösen, und dieser Hostname muss per AAAA-Record wieder exakt auf 2a03:4000:60:1234::2 zeigen. Fehlt der IPv6-PTR-Record, lehnt Gmail Ihre E-Mails sofort mit 550-5.7.25 The IP address sending this message does not have a PTR record ab.

Möchten Sie auch Ihren Docker-Containern ausgehende und eingehende IPv6-Konnektivität ermöglichen, ohne sich mit komplexem ndppd-NDP-Proxying herumzuschlagen, bietet Docker ab Version 24+ eine saubere IPv6-NAT (NAT66)-Integration direkt in der /etc/docker/daemon.json. Durch das Eintragen von "ipv6": true, "ip6tables": true, "experimental": true und einem privaten ULA-Subnetz "fixed-cidr-v6": "fd00:dead:beef::/48" weist Docker jedem Container automatisch eine interne IPv6-Adresse zu und übersetzt ausgehende Verbindungen per Kernel-ip6tables-MASQUERADE auf die öffentliche Netcup-IPv6-Adresse Ihres Hosts.

Führen Sie die folgenden Befehle aus, um Ihr IPv6-Routing, die Quelladressauswahl über mehrere /64-Adressen sowie die ip6.arpa-PTR-Auflösung im Terminal zu verifizieren:

# 1. Cloudflare IPv6-DNS anpingen und den AS197540-IPv6-Pfad prüfen
ping6 -c 4 2606:4700:4700::1111

# 2. Ausgehendes HTTP über IPv6 mit spezifischen Quelladressen aus Ihrem /64-Subnetz testen
curl -6 --interface 2a03:4000:60:1234::1 https://ifconfig.co
curl -6 --interface 2a03:4000:60:1234::2 https://ifconfig.co

# 3. Prüfen, ob Ihr im SCP gesetzter Reverse-DNS-Eintrag (PTR) sauber auflöst
dig -x 2a03:4000:60:1234::1 +short

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