There, I fixed it! NAT64 to the rescue
Al jaren doen we bij Tuxis dingen met IPv6. Eigenlijk is er niets dat bij ons geen IPv6 doet. En dus leveren we onze TCC-clusters tegenwoordig IPv6-only op. Dat wil zeggen, de management laag. Om de apparatuur van onze klanten te beheren hebben wij geen IPv4 meer nodig, en dat scheelt weer IPv4-adressen in de schaarste!
Maar soms heb je wel eens iets nodig, van Github.com bijvoorbeeld. Een mooi platform waar heel veel (open source) software op te vinden is die wij kunnen gebruiken om het leven van onze klanten nog prettiger te maken. (Vandaag was het netdata)
Github.com is handig en we zijn alle ontwikkelaars die er code op zetten erg dankbaar, maar het heeft één nadeeltje als je IPv6-only deployed:
root@node01:~# ping -c 1 github.com
connect: Network is unreachable
Github doet geen IPv6, gewoon niet.
‘Vroeger’ had Tuxis een NAT64-server. Een server waar derden met IPv6-only machines gebruik van konden maken om zo toch de IPv4-wereld nog te kunnen bereiken. Die is op een gegeven moment opgeruimd omdat IPv6-only toen echt nog niet haalbaar was. Maar, met de ontwikkelingen van de afgelopen jaren hebben we die vanmiddag weer opnieuw opgezet.
Als je klant van Tuxis bent en je wilt IPv6-only machines opzetten, dan kun je de nameserver van je machine aanpassen naar 2a03:7900:2:0:31:3:104:161, en vervolgens het hele internet bereiken, over IPv6!
root@node01:~# ping -c 1 github.com
PING github.com(2a03:7900:6446::8c52:7104 (2a03:7900:6446::8c52:7104)) 56 data bytes
64 bytes from 2a03:7900:6446::8c52:7104 (2a03:7900:6446::8c52:7104): icmp_seq=1 ttl=48 time=89.7 ms
--- github.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 89.710/89.710/89.710/0.000 ms
De betere oplossing is natuurlijk dat Github zelf snel IPv6 gaat doen, maar tot die tijd kunnen wij in elk geval vooruit!