Implementace bezpečnostních mechanismů je v IPv6 povinná, což se uvádí jako jedna z významných výhod proti IPv4. Bohužel však programátoři tuto povinnost odkládají na později, takže ve většině stávajících implementací bezpečnostní mechanismy prostě chybí. Bývá označována zkratkou IPsec (podle IP security).
Základní mechanismy jsou dva a mají podobu rozšiřujících hlaviček. První z nich nese název Authentication Header (AH) a slouží především k ověření totožnosti odesilatele datagramu. Volitelně též může poskytnout ochranu proti opakování paketů (aby vetřelec nemohl jednoduše odeslat ještě jednou sekvenci vašich paketů, které se mu podařilo zachytit).
Druhou rozšiřující hlavičkou je Encapsulating Security Payload (ESP), která nabízí poněkud širší sortiment služeb. Jejím primárním účelem je zašifrovat nesený datagram, vedle toho však umí poskytovat i služby podobné AH. Neumí však oboje naráz - musíte si vybrat, zda sáhnete po šifrování nebo po ověřování totožnosti. ESP se dotýká všeho, co leží za ním. Typicky tedy je poslední nezašifrovanou částí datagramu. Datagram může mít jednu nebo obě bezpečnostní hlavičky.
Základní datovou strukturou bezpečnostního modelu IPv6 je databáze bezpečnostních politik (security policy database). Je to vlastně sada pravidel určujících, které datagramy mají být podrobeny jakým bezpečnostním procedurám. Z ní vedou odkazy na tak zvané bezpečnostní asociace (security association). Taková asociace existuje pro každé zabezpečené spojení, které počítač navázal, a obsahuje konkrétní data - způsob zabezpečení, klíče a podobně.
Databáze bezpečnostních politik posuzuje datagramy podle obvyklých kritérií, jako jsou zdrojová/cílová IP adresa, porty, protokoly, jména a podobně. Na jejich základě je datagramu určena jedna ze tří možností zpracování:
- zahodit
- akceptovat, aniž by byl podroben další bezpečnostní prověrce
- aplikovat bezpečnostní mechanismy (v tom případě vydá bezpečnostní asociaci, která se k němu vztahuje)
Databáze bezpečnostních politik například může stanovit, že datagramy přicházející od počítače bankomat123.banka.cz na port 4567 mají být podrobeny bezpečnostní prověrce a vydá odkaz na příslušnou bezpečnostní asociaci. V ní je uloženo, že datagramy musí být opatřeny hlavičkou AH a veškerá data potřebná k jejich ověření. Vyhoví-li datagram této kontrole, bude propuštěn ke zpracování. V opačném případě jej bezpečnostní mechanismus zahodí. Datagramy přicházející na port 4567 z jiných adres budou rovnou zahozeny.
Podpora mobilních zařízení
Přenosné počítače či nejrůznější komunikující zařízení jsou silně in. Čím dál více mobilních telefonů umožňuje přístup k Internetu, nejrůznějšími notebooky, handheldy či palmtopy se svět kolem nás jen hemží (praktický důkaz: tento text vzniká na notebooku a provází mne po nejrůznějších končinách).
Základní charakteristikou mobilních zařízení je, že za provozu přecházejí z jedné sítě do druhé (např. když komunikujete ze svého notebooku během cesty z Prahy do Vídně) a tudíž mění svou IP adresu. To nepředstavuje problém, pokud spojení navazuje mobilní počítač - prostě použije svou aktuální adresu.
Potíže nastanou, pokud se někdo chce spojit s cestujícím počítačem. Řešení je poměrně prosté. Každý počítač má svou domácí síť a jí odpovídající domácí IP adresu. Tato adresa je zanesena v DNS a tu také použije externí stroj při pokusu o spojení.
Pokud je počítač právě na cestách, zastupuje jej jeho domácí agent. Tuto roli hraje jeden ze směrovačů v domácí síti mobilního stroje (podpora mobility zahrnuje i způsob jeho automatického výběru, aby nemusel být konfigurován staticky). Domácí agent na sebe přesměruje data určená mobilnímu stroji (při objevování sousedů odpovídá místo něj). Mobilní uzel průběžně informuje svého domácího agenta o aktuální IP adrese.
Navázání spojení tudíž probíhá následovně: externí počítač zašle paket s žádostí o navázání spojení na domácí (trvalou) adresu mobilního uzlu. Jeho domácí agent ji zachytí a předá tunelem mobilnímu uzlu. Ten odpoví žadateli a ke svému datagramu přidá rozšiřující hlavičku s „aktualizací vazby“ (binding update), která jej informuje o aktuální (dočasné) adrese. Další komunikace pak už probíhá přímo mezi oběma zúčastněnými.
Kdykoli mobilní uzel změní svou adresu, pošle aktualizaci vazby svému domácímu agentovi a také všem strojům, se kterými v poslední době komunikoval. Navíc lze poslat aktualizaci vazby implicitnímu směrovači ze sítě, kterou právě opustil. Ten pak může pracovat jako domácí agent pro datagramy směřující na předchozí dočasnou adresu.
V pozadí popsaných mechanismů vystrkuje růžky nepříjemný bezpečnostní problém. Někdo by se mohl neprávem vydávat za počítač na cestách a přesměrovat tak na sebe jeho provoz. Proto každá aktualizace vazby musí být autentifikována (pomocí AH nebo ESP).
Implementace
Nejzávažnější slabinou IPv6 v současnosti je stav implementace tohoto protokolu. Pravda, pro celou řadu operačních systémů či směrovačů byla ohlášena podpora IPv6 nebo je dokonce již k dispozici. Dostupné implementace jsou však zpravidla jen částečné a při nejlepší vůli je nelze nazvat jinak, než experimentální.
Pokročilejší funkce, jako jsou bezpečnostní mechanismy či podpora mobilních počítačů, jsou k dispozici jen vzácně. Právě tyto vlastnosti se však mají zasloužit o prosazení IPv6 do praxe. Nacházíme se v začarovaném kruhu: IPv6 má zatím minoritní zastoupení a investice do jeho implementací proto nepřináší okamžité ekonomické výsledky, ovšem dokud tu nebudou implementace, nemůže se ve větší míře prosadit.
Nejkvalitnější IPv6 najdete v současné době v operačních systémech rodiny BSD (NetBSD, FreeBSD a spol.). Zde je k dispozici hned několik implementací, z nichž největší jméno si vydobyl japonský projekt Kame. Najdete tu bezpečnost i mobilitu, zkrátka IPv6 jak má být.
Naproti tomu nejrozšířenější operační systémy (MS Windows, Linux) nemají mnoho co nabídnout. IPv6 zde buďto vůbec není k dispozici (MS Windows 95/98) nebo má značné nedostatky.
Zrovna tak ve světě profesionálních směrovačů není důvod k bezbřehému optimismu. Největší hráč - firma Cisco - nabízí IPv6 pouze v testovací verzi svého systému a leccos mu schází (například OSPFv6 či klasicky mobilita). Zavedení do produkčního systému se stále odkládá. Dánská firma Telebit sice nabízí IPv6 ve svém standardním systému, ale k dokonalosti tu také schází hodně.
Sečteno a podtrženo: v současné době není IPv6 zralé k rutinnímu použití. Jedná se zatím o ryze experimentální půdu. Stávající implementace umožňují vyzkoušet si je v praxi, ale reálný přínos od nich zatím nelze očekávat.
Prosazování do praxe
Je zjevné, že i kdyby byl stav implementací mnohem lepší než v současnosti je, přechod z IPv4 na IPv6 se nemůže odehrát skokem. Nelze zkrátka prohlásit „od 1. ledna 2003 přechází Internet na IPv6, starej se každý jak umíš“.
Značná pozornost je proto věnována metodám koexistence a vzájemné spolupráce protokolů IPv4 a IPv6. Vedle celkem klasických cest, jako je propojování IPv6 sítí stávající IPv4 infrastrukturou, se hledají i možnosti jak by spolu mohl komunikovat počítač používající IPv4 s protějškem založeným striktně na IPv6. Byla navržena celá řada řešení počínaje dvojím zásobníkem (uzly hovořící oběma protokoly) přes tunelování až po nejrůznější translátory (SOCKS64, SIIT, NAT-PT či BIS).
Pro počáteční fázi zavádění IPv6 do praxe (která v podstatě již běží) budou hrát klíčovou roli obojživelníci - stroje podporující jak IPv4, tak IPv6. Jejich prostřednictvím bude zajištěna alespoň částečná spolupráce obou světů.
Typickou situací v současnosti je, že existují malé IPv6 sítě či pouhé izolované počítače, které jsou obklopeny čistou IPv4 sítí. Vzniká tedy potřeba propojit je navzájem prostřednictvím IPv4 infrastruktury. Podobná situace tu již byla (např. při šíření skupinově adresovaných datagramů) a existuje řešení. Je jím mechanismus s názvem, který má v našich končinách pikantní příchuť: tunelování.
Tunelování spočívá v tom, že se IPv6 datagram zabalí do IPv4 datagramu (z jeho pohledu tvoří IPv6 datagram přenášená data). Ten se dopraví klasickými mechanismy na druhý konec tunelu, kde z něj bude vybalen IPv6 datagram a ten bude dále zpracováván zdejší IPv6 vrstvou. Tímto způsobem lze propojit jednotlivé IPv6 ostrovy v současném Internetu.
Značná pozornost je věnována tomu, aby se pokud možno minimalizovala potřebná konfigurace. Klasický tunel je ručně konfigurován správcem daného stroje. Alternativu představují automatické tunely. Pro ně byl přidělen speciální prefix 0::/96, za kterým následuje 32 bitů IPv4 adresy. Takto vytvořeným adresám se říká IPv4-kompatibilní IPv6 adresy.
Dorazí-li takto adresovaný paket na obojživelný stroj, zabalí jej do IPv4 datagramu s cílovou adresou tvořenou poslední čtveřicí bajtů z cílové IPv4-kompatibilní adresy původního paketu. Odešle se IPv4 sítí až na místo určení, kde bude vybalen a zpracován. Tímto způsobem lze bezpracně - jen na základě vhodného adresování - tunelovat na celou řadu cílů.
K získávání praktických zkušeností s provozem IPv6 sítí je určena virtuální síť 6bone. Je složena z „ostrovů“ (lokálních sítí či dokonce jen individuálních počítačů) podporujících IPv6. Navzájem jsou propojeny stávajícím Internetem prostřednictvím tunelů, kdy se IPv6 datagramy obalují běžnými IPv4 datagramy. Ty jsou dopraveny na místo určení (do příslušné IPv6 sítě), rozbaleny a dále pokračují ve svém přirozeném prostředí.
Síť 6bone dnes zasahuje do řady zemí a slouží jako cenný zdroj poznatků pro další rozvoj jednotlivých protokolů a mechanismů.
Perspektivy
Současná situace IPv6 poněkud připomíná stav, ve kterém se koncem osmdesátých let nacházely protokoly referenčního modelu OSI. Všeobecně se tehdy tvrdilo „dnes sice všichni používáme IP, protože je to praktické, ale budoucnost patří OSI protokolům“. Jejich implementace (a často dokonce i samotné protokoly) však byly dost vzácné a nekvalitní a postupem času se zdánlivě perspektivní OSI rodinka odebrala na smetiště dějin.
Bratru o deset let později tu máme tezi „dnes sice všichni používáme IPv4, protože je to praktické, ale budoucnost Internetu patří IPv6“. Přitom jeho implementace váznou a širší prosazování do praxe se příliš nedaří. Neskončí IPv6 stejně jako OSI?
Odpověď ukáže teprve čas. Je tu však několik aspektů, díky kterým snad IPv6 může doufat ve světlejší budoucnost. Především vzniká na základě interního úsilí internetovské komunity, jehož cílem je vyřešit konkrétní problémy (zatímco OSI se stavělo ke světu stylem „já jsem mezinárodní standard, mám na to bumášku a všichni mě budete muset používat“). Druhým pozitivem je, že nevázne samotné vytváření protokolů. Pro klíčové prvky IPv6 již existují definice v podobě RFC, či alespoň pracovních návrhů.
Nejvýznamnější brzdou je jednoznačně implementace. Když si vzpomenu, že jedním z klíčových momentů pro rozvoj Internetu byla včasná implementace jeho protokolů do Unixu na základě grantu, nemohu se ubránit myšlence, že by situaci výrazně pomohl nějaký ten grant, který by postrčil kupředu implementaci v nejrozšířenějších systémech. Nechtělo by americké ministerstvo obrany zase jednou udělat něco pro nás prašivé civily a přidat si tak další zápis do historie?
