Nekem (volt szerencsém 4-5 éve architectként végigszívni egy összetettebb szerver-termék IPv6-osítását) az volt a tapasztalatom, hogy hiába volt már akkor is több generáció óta IPv6 support, mivel nem nagyon használják elsődlegesnek, ezért tele van bugokkal. Túl lassan takarítódnak ki a bugok. Még az OpenSSH-ban is fogtunk IPv6 support bugot. Szinte az összes DB, MQ, clustering megoldás belső replikációs forgalmában volt IPv6 bug. Ha frontend oldalon jól is működik, a cluster belső forgalmát annyira nem teszi senki v6-ra, hogy abban nem derülnek ki a hibák. Nekünk meg ügyfél kifejezetten kérte, hogy IPv6-only módon is tudjunk működni.
Az egyik leggyakoribb problémakör az IPv6 címek írási formájának kezelésével van.
- Tipikus, hogy a ":"-ról azt hiszi, hogy URL-ben (vagy csak simán címben) a portszám elválasztó karakter, nem kezeli le a []-es jelölést. Többnyire DNS-sel tudod csak workaroundolni.
- A másik, hogy a v6-os címeknek nincs egy egyértelmű string reprezentációja és rengeteg szoftver stringként komparálja a címeket, nem veszi észre ha két cím eltérő írásmóddal valójában azonos.
- Vagy megpróbálja a címet kanonikus formára hozni és úgy stringként komparálni, de akad valami sunyi corner-case, amikor hibázik (pl SSH-nál futottunk bele, volt olyan cím, amit más formában rakott be a known_hosts-ba, mint ahogy ellenőrizte, hogy már benn van-e. Így minding azzal jött, hogy ismeretlen a host fingerprint. Saját scriptből kellett betennünk a known_hostsba, hogy olyan formában legyen, amiben keresi).
- Javascriptben volt kismillio ipv6 cím validátor library és kb midegyiknek volt valami baja. Vagy nagyon kicsi subneteket nem kezelte (/120 és kissebb) vagy a nagyon nagyokat nem (/8 és nagyobb). Nyilván le volt tesztelve a legtipikusabb "/48", "/64"-re oszt jóvan. Az IPv6 cím nem fér be egy javascript-es number-be, ezért kellett mindenféle custom reprezentációkat (tipikusan tömböket) bevezetni, aminél az első és/vagy utolsó elem tömbcímzésében volt lekezeletlen corner case.
Azok a programnyelvek, amik saját maguknak implementálnak TLS-t, DNS klienst stb. szintén igen változatos bugokat tudnak tartalmazni. Főleg python-nal szoptunk sokat:
- Python-ban a "Green DNS" - ami akarva akaratlanul függőségként beránt egy csomó lib és lecseréli a standard DNS libc-s resolvert egy non-blocking saját python-os implementációra - gyakorlatilag nem tudott normális AAAA-s lekérdezést csinálni. Aztán verzióról verzióra variáltak a viselkedésén, de valahogy az RFC szerinti viselkedést sosem sikerült eltalálni. Másik kedvencem, hogy a fully qualified domain nevek végére is - biztos ami biztos - odabiggyesztette a lokális search domain suffixet. Így lehetett szívni pl a localhost.localdomain.localdomain feloldásával, vagy mondjuk például google.com.localdomain-re, amire ha nem kapott megfelelő választ az upstream DNS szervertől, akkor 60 másodperc timeouttal honorált minden connection nyitást. Ráadásul a GreenDNS immunis minden standard resolver konfigurációra, lokális hosts file-t is teljesen ignore-álta. Nyilván lokális dnsmasq-al meg lehetett patkolni, de akkor is...
- Python-os cert kezeles szintén össze-vissza bugos volt, ha a cert subject name/subject altname-ben IPv6-os cím volt. Volt olyan verzió, amikor - helytelenül - a certben "DNS" típusú subject altname-et kellett felvenni és abba stringként IPv6-os cím. Persze a "szokásos" stringként komparálási bugokkal. Aztán egyszercsak úgy kijavították, hogy már nem is fogadta el validnak az ilyen certet (enyhe understatement... exceptionnel elszállt az egész), ha a "DNS" típusú mezőben IP címet talált. Persze tudom, certet nem írunk alá IP címre...
- Amúgy ez is egy általános problémakör volt, szoftverenként igen változatos volt, hogy IPv6-ra pontosan hogyan is kell olyan certet aláírni, amit elfogad validnak.
Teljesen általános probléma még a source cím választás kérdésköre (pl ha a fogadó oldalon tűzfal source alapján engedne be, vagy kliens cert validálásnál):
- IPv6-nál alap, hogy van legalább 2-3 címed egy interfészen. Egyazon subnetben van pl SLAAC és stateful DHCP, vagy manuális statikus IP címed is. Ha a kliens szoftver nem köti le a socket nyitásnál a source címet, akkor tipikusan a SLAAC-os címet fogja preferálni kimenő kapcsolatokhoz. Ami meg ugye MAC-cím függő, rosszabb esetben még randomizált és periodikusan változik is, és a tűzfalon nyilván nem azt fogod beengedni.
Biztos volt még több is, ami most éppen nem jut eszembe... Nyilván idő közben javulgatott a helyzet, de nem egyszerű.