und das ist bei WhatsApp nicht?
mein 6in4-server bei netcup flutscht 
ist auf CentOS Basis, und so wie das Routing bei netcup realisiert ist, gibt es ein hervorragendes Feature;
f. Interessierte hier meine Umsetzung mit CentOS
ich habs mit 2 zusätzlichen /64-Prefixen realisiert,
würde wahrscheinlich auch nur mit einem gehen, könnte dann aber etwas Tricky sein;
zur Bezeichnung/Benennung der einzelnen Prefixe und IP-Adressen
2a03:4000:1:1::/64 (Server-IPv6) bzw. 37.37.37.37 (Server-IPv4)
geholt hab ich mir 2a03:4000:17:17::/64 (Tunnel-Prefix) und 2a03:4000:31:31::/64 (LAN-Prefix)¹
und 81.81.81.81 (Home-IPv4)
zuerst der Server:
/etc/sysconfig/network-scripts/ifcfg-eth0
...
IPV6_ROUTER=yes
# hier eine Adresse hinzufügen, mehr dazu weiter unten ...
IPV6ADDR_SECONDARIES="... SPECIALADDR ..."/etc/sysconfig/network-scripts/ifcfg-sit1
# IPv6-in-IPv4 tunnel
TYPE=SIT
NAME=sit1
ONBOOT=yes
DEVICE=sit1
BOOTPROTO=none
IPV6INIT=yes
IPV6TUNNELIPV4=81.81.81.81
IPV6TUNNELIPV4LOCAL=37.37.37.37
IPV6ADDR=2a03:4000:17:17::1/64/etc/sysconfig/network-scripts/route6-sit1
2a03:4000:17:17::/64 dev sit1 metric 1
2a03:4000:31:31::/64 via 2a03:4000:17:17::2 dev sit1 metric 1/etc/sysconfig/network
IPV6FORWARDING="yes" hinzufügen
jetzt der Router zu Hause - ist bei mir ebenfalls ein CentOS, und hier gibt es Unterschiede bzw. Besonderheiten
/etc/sysconfig/network-scripts/ifcfg-eth0
...
IPV6_ROUTER=yes
IPV6ADDR=2a03:4000:31:31::1
# hier einfach fe80::1 als secondary definieren, dann kann dies einfach als Gateway eingetragen werden
IPV6ADDR_SECONDARIES="... fe80::1 ..."/etc/sysconfig/network-scripts/ifcfg-sit1 ist ähnlich der am Server nur mit vertauschten IPv4 Adressen bzw. das andere Ende vom Tunnel-Prefix
# IPv6-in-IPv4 tunnel
TYPE=SIT
NAME=sit1
ONBOOT=yes
DEVICE=sit1
BOOTPROTO=none
IPV6INIT=yes
IPV6TUNNELIPV4=37.37.37.37
# falls jemand seinen Router hinter einem vom ISP gestellten Router hat,
# geht auch das, dann hier die entsprechende RFC1918 IPv4 verwenden
IPV6TUNNELIPV4LOCAL=81.81.81.81
IPV6ADDR=2a03:4000:17:17::2das Routing funktioniert hier aber anders, man braucht keine eigene Route definieren
/etc/sysconfig/network beinhaltet hier im Vergleich zum Server etwas mehr
IPV6FORWARDING="yes"
IPV6_DEFAULTGW=2a03:4000:17:17::1
IPV6_DEFAULTDEV=sit1zur Firewall, hier kommt bei mir IPtables/IP6tables zum Einsatz
IPv4 das Protokoll 41 erlauben, gilt f. beide Teile, sowohl der Router als auch der Server, folgendes in /etc/sysconfig/iptables an entsprechender Stelle hinzufügen, am Router ist das WAN-Interface bei mir eth1 und am Server ist es eth0, daher hier ethX
# Enable IPv6-A INPUT -i ethX -p ipv6 -j ACCEPT
-A OUTPUT -o ethX -p ipv6 -j ACCEPTbei IPv6 ist am Server etwas mehr zu tun, folgendes in /etc/sysconfig/ip6tables hinzufügen
# ICMP bzw. TRACEroute auch vom LAN erlauben
-A INPUT -i sit1 -p icmpv6 -j ACCEPT
-A INPUT -i sit1 -p udp --sport 32769:65535 --dport 33434:33523 -j ACCEPT
# direkter Weg f. SSH von zu Hause
-A INPUT -i sit1 -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
# Enable 6in4 Tunnel traffic
-I FORWARD -i eth0 -o sit1 -d 2a03:4000:17:17::2,2a03:4000:31:31::/64 -j ACCEPT
-I FORWARD -i sit1 -o eth0 -s 2a03:4000:17:17::2,2a03:4000:31:31::/64 -j ACCEPTjetzt die Besonderheiten
ich brauchte net.ipv6.conf.all.forwarding = 1 nicht explizit setzen, dies erfolgt durch die Skripte an Hand
IPV6FORWARDING="yes" in /etc/sysconfig/network
am Router zu Hause ist klarerweise net.ipv4.ip_forward = 1 gesetzt, beim Server ist das nicht notwendig;
nachdem man sich bei netcup die Prefixe holt, hat man im SCP im Menüpunkt Netzwerk die Mglkt. den Prefix bei einem VPS/RS zuzuordnen,
wenn man dies macht, dann zeigt er das an
beim Tunnel-Prefix:
2a03:4000:17:17::/64 -> 2a03:4000:1:1:4711:dead:beef:0007
als auch beim LAN-Prefix:
2a03:4000:31:31::/64 -> 2a03:4000:1:1:4711:dead:beef:0007
jeweils darunter kann man rDNS Einträge definieren; und diese IPv6 rechts, ist die 'SECIALADDR' beim Server,
welche man als zusätzl. IPv6-Adresse am Server definiert;
jetzt das geniale Feature auf Grund der Umsetzung bei netcup
man braucht keinen NDP-Proxy, das klappt nativ zum einem,
und zum anderen, ist der Tunnel-Prefix bei einem Traceroute von außen ins LAN versteckt, sieht bei mir so aus:
# traceroute6 2a03:4000:31:31::1
traceroute to 2a03:4000:31:31::1 (2a03:4000:31:31::1), 30 hops max, 80 byte packets
...
5 ae3-1337.bbr02.anx25.fra.de.anexia-it.net (2001:7f8::a5e9:0:3) 1.315 ms 1.536 ms 1.487 ms
6 2a00:11c0:47:1:47::140 (2a00:11c0:47:1:47::140) 4.490 ms 4.370 ms 4.909 ms
7 2a00:11c0:47:3::21 (2a00:11c0:47:3::21) 4.523 ms 4.732 ms 4.660 ms
8 2a03:4000:1:1:4711:dead:beef:0007 (2a03:4000:1:1:4711:dead:beef:0007) 4.660 ms 4.601 ms 4.737 ms
9 2a03:4000:31:31::1 (2a03:4000:31:31::1) 38.772 ms 37.634 ms 41.713 ms es funktioniert damit alles, vielleicht hat der eine od. andere eine Ahnung, wieso beim TRACEroute von zu Hause, Hop2 und Hop3 ident sind, nämlich
2a03:4000:17:17::1, sprich Tunnel-Prefix::1, dies auch beim HE-IPv6-Tunnel; ist dies bei Dir auch whoami0501 ?
¹ sollte jemand wirklich diese Prefixe haben, dann ist das Zufall, war nicht Absicht
und wegen seiner Haarfarbe