Případová studie podpory mobility u IPv6

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Případová studie podpory mobility u IPv6 Bakalářská práce Vedoucí práce: Ing. Jiří Balej Jakub Stratil Brno 2015

2 Děkuji především vedoucímu práce Ing. Jiřímu Balejovi za vstřícnost, odborné vedení a cenné rady při vypracovávání této bakalářské práce. Děkuji také Mendelově univerzitě v Brně za poskytnutí zařízení potřebných k vypracování této práce.

3 Čestné prohlášení Prohlašuji, že jsem tuto práci: Případová studie podpory mobility u IPv6 vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne

4 4 Abstract Stratil, J. Case study of IPv6 mobility support. Bachelor thesis. Brno, 2015 This thesis includes information about important properties and functions of the IPv6 protocol with the main focus on the mobility mechanism. Practical part consist of network topology design and implementation, testing IPv6 mobility configuration on actual devices in laboratory enviroment. Key words: IPv6, IPv6 Mobility, MIPv6, IPsec, RFC 6275, UMIP, Linux, Debian, Cisco, Computer Network Abstrakt Stratil, J. Případová studie podpory mobility u IPv6. Bakalářská práce. Brno, 2015 Práce obsahuje souhrn důležitých informací o vlastnostech a fungování protokolu IPv6, se zaměřením na mechanismus mobility. Praktická část práce se věnuje návrhu a implementaci síťové topologie pro testování různých konfigurací mobility IPv6 na fyzických zařízeních v laboratorním prostředí. Klíčová slova: IPv6, Mobilita IPv6, MIPv6, IPsec, RFC 6275, UMIP, Linux, Debian, Cisco, Počítačová síť

5 OBSAH 5 Obsah 1 Úvod a cíl práce Úvod práce Cíl práce Metodika Vlastnosti protokolu IPv Vývoj Adresy Podoba a zápis adresy Prefix Formát datagramu ICMPv Objevování sousedů Automatická konfigurace DHCPv Bezstavová konfigurace Směrování Statický routing RIPng OSPFv IS-IS BGP DNS Dopředné dotazy (AAAA) Zpětné dotazy (PTR) IPsec Režimy ochrany Bezpečnostní asociace a databáze bezpečnostní politiky Mobilita Základní princip Adresy Domácí agent Optimalizace cesty Hlavičky a volby Aktualizace vazby Potvrzení vazby Získání domácího agenta Hledání potenciálních agentů Dohoda s agentem Změny adres v domácí síti

6 OBSAH Optimalizace cesty Zahájení komunikace Odpověď partnera Aktualizace vazby Seznam aktualizací vazby Cache vazeb Změny a návrat domů Návrat domů Rozšíření mobility Rychlé předání Hierarchická mobilita Proxy Mobilita Mobilní sítě (NEMO) Rešerše prací zabývajících se nasazením mobility IPv Certifikace IPv6 u programů a zařízení Analýza handoveru v mobile IPv Nové trendy v oblasti mobility v datových sítích Podpora mobility IPv6 u síťových a koncových zařízení IPv6 Ready Logo Program Operační systémy Směrovače Případová studie nasazení mobility IPv Topologie síťové infrastruktury Použitá konfigurace Konfigurace zařízení Příprava operačního systému Domácí agent Mobilní uzel Korespondenční uzel Konfigurace rozhraní Spuštění procesů mobility Domácí síť Obousměrný tunel Přechod z domácí sítě do sítě cizí Přechod mezi cizími sítěmi Návrat do domácí sítě Optimalizace cesty Přechod z domácí sítě do sítě cizí Přechod mezi cizími sítěmi Návrat do domácí sítě

7 OBSAH 7 7 Finanční zhodnocení 51 8 Závěr 52 9 Reference 53

8 1 ÚVOD A CÍL PRÁCE 8 1 Úvod a cíl práce 1.1 Úvod práce Internetový protokol verze 6 (dále už jen IPv6), byl vyvinut v roce 1994 jako náhrada za IPv4. Hlavním motivem bylo vyčerpání centrálních zásob adres, ale také vylepšení vlastností protokolu, vzhledem k vývoji internetu, jako takového. Problém s nedostatkem adres byl nakonec oddálen za pomocí vícero metod, především mechanismem NAT (Network Address Translation) a využitím beztřídního adresování CIDR (Classless Inter-Domain Routing) (Satrapa, 2011). V současnosti už jsou pro většinu světových regionů centrální zásoby vyčerpány 1 (IANA, 2014). Dá se předpokládat, že i po vyčerpání všech zásob bude přesun na nový protokol postupný a protokoly budou existovat, s větším či menším podílem, současně několik let. Přesto je vhodné, aby se funkčnost nového protokolu testovala, neustále vylepšovala a aby se budoucí uživatelé s protokolem včas seznámili. Mnoho mechanismů nového protokolu se v IPv4 nevyskytuje nebo se v praxi zatím nepoužívají. Jedním z nich je i mechanismus mobility, který sice je definován v RFC 5944 (Perkins, 2010) i pro IPv4, ale využívá se výjimečně. Podpora mobilních zařízení je v IPv6 velmi promyšlená a měla by hrát roli jednoho z významných trumfů při prosazování tohoto protokolu do praxe. Mobilní telefony, mobilní počítače a přenosná či pojízdná zařízení všeho druhu jsou v současnosti velmi rozšířená a dá se předpokládat, že budou i nadále přibývat. Vzhledem k možnostem těchto zařízení a potřebám uživatelů je stálé připojení k internetu nutností. Bohužel, i přes užitečnost a potenciál mobility, není její využití v praxi dostatečně otestováno. Jednou z příčin je mimořádně dlouhý vznik její specifikace. První verze specifikace RFC 3775: Mobility Support in IPv6 (Johnson, et al., 2004) vyšla až v polovině roku Specifikace byla aktualizována v RFC 6275 (Perkins, et al., 2011), došlo ale jen ke drobným změnám. (Satrapa, 2011) 1.2 Cíl práce Cílem této bakalářské práce je popsat základní vlastnost a fungování IPv6, podrobněji se pak zaměřit na mechanismus mobility. Zjistit v jakém stavu se mobilita nachází a otestovat využitelnost v praxi na fyzických zařízeních. 1.3 Metodika První část rozebírá základní problematiku IPv6, se zaměřením na mobilitu. V praktické částí je zpracován návrh a implementace infrastruktury sítě, pro testování moblity v IPv6. Pomocí dokumentace dostupné na umip.org (umip.org, 2013) byly nastaveny jednotlivé prvky topologie (domácí agent, mobilní uzel, korespondenční 1 V praxi to znamená, že adresy jsou přidělené konkrétním organizacím, společnostem a mimo jiné také poskytovatelům internetu, kteří mohou mít ještě tisíce volných adres v zásobě.

9 1.3 Metodika 9 uzel) a následně otestovány možné způsoby komunikace, tedy obousměrný tunel a optimalizace cesty. Na navržené topologii jsou postupně testovány přechody mobilního uzlu mezi sítěmi. Monitoruje se jak dlouho trvá přechod, jestli si mobilní uzel udrží spojení při průběžném zasílání dat, případně jaké množství datových paketů při přechodu ztrácí. Výstupem jsou zprávy generované procesem (daemonem) mobility, informující o průběhu přechodu a přehled síťové komunikace mezi prvky.

10 2 VLASTNOSTI PROTOKOLU IPV Vlastnosti protokolu IPv6 2.1 Vývoj Hlavní požadavky od počátku vývoje IPv6 (Satrapa, 2011): rozsáhlý adresní prostor, který vystačí pokud možno navždy tři druhy adres: individuální (unicast), skupinové (multicast) a výběrové (anycast) jednotné adresní schéma pro Internet i vnitřní sítě hierarchické směrování v souladu s hierarchickou adresací zvýšení bezpečnosti (zahrnout do IPv6 mechanismy pro šifrování, autentizaci a sledování cesty k odesilateli) podpora pro služby se zajištěnou kvalitou optimalizace pro vysokorychlostní směrování automatická konfigurace (pokud možno plug and play) podpora mobility (přenosné počítače apod.) hladký a plynulý přechod z IPv4 na IPv6 Adresní prostor IPv6 je dlouhý 128 bitů, oproti 32 bitům IPv4 (Deering, Hinden, 1998). Prakticky to znamená, že pro každého člověka planety je k dispozici několik miliard adres. Každé koncové zařízení má svoji unikátní veřejnou adresu, není proto ani třeba mechanismů jako NAT a CIDR. 2.2 Adresy Délka adresy IPv6 je 128 bitů. Adresy jsou přiřazovány síťovému rozhraní, ne samotnému zařízení. Existují tři druhy adres s odlišným chováním (Graziani, 2013): Individuální (Unicast) identifikuje jedno síťové rozhraní, paket je doručen na konkrétní adresu. Rozhraní může mít více IPv6 adres a zároveň i více IPv4 adres. Výběrové (Anycast) je Individuální adresa přidělená několika zařízením. Datový paket se ale doručí jen jednomu ze zařízení a to tomu, které je nejblíže. Skupinové (Multicast) slouží pro adresování skupin zařízení. Datový paket poslaný na skupinovou adresu je zpracovaný každým zařízením v této skupině. Oproti IPv4 zmizely všesměrové (broadcast) adresy, jejich funkci přebraly adresy skupinové (multicast). IPv6 umožňuje, aby rozhraní mělo libovolný počet adres různých druhů.

11 2.2 Adresy 11 Typy individuálních (unicast) adres (Satrapa, 2011): Globální individuální adresy (Global unicast) představují protipól adres současného IPv4. Identifikují svého nositele v rámci celého Internetu a musí tudíž být celosvětově jednoznačné. Jedno rozhraní může mít několik globálních adres. Strukturu znázorňuje obr. 1. Obrázek 1: Obvyklá struktura globální individuální adresy (Satrapa, 2011) Lokální linkové adresy (Link-local unicast) si rozhraní vytváří sami pomocí nástrojů automatické konfigurace. Začínají prefixem fe80::/10, následujících 54 bitů je nulových a za nimi je 64bitový identifikátor rozhraní, automaticky generovaný na základě MAC adresy. Dosah lokálních linkových adres je pouze na linkové úrovni a nemohou proto sloužit ke směrování. Unikátní individuální lokální adresy (Unique local unicast) začínají prefixem fd00::/8. Tento typ adres nahrazuje lokální místní adresy (site local) a jsou použitelné pouze v lokální síti. Nedefinovaná adresa (Unspecified address) ::/128, může být použita pouze jako zdrojová adresa. Značí, že rozhraní nemá IPv6 adresu. Lokální smyčka (Loopback address) ::1/128, není přidělená fyzickému rozhraní. Zařízení může na tuto adresu poslat paket sobě samému. Podoba a zápis adresy Adresy se zapisují v šestnáctkové soustavě. Adresa je rozdělená do osmi skupin (každá 16 bitů) po čtyřech číslech, oddělenými dvojtečkami (IPv6.cz, 2012): 2001:0db8:ffff:0000:2510:cea8:60cf:1000 V každé čtveřici můžeme vynechat počáteční nuly, místo :0000: můžeme zapsat pouze jednu nulu :0:. Více skupin nul bezprostředně za sebou, můžeme nahradit ::, ale pouze pro jeden sled. 2001:0db8:ffff:0000:0000:f32c:0000: :0db8:ffff:0000:0000:0000:0000:1000 můžeme zkrátit na

12 2.3 Formát datagramu 12 nebo nejvíce na 2001:db8:ffff:0:0:f32c:0: :db8:ffff:0:0:0:0: :db8:ffff::f32c:0: :db8:ffff::1000 Poslední tvar splňuje kanonický zápis pro výstupy aplikací 2. Prefix Příslušnost k podsíti se definuje prefixem: 2001:db8:ffff::1000/64 Prvních 64 bitů adresy určuje podsíť, tudíž budou v rámci této podsítě u všech rozhraní stejné. Spodních 64 bitů pak identifikuje konkrétní rozhraní. 2.3 Formát datagramu Datagram (viz obr. 2) začíná libovolným počtem hlaviček, za kterými následují obsahová data. IPv6 minimalizuje základní hlavičku, omezilo její prvky jen na ty nejnutnější a má, na rozdíl od IPv4, konstantní velikost (40 B). Veškeré doplňující a nepovinné informace se nacházejí v následujících hlavičkách, které mohou a nemusí být přítomny. (Satrapa, 2011) Obrázek 2: Formát IPv6 datagramu. (Satrapa, 2011) Definice jednotlivých částí základní hlavičky (Graziani, 2013): 2 Pouze malá písmena, maximální krácení, :: nahrazuje nejdelší možný sled, případně první. Sled nenahrazujeme v případě pouze jedné nulové čtveřice.

13 2.4 ICMPv6 13 Verze (4 bity) identifikuje verzi protokolu, pro IPv6 obsahuje vždy hodnotu 6. Třída provozu (8 bitů) identifikuje a vyjadřuje prioritu datagramu nebo zařazení do určité přepravní třídy. Značka toku (20 bitů) slouží k zařazení všech paketů se stejnými vlastnostmi do stejného proudu, který pak směrovač jednotně zpracuje. Použití značky toku je popsáno v RFC 6437 (Amante, et al., 2011). Délka dat (16 bitů) udává délku datagramu. Základní hlavička se do údaje nepočítá, rozšiřující již ano. Maximální délka datagramu je 64 KB. Pro delší datagram je možno využít rozšiřující hlavičku Jumbo obsah 3 Další hlavička (8 bitů) identifikuje následující hlavičku. Zřetězení hlaviček umožňuje libovolný počet rozšiřujících hlaviček. Poslední hlavička pak odkazuje na datovou složku datagramu (viz obr. 3). 4 Max. skoků (8 bitů) ekvivalent TTL (Time to live), každý průchod směrovačem sníží hodnotu o 1. Brání zacyklení. Zdrojová adresa (128 bitů) je 128 bitů dlouhá IP adresa původce paketu. Zdrojová adresa musí být unicast. Cílová adresa (128 bitů) je 128 bitů dlouhá IP adresa příjemce paketu. Cílová adresa může být unicast nebo multicast. Obrázek 3: Příklad zřetězení datagramů. (Satrapa, 2011) 2.4 ICMPv6 Internet Control Message Protocol (ICMP) je režijním protokolem Internetu. Slouží k ohlašování chybových stavů, testování dosažitelnosti a všeobecně k výměně některých provozních informací. Jeho implementace je povinná v každém zařízení podporujícím IP. Ve verzi pro IPv6 pak definuje typy zpráv pro komponenty IPv6 objevování sousedů, podpora skupinových adres a další (viz obr. 5). (Satrapa, 2011) Definice jednotlivých částí ICMPv6 (viz obr. 4) (Graziani, 2013): 3 Až 4 GiB, délka větší jak 64 KB ale způsobuje komplikace. 4 Samotná základní hlavička může být poslední.

14 2.5 Objevování sousedů 14 Obrázek 4: Formát ICMP zprávy (Satrapa, 2011) Typ (8 bitů) indikuje typ ICMPv6 zprávy. 5 Kód (8 bitů) rozšiřuje identifikaci typu naznačení konkrétního důvodu. Kontrolní součet (16 bitů) slouží k odhalení korupce dat. Obrázek 5: Některé typy ICMP zpráv (Satrapa, 2011) 2.5 Objevování sousedů Mechanismus objevování sousedů (Neighbour Discovery) plní funkci ARP (Adress Resolution Protocol), používaného u IPv4 a přidává některé další funkce. Je definován jako základní součást IP a slouží k následujícím účelům (Narten, et al., 2007): zjišťování linkových adres uzlů v lokální síti a parametrů této linky zjištění parametrů pro bezstavovou autokonfiguraci uzlu objevování sousedních směrovačů, umožňujících přesměrování paketů ověřování dosažitelnosti sousedů kontrola duplicity a změn linkových adres, rychlé odstranění neplatných údajů a aktualizace automatické hledání nejlepších a alternativních cest Pro svou činnost využívá pět typů ICMP zpráv (Narten, et al., 2007): 5 Chyby: Informační zprávy:

15 2.6 Automatická konfigurace 15 Výzvou směrovači (Router Solicitation) může uzel zažádat směrovač o generování Ohlášení směrovače. Ohlášení směrovače (Router Advertisement) posílá směrovač v náhodných intervalech nebo v reakci na Výzvu směrovači. Oznamuje síťové parametry a slouží pro automatickou konfiguraci. Výzva sousedovi (Neighbour Solicitation) ověřuje dosažitelnost souseda uloženou adresou, zjištění linkové adresy souseda, detekce duplicit. Ohlášení souseda (Neighbour Advertisement) je odpovědí na Výzvu sousedovi. Případně samovolné ohlášení změny linkové adresy. Přesměrování (Redirect) používají směrovače k informování uzlů o lepší směrovací cestě. 2.6 Automatická konfigurace Protokol IPv6 je již od začátku vyvíjen tak, aby usnadnil práci s konfigurací síťového rozhraní. Pomocí těchto mechanismů se zařízení, po připojení do sítě, snaží automaticky nastavit všechny potřebné parametry síťového rozhraní. DHCPv6 Server pomocí Dynamic Host Configuration Protocolu (DHCP) připojenému zařízení přiřadí potřebné údaje pro síťový provoz (IP adresu, masku podsítě, adresu DNS serveru) 6. Získání parametrů prostřednictvím DHCP, které ilustruje obr. 6, má čtyři fáze (Satrapa, 2011): 1. Objevování (discover): Klient pošle dotaz na servery o přiřazení parametrů Nabídka (offer): Servery, k nimž se dotaz dostane, nahlédnou do svých tabulek, zda pro tohoto klienta mají nějaké použitelné parametry. 8 Nabídku pak pošlou klientovi. 3. Požadavek (request): Klient vybere z nabídek nejvhodnější a příslušnému serveru pošle požadavek, v němž žádá o přidělení nabídnutých parametrů. 4. Potvrzení (acknowledge): Server potvrdí, že žádosti vyhověl. Přidělení parametrů je však pouze dočasné, po vypršení platnosti musí klient požádat o prodloužení nebo získat zcela nové parametry. 6 DHCPv6 nepřiděluje implicitní směrovač (default gateway) pro odchozí provoz 7 Na standardní skupinové adresy: DHCP agenti a servery ff02::1:2, DHCP servery ff05::1:3 8 Při přidělování adresy server bere v úvahu především linku (fyzickou síť), ke které je klient připojen, a DUID klienta.

16 2.7 Směrování 16 Obrázek 6: Získání parametrů přes DHCPv6. (IPv6.cz, 2012) Významnou roli v DHCP hraje otázka identifikace jak serverů, tak především klientů. Dříve se k tomuto účelu používala ethernetová adresa, DHCPv6 však zavádí pojem DHCP Unique Identifier (DUID). Jedná se o jednoznačný identifikátor účastníka DHCP života. Právě jeden DUID má každý klient i server. (Satrapa, 2011) Bezstavová konfigurace Nosným pilířem bezstavové konfigurace je Ohlášení směrovače (Router advertisement). Směrovač je posílá do všech sítí, k nimž je připojen. Z ohlášení směrovačů se počítač dozví, jaké adresy používá zdejší síť. K nim si doplní identifikátor rozhraní který si jednoznačně vygeneruje ze své MAC adresy. Tak získá platné IPv6 adresy pro své rozhraní. Jejich jednoznačnost ověří pomocí detekce duplicit. V rámci bezstavové konfigurace si stroj také vytvoří základ směrovací tabulky, tj. seznam implicitních směrovačů, kterými bude předávat pakety směřující mimo síť. Pokud je jich více, střídá je a směrovací tabulku si postupně vylepšuje na základě jejich upozornění (přesměrování). (IPv6.cz, 2012) Hlavní nevýhodou bezstavové automatické konfigurace je velmi omezený sortiment informací, které lze jejím prostřednictvím získat. Proto obsahuje bezstavová konfigurace možnost, jak doplnit další informace jiným (stavovým) způsobem. Ohlášení směrovače obsahuje dvojici příznaků, viz Tab. 1, které definují konfiguraci. (Satrapa, 2011) 2.7 Směrování Princip a systém směrování se od IPv4 nijak významně neliší, zařízení ukládá směrovací informace do směrovací tabulky. Koncová zařízení naplní směrovací tabulku automaticky při prvotní konfiguraci po připojení do sítě, případně se dá upravit manuálně (staticky).

17 2.7 Směrování 17 Tabulka 1: Význam příznaků při bezstavové konfiguraci. (Satrapa, 2011) M O význam 1 - DHCPv6 poskytne vše 0 1 kombinovat bezstavovou konfiguraci (pro adresu, prefix a směrování) s DHCPv6 (pro ostatní parametry) 0 0 DHCPv6 není k dispozici Směrovače mají tabulky často rozsáhlé a i když je můžeme konfigurovat staticky, obvykle se využije některý z dynamických směrovacích protokolů. Statický routing Konkrétní směrovací adrese přiřadíme cílovou adresu s libovolně dlouhým prefixem. Pro nedefinované adresy se využije implicitní nulová adresa ::/128. Příklad typické směrovací tabulky zařízení napojeného na jeden směrovač, lze vidět na obr. 7. Přístup ze/do sítě je zprostředkován přes adresu směrovače fe80::21b:8fff:feff:ff. Obrázek 7: Příklad směrovací tabulky koncového počítače (Satrapa, 2011) RIPng Routing Information Protocol (RIP) next generation je dynamický směrovací protokol vhodný pro malé a jednoduché sítě. Jedná se o protokol založený na vektoru vzdáleností. Linky a sítě, propojující jednotlivé směrovače, mají přiřazenu určitou cenu - počet skoků (hop count). Má-li datagram projít určitou cestou, určí se její celková cena součtem cen linek, z nichž se skládá. RIPng se snaží, aby datagramy k danému cíli vždy dorazily cestou s nejmenší celkovou cenou 9. Směrovače si se svými sousedy každých 30 sekund vyměňují příslušné informace a ceny cest aktualizují. (Satrapa, 2011) 9 Maximální počet skoků je 15.

18 2.8 DNS 18 OSPFv3 Open Shortest Path First (OSPF) version 3 je podstatně výkonnější, ale také složitější dynamický protokol. Každý směrovač si v něm udržuje mapy sítě, z níž vypočítává optimální cesty k jednotlivým cílům. Každou změnu v topologii si směrovače okamžitě ohlašují, aby jejich mapy byly stále aktuální. OSPF umožňuje rozdělit velkou síť na oblasti a směrovat hierarchicky. (IPv6.cz, 2012) Základními výhodami OSPF je velmi rychlá reakce na změny a schopnost zajistit směrování i v poměrně rozsáhlých sítích. (Satrapa, 2011) IS-IS Protokol Intermediate System to Intermediate System (IS-IS) posloužil jako inspirace pro OSPF. Má proto podobné základní vlastnosti. Také zde si směrovače udržují aktuální mapy sítě, kterou lze rozdělit na oblasti a směrovat hierarchicky. Hlavní výhodou protokolu je schopnost směrovat IPv4 i IPv6 současně. (IPv6.cz, 2012) BGP4+ Border Gateway Protocol (BGP) patří mezi externí směrovací protokoly, jejichž prostřednictvím se vyměňují směrovací informace mezi různými autonomními systémy (nicméně jej lze použít i uvnitř jednoho AS). (Satrapa, 2011) V současné době je nutnou součástí komunikace sítí přes internet. Verze plus umožňuje směrování prakticky libovolného protokolu síťové vrstvy, včetně IPv6. (Satrapa, 2011) 2.8 DNS Domain Name System (DNS) umožňuje používat místo IP adres symbolická jména počítačů, uspořádaná do hierarchické struktury. Jeho dvě nejzákladnější funkce jsou převod jména na IP adresu a naopak převod IP adresy na odpovídající jméno. Vzhledem k délce IPv6 adres je role DNS velmi významná a nutná. (Satrapa, 2011) DNS na IPv6 podporuje např. BIND (Berkeley Internet Name Domain) od verze 9. Dopředné dotazy (AAAA) Pro dopředné dotazy, tj. zjištění adresy k určitému jménu, využíváme typ záznamů nazvaný AAAA. V IPv4 se pro tyto záznamy používá typ záznamu A, podle čtyřnásobné délky adresy IPv6 oproti IPv4 tedy AAAA. Má-li počítač pc.kdesi.cz adresu 2001:db8:89ab:1:123:45ff:fe67:89ab, bude v zónovém souboru 10 pro doménu kdesi.cz obsažen záznam (Satrapa, 2011): pc AAAA 2001:db8:89ab:1:123:45ff:fe67:89ab 10 Zónový soubor obsahuje definici dané domény.

19 2.9 IPsec 19 Zpětné dotazy (PTR) Zpětný dotaz vychází ze známé IPv6 adresy a snaží se k ní získat jméno. Dotaz je položen prostřednictvím doménového jména sestaveného tak, že se obrátí pořadí šestnáctkových číslic v adrese a na konec se připojí doména ip6.arpa. Adresa musí být kompletní, včetně všech nul. Pro adresu 2001:db8:89ab:1:123:45ff:fe67:89ab by reverzní dotaz měl tedy tvar (Satrapa, 2011): b.a e.f.f.f b.a b.d ip6.arpa Díky obrácenému pořadí číslic se obecná část adresy (prefix) dostává na konec a lze tedy realizovat distribuovanou správu reverzních domén. Například síť instituce vlastnící doménu kdesi.cz má prefix 2001:db8:89ab::/48 a tudíž dostane do správy reverzní doménu b.a b.d ip6.arpa. Pro počítač pc.kdesi.cz by její zónový soubor obsahoval záznam (Satrapa, 2011): b.a e.f.f.f PTR pc.kdesi.cz. 2.9 IPsec IPsec poskytuje bezpečnostní prvky přímo na úrovni IP. Pro uživatele či aplikace nabízí IPsec dvě základní služby: autentizaci a šifrování. Vlastní realizace bezpečnostních služeb spočívá na dvou rozšiřujících hlavičkách: AH (Authentication Header) a ESP (Encapsulating Security Payload). První hlavička má na starosti autentizaci datagramu, tedy především ověření pravosti jeho adres a obsahu. Druhá hlavička umí zajistit podobné služby, navíc k nim přidává možnost zašifrovat obsah. Datagram může být opatřen jednou či oběma bezpečnostními hlavičkami v závislosti na požadovaném zabezpečení. (Satrapa, 2011) Vývoj bezpečnostních prvků IPv6 se postupně odklání od AH ve prospěch ESP. Odráží se to i ve skutečnosti, že požadavek na podporu ESP v implementacích je přísnější. (IPv6.cz, 2012) Režimy ochrany Bezpečnostní hlavičky lze doplňovat ve dvou režimech (viz obr. 8). V transportním režimu se vkládají přímo jako součást datagramu mezi jeho rozšiřující hlavičky. V tunelujícím režimu se celý stávající datagram zabalí jako data do nového datagramu, který opatří novými hlavičkami, včetně bezpečnostních. (Satrapa, 2011) Bezpečnostní asociace a databáze bezpečnostní politiky Základní datovou strukturou bezpečnostního modelu je databáze bezpečnostní politiky (security policy database, SPD). Je to sada pravidel určujících, které datagramy

20 2.9 IPsec 20 Obrázek 8: Režimy IPsec (Satrapa, 2011) mají být podrobeny jakým bezpečnostním procedurám. Z nich vedou odkazy na bezpečnostní asociace (security association, SA). Taková asociace existuje pro každé zabezpečené spojení, které počítač navázal, a obsahuje konkrétní data způsob zabezpečení, šifrovací algoritmus, klíče a podobně. Bezpečnostní asociace je jednosměrná. Komunikující stroje je proto obvykle navazují po párech, po jedné pro každý směr komunikace. (IPv6.cz, 2012) 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í (IPv6.cz, 2012): 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)

21 3 MOBILITA 21 3 Mobilita 3.1 Základní princip Adresy Každé zařízení má nějakou domácí síť, ve které mu je přidělena domácí adresa (Home Address, HA). Předpokládá se, že zařízení mobilní uzel (Mobile Node, MN) bude vždy dostupný na své domácí adrese. Když se uzel nachází v domácí síti, směrování probíhá klasickým způsobem. (Perkins, et al., 2011) Ve chvílích, kdy se mobilní uzel nachází v cizích sítích, mu jsou přidělovány dočasné adresy (Care-of Address, CoA). Dočasné adresy jsou nastaveny obvyklými způsoby (stavová/bezstavová autokonfigurace) s prefixem dané sítě. Uzel může být dosažitelný i na několika dočasných adresách zároveň, pokud se dosah sítí překrývá. (Perkins, et al., 2011) Vztah mezi domácí a aktuální adresou mobilního uzlu se nazývá vazba (Binding). (Satrapa, 2011) Domácí agent Aby byl mobilní uzel dosažitelný na domácí adrese i v sítích cizích, ustaví si v domácí síti domácího agenta (Home Agent, HA). Jedná se o jeden ze směrovačů v domácí síti, který na sebe stahuje datagramy směřující k mobilnímu uzlu a předává mu je tunelem (viz obr. 9). Jakmile mobilnímu uzlu dorazí tunelovaný datagram od domácího agenta, dozví se z něj, že se jej někdo pokoušel kontaktovat na domácí adrese. (Satrapa, 2011) Obrázek 9: Navázání spojení s mobilním uzlem (Satrapa, 2011)

22 3.2 Hlavičky a volby 22 Optimalizace cesty Pokud korespondenční uzly aktivně podporují mobilitu, mohou navázat vazbu s mobilním uzlem a komunikovat s ním přímo přes jeho dočasnou adresu 11. Tento způsob komunikace se nazývá optimalizace cesty (Route Optimization, RO) (viz bod 3 na obrázku 9). (Satrapa, 2011) 3.2 Hlavičky a volby RFC 3775 (Johnson, et al., 2004) zavedlo novou hlavičku Mobilita, definuje nový typ hlavičky Směrování a novou volbu pro příjemce Domácí adresa. K některým dalším účelům využívá protokol ICMP, jemuž doplňuje čtyři nové typy zpráv a rozšiřuje ohlášení směrovače (viz obr. 10). (Satrapa, 2011) Rozšiřující hlavičku mobility využívají mobilní uzly, korespondenti a domácí agenti při veškeré komunikaci týkající se vytváření a správy vazeb (Perkins, et al., 2011). Přehled zpráv pro tuto hlavičku lze vidět na obrázku 11. Následuje podrobnější vysvětlení hlaviček číslo 5 a 6. Obrázek 10: Přehled zpráv pro podporu mobility (Satrapa, 2011) Obrázek 11: Typy zpráv pro hlavičku Mobilita (Satrapa, 2011) Aktualizace vazby Základní funkcí aktualizace vazby (Binding Update, BU) je oznámit aktuální adresu mobilního uzlu buď korespondentovi nebo domácímu agentovi. Aktualizaci vazby si lze také vyžádat prostřednictvím zprávy Žádost o obnovení vazby (Binding Refresh Request, BRR). Po této možnosti sáhne partner mobilního uzlu, když se platnost vazby blíží svému konci, ale komunikace dosud probíhá. (Satrapa, 2011) 11 Protokoly vyšších vrstev vždy používají domácí adresu. Z jejich pohledu je mobilita zcela transparentní a o nějakých dočasných adresách se nikdy nedozvědí.

23 3.3 Získání domácího agenta 23 Potvrzení vazby Jako reakce na aktualizaci vazby slouží potvrzení vazby (Binding Acknowledgement, BA). Nejvýznamnější položkou je stav (Status). Obsahuje informaci o tom, zda aktualizace byla akceptována či nikoli. (Satrapa, 2011) Hodnoty častých stavů ukazuje obr. 12. Obrázek 12: Hodnoty položky Stav (Satrapa, 2011) 3.3 Získání domácího agenta Domácího agenta můžeme mobilnímu uzlu přidělit a udržovat buď staticky (obr. 13) nebo využít dynamické objevování adresy domácího agenta (Dynamic Home Agent Address Discovery) (obr. 14). (Satrapa, 2011) Získání domácího agenta probíhá ve dvou fázích. V první fázy se mobilní uzel dozví adresy všech potenciálních domácích agentů a ve druhé se domluví s jedním z nich, že pro něj bude tuto funkci skutečně vykonávat. (Satrapa, 2011) Hledání potenciálních agentů Mobilní uzel pošle ICMP zprávu Žádost o adresy domácích agentů (Home Agent Address Discovery Request). Tuto zprávu zašle na výběrovou (anycast) adresu domácích agentů v síti. (Perkins, et al., 2011) Každý domácí agent je povinen si udržovat datovou strukturu nazvanou Seznam domácích agentů (Home Agents List). V ní si na základě ohlášení ostatních udržuje přehled o všech domácích agentech na dané lince. Z těchto dat sestaví ICMP zprávu Odpověď na objevování adresy domácího agenta (Home Agent Address Discovery Reply), kterou pošle odesilateli žádosti. (Satrapa, 2011)

24 3.3 Získání domácího agenta 24 Dohoda s agentem Mobilní uzel ze seznamu potenciálních domácích agentů vybere uchazeče s nejvyšší prioritou a zašle mu aktualizaci vazby s nastaveným příznakem H 12. (Satrapa, 2011) Agent zkontroluje pomocí detekce duplicit, zda je zvolená domácí adresa volná 13. Když testy dopadnou dobře, zanese si mobilní uzel do svých datových struktur a pošle mu kladné potvrzení vazby. Jakmile se stane domácím agentem, rozešle do domácí sítě několik nevyžádaných ohlášení souseda, v nichž uvádí domácí IP adresu mobilního uzlu a svou vlastní linkovou adresu. Také bude od tohoto okamžiku odpovídat na výzvy sousedovi s IP adresou mobilního uzlu. Díky tomu budou datagramy adresované na domácí adresu mobilního uzlu předávány jemu. (Satrapa, 2011) Blíží-li se vypršení doby, po kterou domácí agent potvrdil své fungování, je na mobilním uzlu, aby zaslal další žádost o registraci primární adresy a pokusil se tak prodloužit svůj vztah s domácím agentem nebo vyhledal domácího agenta nového. (Satrapa, 2011) Registrace je chráněna pomocí IPsec, konkrétně ESP se zapnutou autentizací. (Satrapa, 2011) Obrázek 13: Statické přidělení domácího agenta Obrázek 14: Dynamické objevení domácího agenta Změny adres v domácí síti Pokud v domácí síti došlo ke změně adres, domácí agent zařadí do své domácí registrace neplatnou adresu. Domácí agent registraci sice potvrdí, ale použije v potvrzení 12 Tento krok se nazývá registrace primární (momentálně používané) dočasné adresy. 13 Má-li aktualizace vazby nastaven příznak L, provede totéž s lokální linkovou adresou odvozenou z identifikátoru rozhraní domácí adresy.

25 3.4 Optimalizace cesty 25 vazby stavový kód 1. Jím žádá mobilní uzel, aby si vyhledal prefixy. (Satrapa, 2011) 3.4 Optimalizace cesty Optimalizace přináší řadu výhod, např. snižuje zatížení domácího agenta a odezvu, ale přináší komplikaci z pohledu bezpečnosti. Vzhledem ke globálnímu charakteru v podstatě nelze zabezpečit komunikaci s korespondentem pomocí IPsec, protože celosvětová důvěryhodná distribuční síť klíčů, není reálným řešením. IPv6 ale má integrovanou metodou, jak ověřit, že mobilní uzel skutečně poslouchá na domácí i dočasné adrese, které uvedl v aktualizaci vazby. Nazývá se zpětná směrovatelnost (Return Routability, RR). (Satrapa, 2011) Zahájení komunikace Když se korespondent snaží navázat spojení s mobilním uzlem, neví o jeho mobilitě, a tak pošle datagram prvně na jeho domácí adresu. V domácí sítí datagram převezme domácí agent a pošle ho mobilnímu uzlu tunelem chráněným ESP. (Satrapa, 2011) Když mobilní uzel obdrží takto tunelovaný datagram, ví, že odesilatel netuší o jeho aktuální adrese. Proto se jej pokusí informovat a prokáže, že je ten pravý. (Satrapa, 2011) Pošle dva navzájem nezávislé datagramy: Zahájení testu domácí adresy (Home Test Init) (bod 1a na obr. 15) a Zahájení testu dočasné adresy (Care-of Test Init) (bod 1b na obr. 15). Každá z nich obsahuje jinou náhodnou hodnotu, pojmenovanou Cookie. Korespondent ji zkopíruje do své odpovědi, aby prokázal, že skutečně reaguje na zahájení testu vyvolané mobilním uzlem. Zahájení testu domácí adresy mobilní uzel pošle z domácí adresy tunelem domácímu agentovi, který je rozbalí a přepošle korespondentovi. Zahájení testu dočasné adresy naproti tomu obsahuje jako odesilatele dočasnou adresu mobilního uzlu a posílá se rovnou komunikačnímu partnerovi. (Satrapa, 2011) Odpověď partnera Partner na příchod obou zpráv reaguje odesláním speciální hodnoty, Tokenu. Když dorazí zpráva Zahájení testu domácí adresy, vybere zde domácí adresu, připojí k ní náhodně generovanou nonce hodnotu a konstantu 0 a to celé předloží hašovací funkci HMAC SHA1 se soukromým klíčem K. Prvních 64 bitů tvoří Token pro domácí adresu (Home Keygen Token). Počítač je zabalí do zprávy Test domácí adresy, přidá index použité unikátní hodnoty k položce Index domácí hodnoty (Home Nonce Index) a odešle na domácí adresu mobilního uzlu (bod 2a na obr. 15). Domácí agent předá zašifrovanou zprávu mobilnímu uzlu. (Satrapa, 2011) Druhý token korespondent vypočítá pomocí dočasné adresy, kterou dostal v Zahájení testu dočasné adresy. Token vzniklý z dočasné adresy, nonce hodnoty a konstanty 1, pošle společně s Indexem dočasné hodnoty (Care-of Nonce Index) ve zprávě

26 3.5 Cache vazeb 26 Obrázek 15: Autentizace mobilního uzlu při aktualizaci vazby (Satrapa, 2011) Test dočasné adresy na dočasnou adresu mobilního uzlu (bod 2b na obr. 15). (Satrapa, 2011) Aktualizace vazby Pokud je vše v pořádku a mobilní uzel obdrží oba tokeny, vypočítá z nich definovaným způsobem klíč pro aktualizaci vazby. Pomocí HMAC SHA1 s tímto klíčem vypočítá autentizační hodnotu (určitou formu digitálního podpisu) pro aktualizaci vazby. Zároveň přibalí volbu Indexy unikátních hodnot, aby protější uzel věděl, jaké náhodné hodnoty použít. Aktualizaci vazby pak pošle přímo korespondentovi (bod 3 na obr. 15), který si, po ověření hodnot, zaznamená dočasnou adresu a vazbu potvrdí (bod 4 na obr. 15). (Satrapa, 2011) Seznam aktualizací vazby Mobilní uzel si musí udržovat Seznam aktualizací vazby (Binding Update List, BUL), přehled o tom, komu všemu zaslal aktualizace vazby 14, jejichž životnost dosud nevypršela. (Satrapa, 2011) 3.5 Cache vazeb Cache vazeb (Binding Cache, BC) si udržuje každý domácí agent a korespondent. Obsahuje informace o navázaných vazbách. Uzel do ní přednostně nahlédne před každým odeslaným paketem. Každá položka obsahuje tyto údaje (Perkins, et al., 2011): 14 Pokud změní svou dočasnou adresu, měl by je o tom informovat.

27 3.6 Změny a návrat domů 27 domácí adresu mobilního uzlu, 15 odpovídající dočasnou adresu, zbývající dobu životnosti, příznak zda je položka domácí registrací (pouze u domácích agentů), maximální hodnotu pole Sekvenčního čísla (Sequence Number), informace o posledním použití položky (jestli při vypršení životnosti poslat Žádost o obnovení vazby). 3.6 Změny a návrat domů Mobilní uzel naslouchá ohlášení směrovačů, která k němu přicházejí. Z nich se dozví prefixy sítě, v níž se právě nachází, i seznam možných implicitních směrovačů. Na základě prefixu si vytvoří primární dočasnou adresu a tu zaregistruje u domácího agenta. Kromě ní může používat i další dočasné adresy s odlišnými prefixy, avšak jako primární může zaregistrovat vždy jen jednu. (Satrapa, 2011) Jakmile je implicitní směrovač nedosažitelný, mobilní uzel si z toho odvodí, že změnil aktuální síť. Podle ohlášení směrovačů si vybere nový implicitní směrovač a novou primární adresu. Tuto změnu ohlásí svému domácímu agentovi a všem strojům, se kterými v poslední době komunikoval. (Satrapa, 2011) Návrat domů Mobilní počítač jej objeví stejnou metodou, jako běžnou změnu aktuální adresy. Tentokrát však posílá žádost o zrušení vazby. Ta má podobu běžné Aktualizace vazby s nulovou životností 16. Tato informace se posílá domácímu agentovi i ostatním uzlům uvedeným v seznamu aktualizací. Kromě toho musí rozeslat několik ohlášení souseda, aby se opět chopil svých datagramů. (Satrapa, 2011) 3.7 Rozšíření mobility Rychlé předání Při přechodu mezi sítěmi může nastat krátké přerušení spojení v důsledku odezvy a konfigurace nového spojení. Toto přerušení by mohlo způsobit kompletní výpadek u některých operací. (Koodli, 2009) Protokol rychlého předání (FMIPv6) umožňuje mobilnímu uzlu, aby potřebné údaje dalšího přístupového bodu a podsítě detekoval ještě před tím, než dojde k samotnému přechodu. Tím redukuje potenciální dobu přerušení. (Koodli, 2009) Princip operace FMIPv6 je znázorněn na obrázku Zároveň slouží jako klíč pro hledání v cache vazeb. 16 Podle toho příjemce pozná, že záznam pro dotyčnou domácí adresu má odstranit z cache vazeb.

28 3.7 Rozšíření mobility 28 Obrázek 16: Rychlé předání (Satrapa, 2011) Hierarchická mobilita Definována v RFC 5380: Hierarchical Mobile IPv6 (HMIPv6) Mobility Management (Soliman, et al., 2008). Cílem je, aby mobilní uzel po celou dobu svého pobytu v určité síti (např. v síti jednoho mobilního operátora) používal stále stejnou dočasnou adresu a nezasílal tedy aktualizace vazby. Tato adresa je označována jako regionální dočasná adresa (Regional care-of address, RCoA). Mobilní uzel se při použití hierarchické mobility registruje dvakrát. Nejprve si u kotevního bodu mobility (Mobility Anchor Point, MAP) zaregistruje předávání datagramů z regionální adresy na aktuální dočasnou adresu. Následně pak u domácího agenta a všech korespondentů registruje vazbu mezi svou domácí adresou a regionální dočasnou adresou. (Satrapa, 2011) Princip operace ukazuje obr. 17. Obrázek 17: Hierarchická mobilita (Satrapa, 2011)

29 3.7 Rozšíření mobility 29 Proxy Mobilita Protokol poskytuje možnost mobility uzlům v sítí, bez potřeby jejich aktivní spolupráce. Mobilní entity v infrastruktuře sítě sledují pohyb mobilního uzlu a starají se o veškeré operace, včetně směrování. (Gundavelli, et al., 2008) Mobilní sítě (NEMO) Mobilní sít je část sítě nebo podsíť, která se může pohybovat a připojovat k libovolným bodům ve směrovací infrastruktuře. Tato mobilní síť je přístupná pouze skrz specifickou bránu mobilní směrovač (Mobile Router, MR). Mobilní směrovač je spojen tunelem s domácím agentem, kterým prochází veškerá komunikace s okolím. Mobilní směrovač je tedy zároveň standardní bránou. (Devarapalli, et al., 2005)

30 4 REŠERŠE PRACÍ ZABÝVAJÍCÍCH SE NASAZENÍM MOBILITY IPV Rešerše prací zabývajících se nasazením mobility IPv6 4.1 Certifikace IPv6 u programů a zařízení Bakalářská práce Certifikace IPv6 u programů a zařízení (Koutecký, 2011), se podrobně zaobírá problematikou certifikace. Po úvodním seznámení s tématem, jsou poskytnuty informace o organizaci IETF a třech významných certifikačních organizacích IPv6 Forum, DoD a NIST. Následuje přehled požadavků a doporučení od IETF, pro implementaci konkrétních funkcí. Práce se věnuje také profilům certifikačních organizací a požadavkům, které musí žadatel pro zisk certifikačního profilu splnit. V praktické částí práce, autor testuje základní podporu IPv6, a zda jsou splněny požadavky pro certifikaci: 1. u běžně používaných operačních systémů Windows a Linux, 2. u některých druhů běžně používaného aplikačního softwarů. Výstupem práce je tedy poskytnutí všech potřebných informací o certifikaci pro IPv6 a ukázka způsobu testování. 4.2 Analýza handoveru v mobile IPv6 Diplomová práce Analýza handoveru v mobile IPv6 (Klügl, 2010), se zabývá problematikou přechodových mechanismů mobility IPv6. Úvodní část práce se věnuje samotnému protokolu mobility IPv6 porovnává tento protokol s verzí pro IPv4 (mobilita IPv4), jsou zde podrobné informace o vlastnostech protokolu a vysvětleny základní mechanismy. Dále jsou poskytnuty podrobné informace o rozšiřujících přechodových mechanismech pro protokol mobility IPv6 rychlé předání (FMIPv6), hierarchická mobilita (HMIPv6) a kombinace rychlého předání a hierarchické mobility (F-HMIPv6). Významná část práce popisuje návrh analytické metody pro hodnocení a porovnání přechodových mechanismů. Metoda je následně aplikována na zmíněné přechodové mechanismy. Z výsledků autorova počítání se jeví jako celkově nejlepší a nejnadějnější protokol F-HMIPv Nové trendy v oblasti mobility v datových sítích Dizertační práce Nové trendy v oblasti mobility v datových sítích (Skořepa, 2014), pojednává o problematice přechodů mobilních uzlů v sítích podporujících mobilitu IPv6, především v souvislosti s leteckou dopravou a s tím související komunikací např. se střediskem letového provozu. Výstupem práce je, kromě testování několika

31 4.3 Nové trendy v oblasti mobility v datových sítích 31 přechodových implementací, také vytvoření nového mechanismu přechodu, který by měl být lepší než mechanismy momentálně dostupné. Autor práce nejprve analyzuje a testuje způsoby přechodových mechanismů klasický, FMIPv6, HMIPv6 a F-HMIPv6. Způsoby přechodu testuje v simulačním prostředí na 200 mobilních uzlech. Jako nejlepší z testovaných vzešel způsob rychlého předání (FMIPv6). Tento způsob tedy použil jako základ pro tvorbu vlastního mechanismu Aeronautical Fast Mobile IPv6 (AFMIPv6). Nový mechanismus pak, podle autorova testování, přináší zlepšení okolo 10 23%, především v závislosti na parametrech linky.

32 5 PODPORA MOBILITY IPV6 U SÍŤOVÝCH A KONCOVÝCH ZAŘÍZENÍ 32 5 Podpora mobility IPv6 u síťových a koncových zařízení 5.1 IPv6 Ready Logo Program Je programem mezinárodního konsorcia IPv6 Forum (ipv6forum.com, 2015), který testuje dodržování jednotných podmínek a interoperabilitu hardwaru a softwaru pracujícího s IPv6. Účelem je zvýšení důvěry uživatelů v připravenost a použitelnost nového protokolu. (ipv6ready.org, 2015) Program je momentálně ve Fázi 2 (Zlaté). Pro získání tohoto loga musí produkt splňovat přísné požadavky stanovené výborem. (ipv6ready.org, 2015) Obrázek 18: IPv6 Ready Logo (ipv6ready.org, 2015) Udělování loga v souvislosti s Mobilitou IPv6 bylo zastaveno a označeno jako experimentální. (ipv6ready.org, 2015) 5.2 Operační systémy Linux Podpora mobility IPv6 je zabudována přímo v linuxovém kernelu od verze , bohužel ve verzích 3.* je až do verze nefunkční. 17 (umip.org, 2013) Podpora mobility nebo některé její funkce nemusí být v kernelu v základu povoleny a musí se před instalací povolit. Samotné použití mobility je pak usnadněno volně dostupnými softwarovými implementacemi. Za nejvíce relevantní a nejaktuálnější lze považovat implementace UMIP (umip.org, 2013) a mip6d-ng (mip6d-ng.net, 2015). To jakou roli 18 zařízení plní, pak závisí na konfiguraci. USAGI-patched Mobile IPv6 for Linux (UMIP) je otevřený software podpory mobility IPv6 a NEMO pro systémy Linux. (umip.org, 2013) Mobile IPv6 Daemon Next Generation (mip6d-ng) je novou implementací mobility IPv6 pro systémy Linux a Android. (mip6d-ng.net, 2015) Ostatní 17 Pro ostatní verze kernelu ať už 2.* nebo 3.* může existovat patch. 18 domácí agent/mobilní uzel/korespondent atd.

33 5.3 Směrovače 33 Přestože ostatní běžně používané operační systémy podporují IPv6, podpora mobility u nich není standardně implementovaná a informace o její případné podpoře nejdou dostupné Systém může případně pracovat jako korespondenční uzel, ovšem bez možnosti optimalizace cesty, která vyžaduje aktivní podporu mobility. 5.3 Směrovače Z tradičních výrobců síťových prvků, pouze směrovače od firmy Cisco přímo podporují mobilitu IPv6. Tabulka 2: Přehled podpory MIPv6 u zařízení Cisco (tools.cisco.com, 2015) Funkce Verze OS Platforma IPv6 ACL Extensions for Mobile IPv6 19 Mobile IPv6 HA phase 2 Proxy Mobile IPv6 support for MAG functionality IPv6 client support on Proxy Mobile IPv6 MAG Proxy Mobile IPv6 LMA NAT Traversal Support for Proxy Mobile IPv6 3.8S, 3.9S, 3.10S, 12.2, 12.4, 15.0, 15.1, 15.2, 15.3, , 15.0, 15.1, 15.2, 15.3, S, 3.5S, 3.6S, 3.7S, 3.8S, 3.9S, 3.10S, 3.11S, 3.12S, 3.13S, 3.14S, 15.2, S, 3.9S, 3.10S, 3.11S, 3.12S, 3.13S 3.6S, 3.7S, 3.8S, 3.10S, 3.12S, 3.13S, 3.14S 3.8S, 3.12S, 3.13S, 3.14S 17XX, 18XX, 19XX, 26XX, 28XX, 32XX, 3660, 3845, 5915, 7200, 7400, 7600, 8XX, AS5400, C8XX, CAT6000 IADXX, UC520, VG350, ISR4451-X a další 17XX, 18XX, 19XX, 26XX, 28XX, 32XX, 3660, 3845, 5915, 7200, 7400, 7600, 8XX, AS5400, C8XX, CAT6000, IADXX, UC520, VG350 a další ASR1000, ASR1001, ASR1002, ISR4321, ISR4331, ISR4351, ISR4431, ISR4451-X, 1941, 2901, 2911, 2921, 2951, 3945, 7200 CSR1000V, ISR4321, ISR4331, ISR4351, ISR4431, ISR4451-X ASR1000, ASR1001, ASR1002, ISR4321, ISR4331, ISR4351, ISR4431, ISR4451-X ASR1000, ASR1001, ASR1002 Všechny verze OS, platformy a další informace lze najít na: 19 Tato funkce povoluje IPv6 paket s hlavičkou specifickou pro mobilitu IPv6.

34 6 PŘÍPADOVÁ STUDIE NASAZENÍ MOBILITY IPV Případová studie nasazení mobility IPv6 Případovou studii jsem prováděl v síťové laboratoři Mendelovy univerzity v Brně s využitím zdejších zařízení. V průběhu studie jsem čerpal především z dokumentace dostupné na umip.org (umip.org, 2013) a částečně také z umip.linux-ipv6.org (umip.linux-ipv6.org, 2009). 6.1 Topologie síťové infrastruktury Obrázek 19: Topologie síťové infrastruktury

35 6.1 Topologie síťové infrastruktury 35 Ve výchozím stavu se mobilní uzel (MN) nachází v domácí síti 2001:db8:ffff::/64 a je spojen s domácím agentem (HA) přes ethernetové rozhraní. Má přidělenou domácí adresu 2001:db8:ffff::1. Dále jsou možné tři druhy přechoduvzhledem k tomu, že jsem neměl k dispozici vhodné zařízení s ethernetovým i bezdrátovým rozhraním, simuloval jsem bezdrátový přechod pomocí tří směrovačů s funkcí bezdrátového mostu. Mobilní uzel byl tedy vždy připojen přes rozhraní eth0.: 1. Mobilní uzel se přesune z domácí sítě, do sítě 2001:3::/64, kde se připojí k místnímu směrovači přes bezdrátové rozhraní. Pomocí autokonfigurace (v tomto případě způsobem EUI64) se mu automaticky přidělí dočasná adresa (CoA). 2. Mobilní uzel se přesune ze sítě 2001:3::/64 do sítě 2001:4::/64, kde se opět připojí k místnímu směrovači přes bezdrátové rozhraní. Dočasná adresa se přidělí stejným způsobem jako u předchozí sítě. 3. Mobilní uzel se z některé z cizích sítí přesune zpátky do sítě domácí, kde se znovu připojí k domácímu agentovi pomocí ethernetového rozhraní. Dočasná adresa je totožná s domácí adresou. Když se mobilní uzel nachází v domácí síti, prochází veškerá komunikace přes domácího agenta. To jak probíhá komunikace s mobilním uzlem v momentě, kdy se nachází v cizí síti, závisí na zvoleném způsobu: 1. Veškerá komunikace prochází přes domácího agenta, který pak vše posílá mobilnímu uzlu tunelem, zabezpečeným ESP. Na korespondenční uzel (CN) nejsou kladeny žádné nároky. 2. Komunikace probíhá způsobem optimalizace cesty. Korespondenční uzel musí aktivně podporovat mobilitu IPv6. Použitá konfigurace Domácí agent osobní počítač s operačním systémem Linux a několika síťovými kartami. Mobilní uzel osobní počítač s operačním systémem Linux. Jako bezdrátové rozhraní byl použit MikroTik RouterBoard 951n. Korespondenční uzel Bez optimalizace cesty osobní počítač s libovolným operačním systémem podporujícím IPv6. S optimalizací cesty osobní počítač s operačním systémem Linux. Směrovač Cisco Catalyst 3560 Layer 3 přepínač tvořící páteř topologie. Přepínač propojení domácí sítě.