Podívejme se na základní principy, podle kterých má podpora mobility fungovat. Některé z nich se za ta dlouhá léta prakticky nezměnily, ale u jiných (zejména v oblasti zabezpečení) došlo k podstatným úpravám.
Domácí agent
Jako mobilní uzel je označován počítač, který cestuje a současně komunikuje – typicky notebook či počítač do dlaně využívající bezdrátové připojení. Průběžně se připojuje do různých sítí a v důsledku toho neustále střídá své IP adresy (bývají označovány jako aktuální či dočasné adresy, anglicky care-of address). To způsobuje komplikace dvojího druhu:
- Chce-li s ním někdo navázat spojení, neví, na jaké adrese je momentálně k zastižení.
- Pokud on sám navázal spojení, vadí změna adresy protokolům vyšších vrstev (IP adresa je například součástí identifikace TCP spojení).
Pro řešení tohoto problému zavádí mobilní IP pojem domácí sítě a domácí adresy. Vychází z myšlenky, že každý mobilní uzel je někde doma a existuje síť, v níž je připojen, pokud zrovna není na cestách. Toto je jeho domácí síť a adresa, kterou v ní dostal přidělenu, je jeho domácí adresou. Pod touto adresou je zaregistrován v DNS, na ni se obracejí případní zájemci o spojení s ním a zpravidla ji také používá jako svoji vlastní.
Pokud se mobilní uzel zrovna nachází na cestách, zastupuje jej v domácí síti jeho domácí agent. Jedná se o jeden ze zdejších směrovačů, u nějž se mobilní uzel zaregistruje – pošle mu zprávu o své momentální dočasné adrese a požádá, aby jej zastupoval. U domácího agenta si vytvoří tak zvanou vazbu (v originále binding) mezi svou domácí a dočasnou adresou.
Od tohoto okamžiku začne domácí agent podvádět při objevování sousedů – vydává se za mobilní uzel a stahuje tak na sebe veškeré datagramy, které směřují na jeho domácí adresu. Následně je přeposílá šifrovaným tunelem mobilnímu uzlu na aktuální adresu. Pro šifrování se používá IPsec, konkrétně hlavička ESP.
Tímto způsobem se přinejhorším může odehrávat celá komunikace. Protější partner (v terminologii mobilního IPv6 označovaný jako korespondent) posílá datagramy na domácí adresu mobilního uzlu, ty dorazí do jeho domácí sítě, odkud je domácí agent přepošle tunelem mobilnímu uzlu. Ten ve svých odpovědích použije jako adresu odesilatele opět svou domácí adresu, předá datagramy tunelem domácímu agentovi (jinak hrozí, že je zahodí některý firewall, protože by adresa odesilatele neodpovídala síti, ze které jsou odesílány) a ten je přepošle protějšímu stroji.
Komunikace prostřednictvím domácího agenta
Popsaný režim pochopitelně zdaleka není ideální. Díky průchodu domácím agentem jsou pakety směrovány neefektivně, dochází ke zbytečnému zatěžování linek do a z domácí sítě a navíc možné selhání domácího agenta představuje potenciální riziko pro komunikaci jako takovou.
Optimalizace směrování
Proto je součástí mobilního IPv6 i optimalizace směrování. Díky ní sehraje mobilní agent svou úlohu jen při počátečním navázání komunikace mezi korespondentem a mobilním uzlem, zatímco později již datagramy proudí přímo mezi oběma koncovými body. Předpokladem pro optimalizaci je, aby se vazba mezi domácí a dočasnou adresou mobilního uzlu vytvořila i u korespondenta.
Tento krok v sobě ale skrývá potenciální bezpečnostní riziko. Je třeba zajistit, aby o sobě libovolný počítač nemohl prohlásit, že je třeba cestující www.seznam.cz a nezcizil tímto způsobem provoz, který mu nepatří.
Podle původních představ se o zabezpečení mělo postarat IPsec. To je skutečně použito, ale pouze mezi mobilním uzlem a jeho domácím agentem. Tady lze předpokládat, že se navzájem znají a že tudíž nebude problém vybavit je odpovídajícími klíči a dalšími náležitostmi. Ovšem korespondentem může být prakticky kdokoli, což činí IPsec nepoužitelným. Dokud nevznikne infrastruktura veřejných klíčů (a o stavu PKI asi nikdo z nás nemá žádné iluze), bude škálovatelnost IPsec prachmizerná a o podobných rolích si může nechat zdát.
Právě tady tkví jedna z příčin velkého zpoždění mobilního IPv6. Jeho autoři vsadili na mrtvého koně, neustále se drželi myšlenky použití IPsec a když byla v roce 2001 definitivně shozena se stolu, museli vymýšlet kompletně nové zabezpečení. Při té příležitosti to vzali od podlahy a radikálně změnili formáty používaných zpráv, takže specifikace z roku 2002 se výrazně liší od té z roku 2000.
A jak to dopadlo? Bez možnosti opřít se o nějaký silnější mechanismus nakonec autoři mobilního IPv6 došli k závěru, že pro ověření totožnosti postačí, když mobilní uzel prokáže korespondentovi, že přijímá data jak na dočasné, tak na domácí adrese. Dotyčný proces byl pojmenován Return Routability Test.
Když mobilní uzel obdrží od domácího agenta tunelovaný datagram, dozví se tak, že se s ním někdo snaží komunikovat a používá jeho domácí adresu. Jako reakci pošle korespondentovi dvě zprávy: zahájení testu domácí adresy (home test init) a zahájení testu dočasné adresy (care-of test init). V první použije svou domácí adresu a tuneluje ji přes domácího agenta, zatímco druhou opatří svou dočasnou adresou a posílá ji přímo.
Jakmile korespondentovi dojde jedna z těchto inicializačních zpráv, reaguje na ni odesláním testu příslušné adresy. Test domácí posílá na domácí adresu (odkud by měl být tunelován), test dočasné opět adresuje přímo. Až mobilní uzel dostane oba testovací pakety, údaje z nich použije ke konstrukci žádosti o vytvoření vazby (tzv. aktualizace vazby), kterou pošle korespondentovi. V ní prokáže, že obdržel jak testovací zprávu směřující na domácí adresu, tak zprávu doručenou na adresu dočasnou. Pokud ji korespondent potvrdí, budou spolu oba nadále komunikovat přímo s využitím dočasné adresy.
Aktualizace vazby u korespondenta
Všech šest zmiňovaných zpráv (zahájení testů, testovací hodnoty i aktualizace a potvrzení vazby) je prošpikováno pořadovými čísly a kryptografickými konstrukcemi vycházejícími z náhodných a neveřejných čísel, aby se zabránilo různým nekalým hrátkám.
Mobilní uzel si udržuje přehled o partnerech, u nichž má registrovánu vazbu. Kdykoli změní svou aktuální adresu, posílá jim aktualizaci, aby měli neustále přehled o tom, jak s ním optimálně komunikovat. Analogicky samozřejmě informuje i svého domácího agenta.
Rozšiřující hlavičky
Přímá komunikace ale není tak úplně jednoduchá, protože je třeba dočasnou adresu skrýt před protokoly vyšších vrstev. Každá strana proto do datagramů přidává jednu rozšiřující hlavičku. Mobilní uzel v datagramu jako odesilatele uvede svou dočasnou adresu, ale přibalí hlavičku nazvanou Domácí adresa obsahující jeho domácí adresu. Příjemce se pak podívá, zda pro danou dvojici adres má platnou vazbu a pokud ano, nahradí adresu odesilatele v datagramu domácí adresou z rozšiřující hlavičky. Jestliže platná vazba neexistuje, datagram s hlavičkou Domácí adresa se zahodí.
Z druhé strany se pak používá rozšiřující hlavička Směrování. Ta představuje obecnější mechanismus, kdy můžete datagramu předepsat průchod určitými body v síti. V každém z nich se vždy prohodí cílová adresa datagramu s další adresou uvedenou v hlavičce Směrování a jede se dál. Pro potřeby mobility byl definován jednodušší formát směrovací hlavičky. Obsahuje jen jedinou adresu. Při odeslání se jako cílová adresa datagramu uvede dočasná adresa mobilního uzlu a do hlavičky směrování se vloží jeho domácí adresa. Při příchodu do cíle se pak vymění, takže paket je zpracováván, jako by došel na domácí adresu uzlu.
Vedle těchto dvou byla ještě definována zcela nová rozšiřující hlavička Mobilita, která slouží především pro správu vazeb. Jejím prostřednictvím se zasílají aktualizace a potvrzení vazeb, údaje pro test dosažitelnosti a podobně.
Několik dalších doplňků bylo definováno do ICMP a objevování sousedů. Jejich cílem je především automatické objevování kandidátů pro domácí klienty a rychlejší orientace mobilního uzlu v dočasné síti.
Definice mobility v IPv6 rozhodně není nic jednoduchého. Příslušné RFC 3775 měří zhruba 350 KB, a to ještě byly detaily použití IPsec pro komunikaci mezi mobilním uzlem a domácím agentem vystrčeny do samostatného RFC 3776 o délce blížící se 100 KB textu. Ovšem podstatné je, že konečně leží na stole její finální podoba a může vypuknout implementace. Dlouhodobě nejdál je v této oblasti japonský projekt Kame pro BSD. Pro ostatní platformy lze jen doufat, že se v dohledné době polepší.
Domníváte se, že předložené RFC urychlí zavádění IPv6?
