Az előbb épp felvázoltam a biztos, megállíthatatlan, elkerülhetetlen tech-pokalipszist, elfogynak az IPv4 címek, a v6-ra senki nem akar áttérni, a routing tábla minden határon túl nő és átszakítja a TCAM gátakat és elönti a szervertermeket, minden sötétebb ajzatból SSL-MITM támadások lesnek ránk, és már a kernel.org-ot is megették a hecskerek és mindmeghalunk (internet nélkül mármint).

Persze vannak roppan érdekes kezdeményezések, projektek, csoportosulások pont az első bekezdésre rákontrázva.

Nézzük őket sorra: LISP 1 2 3, ILNP és SHIM6. Ez ilyen erős mindfuck faktorral rendelkező betű-szóleves. A LISP érdekes túlzásba vitele a "rátervezésnek" (mondjatok szépszót az "overengineering"-re). Mármint az alapprobléma a "core router"-eknek túl sok infót kell tárolniuk. (Core router, hálózati eszköz nagyon-nagy szolgáltatónál, melyeken esetenként több szolgáltató teljes forgalma átfolyik és L3 - layer 3, azaz IP szintű - útválasztást végez.) Ez azért van, mert mindenki szeretné a saját kis hálózatát finomhangolni, a saját IP tartományocskáját használni, ahelyett, hogy a területi aggregáció szerint ésszerűt használná. Persze ez kb. kivitelezhetetlen, mert pont ez az őrült szabadság az egyik előnye az Internetnek, de tény, hogy túl sokat pakolnak az alap protokolok nyakába, mármint szeretik elsumákolni azokat a problémákat, hogy mi van akkor, ha megváltozik az IP címem menet közben. A TCP nem képes ezt kezelni. Nem is értem miért. Oh, várjunk csak, de! Már így is ~20 oldalnyi diagram kell a pontos (!) specifikációjához. Az SCTP elvben tudna ilyet, de az meg egy bughalmaz, hiszen senki nem használja. Hm, hm. Lehet, hogy akkor ezt a TCP-re kéne ráépíteni? OSI modell, megint helló. Viszont így is gyászosan low-level az operációs rendszerek hálózattámogatása (socket programming, hajrá). Ehhez képest a LISP egy már ma működő, meglehetősen kifinomult, biztonságos, a végfelhasználók és a nagy-és-drága routerek szempontjából észrevétlen megoldást kínál. Érdekes lesz.

OpenFlow. Itt a lényeg, hogy egy igazi, normális menedzsment szintet húznak a hálózatra. Van egy csomó nagyon jó alprojektjük, pl. a FlowVisor, ami virtuális hálózatot tud csinálni (kap egy kis címtartományt, és azok szempontjából úgy konfigurálod az eszközöket az OpenFlow-n keresztül, ahogy akarod, a FlowVisor meg vigyáz, hogy tényleg csak ahhoz nyúlj, amit neked osztottak), OpenPipes, amivel kiterjeszthető a koncepció adatforrásokra és adatfeldolgozókra/végpontokra, még holisztikusabb (teljesebb) szemléletet, algoritmusokat lehetővé téve. Alapvetően a lényege, hogy a hálózat újrakonfigurálásához kapsz egy API-t, és nem kell a fostos Cisco parancssort buzerálnod, meg feketemágiázni mindenféle egyéb konzolon.

DNSSEC, Key Signing Ceremony. Még több biztonság, manapság nem árthat. A főfő koncepció a "trust anchor", azaz a bizalomhorgony, amit valahova le kell betonozni, ha meg akarsz állni stabilan az internet vad vizein. Az SSL/PKI globális tanusítvány infrastruktúra elvben az ellen védett, hogy valaki ne adhassa ki magát másnak, viszont a problémája az, hogy túl sok megbízható "tanusító hatóság" (certificate authority) van benne. A DNSSEC esetén csak a legfelső (a DNS-gyökér) zónának a kulcsát kell ismerni, hogy le lehessen vezetni a DNS szerver válaszából az igazságot. (Mondjuk itt a DNS regisztrátorok lettek valamelyest a gyenge pontok.)

Aztán vannak ilyen egyéb biztonsági mozgolódások: Az EFF HTTPS Everywhere + SSL Observatory-ja, a Mozilla is keményebben dobálja ki a romlott almákat a CA-s kosárkájából, itt egy új-érdekes szoftver a Convergence, egy előadás szlájdjai ~ avagy mit kezdjünk az egész SSL/TLS tanusítvány infrastruktúrával (hackerspace budapest tiki link). SSL + Global PKI vita, a Hacker News-on is. (Külön érdekes az egyik hozzászólás a tofu/pop ~ trust on first use, persistence of pseudonym előnyeiről és hátrányairól.)

Furcsa, hogy néha teljesen lázba hoz a mindenféle routing protokoll és az épp aktuális leggyorsabb-kurvanagy több szekrényes szolgáltatóknak szánt Cisco/Juniper eszköz, meg ezek kapcsán az ilyen Internet Engineering témák.

Most például itt ez (az örökös) probléma, a routing tábla mérete (állandóan nő), amit az undorító NAT66 egyik aspektusának megoldásása miatti aggodalmak súlyosbítanak. Miről is van szó? A Provider Independent address space-ről (szolgáltató független címtartomány, röviden PI addresses). Mert konkrétan elég sok olyan közép- és nagyvállalat van, amelyik nem igényel saját ASN-t (autonomous system number, autonóm rendszer), tehát nem akar BGP-zni meg multihoming-elni (ténylegesen több netszolgáltatóval leszerződni, külön kábeleken netet kötni), viszont mégsem szeretné, ha szolgáltatóváltás esetén az IP címei változnának. Na, akkor ők szépen kérnek a regionális internet nyilvántartótól (RIR, regional internet registry) egy IP tartományt, és örülnek.

Mi a gond ezzel? Az, hogy ezt a címtartományt külön kell babusgatni, legjobb esetben csak egy új bejegyzést jelent a nagy-globális táblában, de lehet, hogy a kedves cég szétszórja a szervereit a világban és felbuzdulva azon, hogy van saját IP tartománya, abból próbál osztogatni IP-ket, ezáltal rengeteg külön szabályt kell felvennie a szolgáltatóknak. (Nyílván egy nagycég, amelyik elég nagy, hogy érezze a szükségét a külön címtartománynak, az elég hülye is, hogy fizessen azért, hogy a Timbuktui szerverteremüzemeltető felvegye a cég IP címét külön.)

Jó, jó, de ez volt IPv4 esetén is, mi köze ehhez a NAT66-nak? Az, hogy a NAT egy rossz, csúnya, rossz dolog, és az IETF próbálja elkerülni, meg kb. mindenki aki él-és-mozog ilyen IPv6 fórumokon tüntet ellene. (Tessék elképzelni, amint a 40 éves 50 kilós 60 Ciscovizsgás netwörkösök halálosztagai felvonulnak követelve a NAT betiltását.) Na jó, már megint itt a szóvirágok, de hogy lehet, hogyha senki nem kedveli ezt, mégis még mindig az asztalon van. Azért, mert szintén ezek a közép-nagy vállalatok azok, ahol nincs pénz a dolgokat jól csinálni (mert a kontrolling, meg a költséghatékonyság, meg a topmenedzsment, meg kell a pénz a Windows licenszre meg az Oracle DBA is drága pénzért kattingat), de arra van, hogy a szépen becsomagolt, masnival átkötött dobozos világmegváltást kipengessék. (Hiszen amikor mindenhol 3 oldal marketing szöveg után is legfeljebb egy 50 pixeles képet látsz egy switchről, akkor biztos lehetsz benne, hogy ez a fajta eladási taktika működik.) Tehát az ilyen félkompetensek által fizetett hálózatosok azok, akik szerint a NAT66 jó ötlet.

Technikailag. A NAT (network address translation, hálózati címfordítás) nem csinál mást, mint bizonyos szabályok szerint átírja az IP csomagokban a forrás és/vagy cél címet. Ez önmagában nem tűnik rossz dolognak. Hol használatos? Például a kis- és középvállalatok és a végfelhasználók szinte 100%-ánál. Mert így az internetszolgáltatótól kapott 1 IP címre fel lehet fűzni gyakorlatilag bármennyi gépet. (Mivel a NAT eszközök stateful jószágok, tehát a szabályok mellett a lokális hálózati képet is tartják a memóriájukban, ezáltal biztosítva, hogy az átírt címmel kiküldött csomagra érkező válaszcsomagot melyik belső címre írja vissza. Hiszen annak nem sok értelme lenne, ha csak kifelé írná át. Vagy csak befelé. Jó, persze, a port forwarding az nem más, mint egy statikus szabály, amihez nem kell állapotot nyílvántartani, de akkor minden alkalommal, mikor egy kisfelhasználó a Wifi-jére enged valakit, akkor kézzel fel kéne vennie egy szabályt, csak hogy tudjon böngészni a vendég.)

A NAT az IPv4 világban egy félig-meddig mesterséges szűkösség révén terjedt el. A netszolgáltatók nem vettek és nem osztottak sok IP-t a végfelhasználóknak, illetve egy irodában egyszerűbbnek tűnt megvenni egy NAT eszközt, mint kifizetni havonta sokezer pénzt a külön IP címekre.

Az IPv6 címtartományok (mármint azok, amiket minimum kapnak majd a végfelhasználók) annyira elképzelhetetlenül elképesztően hatalmasok, hogy ilyen hiány fel sem merülhet senkiben. (/56 vagy /48 a minimum allokációs egység, legzsidóbbak /64-et adnak mondjuk, de azokhoz be kell menni kezet-lábat-orrot törni, láncfűrésszel rendet tenni, gázolajjal egyezkedni. Oh, egy ilyen /valamennyi azt jelenti, hogy annyi a 128 bites IPv6 címből annyi bitet tud a kisfelhasználó szabadon állítgatni, tehát kettő-a-valamennyiediken lehetséges címet tud kiosztani, tehát be-szarsz, be-hu-gyo-zol, annyira k u r v a s o k. (Itt a jó öreg perzsa Sah és a sakk feltálálójának meséje, amikor a jófej uralkodó megkérdezte a szótlan, joviális kis játékmestert, hogy milyen ajándékot kér eme poNpás játékért, aki csak pár szem rizst kért, annyit, hogy a sakktábla 64 mezőjén egyenként dupla annyi legyen, mint az előtte lévőn, ha az elsőn 1 szem van. Na, az utolsón annyi rizs lenne, hogy nagyobb kupac lenne, mint a Mount Everest.)

Tehát az IPv6 esetén nem kell NAT-olni, ami régi mániája a hálózatosoknak, mivel végre visszaállna az egyensúly az Erőben, meg minden, de főleg az end-to-end principle, ami azt mondja, hogy a hálózati rétegben a címzést nem basztatjuk. Ami ugye egy elég fontos axióma a hálózati rétegekkel kapcsolatban, hiszen így lehet(ne) hatékony kommunikációs protokollokat tervezni, mivelhogy nem kéne paranoiásan ellenőrizni, hogy nem kell-e más címre kérni a visszaválaszt, mint amiről küldjük.

Kis kitérő. Ha már hálózati rétegek, és NAT meg protokolltervezés. Komoly gond a portok és címek átirogatásával az, hogy egy csomó rosszul tervezett protokoll képtelen megmaradni egy TCP kapcsolatnál, hanem neki kell kontrolcsatorna, meg külön port tartomány, és egy kávét is szeretnék. Ja, és az igazán izgágákat meg csak úgy lehet NAT-olni, ha alkalmazásszintű feldolgozást végez a hálózati eszköz az adott porton átmenő adatfolyamon, mert a protokoll valahol önmagában mélyen is kódolja mondjuk a saját címét/portját, amit szintén át kell írni. Pedig elég egyértelmű az OSI modell, a kommunikáció különböző szempontjai szépen szét vannak válaszva, így egy-egy réteg más-más dologért felelős. Do only one thing, and do it well. (Jó öreg, ~ 1970, UNIX filozófia.) Tehát függetlennek kéne lennie a dolgoknak egymástól.

Azért jó, ha a dolgok kohéziója kicsi, mert akkor könnyű csereberélni a komponenseket, és könnyű inkrementálisan javítani a rendszeren. (Ismerős a probléma, nem? Az objektum-orientált programozás nagy rákfenéje, hogy nem tudunk jól osztályokat tervezni. Vagy túl sok osztályunk van és szétforgácsolódnak a felelősségek-feladatok, vagy túl kevés, és akkor meg romlik a hatékonyság túl nagy lesz a belső komplexitás, váratlan mellékhatások jelennek meg, stb.)

És még mindig lehet mit írni a NAT-ról! Hogy miért is ragasznodnak sokan hozzá, akiket - szegényeket - nem is fizeti le egyik cég sem, hogy össze-vissza beszéljenek, hanem maguktól keverik a flórát-meg-a-faunát. Mert sokan a biztonsági tényezőt hozzák fel, mint előnyt. Lévén a NAT alapból eldob minden csomagot, amiről nem tud dönteni, így egy tűzfal látszatát keltve. Az illúzió elég hatásos, hiszen sokan azt hiszik, hogy ha egy ilyen alap kis routeren van "tűzfal" akkor már biztonságban vannak. Persze azt nem tudják, hogy pont ők maguk herélik ki az eszköz tűzfalságát azzal, hogy dinamikus-NAT-ot használnak. Hiszen így ha a böngészőjük (vagy ami valószínűbb, egyik sebezhető beépülő kisalkalmazás, plugin, codec (!), segédprogram), levelezőprogramjuk, a Word vagy az Excel fertőződik meg, akkor a vírus kénye kedve szerint tud kifele kapcsolódni a gonoszokhoz, akiktől simán vissza tud jutni az ÁRTS-ÖLJ-FERTŐZZ parancs, hiszen a NAT így már beengedi, hiszen bentről kezdeményezték a kommunikációt. (Így fertőzték meg az RSA Inc.-t, akik elvileg biztonságtechnológiát adtak el mocskosfontos cégeknek a koszoskis titkaik rejtegetésére. És a kriptográfia első szabálya, hogy ne csináld magad, sőt, hidd, hogy te vagy a leggyengébb lánccszem. Hát az RSA tényleg elég gyenge volt ezek szerint. És így fetrőztek meg egy csomó céget, a Google-t is, az Aurora attack keretében, amikor jó kis Adobe sebezhetőségekkel szórtak meg PDF fájlokat meg Flash-es oldalakat, és küldték el a linket a szóbanforgó cég alkalmazottainak.)

Tehát a NAT66 az IPv6-IPv6 címek és portok egymásba keverése. Van még NAT64 (ami még egész ésszerű) meg a NAT444 (amit CGN-nek is csúfolnak és tűzzel-vassal-írtós-faszság), ezek ilyen igazán ocsmány áthidaló szigszalagozások, ahelyett, hogy rendes, teljes, fasza-király IPv6-ot vezetnének be az elvtársak.

Miért nem váltunk v6-ra? Azért, mert alapvetően csak az "új belépőket" érinti a probléma. Azaz azokat a csóró kis indiaiakat, akik most akarnak netet venni. Sőt, igazából azokat a kis cégeket, akik most szeretnének "beszállni az Internetbe". Hiszen a végfelhasználó pont leszarja, hogy nem tud aktív módban torrentezni, vagy SMTP (levelező) szervert üzemeltetni a lakásában, szóval neki jó lenne az is, ha ilyen passzív szarral szúrják ki a szemét, amúgy is csak fészbúkozni akar. A nagy cégek, akik ugyan tudják, hogy a v6-ra áttérés elkerülhetetlen, még húzzák, hiszen venni kéne akkor új v6 képes eszközöket, sőt (!). Sőt! Mióta is van v6? ~20 éve kész a szabvány. Viszont az elmúlt tíz évben a világban szétszórt ADSL- és kábelmodemek kurvára nem valószínű, hogy tudják kezelni. Sem a routerek és a switchek, amik a szolgáltatóknál vannak. Hiszen egyszerűen nem volt fontos. Persze, ezutóbbiakat még fel lehetne könnyen firssíteni, hovatovább, a modemekre is biztos lehet valami ördögi firmware frissítést tenni, hogy valahogy "muukodjon", de minél később kell erre költeni, annál jobb.

Cikkek, amiket olvastam, mielőtt a fenti agyömlésem támadt:

Félelem és reszketés IPv6-ban

Az IAB javaslata, szolgáltató független címzés ~ nem tudom amúgy, hogy ki-vagy-mi az az IAB :)

35. adás, A 3-réteg-modell megtörése ~ Juniper QFabric, meg ilyen konvergens hálózatok marketingszöveg, jó kis vesézés a PacketPusher podcast adásában.

54. adás, LISP

40. adás, OpenFlow