Pokročilé komunikační techniky

Transkript

1 FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Pokročilé komunikační techniky Garant předmětu: Ing. Jan Jeřábek, Ph.D. Autoři textu: Ing. Jan Jeřábek, Ph.D. BRNO * 2012 Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/ Evropského sociálního fondu a státním rozpočtem České republiky.

2 2 FEKT Vysokého učení technického v Brně Autor Ing. Jan Jeřábek, Ph.D. Název Pokročilé komunikační techniky Vydavatel Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací Purkyňova 118, Brno Vydání první Rok vydání 2012 Náklad elektronicky ISBN Tato publikace neprošla redakční ani jazykovou úpravou

3 Pokročilé komunikační techniky 3 Obsah 1 ÚVOD ZAŘAZENÍ PŘEDMĚTU VE STUDIJNÍM PROGRAMU ÚVOD DO PŘEDMĚTU SÍŤOVÝ MODEL SADY TCP/IP A INTERNETU VAZBA MEZI RM OSI A MODELEM TCP/IP Vrstva síťového rozhraní (Network Interface Layer) Internetová vrstva (Internet Layer) Transportní vrstva (Transport Layer) Aplikační vrstva (Application Layer) FILOZOFIE VZÁJEMNÉHO PROPOJOVÁNÍ SÍTÍ POMOCÍ TCP/IP ORGANIZACE KOLEM INTERNETU ZÁKLADNÍ ZPŮSOBY KOMUNIKACE PŘEHLED PROTOKOLŮ PATŘÍCÍCH DO TCP/IP Protokoly aplikační vrstvy Protokoly transportní vrstvy Protokoly Internetové vrstvy Protokoly síťového rozhraní SOUBĚH APLIKACÍ V RÁMCI TCP/IP A ZAPOUZDŘOVÁNÍ SOFTWAROVÝ POHLED NA TCP/IP ÚLOHA SÍŤOVÉ (INTERNETOVÉ) VRSTVY S PROTOKOLEM IP (IPV4) IP adresy zápis, masky, třídy a speciální adresy Podstata směrování v sítích TCP/IP Podsíťové adresy IPv4 datagramy (pakety) Fragmentace a opětovné skládání IP paketů IP tunelování PROTOKOL ICMP PROTOKOLY TRANSPORTNÍ VRSTVY SADY TCP/IP User Datagram Protocol (UDP) Transmission Control Protocol (TCP) Adresování na základě portů, základní dělení portů Segmentace a znovu složení uživatelských dat RŮZNÉ ÚROVNĚ PŘEKLADU ADRES V IP SÍTÍCH Převod IP adres na fyzické adresy Dynamic Host Configuration Protocol (DHCP) Překlad síťových adres (Network Address Translation = NAT) Převod IP adres na jména - Domain Name System (DNS) Firewally PROTOKOLY ZÁLOHOVÁNÍ VÝCHOZÍ BRÁNY LOKÁLNÍ SÍTĚ Podstata problému Hot Standby Router Protocol Virtual Router Redundancy Protocol Gateway Load Balancing Protocol MULTICASTOVÝ PŘENOS DAT TYPY PŘENOSU... 66

4 4 FEKT Vysokého učení technického v Brně 4.2 VÝHODY A NEVÝHODY MULTICASTU ADRESOVÁNÍ MULTICASTU V SÍTÍCH IPV MULTICASTOVÉ PROTOKOLY Druhy multicastového přenosu Internet Group Management Protocol (IGMP) Směrování multicastu IP VERZE MOTIVACE ZAVÁDĚNÍ NOVÉHO PROTOKOLU ZÁKLADNÍ VLASTNOSTI IPV HISTORIE A SOUČASNOST IPV4 A IPV ZAVÁDĚNÍ IPV IPV6 DATAGRAMY (PAKETY) ROZŠIŘUJÍCÍ ZÁHLAVÍ ADRESACE IPV Adresní prostor a způsoby adresování Zápis adres Typy adres Globální individuální adresy Výběrové adresy Povinné adresy IPv Výběr adresy k použití Podsíťování v IPv PROTOKOL ICMPV OBJEVOVÁNÍ SOUSEDŮ (NEIGHBOR DISCOVERY) AUTOMATICKÁ KONFIGURACE ADRES PROTOKOL DHCPV MOBILITA FUNGOVÁNÍ MULTICASTU V IPV Přenos multicastu po Ethernetu (a Wi-Fi) Multicast Listener Discovery (MLD) SMĚROVÁNÍ V IPV6 SÍTÍCH IPV6 V PRAXI Fungování IPv6 ve Windows Mechanizmy přechodu komunikace mezi IPv6 a IPv AUTONOMNÍ SYSTÉMY FUNGOVÁNÍ AUTONOMNÍCH SYSTÉMŮ IGPS (INTERIOR GATEWAY PROTOCOLS) PROTOKOL EGP (EXTERIOR GATEWAY PROTOCOL) PROTOKOL BGP (BORDER GATEWAY PROTOCOL) Obecný popis protokolu BGP Formát záhlaví protokolu BGP Zpráva NLRI Update Směrovací proces u protokolu BGP Možné problémy BGP Filtrování rout Agregace směrovacích cest MULTIHOMING PEERING

5 Pokročilé komunikační techniky Veřejný a privátní peering Peeringové uzly Tranzit PŘÍKLAD AUTONOMNÍHO SYSTÉMU SDRUŽENÍ CESNET

6 6 FEKT Vysokého učení technického v Brně 1 Úvod Komunikace představuje sdělování informací mezi několika místy podle dohodnutých pravidel. Existuje velké množství technik a technologií, které nám moderní komunikaci umožňují, a to různými způsoby a v různých podmínkách. V současné době je dobře patrná konvergence veškeré naší komunikace do vzájemně propojených digitálních sítí. Dobrá znalost pokročilejších komunikačních technik představuje jednu ze základních charakteristik absolventů telekomunikačních a počítačových oborů. 2 Zařazení předmětu ve studijním programu Předmět Pokročilé komunikační techniky je vyučován v letním semestru prvního ročníku oboru Telekomunikační a informační technika, který spadá do navazujícího magisterského studijního programu Elektrotechnika, elektronika, komunikační a řídící technika. Jedná se o povinný oborově zaměřený předmět, jehož cílem je rozšířit a prohloubit znalosti studentů v oblasti komunikačních technik. Obsahem předmět navazuje zejména na předmět Komunikační technologie. Absolventi bakalářského studia by měli být schopni předmět zvládnout, jelikož se u nich již předpokládá poměrně dobrá orientace v základech. Na předmět navazují předměty zabývající se přenosem multimediálních dat, zajištěním kvality služeb (QoS) v komunikačních systémech a taktéž předměty, ve kterých se věnuje pozornost všem bezpečnostním aspektům digitální komunikace a v neposlední řadě kryptografii, tedy nauce o šifrování. 2.1 Úvod do předmětu Předmět se zaměřuje na nejmodernější způsoby komunikací. Obsahově navazuje na předmět Komunikační techniky zařazený do bakalářského studia. Prohlubuje znalosti základního síťového modelu TCP/IP. Studenti budou podrobněji seznámeni s mnoha aplikačními protokoly. Nejsou opomenuty ani protokoly nižších vrstev transportní a síťové. Prostor je věnován také technice multicastového přenosu dat. Dvě samostatné kapitoly jsou věnovány sadě Internet Protocol verze 6 (IPv6) a autonomním systémům.

7 Pokročilé komunikační techniky 7 3 Síťový model sady TCP/IP a Internetu 3.1 Vazba mezi RM OSI a modelem TCP/IP Soustava protokolů TCP/IP je největším rivalem obecného sedmivrstvého referenčního modelu ISO/OSI. Řekne-li se dnes TCP/IP, je to obvykle chápáno jen jako označení dvou přenosových protokolů, konkrétně protokolů TCP (Transmission Control Protocol) a IP (Internet Protocol). Ve skutečnosti ale zkratka TCP/IP označuje celou soustavu protokolů a ucelenou soustavu názorů o tom, jak by se počítačové sítě měly budovat, a jak by měly fungovat. Zahrnuje totiž i vlastní představu o tom, jak by mělo být síťové programové vybavení členěno na jednotlivé vrstvy, jaké úkoly by tyto vrstvy měly plnit, a také jakým způsobem by je měly plnit tedy jaké konkrétní protokoly by na jednotlivých úrovních měly být používány. TCP/IP je tedy stejně jako RM ISO/OSI síťovou architekturou. Hlavní odlišnosti mezi referenčním modelem ISO/OSI a TCP/IP vyplývají především z rozdílných výchozích předpokladů a postojů jejich tvůrců. Při koncipování referenčního modelu ISO/OSI měli hlavní slovo zástupci spojových organizací, kteří kladli důraz na vlastnosti sítě (především spojovaný a spolehlivý charakter služeb) s tím, že k síti připojované hostitelské počítače budou mít relativně jednoduchou úlohu. Později se ale ukázalo, že např. právě v otázce zajištění spolehlivosti to není nejšťastnější řešení že vyšší vrstvy nemohou považovat spolehlivou komunikační síť za dostatečně spolehlivou pro své potřeby, a tak se snaží zajistit si požadovanou míru spolehlivosti vlastními silami. V důsledku toho se pak zajišťováním spolehlivosti do určité míry zabývá vlastně každá vrstva referenčního modelu ISO/OSI. Tvůrci protokolů TCP/IP 1 naopak vycházeli z předpokladu, že zajištění spolehlivosti je problémem koncových účastníků komunikace, a mělo by tedy být řešeno až na úrovni transportní vrstvy. Komunikační síť pak podle této představy nemusí ztrácet část své přenosové kapacity na zajišťování spolehlivosti (na potvrzování, opětné vysílání poškozených paketů atd.), a může ji naopak plně využít pro vlastní datový přenos. V komunikační síti může docházet ke ztrátám přenášených paketů, a to bez varování a bez snahy o nápravu. Komunikační síť by ovšem neměla zahazovat pakety bezdůvodně. Měla by naopak vyvíjet maximální snahu přenášené pakety doručit (v angličtině se v této souvislosti používá termín best effort), a zahazovat pakety až tehdy, když je skutečně nemůže doručit - tedy např. když dojde k jejich poškození při přenosu, když pro ně není dostatek místa ve vyrovnávací paměti pro dočasné uložení, v případě výpadku spojení apod. Na rozdíl od referenčního modelu ISO/OSI tedy TCP/IP předpokládá jednoduchou a rychlou komunikační podsíť, ke které se připojují inteligentní hostitelské počítače. 1 Počátky TCP/IP se datují do konce 60. let a jsou úzce spojeny s činností účelové agentury ARPA (Advanced Research Projects Agency) Ministerstva obrany USA, které si nové protokoly nechalo vyvinout pro svou počítačovou síť ARPANET. Na vývoji celé soustavy protokolů, financovaném prostřednictvím grantů Ministerstva obrany (účelových dotací na výzkum), se pak podílela počítačově orientovaná pracoviště předních univerzit USA. Svou dnešní podobu získaly nové protokoly zhruba v letech , a brzy poté na ně začala postupně přecházet i vlastní síť ARPANET, která se posléze stala zárodkem a páteří celého konglomerátu sítí, dnes nazývaného Internet.

8 8 FEKT Vysokého učení technického v Brně TCP/IP předpokládá nespojovaný charakter přenosu v komunikační síti tedy jednoduchou datagramovou službu a obsahuje jen čtyři vrstvy (viz Obr. 3-1): Vrstva síťového rozhraní (Network Interface Layer) Nejnižší vrstva, (dle OSI spojová vrstva (Data Link Layer) a fyzická vrstva (Physical Layer) dohromady) má na starosti vše, co je spojeno s ovládáním konkrétní přenosové cesty resp. sítě, a s přímým vysíláním a příjmem datových paketů. V rámci soustavy TCP/IP není tato vrstva blíže specifikována, neboť je závislá na použité přenosové technologii. Vrstvu síťového rozhraní může tvořit relativně jednoduchý ovladač (device driver), je-li daný uzel přímo připojen například k lokální síti či ke dvoubodovému spoji, nebo může tato vrstva představovat naopak velmi složitý subsystém, s vlastním linkovým přenosovým protokolem (např. HDLC apod.) Internetová vrstva (Internet Layer) Vyšší vrstva, která již není závislá na konkrétní přenosové technologii, označována též jako IP vrstva (IP Layer) podle toho, že je realizována pomocí protokolu IP, odpovídá síťové vrstvě ISO/OSI a často je nazývána stejným způsobem. Úkolem této vrstvy je, aby se jednotlivé pakety dostaly od odesílatele až ke svému skutečnému příjemci, zpravidla přes mezilehlé směrovače. Vzhledem k nespojovanému charakteru přenosů v TCP/IP je na úrovni této vrstvy zajišťována jednoduchá (tj. nespolehlivá) datagramová služba. Síťová vrstva se však musí vyrovnávat i s konkrétními odlišnostmi jednotlivých dílčích sítí například s odlišným charakterem adres, s různou maximální velikostí přenášených paketů resp. rámců a jejich formátem a s odlišným charakterem nižší vrstvou poskytovaných přenosových služeb. Pro každou síť či každý přenosový kanál, na který je brána připojena, má samostatný ovladač na úrovni vrstvy síťového rozhraní Transportní vrstva (Transport Layer) Třetí vrstva, též označována jako TCP vrstva (TCP Layer), neboť je nejčastěji realizována právě protokolem TCP (Transmission Control Protocol). Hlavním úkolem této vrstvy je zajistit přenos mezi dvěma koncovými účastníky, kterými jsou v případě TCP/IP přímo aplikační programy (jako entity bezprostředně vyšší vrstvy). Podle jejich nároků a požadavků může transportní vrstva regulovat tok dat oběma směry, zajišťovat spolehlivost přenosu a také měnit nespojovaný charakter přenosu (v síťové vrstvě) na spojovaný. Přestože je transportní vrstva TCP/IP nejčastěji zajišťována právě protokolem TCP, není to zdaleka jediná možnost. Dalším používaným protokolem na úrovni transportní vrstvy je např. protokol UDP (User Datagram Protocol), který na rozdíl od TCP nezajišťuje (mimo jiné) spolehlivost přenosu. Samozřejmě je využíván pouze aplikacemi, které si spolehlivost na úrovni transportní vrstvy nepřejí, příkladem je SNMP protokol, který se používá pro zajištění přenosu dat pro dohlížení sítě.

9 Pokročilé komunikační techniky Aplikační vrstva (Application Layer) Nejvyšší vrstva, jejími entitami jsou jednotlivé aplikační programy, které na rozdíl od referenčního modelu ISO/OSI komunikují přímo s transportní vrstvou. Případné prezentační a relační služby, které v modelu ISO/OSI zajišťují samostatné vrstvy, si zde musí jednotlivé aplikace realizovat samy (pokud je vyžadují). TCP/IP tedy nemá relační vrstvu, ten, kdo ji skutečně potřebuje, si ji musí implementovat na úrovni aplikace. TCP/IP nemá ani prezentační vrstvu, zajištění prezentačních služeb je taktéž na koncových aplikacích. Pokud aplikace prezentační nebo relační vrstvu nepotřebuje, nevzniká žádná zbytečná režie. OSI Model Aplikace TCP/IP Model a protokoly Aplikace 7. Aplikační vrstva 6. Prezentační vrstva Aplikační vrstva telnet, ftp, http, smtp, dns, Relační vrstva 4. Transportní vrstva Transportní vrstva TCP UDP 3. Síťová vrstva Internetová vrstva IP 2. Spojová vrstva 1. Fyzická vrstva Vrstva síťového rozhraní Není součástí modelu, závislé na použité přenosové technologii Obr. 3-1: Srovnání modelu RM ISO/OSI a TCP/IP 3.2 Filozofie vzájemného propojování sítí pomocí TCP/IP Řešení vzájemného propojování sítí je jedním z prvotních příčin vzniku celé soustavy protokolů TCP/IP. Filozofie TCP/IP od začátku usiluje o co nejuniverzálnější propojení sítí různých typů od lokálních sítí typu Ethernet, Token Ring apod., přes veřejné datové sítě, až po rozlehlé sítě celosvětového dosahu. Klade si přitom za cíl umožnit každému počítači komunikovat s kterýmkoli jiným počítačem, bez ohledu na to, zda mezi nimi existuje přímé spojení, nebo zda jsou například tyto uzly v různých sítích, které jsou vzájemně propojeny jednou nebo několika dalšími sítěmi. Výsledkem je pak jediná soustava vzájemně propojených sítí, v terminologii TCP/IP označovaná obecně jako Internetworking. Z pohledu uživatele by vnitřní struktura této soustavy sítí měla být irelevantní - uživatelé, resp. jejich aplikační programy, se mohou na celý Internetworking dívat jako na jedinou velkou síť, ke které jsou připojeny jednotlivé koncové počítače - v terminologii TCP/IP označované jako hostitelské počítače (host computers, hosts).

10 10 FEKT Vysokého učení technického v Brně Ve skutečnosti je výsledná soustava (Internet) tedy jen konglomerátem (dílčích) sítí stejného či různého typu, vzájemně propojených na úrovni síťové vrstvy pomocí zařízení označených někdy nesprávně jako brány (gateway), správně termínem IP router (tj. IP směrovač). Výhodou IP protokolu je, že zavádí jednotný formát adres a způsob adresování i jednotný formát přenášených dat na úrovni síťové vrstvy. Na Obr. 3-2 je ukázka propojení dvou stanic přes Internet (Host A resp. Host B, kteří sídlí na lokální sítí LAN A resp. LAN B). V dolní části Obr. 3-2 je vidět na jakých vrstvách jednotlivé prvky pracují, spojitá čára značí reálný průchod dat sítí od Hosta A k Hostu B, přerušovaná čára značí virtuální spoje na jednotlivých vrstvách. (Přerušované čáry vedoucí ze směrovačů v horní části značí cesty k dalším částem Internetu, které v obrázku nejsou pro zjednodušení nakresleny.) HOST A LAN A Router 1 Router 2 Síť 1 Síť 2 Router 3 LAN B HOST B Aplikační vrstva Aplikační vrstva Transportní vrstva Transportní vrstva Internetová vrstva Internetová vrstva Internetová vrstva Internetová vrstva Internetová vrstva Vrstva síťového rozhraní Vrstva síťového rozhraní Vrstva síťového rozhraní Vrstva síťového rozhraní Vrstva síťového rozhraní Vrstva síťového rozhraní Vrstva síťového rozhraní Vrstva síťového rozhraní Obr. 3-2: Ukázka propojení sítí v rámci Internetu 3.3 Organizace kolem Internetu Internet byl vždy vyvíjen formou otevřené spolupráce. Vzhledem k tomu, že je Internet dnes hnací silou světového hospodářství, mají lidé z některých oborů a zemí obavy, kdo má vlastně Internet v rukou, případně zda je vůbec možné ho nějakým způsobem řídit. Ať už se nám to líbí nebo ne, přichází Internetová vláda. Vybrané organizace starající se o různé části s Internetem související problematiky jsou např. ICANN (Internet Corporation for Assigned Names and Numbers), tedy Internetová společnost pro přiřazení názvů a čísel. Pokud se dá říci, že někdo vládne Internetu, je to tato skupina ( o Neziskové sdružení, jehož snahou je koordinace Internetu, o udržuje Internet bezpečný, stabilní, schopný vnitřního fungování, o snaží se o přirozené konkurenční prostředí, o nekontroluje obsah Internetových stránek, není schopná zabránit spamu, regulovat poskytovatele Internetu atd., o věnuje se také politice a politikaření, o má více podčástí, např. IANA viz dále. IANA (Internet Assigned Numbers Authority), (

11 Pokročilé komunikační techniky 11 o Podčást ICANN, technický správce, přidělování a správa různých veličin, o spravuje systém DNS, administrace tzv. DNS root zóny (.), o provozuje domény.int a.arpa, o správa a přidělování IP (v4 a v6) adres (prostřednictvím regionálních součástí), poměrně zajímavý je přehled využití rozsahu IPv4 adres ( o správa a přidělování čísel autonomních systémů (kap. 6), o registr protokolů (ve spolupráci s IETF), zejména udržování seznamu a významu kódů a čísel vyskytujících se v protokolech (př. kódy ARP operací). o Zastoupení v jednotlivých regionech RIR (Regional Internet Registry) AFRINIC (African Network Information Center) - Afrika APNIC (Asia Pacific Network Information Centre) Asie a Pacifik ARIN (American Registry for Internet Numbers) Serverní Amerika LACNIC (Latin American and Caribbean Internet Addresses Registry) Latinská Amerika RIPE NCC (Réseaux IP Européens Network Coordination Centre) Evropa a Blízký východ V uvedených regionech pak působí organizace označované jako LIR (Local Internet Registry), které již komunikují přímo s koncovými zákazníky, a prostřednictvím nich lze získat např. IP adresní prostor. Seznam LIR působících v ČR je poměrně dlouhý 2, jelikož jako LIR jsou zaregistrováni prakticky všichni poskytovatelé Internetu. ISOC (Internet Society), tedy Internetová společnost. ISOC je členská organizace, reprezentující uživatele Internetu a snažící se o celosvětovou propagaci a přirozený rozvoj Internetu. ( Příkladem jejich činnosti je pořádání různých vzdělávacích kurzů. Členem sdružení se může stát prakticky každý uživatel Internetu, základní členství je zdarma. IETF (Internet Engineering Task Force), tedy Internetová technická pracovní síla. Tato skupina dohlíží nad vývojem a normalizací technických aspektů Internetu. Cílem jejich práce je tedy vývoj standardů resp. jejich technické části, de facto norem Internetu, např. RFC 2460 protokol IPv6 (specifikace), viz dále. IETF je založeno na otevřeném fóru, kterého se může účastnit kdokoliv ( Komunikace probíhá zpravidla prostřednictvím mailingových listů. Z těchto skupin má nejtěžší poslání ICANN: stát se autoritou, která řídí Internet, odstraňuje chyby z minulosti a předpovídá budoucnost. Všechny informace o síti Internet (konvencích a síťových protokolech) jsou od roku 1969 publikovány v tzv. Request for Comments (RFC), vydávaných Radou pro architekturu Internetu (Internet Architecture Board, 2 Aktuální seznam lze nalézt na stránkách RIPE NCC, konkrétně

12 12 FEKT Vysokého učení technického v Brně IAB) a veřejně dostupných prostřednictvím WWW (World Wide Web). Specifikace skupiny IETF (Internet Engineering Task Force) jsou považovány za de facto normy, tj. žádnému z orgánů spravujících vývoj Internetu a jeho technických specifikací nebyl přiznán statut mezinárodní normalizační organizace (na rozdíl od ISO, IEC, ITU, IEEE apod.). 3.4 Základní způsoby komunikace Základní typy komunikačních systémů z pohledu vnitřní organizace komunikace jsou klient-server a klient-klient (peer-to-peer = P2P). Systémy P2P jsou založeny na skutečnosti, že všechny stanice v rámci systému jsou si rovny (viz Obr. 3-3a), zatímco model klient-server rozlišuje klientské stanice, které zasílají své požadavky na zpracování serverovým stanicím. Na P2P systém, se lze dívat jako na systém, jehož všechny stanice obsahují jak klientskou, tak i serverovou část (servent). Z pohledu zpracování požadavku lze model typu klient-server (viz Obr. 3-3b) dále ve většině případů teoreticky rozdělit na tyto vrstvy: uživatelské rozhraní, zpracování dat, datová vrstva. Na vrchu stojí vrstva uživatelského rozhraní, která zprostředkovává komunikaci s koncovým uživatelem. Jako druhá (prostřední) se nachází vrstva zpracování dat, kde dochází ke zpracování požadavků přijatých od vrstvy uživatelského rozhraní. Zde se nachází vlastní logika celého systému. Nejníže je pak situována datová vrstva, kterou využívá vrstva zpracování pro získávání a ukládání dat, které sama následně zpracovává. Datová vrstva je často realizována databází nebo v nejjednodušším případě pevným diskem. Obr. 3-3: a) Peer-to-Peer komunikace b) Klient-server komunikace Jednotlivé z vrstev mohou být rozprostřeny rozdílně mezi klientskou a serverovou částí systému, tak jak ukazuje Obr. 3-4 (zde jsou jednotlivé vrstvy již konkrétně specifikované, tedy: uživatelské rozhraní, aplikace a databáze). Nejčastějším případem, který je typický pro protokoly rozebírané v rámci této kapitoly, je prostřední varianta, tj. že klient obsahuje uživatelské rozhraní, aplikace je jak na straně klienta, tak serveru a databáze (informace) celá na straně serveru. Ostatní varianty rozdělení mají větší smysl v případě distribuovaných systémů.

13 Pokročilé komunikační techniky 13 Klient Uživatelské rozhraní Uživatelské rozhraní Uživatelské rozhraní Uživatelské rozhraní Uživatelské rozhraní Aplikace Aplikace Aplikace Uživatelské rozhraní Databáze Aplikace Aplikace Aplikace Databáze Databáze Databáze Databáze Databáze Server Obr. 3-4: Možné rozdělení tří vrstev mezi klienta a server 3.5 Přehled protokolů patřících do TCP/IP Na Obr. 3-5 je znázorněn přehled protokolů patřících do sady TCP/IP, výčet není samozřejmě úplný. Význam zkratek názvů protokolů včetně krátkého přiblížení je možné nalézt níže. Je třeba si znovu uvědomit, že protokoly vyšších vrstev využívají k přenosu svých dat vždy i protokoly všech nižších úrovní, tedy např. HTTP > TCP > IPv4 > Ethernet, což je schematicky naznačeno na Obr. 3-6 a s ním úzce souvisejícím Obr Aplikační vrstva DHCP, DNS, FTP, TFTP, HTTP, IMAP, POP3, SIP, SMTP, SNMP, RPC, NFS, SSH, TELNET, RTCP, RTP, RTSP, TLS/ SSL, SOAP, GTP, BGP,... Transportní vrstva TCP, UDP, SCTP, RSVP,... Internetová vrstva IPv4, IPv6, ICMP, ICMPv6, IGMP, OSPF, IS-IS, IPsec,... Vrstva síťového rozhraní ARP, RARP, , WiMAX, ATM, Token Ring, Ethernet, FDDI, Frame Relay, GPRS, HDLC, PPP, ISDN,... Obr. 3-5: Vybrané protokoly sady TCP/IP a jejich zařazení do vrstev modelu Protokoly aplikační vrstvy DHCP (Dynamic Host Configuration Protocol), stanicí v síti využíván k získání IP adresy a dalších síťových parametrů (výchozí brána, DNS server, ) z DHCP serveru.

14 14 FEKT Vysokého učení technického v Brně Usnadňuje úkony související s adresací v rámci lokální sítě tím, že centralizuje přidělování zmíněných klíčových parametrů síťové konfigurace. Více v kap DNS (Domain Name System), umožňuje překlad pro člověka zapamatovatelného jména (např. na odpovídající IP adresu ( která je potřebná, aby stanice byla schopna přistoupit na požadovaný server. Více v kap FTP (File Transfer Protocol), se používá k přenosu dat mezi stanicemi přes Internet. TFTP (Trivial File Transfer Protocol), zjednodušená verze FTP s omezenými funkcemi. HTTP (Hypertext Transfer Protocol), používán k dopravě informací u WWW. IMAP (Internet Message Access Protocol), pro přístup lokální stanice do ové schránky na vzdáleném serveru. POP3 (Post Office Protocol verze 3), určen k získávání ových zpráv z poštovního serveru. SMTP (Simple Mail Transfer Protocol), standard pro výměnu ových zpráv v rámci Internetu. RPC (Remote Procedure Call), protokol pro vzdálené volání procedur, založeno na modelu klient-server. Požadavek ze strany klienta specifikuje proceduru a umožňuje přidat vstupní parametry. Na serveru proběhne vykonání procedury a odpověď serveru (při úspěšném vykonání procedury) může obsahovat výstupní parametry. NFS (Network File System), protokol umožňující přístup k souborům v síti, využívá služeb RPC. SNMP (Simple Network Management Protocol), využíván k monitorování stavu aktivních síťových prvků vyskytujících se ve spravované síti. SSH (Secure Shell), protokol dovolující výměnu dat zabezpečeným kanálem mezi dvěma stanicemi. Bezpečností se myslí nejen důvěrnost, ale i integrita dat. TELNET (Telecommunication Network), využíván k (nezabezpečenému) vzdálenému přístupu a administraci různých zařízení. RTCP (Real Time Control Protocol), řízení činností vykonávaných protokolem RTP (více dále). RTP (Real Time Transport Protocol), standardizovaný formát přenosu audio a video proudů 3 Internetem. RTSP (Real Time Streaming Protocol), vzdálené ovládání multimediálního toku dat (play, pause, ). SIP (Session Initiation Protocol), protokol pro vytváření, modifikaci a ukončování relací mezi dvěma a více účastníky. Využíván při multimediálních přenosech, jako je např. videokonference. SIP je nezávislý na použitém protokolu transportní vrstvy (UDP, TCP). TLS/SSL (Transport Layer Security / Secure Socket Layer), kryptografické protokoly umožňující zabezpečenou komunikaci (webovou, ovou, ). Zabezpečení se 3 Multimediálním protokolům, jako jsou RTP, RTCP, RTSP, RSVP, SIP a dalším, není v tomto učebním textu věnována bližší pozornost, zájemci se s nimi mohou seznámit ve specializovaných předmětech.

15 Pokročilé komunikační techniky 15 provádí na úrovni transportní vrstvy, přesto se pro svou komplexnost řadí do aplikační vrstvy. SOAP (Simple Object Access Protocol), protokol pro výměnu XML zpráv přes komunikační síť. GTP (GPRS Tunneling Protocol), protokol na tunelování (zapouzdřený přenos) IP paketů v datových podsítích v rámci GSM nebo UMTS. BGP (Border Gateway Protocol), základní směrovací protokol Internetu. Používán na směrování mezi jednotlivými sítěmi, např. jednotlivými poskytovateli, podrobněji v kap Protokoly transportní vrstvy TCP (Transmission Control Protocol), klíčový protokol (spolu s UDP, ICMP a IP, viz dále). Poskytuje aplikačním protokolům spolehlivou spojovanou službu s dodržením správnosti pořadí doručení přenášených jednotek. Více viz kap UDP (User Datagram Protocol), klíčový protokol (spolu s TCP, ICMP a IP). Poskytuje nespolehlivou službu (tzv. datagramová služba), rychlý přenos dat bez navazování spojení. Nezaručuje ani správné pořadí předávání doručených jednotek, pokud je to nezbytné, musí se to řešit na úrovni aplikačního protokolu, který využívá služeb UDP. Více viz kap SCTP (Stream Control Transmission Protocol), kombinuje vlastnosti TCP a UDP, není tak masově používán. RSVP (Resource Reservation Protocol), protokol umožňující rezervaci prostředků pro přenos dat sítí Protokoly Internetové vrstvy IPv4 (Internet Protocol verze 4), klíčový protokol (spolu TCP, UDP a ICMP). Paketově orientovaný protokol fungující způsobem best effort. Poskytuje globálně unikátní identifikátor (IP adresa), zajišťuje tedy jednoznačnou identifikaci stanice v rámci Internetu a tedy i možnost směrování dat přenášených sítí k danému cíli (nejkratší nebo nejrychlejší cestou). Více viz kap IPv6 (Internet Protocol verze 6), nejen nová verze IP protokolu obsahující mnohá vylepšení a rozšíření, ale také označení kompletní sady protokolů podobně jako TCP/IP. Podstata je ale stejná, tj. jednoznačná identifikace stanice v rámci Internetu a možnost směrování dat přenášených sítí k danému cíli (nejkratší nebo nejrychlejší cestou). Více viz kap. 5. ICMP (Internet Control Message Protocol), klíčový protokol (spolu s TCP, UDP a IP). Umožňuje např. oznamování chybových stavů, ověřování dostupnosti síťových zdrojů apod. Více viz kap ICMPv6 (Internet Control Message Protocol verze 6), nová verze ICMP pro IPv6 sítě. Kombinuje služby poskytované v IPv4 pomocí protokolů ICMP, ARP a IGMP. Kap. 5.8.

16 16 FEKT Vysokého učení technického v Brně IGMP (Internet Group Management Protocol), umožňuje řízení multicastových skupin, tj, např. přidávání nebo odebírání příjemců skupinového vysílání, více viz kap OSPF (Open Shortest Path First), směrovací protokol, využíván směrovači (routery) k vytváření směrovacích tabulek, tj. údajů podle kterých se následně rozhodují, kudy posílat pakety (IP protokolu) k požadovanému cíli (cílová IP adresa). IS-IS (Intermediate System to Intermediate System), taktéž směrovací protokol ke stejnému účelu jako OSPF. IPsec (IP Security), sada protokolů pro zabezpečení komunikace IP protokolem Protokoly síťového rozhraní (z hlediska ISO/OSI patřící většinou do spojové vrstvy, některé do spojové i do fyzické vrstvy zároveň) ARP (Address Resolution Protocol), standard pro hledání fyzické adresy stanice na lokální síti na základě známé Internetové adresy (nejčastěji hledaní MAC adresy na základě IP adresy), podrobněji v kap , patří do linkové vrstvy. RARP (Reverse Address Resolution Protocol), protokol, kterým stanice může získat Internetovou adresu na základě své fyzické adresy. Nepoužívá se, plně nahrazen DHCP. Zevrubný popis je možné nalézt v kap , patří do linkové vrstvy (Wireless Local Area Network standards), několik standardů pro bezdrátové lokální sítě v pásmu 2.4 GHz a 5 GHz. WiMAX (Worldwide Interoperability for Microwave Access), bezdrátová technologie navržená pro spojení na větší vzdálenosti než Umožňuje spojení od typu bod-bod až po buňkový systém podobný sítím GSM. Založen na standardu IEEE ATM (Asynchronous Transfer Mode), spojově a paketově orientovaná technologie, která přenáší datové jednotky o přesně definované délce 53 bajtů. Token Ring (IEEE 802.5), kruhová topologie lokální sítě, která postupně upadla po nástupu Ethernetu. Ethernet (IEEE 802.3), v současné době nejpoužívanější standardy lokální sítě, které se prosadily zejména svou jednoduchostí. K přenosu dat se využívají tzv. rámce. FDDI (Fiber Distributed Data Interface), dvou-kruhová optická technologie lokální sítě větších vzdáleností, taktéž převálcována Ethernetem. Frame Relay, nejčastějším použitím je zapouzdřený přenos rámců mezi lokálními sítěmi přes větší vzdálenosti (WAN) a skrz trvale utvořené virtuální okruhy (PVC = Permanent Virtual Circuit). GPRS (General Packet Radio Service), technologie paketově orientovaného přenosu dat v mobilních sítích GSM, u které se zpravidla platí pouze za přenesená data, nikoliv za čas, na rozdíl od CSD = Circuit Switched Data. HDLC (High-Level Data Link Control), protokol poskytující spojované i nespojované služby, zpravidla na lince mezi dvěma zařízeními (point-to-point), ale umožňuje i spojení typu point-to-multipoint.

17 Pokročilé komunikační techniky 17 PPP (Point-to-Point Protocol), jak napovídá název, jedná se o protokol pro vytvoření přímého spojení mezi dvěma body přes sériovou, telefonní nebo i jinou linku. ISDN (Integrated Services Digital Network), digitální telefonní technologie s přepínáním okruhů a možností přenášet nejen hlas, ale i data nebo např. videokonference. 3.6 Souběh aplikací v rámci TCP/IP a zapouzdřování Na Obr. 3-6 jsou jako př. znázorněny tři současně běžící aplikace, www prohlížeč, ový klient a ftp klient. Každá z těchto aplikací využívá příslušný aplikační protokol, při této volbě služeb jsou to HTTP, např. IMAP a FTP, které jsou schopny uživatelovy požadavky zformulovat do zprávy, kterou bude následně schopna druhá strana komunikace zpracovat, tzv. Application PDU (Protocol Data Unit), tedy protokolová datová jednotka aplikační vrstvy, jednoduše nazývána data. Tyto údaje (pocházející z libovolného z aplikačních protokolů) jsou předávány transportní vrstvě, při volbě protokolů HTTP, IMAP a FTP pouze protokolu TCP, protokol UDP by byl použit v případě volby jiných aplikací. Přidáním hlavičky TCP vznikne TCP PDU, tedy protokolová datová jednotka transportní vrstvy, též nazývaná segment. Transportní vrstva takto vzniklou jednotku předá Internetové vrstvě, v našem příkladu IP protokolu a přidáním IP hlavičky vznikne IP datagram, zkráceně paket. Další postup závisí na použitém síťovém rozhraní, tedy v případě připojení stanice (hosta) na LAN se paketu přidá LAN záhlaví (header) a LAN zápatí (trailer) a vznikne rámec. Tomuto ději se říká zapouzdřování (encapsulation) a struktura výsledné jednotky (rámce) je patrná z Obr Host Aplikace Aplikace Aplikace Aplikační protokol 1 Aplikační protokol 2 Aplikační protokol 3 TCP UDP IP Protokoly vrstvy síťového rozhraní Datová komunikační síť Obr. 3-6: Znázornění souběžného fungování více aplikací v rámci TCP/IP

18 18 FEKT Vysokého učení technického v Brně Datová jednotka aplikační vrstvy (data) TCP/UDP PDU záhlaví Data LAN/WAN PDU záhlaví IP záhlaví Segment Přenášená data (z pohledu síťového rozhraní) paket LAN/WAN zápatí Obr. 3-7: Zapouzdřování (encapsulation) uživatelských dat jednotlivými vrstvami 3.7 Softwarový pohled na TCP/IP V rámci operačního systému bývá protokolová sada TCP/IP implementována prostřednictvím tzv. IP modulu. Tento modul je pak schopný komunikovat s více vyššími protokoly a i s více fyzickými rozhraními konkrétního stroje. Tuto situaci lze znázornit prostřednictvím Obr V obrázku jsou naznačeny i hranice mezi jednotlivými vrstvami. Nejvyšší (aplikační) vrstva je zpravidla implementována až v rámci konkrétního softwaru, který ji využívá ke své funkci. Např. ftp server bude mít implementovaný ftp aplikační protokol, webový prohlížeč protokol http apod. IP modul, který se skládá z transportní a síťové vrstvy, bývá běžně součástí operačního systému. Pokud v operačním systému není obsažen, zpravidla existuje možnost, jak ho doinstalovat. Na vrstvě IP modulu dochází k multiplexování a demultiplexování zpráv pro jednotlivé aplikační protokoly. IP modul následně spolupracuje s konkrétními přenosovými cestami, které má daný stroj k dispozici může jich být i více než jedna. Na úrovni IP modulu a výše se při adresování pracuje s IP adresami, níže s fyzickými adresami. Zabývá se detaily aplikace Aplikační protokol 1 Aplikační protokol 2 Aplikační protokol 3 Aplikační protokol 4 Software vně operačního systému (uživatelské procesy) Zabývá se detaily komunikace IP modul Transportní vrstva Vrstva Internetu Software uvnitř operačního systému Síťové rozhraní 1 Síťové rozhraní 2 Síťové rozhraní 3 Ovládání konkrétní přenosové cesty Obr. 3-8: Organizace softwaru na podporu sady TCP/IP

19 Pokročilé komunikační techniky Úloha síťové (Internetové) vrstvy s protokolem IP (IPv4) Síťová vrstva (resp. Internetová vrstva realizovaná protokolem IP) v síťovém modelu TCP/IP zajišťuje potřebné směrování mezi jednotlivými dílčími sítěmi, a vyšším vrstvám tak vytváří iluzi jediné homogenní sítě. Sama však musí pracovat se skutečnou vnitřní strukturou resp. způsobem vzájemného propojení. Síťová vrstva se musí vyrovnávat i s konkrétními odlišnostmi jednotlivých dílčích sítí například s odlišným charakterem adres, s různou maximální velikostí přenášených paketů resp. rámců a jejich formátem, s odlišným charakterem poskytovaných přenosových služeb (spojovaných či nespojovaných) apod. Ovladač na úrovni vrstvy síťového rozhraní dokáže odstínit síťovou vrstvu od konkrétního způsobu ovládání příslušné sítě a přesného formátu datových rámců. Není ovšem již v jeho silách zastřít před síťovou vrstvou rozdíl v používaném mechanizmu adresování, resp. zajistit používání jednotných adres ve všech dílčích sítích. Tento jednotný způsob adresování může zajistit až síťová vrstva, která provádí tzv. jednotnou abstrakci, tedy sjednocení v: způsob adresování (IP adresy), Adresy, které protokol IP zavádí (IP adresy), jsou 32-bitové (u protokolu IP verze 4). Z pohledu transportní a aplikační vrstvy je lze interpretovat jako lineární (resp. jednosložkové) adresy - což odpovídá představě jediné homogenní sítě. Na úrovni síťové vrstvy se ale interpretují jako dvousložkové, tvořené číslem resp. adresou hostitelského počítače, a číslem resp. adresou (dílčí) sítě, ve které se tento hostitelský počítač nachází. IP adresy jsou pouze abstraktními adresami, které musí být posléze převedeny na skutečné fyzické adresy, protože ovladač na úrovni vrstvy síťového rozhraní, pokud dostane nějaká data k odeslání, musí spolu s nimi dostat i konkrétní fyzickou adresu, na kterou je má odeslat. Sám totiž s IP adresami nepracuje. Jde-li například o lokální síť typu Ethernet, dostane síťová vrstva (od vrstvy transportní) adresu cílového hostitelského počítače ve formě 32-bitové IP adresy, ale příslušný ovladač vrstvy síťového rozhraní musí získat 48-bitovou Ethernetovou adresu. K mechanizmu, jakým se v TCP/IP sítích zjišťuje korespondence mezi IP adresami a konkrétními fyzickými adresami, se vrátíme podrobněji v kap , která se věnuje protokolu ARP. formát datových paketů používaných na síťové vrstvě (IP datagramy), Podobně jako jednotný formát adres a způsob adresování, zavádí protokol IP i jednotný formát přenášených dat na úrovni síťové vrstvy - již zmíněné IP datagramy. Jde o datové pakety, označované jako datagramy proto, že jsou přenášeny pomocí nespojované (datagramové) síťové přenosové služby. Na úrovni vrstvy síťového rozhraní jsou tyto datagramy přenášeny pomocí takových rámců, se kterými příslušná dílčí síť pracuje. Tyto se ovšem mohou obecně síť od sítě lišit. nespolehlivá nespojovaná přenosová služba z pohledu vyšších vrstev (transportní a aplikační) IP adresy zápis, masky, třídy a speciální adresy Zápis 32-bitové IP adresy lze vyjadřovat jako celá dvojková čísla. Pro člověka to ale není příliš srozumitelné, a tak se pro symbolický zápis IP adres zavedla konvence, označovaná jako tečkovaná desítková notace (dotted decimal notation). Spočívá v tom, že 32 bitů IP

20 20 FEKT Vysokého učení technického v Brně adresy se rozdělí na čtyři části po osmi bitech (oktety), a každá část se pak vyjádří jako celé desítkové číslo bez znaménka (s použitím tečky jako oddělovače jednotlivých částí). Příklad 3.1 Například nepříliš snadno zapamatovatelný tvar: tak dostává podobu: Maska sítě Jak již bylo uvedeno, IP adresy jsou dvousložkové, tj. tvořené číslem resp. adresou (dílčí) sítě, ve které se hostitelský počítač nachází, a číslem resp. adresou tohoto hostitelského počítače. Jestliže všechny bity, které jsou vyhrazeny pro adresu sítě, budou nahrazeny binární 1 a převedeme takto vzniklé číslo na desítkové číslo podobně jako v předchozím příkladu, dostaneme masku sítě. Příklad 3.2 Adresa IP Adresa sítě (dekadicky) (proč je toto adresa sítě viz Příklad 3.3.) Adresa sítě (binárně) Maska sítě (binárně) Maska sítě (dekadicky) Maska sítě se taktéž často zapisuje tzv. délkou prefixu, která vyjadřuje počet jedniček v masce a píše se s lomítkem za adresu IP. Prefix představuje začátek adresy, který vyjadřuje adresu sítě. Totožné zápisy IP adresy a masky, resp. délky prefixu tedy jsou: / Třídy IP adres Podle počtu bitů (z 32 celkem) využívaných pro adresu sítě a tedy i počtu bitů zbývajících pro uvažované stanice v rámci sítě dělíme IP adresy na třídy, viz Tab. 1. Původní filozofie TCP/IP počítá s malými (C), středními (B) a velkými sítěmi (A). Toto rozdělení se později ukázalo jako příliš hrubé a neefektivní, efektivnější řešení je možné vyčíst v kap o podsíťování Speciální IP adresy Adresa sítě (často označována jako prefix) vznikne tak, že se všechny bity z části pro adresu hosta nahradí binární 0, jedná se o první adresu v rámci dané sítě. Matematicky se tato operace dá popsat logickým součinem jednotlivých bitů IP adresy a masky sítě.

21 Pokročilé komunikační techniky 21 Třída Rozsah prvního oktetu adresy (dekadicky) Tab. 1: Dělení IP adres do tříd Dělení adresy na adresu Sítě a Hosta Standardní maska sítě (dekadicky) Počet možných sítí / hostů na jednu síť A S.H.H.H / B S.S.H.H / C S.S.S.H / 254 D Multicastové adresy E Experimentální adresy Příklad 3.3 Dána IP adresa ; je patrné, že je ze třídy B. Její standardní (výchozí) maska je , tedy adresa sítě je Výpočet: Adresa IP IP binárně Maska sítě (dekadicky) Maska sítě (binárně) Adresa sítě (binárně) Adresa sítě (dekadicky) Všesměrová (broadcast) adresa, je taková IP adresa, jejichž použitím lze poslat paket zároveň všem stanicím v rámci dané sítě. Vznikne tak, že všechny bity tvořící adresu hosta v rámci IP adresy se nahradí binární 1, jedná se tedy o poslední adresu v rámci dané sítě. Příklad 3.4 Zadání stejné jako v Příklad 3.3, vypočtěte všesměrovou adresu: Adresa IP IP binárně Maska sítě (dekadicky) Maska sítě (binárně) Broadcast (binárně) Broadcast (dekadicky) Adresy použitelné pro koncové stanice v síti, jsou všechny adresy v rámci dané sítě v rozsahu mezi adresou sítě a všesměrovou adresou. Příklad 3.5 Jestliže máme danou síť s maskou , jaký je rozsah adres použitelných pro stanice v rámci sítě?

22 22 FEKT Vysokého učení technického v Brně Vše mezi adresou sítě (Příklad 3.3) a všesměrovou adresou (Příklad 3.4), tedy: Rozsah pro hosty až , tedy celkem (2 16 2) adres. Lokální smyčka (loopback), je to softwarová smyčka uvnitř počítače, adresy 127.x.x.x. Pakety s touto adresou nikdy neopustí počítač, vhodné např. pro meziprocesovou komunikaci. Z celého rozsahu IP adres jsou vyčleněny rozsahy tzv. privátních adres, které se původně měly používat pouze v sítích nepřipojených k Internetu. Dnes se však z důvodu nedostatku IPv4 adres používají pro lokální sítě s vlastním mechanizmem adresace, které mají navenek pouze např. jednu veřejnou adresu (funkce NAT = Network Address Translation překlad privátních adres na veřejné, kap ). Privátní adresy tak musí být unikátní pouze v rámci jedné lokální sítě, ale celosvětově se můžou libovolně opakovat, jelikož se vždy skrývají za veřejnou adresou hraničního směrovače své lokální sítě. O tyto adresy tedy není nutné žádat. Zvyšuje se tak bezpečnost vnitřních počítačů, protože jejich adresy nejsou z vnější sítě snadno dostupné. Pozn.: Veřejné adresy musí být v rámci celého Internetu unikátní a to je důvod, proč je jich nedostatek (v případě IPv4). Rozsahy vyčleněné pro privátní adresy jsou Třída A (1 síť o možných hostech) Třída B (16 sítí o možných hostech) Třída C (256 sítí o 254 možných hostech) Lokální linkové adresy, rozsah až V případě, že se stanici nepodaří konfigurovat IP, např. v případě že nefunguje DHCP server, sama si nastaví IP z uvedeného rozsahu. V adresním rozsahu IPv4 existuje několik dalších bloků, které jsou vyhrazeny pro speciální účely. Například blok / 8 je vyhrazen pro lokální identifikaci stanic, adresa / 32 je vyhrazena pro vlastní identifikaci stanice ve speciálních případech jako je např. komunikace s DHCP serverem před přidělením IP adresy. Adresní prostor / 24 je vyhrazen pro příklady v textech, síť se nazývá TEST-NET-1, představuje neexistující doménu example.com. Tyto adresy nejsou ve skutečnosti Internetem směrovány. Adresní prostor a jeho alokace není statický proces, v čase se mění. Aktuální a platný stav lze nalézt na stránkách organizace IANA Podstata směrování v sítích TCP/IP Směrování (routing) představuje proces hledání cest z jednoho bodu do jiných bodů v rámci propojených sítí. Směrování je netriviální úloha a provádějí ho zpravidla zařízení, které se nazývají směrovače (routery). Problémy směrování spočívají především ve volbě optimální (nejkratší, nejrychlejší, nejspolehlivější, ) cesty (routy) z bodu A do bodu B. Je 4

23 Pokročilé komunikační techniky 23 přitom třeba brát v potaz, že topologie propojených sítí se mění, linky nemusí být vždy funkční apod. Každý směrovač, přes který paket na cestě z bodu A do bodu B prochází, musí lokálně rozhodnout kam paket dále směrovat (v případě, že existuje více cest). Toto lokální rozhodnutí je vždy založeno na určité úrovni znalosti globální topologie, což představuje základní problém směrování. Globální topologie je totiž nepředstavitelně složitá a rozsáhlá, dále dynamická, tj. proměnná v čase a navíc je obtížné všechny informace o ní sbírat. Směrovač potřebuje zpravidla k úspěšnému plnění směrovací úlohy tyto informace: adresátovu adresu (IP), možné cesty do všech vzdálených sítí, aktuálně zvolenou nejlepší cestu do cílové sítě, sousední směrovače, od kterých se může dozvědět o routách, a poslat jim data, způsob jak se dozvědět o routách, jak tyto informace aktualizovat a udržovat. Může samozřejmě nastat i situace, že směrovač nebude vědět kudy paket dále směrovat. V takovém případě paket zahodí a měl by odesilatele paketu o této skutečnosti informovat 5 ICMP zprávou destination unreachable (adresát nedostupný), více viz kap V rámci Internetu funguje tzv. hierarchické směrování neboli směrování s více úrovněmi. Celá síť je rozdělena do tzv. autonomních částí, které uvnitř provádí směrování na jedné úrovni a mezi těmito částmi je pak prováděno směrování na vyšší úrovni. Této problematice se blíže věnuje kap. 6. Úloha konfigurace směrovacího procesu může být realizována jedním z níže uvedených způsobů, případně častěji kombinací obou metod. statické směrování směrovací informace ručně nakonfigurované administrátorem, který musí exaktně stanovit, co se bude kudy směrovat. Nevýhodou je nulová dynamika tohoto systému a nefunkčnost v případě jakékoliv změny nebo poruchy v síti. Výhodou nulový provoz v sítí v souvislosti s výměnou směrovacích informací. Běžně se používá pouze v malých sítích nebo ke konfiguraci tzv. gateway of last resort, česky často ne zcela správně označované jako výchozí brány. Tato brána je zpravidla směrovač, na který se odešle paket, u kterého se nenalezla jiná (vhodnější) cesta, kudy jej směrovat. Jedná se tedy o jakousi formu poslední instance, kam paket odeslat místo jeho zahození. dynamické směrování směrovací informace si směrovače dynamicky vyměňují na základě směrovacích protokolů, základní informace o běžných směrovacích protokolech je možné nalézt v kap Výhoda tohoto způsobu je zřejmá z nevýhod statického směrování a obráceně. Další nevýhodou je větší zatížení procesoru směrovačů v souvislosti s přípravou a zpracováním paketů souvisejících se směrovacími protokoly a určité zpoždění, které tímto vzniká. Hlavní úlohou směrovacích protokolů je inteligentně sumarizovat relevantní směrovací informace. Základní požadavky jsou: 5 Běžně se však zpráva ICMP destination unreachable z bezpečnostních důvodů ochrany před různými útoky ze směrovačů neodesílá. O zahození paketu z důvodu nenalezení cesty k adresátovi se tak často nedozvíme.

24 24 FEKT Vysokého učení technického v Brně minimalizace velikosti směrovacích tabulek z důvodu rychlého vyhledávání a také následně menšího množství vyměňovaných informací mezi sousedy. minimalizace počtu přenášených kontrolních zpráv aby nedocházelo k zbytečnému zatížení linek servisním provozem, který pro běžného uživatele nemá hodnotu. robustnost nesmí docházet ke vzniku černých děr, kde by se ztrácely pakety, nebo směrovacích smyček; žádoucí je rychlá konvergence procesu výměny směrovacích informací. využívání optimálních tras optimální nemusí vždy být nejkratší nebo nejrychlejší. Všechny získané směrovací informace, ať statické nebo dynamické se ukládají v paměti každého směrovače do tzv. směrovací tabulky. Topologie znázorněná pro demonstraci možného vzhledu směrovací tabulky je na Obr Síť se skládá z osmi směrovačů R1 až R8, každý z nich má pro ilustraci pouze jednu lokální síť, označenou postupně 1 až 8. Směrovací tabulka vypadá z pohledu každého směrovače jinak, společné však je, že každý chce komunikovat s každým, tzn., že v každé směrovací tabulce musí být informace o všech sítích, které mají být dostupné. Např. z pohledu R1 by směrovací tabulka mohla vypadat tak, jak je naznačeno v následující Tab. 2. Záznamy jsou označeny hvězdičkou. V obecné rovině nelze totiž exaktně stanovit, jaká hodnota dalšího skoku by byla ve směrovací tabulce uložena. Je to zapříčiněno existencí více cest. Která z možných cest by byla aktivní, to je úlohou směrovacího protokolu případně protokolů. Tab. 2: Směrovací tabulka směrovače R1 z Obr. 3-9 Cílová síť Cesta kudy (další skok) Cílová síť Cesta kudy (další skok) 1 - (lokální) 5 R5* 2 R2* 6 R5* 3 R3* 7 R2* 4 R2* 8 R2* 5 6 R5 R6 3 R4 R7 7 R3 4 1 R1 R2 2 R8 8 Obr. 3-9: Možná topologie sítě (k vysvětlení směrovací tabulky)

25 Pokročilé komunikační techniky 25 Směrování z pohledu síťové vrstvy V zájmu minimalizace objemu směrovacích tabulek je směrovací proces v TCP/IP sítích založen jen na adresách (dílčích) sítí, a nikoli na adresách jednotlivých hostitelských počítačů v rámci těchto sítí. Síťová vrstva tedy pracuje s představou členění Internetu na dílčí sítě a nikoli s představou jednolité, dále nestrukturované výsledné sítě. Každý hostitelský počítač, který chce odeslat nějaký IP datagram jinému hostitelskému počítači, dokáže z IP adresy příjemce rozpoznat, zda leží ve stejné (lokální) síti či nikoli. Pokud ano (nachází-li se například v téže síti typu Ethernet), pošle mu odesílatel svůj datagram přímo. Pokud se ale příjemce nachází v jiné síti, předá odesílatel svůj datagram nejbližší bráně (resp. IP směrovači = router) ve své síti. Na ní je pak rozhodnout, kudy datagram poslat dále. Podstatné přitom je, že při svém rozhodování vychází brána pouze z té části IP adresy konečného příjemce, která vyjadřuje příslušnou cílovou síť. Každá brána má své směrovací tabulky ve formě seznamu dvojic <síť, následující skok> a podle cílové sítě příjemce si v nich najde, které další bráně má příslušný datagram poslat dále. Zbývající část IP adresy příjemce, která vyjadřuje adresu hostitelského počítače v rámci cílové sítě, pak využije až ta brána (poslední v řetězci), která již leží v příslušné cílové síti, a která pak datagram pošle přímo jeho konečnému adresátovi Podsíťové adresy Vzhledem k neefektivnímu rozdělení adres (třídy adres, viz kap ) a především nedostatku adres stanic pro adresy třídy C a naopak nevyčerpatelnému přebytku adres uzlů v třídě A, se přistoupilo k mechanizmu tzv. podsíťování (subnetting). Část adresy původně určená stanici v rámci sítě se rozdělí na dvě části: adresu podsítě (v rámci pevně dané adresy sítě) a adresu stanice. V rámci jednoho adresního bloku tedy vytvoříme několik logických podsítí. Dodržuje se pravidlo, že pro podsíťové adresy se využívá souvislého toku bitů zleva od (nedotknutelné) adresy sítě. Jakmile se používá podsíťování, je třeba přesně rozlišovat mezi adresou sítě, adresou její podsítě a adresou stanice v rámci dané podsítě. Zatímco v případě adresace bez použití podsíťování bylo při pohledu na první oktet adresy zřejmé, jaká je její struktura (třída, adresa sítě i stanice), pak s podsíťováním to již není tak jednoduché. IP adresa musí být vždy doplněna ještě tzv. podsíťovou maskou (subnet mask). Tato maska má stejný formát jako maska sítě (viz kap ), tedy 32-bitové číslo, obsahující 1 v souvislé řadě zleva na pozicích označujících adresu sítě a podsítě. Zbývající 0 označují pozice bitů pro adresu hosta. Jak je patrné z Tab. 3, při podsíťování nelze použít zcela libovolné bity pro adresaci podsítí; musí existovat možnost adresovat alespoň nějaké stanice v rámci podsítě (proto se nepoužívají poslední dva bity, aby zbyly 4 volné adresy v rámci podsítě, tj. adresa podsítě, dvě adresy pro stanice a broadcastová adresa). Třída dělené sítě Implicitní maska dělené sítě Tab. 3: Pořadí bitů pro adresaci stanice Podsíťování podle tříd IP Pořadí bitů použitelných pro adresu podsítě Celkem bitů použitelných pro podsítě Celkem možných podsítí v rámci jedné sítě A B C

26 26 FEKT Vysokého učení technického v Brně Kombinací konkrétní IP adresy stanice a příslušné podsíťové masky lze zjistit, v jaké podsíti (případně síti, pokud se jedná o implicitní masku) stanice leží, postup je naprosto stejný jako v Příklad 3.3, přesto uveďme ještě jeden s použitím podsítě: Příklad 3.6 Dána síť / 24. Potřebujeme tuto síť rozdělit na 3 podsítě. a) Kolik bitů z části pro hosty musíme využít? b) Kolik může být v každé podsíti stanic? c) Jaká je podsíťová maska, resp. délka prefixu? d) Uveďte přehled podsítí. Řešení a) 3 podsítě potřebujeme 2 bity, protože 2 2 = 4 je nejbližší vyšší mocnina dvou, (jedna podsíť tedy zůstane nevyužita). b) Pro stanice nám zbude 6 bitů, hostů může tedy být 2 6 = 64, resp. o dva méně, tedy 62, jelikož první adresa je vždy adresa (pod)sítě a poslední je vždy všesměrovou adresou. c) Původní maska (24 binárních 1 ) se o dvě 1 rozšíří, tj. o bity použité pro tvorbu podsítí, délka prefixu tedy bude /26 a maska podsítě d) Číslo podsítě Tab. 4: Informace o podsítích (příklad 3.6) Adresa podsítě Rozsah adres použitelných pro stanice v podsíti (první a poslední) Všesměrová adresa podsítě Situaci řešenou v Příklad 3.6 můžeme chápat ještě z mírně odlišného úhlu pohledu. Mějme situaci: máme 3 samostatné LAN sítě (např. jednotlivá patra budovy), kde v každé z nich je přibližně 20 stanic. Pro tyto stanice samozřejmě potřebujeme IP adresy, abychom mohli provozovat aplikace založené na TCP/IP. Kdyby neexistovala technika podsíťování, bylo by nezbytné využít tři samostatné rozsahy třídy C, např /24, /24 a /24. V každé z těchto sítí pak bude přibližně 230 nevyužitých IP adres, což není příliš efektivní. Situaci znázorňuje Obr Nevýhodou tohoto řešení jsou pak i trojnásobné náklady, jelikož získání bloků IP adres třídy C není zadarmo.

27 Pokročilé komunikační techniky 27 IP SíťC.2 IP SíťC.3 IP SíťC LAN A LAN C IP SíťC.1 IP SíťA.1 LAN B Odchozí brána WAN Tři rozsahy adresního prostoru SíťA: až SíťB: až SíťC: až IP SíťB.1 Počet uzlů až 254 x IP SíťA.2 IP SíťA.3 IP SíťA.21 IP SíťB.2 IP SíťB.3 IP SíťB.21 Obr. 3-10: Rozdělení na dílčí sítě LAN klasický přístup IP podsíťc.2 LAN C WAN IP podsíťc.3... IP podsíťc.1 Odchozí brána IP podsíťc.21 LAN A IP podsíťa.1 LAN B IP podsíťb IP podsíťa.2 IP podsíťa.3 IP podsíťa.21 IP PodSíťB.2 IP podsíťb.3 IP podsíťb.21 Obr. 3-11: Rozdělení na dílčí sítě LAN podsíťování Z předcházejícího popisu je zřejmé, že celkem potřebujeme přibližně 70 IP adres (včetně IP adres směrovačů a všesměrových adres). Toto množství lze s velkou rezervou umístit pouze do jedné sítě třídy C. Proto by bylo velmi neefektivní tohoto mechanizmu nevyužít. Síť /24 tedy rozdělíme na čtyři podsítě, jak bylo popsáno v Příklad 3.6. V každé podsíti máme možnost mít až 62 stanic, takže nám zůstala poměrně velká rezerva pro budoucí rozšíření počtu stanic. Stejně tak nám zůstala v rezervě jedna celá podsíť. (Ta by se však v reálném případě rozdělila na menší podsítě a využila pro adresování sítí spojujících směrovače.) Situace při využití techniky podsíťování je naznačena na Obr

28 28 FEKT Vysokého učení technického v Brně IPv4 datagramy (pakety) Jak již bylo uvedeno v úvodu kap. 3.8, síťová vrstva zavádí jednotnou abstrakci i v případě formátu datových jednotek používaných na této vrstvě, tzv. IP datagramy, též nazývané pakety. IP paket je na úrovni síťového rozhraní vždy zabalen do rámce příslušné technologie (Ethernet, ), který se mění, tak jak paket prochází přes dílčí sítě. Zabalený paket však zůstává ve stejném formátu a nemění se, tedy s výjimkou proměnných polí, jako je hodnota čítače, která vyjadřuje životnost paketu (viz dále). Základní struktura paketu je naznačena na Obr. 3-12, význam jednotlivých polí následuje níže. Bity Verze IP Délka záhlaví Typ služby Celková délka IP datagramu Identifikace IP datagramu Příznaky Posunutí fragmentu od počátku Doba života (TTL) Protokol vyšší vrstvy Kontrolní součet záhlaví datagramu IP adresa odesílatele paketu IP adresa příjemce paketu Volitelné položky záhlaví Přenášená data Obr. 3-12: Složení IPv4 datagramu s detailním znázorněním struktury záhlaví Verze (version) 4 bity, obsahuje verzi protokolu IP a zajišťuje, aby ostatní systémy, které zpracovávají datagram během přenosu, mohly různá pole datagramu správně použít. Verze IPv4 zde má samozřejmě hodnotu 4. Délka záhlaví (header length) 4 bity, musí se uvádět, protože záhlaví může mít proměnnou délku v násobcích 32 bitů, kvůli volitelným položkám. Minimum je 5 slov (5 32 bitů = 20 bajtů) délky záhlaví, maximum 60 bajtů, nevyužité pozice musí být vycpány daty bez významu. Typ služby (type of service, ToS) 8 bitů, položka měla sloužit ke specifikaci požadované kvality přenosu IP datagramu. Směrování pak mělo brát ohled na hodnotu ToS a volit z alternativních tras tu, která nejlépe odpovídala požadavkům datagramu. V současnosti se položka používá k podobným účelům nese značku pro mechanizmy zajišťující služby s definovanou kvalitou služby (QoS). Celková délka IP datagramu (total length) 16 bitů, definuje úplnou délku datagramu včetně záhlaví a uživatelských dat. Maximum je bajtů. Identifikace IP datagramu (identification) 16 bitů, primárně určeno k identifikaci k sobě patřících fragmentů, vždy přiděleno odesílatelem.

29 Pokročilé komunikační techniky 29 Příznaky (flags) 3 bity, používají se dva: DF-bit (don t fragment) označuje případný požadavek na nepoužítí fragmentace, tj. dodatečného dělení paketu na menší části. MFbit (more fragments) říká, že datagram byl fragmentován a že bude následovat další část. Posunutí fragmentu od počátku (fragment offset) 13 bitů, indikuje pozici obsahu dat datagramu vzhledem k začátku původního (rozdělovaného) paketu. Doba života datagramu (Time To Live - TTL) 8 bitů, tato hodnota definuje maximální počet skoků (hops), každý směrovač sníží při zpracování hodnotu položky o 1. Pokud již nelze hodnotu snížit, je paket zahozen. Protokol vyšší vrstvy (protocol) 8 bitů, obsahuje číselnou identifikaci protokolu vyšší vrstvy, který využívá IP datagram ke svému přenosu. Kontrolní součet záhlaví datagramu (header checksum) 16 bitů, je použit na záhlaví datagramu, pokud se při kontrole zjistí, že součet nesedí (došlo k chybě), paket se zahodí. IP adresa odesílatele/příjemce paketu (source/destination address) každá 32 bitů, jedná se o logickou adresu v rámci IP protokolu. Volitelné položky záhlaví (options) volitelně až do délky 40 bajtů, nevyužívá se příliš často, některé jsou dokonce zakázány. Např.: - zaznamenej směrovače (record route) zjištění kudy paket procházel, - zaznamenej čas (time stamp), - explicitní směrování (loose source routing) umožňuje výslovně zadat, přes které směrovače má být IP datagram dopravován (nemusí být uvedeny všechny), - striktní explicitní směrování (strict source routing) musí být zadány všechny mezilehlé směrovače Přenášená data (payload) teoreticky až do bajtů délky (v součtu se záhlavím), jsou to údaje, které IP vrstvě předal protokol vyšší vrstvy, tedy např. TCP segment Fragmentace a opětovné skládání IP paketů Maximální velikost IP datagramu je bajtů (položka Celková délka IP datagramu o 16 bitech), viz Obr Maximální velikost paketu se označuje MTU (Maximum Transmission Unit) a v různých sítích je její hodnota rozdílná, viz Tab. 5. Proto musí existovat mechanizmy fragmentace (rozdělení na menší části) a blokování (opětovné složení datagramu z jednotlivých částí). Tab. 5: Maximální délka jednotek podle jednotlivých technologií Linkový protokol MTU [bajty] Ethernet II 1500 Ethernet SNAP 1492 Frame Relay 1600 FDDI 4478 ATM 48

30 30 FEKT Vysokého učení technického v Brně Může tedy nastat situace, že paket přenášený od zdroje k cíli přes různé sítě je třeba při přechodu mezi nimi rozdělit, v případě, že hodnota MTU další sítě je nižší než MTU předcházející. Mohou tedy nastat dvě varianty: Fragmentace je možná a provede se, v případě, že bit DF (don t fragment) v IP záhlaví není nastaven, Fragmentace není možná, protože bit DF je nastaven, směrovač datagram zahodí a informuje o tom odesílatele pomocí ICMP zprávy fragmentace zakázána, avšak pro další přenos byla nutná, což je pod-zpráva u typu 3 z Tab. 6. Následující Obr ukazuje první případ, tj. když ke fragmentaci dojde. (Popis následuje níže) IP záhlaví Datová část IP datagramu Identifikace (ID) = 4321, offset = 0, total length = 3400, Don t Fragment (DF) = no, More Fragments (MF) = no IP záhlaví 1. část datagramu ID = 4321, offset = 0, total length = 1500, DF = no, MF = yes IP záhlaví 2. část datagramu ID = 4321, offset = 1500, total length = 1500, DF = no, MF = yes IP záhlaví 3. část MTU = 1500 B ID = 4321, offset = 3000, total length = 440, DF = no, MF = no Obr. 3-13: Schematická ukázka fragmentace IP datagramu Původní paket délky 3400 B je rozdělen (vzhledem k MTU další technologie na trase přenosu) na tři části o délkách 1500 B, 1500 B a 440 B. Součet velikostí dílčích fragmentů je hodnota o 40 B větší než velikost původního datagramu, což je dáno tím, že potřebujeme o dvě IP záhlaví více. U fragmentů se nastavuje pole Posunutí fragmentu od počátku (offset), celková délka datagramu (total length), příznakové bity označující možnost fragmentace (DF) a zda bude následovat další fragment (MF). Že fragmenty patří k sobě, se pozná podle stejné hodnoty pole Identifikace IP datagramu (ID). Všechna ostatní pole IP záhlaví zůstávají stejná jako v původním datagramu. Každý fragment je následně opatřen záhlavím příslušné technologie, např. Ethernet, případně i zápatím, a vyslán na linku IP tunelování Existují situace, kdy je nutné umožnit komunikaci počítačů ve vnitřních (firemních) sítích přes veřejný Internet, tj. je nutno propojit několik VPN sítí (Virtual Private Network). Tunelování zapouzdřuje původní IP paket do nového IP paketu, který má novou cílovou adresu, zpravidla bránu druhé VPN. Tato brána IP paket odpouzdří a zašle skutečné cílové stanici. Tunelování prováděné ve spolupráci s IPsec protokolem zvyšuje bezpečnost VPN

31 Pokročilé komunikační techniky 31 spojení. IP adresy bran na hranicích privátních a veřejných sítí jsou užity ke směrování. Celý obsah paketu včetně vnitřní IP adresy zdroje a cíle hostitelského počítače vnitřní sítě je skrytý vnějšímu světu. Grafické znázornění zapouzdřování je možné nalézt na Obr a) Původní IP záhlaví Datová část datagramu b) Nové IP záhlaví Původní IP záhlaví Datová část datagramu Datová část nového datagramu c) Nové IP záhlaví Zašifrovaný původní paket (IPsec) Obr. 3-14: Zapouzdření paketu při tunelování a) původní paket b) zapouzdřený paket c) zapouzdřený paket s použitím IPsec IP tunelování je velmi užitečné v situaci, kdy jsou dvě počítačové sítě používající stejný síťový protokol (např. IPv4) navzájem propojené sítí s odlišnou verzí protokolu IP, tedy IPv6, případně naopak. (O protokolu IPv6 je pojednáno v kap. 5.) Mezilehlá (transportní) síť pak musí přenášet pakety zabalené do nového záhlaví, aby byla schopna s nimi správně pracovat. Dochází tedy k tunelování původních paketů IPv4. Možnou situaci ilustruje Obr Odchozí brána 1 Tunel Odchozí brána 2 LAN1 IPv4 WAN IPv6 LAN2 IPv4 Nové záhlaví (IPv6) Původní záhlaví (IPv4) Datová část datagramu Původní záhlaví (IPv4) Datová část datagramu Původní záhlaví (IPv4) Datová část datagramu Obr. 3-15: Tunelování paketu IPv4 sítí IPv6 Tato technika není až tak neobvyklá, jelikož existují poskytovatelé, kteří mají již svoje páteřní (transportní) sítě transformované na protokol IPv6 a běžný provoz založený na protokolu IPv4 tak musí být zapouzdřován do záhlaví IPv6. Samozřejmě může docházet i k opačnému zapouzdřování, kdy je provoz protokolu IPv6 zapouzdřován do paketů IPv4, v případě, že mezi dvěma sítěmi IPv6 leží síť fungující na IPv4.

32 32 FEKT Vysokého učení technického v Brně 3.9 Protokol ICMP Protokol ICMP (Internet Control Message Protocol - doslova protokol služebních hlášení) je služební protokol, což znamená, že nepřenáší žádná uživatelská data. Jedná se o klasický příklad aplikace typu klient-server. ICMP je součástí sady TCP/IP protokolů a slouží k signalizaci mimořádných událostí v síti. Jeho obsah se přenáší přímo v IP datagramech, viz Obr znázorňující zapouzdřování ICMP v prostředí Ethernetu. Ethernet záhlaví IP záhlaví ICMP záhlaví Datová část ICMP Ethernet CRC Obr. 3-16: Zapouzdření ICMP paketu přenášeného v síti Ethernet ICMP je určen pro informování o nějakém nestandardním stavu při doručování IP datagramů. Generují se např. při zahození datagramu, kdy se IP nestará o nápravu, ale pouze informuje odesílatele, že se tak stalo. Vybrané druhy ICMP zpráv shrnuje Tab. 6. Tab. 6: Vybrané typy ICMP zpráv Typ Funkce Popis odpověď na požadavek o odezvu (echo reply) nedoručitelný IP datagram (destination unreachable) snížení rychlosti odesílání (source quench) odpověď na výzvu k odezvě (typ 8) paket byl zahozen, důvody jsou standardizovaným způsobem uvedeny ve zprávě použití v situaci kdy je potřeba utlumit rychlost zdroje paketů 8 požadavek na odpověď (echo request) výzva k zaslání odpovědi 11 Vypršel časovač (time exceeded) TTL v IP záhlaví bylo sníženo až na nulovou hodnotu

33 Pokročilé komunikační techniky Protokoly transportní vrstvy sady TCP/IP User Datagram Protocol (UDP) UDP je jednoduchý protokol umožňující nespojovaný (connectionless) a nespolehlivý (nepotvrzovaný) přenos dat v anglické literatuře označováno jako best effort. Jednotlivým přenášeným jednotkám se při použití protokolu UDP říká obvykle datagramy. Pokud je potřeba potvrzovat doručení, musí to být řešeno na úrovni aplikačního protokolu. Typickým příkladem přenosu využívajícího UDP je technika VoIP (Voice over IP). Při přenosu hlasových dat není až tak důležité, aby byl doručen úplně každý datagram. Zpravidla totiž obsahuje jen malou část slova a jeho velikost by zbytečně narostla, kdyby měl každý z nich obsahovat mnoha-položkové záhlaví protokolu. Stejně tak je zbytečné, aby se přenášel datagram opakovaně, protože čekání na opakovaný přenos by komunikaci jen zpomalilo. Záhlaví UDP je tedy maximálně jednoduché, jak je patrné z Obr. 3-17, obsah jednotlivých polí je natolik zřejmý, že není třeba dalšího vysvětlení. Bity Zdrojový port (source port) Cílový port (destination port) Délka dat (UDP length) Kontrolní součet (UDP checksum) Data aplikace Obr. 3-17: Záhlaví UDP protokolu Transmission Control Protocol (TCP) TCP je na rozdíl od UDP spojově orientovaný (connection oriented) a spolehlivý (potvrzovaný přenos) protokol. Délka záhlaví Rezerva Bity Zdrojový port U R G Pořadové číslo odesílaného bajtu Pořadové číslo potvrzovaného bajtu A C K P S H Kontrolní součet R S T S Y N F I N Volitelné položky záhlaví Data aplikace Cílový port Délka okna Ukazatel naléhavých dat Obr. 3-18: Struktura TCP záhlaví

34 34 FEKT Vysokého učení technického v Brně Mezi komunikujícími stranami nejdříve naváže spojení, až poté zahájí přenos dat. Datové jednotce na úrovni transportní vrstvy a využívající TCP se říká segment. Ztracený nebo poškozený segment je přenášen opakovaně. Záhlaví TCP je výrazně obsáhlejší než u protokolu UDP, viz Obr. 3-18, význam položek je objasněn níže. Zdrojový port (source port) 16 bitů, hodnota indikuje port na straně odesílatele segmentu, vybrané hodnoty portů viz dále. Cílový port (destination port) 16 bitů, hodnota indikuje port na straně příjemce segmentu, není zpravidla shodná se zdrojovým. Pořadové číslo odesílaného bajtu (sequence number SEQ) 32 bitů, odesílané bajty se číslují, pole obsahuje pořadové číslo prvního z odesílaných v segmentu. Pořadové číslo potvrzovaného bajtu (acknowledgment number ACK) 32 bitů, jestliže máme obousměrnou komunikaci (což je většina případů), tak strana, která odesílá data, má možnost v rámci hlavičky těchto dat potvrdit přijetí dat od protistrany. Uvádí se hodnota dalšího očekávaného bajtu, tj. např. když poslední správně přijatý bajt je číslován jako 100, pole obsahuje 101. Délka záhlaví (header length) 4 bity, délka záhlaví v bajtech. Příznakové bity (flags) 6 bitů, význam jejich nastavení na 1 je: - URG (urgent) segment nese naléhavá data - ACK (acknowledgment) indikuje, že hodnota uvedená v poli potvrzovaného bajtu je platná (tj. že segment zároveň i potvrzuje přijetí dat). - PSH (push function) signalizuje, že data mají být ihned po přijetí předána aplikaci a nemá se čekat na přijetí dalších segmentů. - RST (reset the connection) pro řešení situace s duplikáty navazovacích segmentů, k odmítnutí spojení. - SYN (synchronize sequence number) odesílatel začíná novou sekvenci číslování bajtů, využíváno při navazování spojení, viz dále. - FIN (no more data from sender) odesílatel ukončil přenos dat, využíváno při uzavírání spojení, viz dále. Délka okna (window size) 16 bitů, vyjadřuje maximální počet bajtů, které může vysílač odeslat, aniž by čekal na potvrzení od přijímače. Kontrolní součet (TCP checksum) 16 bitů. Ukazatel naléhavých dat (urgent pointer) 16 bitů, pole vyplněno jen když je příznakový bit URG nastaven na 1. Volitelné položky záhlaví (options) pole nemusí být přítomna, jejich délku lze odvodit z celkové délky záhlaví uvedené v příslušné pozici.

35 Pokročilé komunikační techniky Průběh navázání a ukončení spojení TCP Jak již bylo uvedeno, protokol TCP před vlastním přenosem dat nejdříve naváže spojení, přenese data a poté spojení ukončí. Průběh navázání spojení je naznačen na Obr a), ukončení spojení na Obr b). HOST A HOST B HOST A HOST B SEQ = 200, SYN SEQ = 800, FIN SEQ = 500, ACK = 201, SYN, ACK SEQ = 201, ACK = 501, ACK SEQ = 900, ACK = 801, ACK SEQ = 901, FIN SEQ = 801, ACK = 902, ACK a) b) Obr. 3-19: Průběh spojení TCP a) navázání, b) ukončení V obrázku jsou tučně označeny významné příznakové bity, které jsou nastaveny na 1. Navázání spojení začíná tak, že strana, která spojení iniciuje (A), zašle SYN (požadována synchronizace číslování přenášených bajtů v dopředném směru) a v poli SEQ toto číslo nastaví. Druhá strana odpoví nastavením příznaku ACK (synchronizace OK) a zároveň taktéž chce synchronizovat (nastaví SYN bit) číslování pro přenos dat ve zpětném směru a toto prvotní číslo nastaví do SEQ. Ještě potvrdí přijetí bajtu číslovaného jako 200, tím že do pole potvrzovaného bajtu (ACK) dá 201. To vše je odesláno v jednom segmentu. Host A následně nastaví příznak ACK (synchronizace pro zpětný přenos OK), dále potvrdí příjem bajtu číslo 500, tím že do pole potvrzovaného bajtu dá číslo 501. Číslo SEQ samozřejmě vzroste, protože musí být zvýšeno na základě počtu přenesených bajtů. Vzniklá jednotka se opět odešle a spojení je nyní navázáno. Tomuto způsobu navázání spojení se říká three-way handshake (třícestné podání rukou). Zkrácený zápis této komunikace: [SYN] > [SYN, ACK] > [ACK]. Princip ukončení spojení je podobný, na obrázku je naznačen nejobecnější způsob, tzv. four-way handshake (čtyřcestné podání rukou), zkráceně zapsáno jako [FIN] > [ACK], [FIN] > [ACK]. Spojení je v tomto případě v každém směru ukončováno zvlášť. Existuje však i zkrácená verze ukončení spojení, three-way handshake, tj. zprávy: [FIN] > [FIN, ACK] > [ACK]. Do navazování a ukončování spojení může jedna z komunikujících stran promluvit ještě bitem RST, který by měl způsobit znovu-navázání spojení. Podrobnější analýza je však nad rámec tohoto textu.

36 36 FEKT Vysokého učení technického v Brně Ukázka komunikace při použití protokolu TCP Komunikace, tj. výměna zpráv, může v případě protokolu TCP probíhat až po navázání spojení, popsaném v předcházející kapitole. Po ukončení výměny zpráv dojde k uzavření spojení, jak bylo popsáno tamtéž. Obecně může při použití protokolu TCP probíhat komunikace jednosměrně nebo obousměrně. V praxi se však jednosměrná komunikace vyskytuje mnohem méně než obousměrná. Příklady obou typů je možné nalézt na Obr. 3-20a a Obr. 3-20b. HOST A HOST B HOST A HOST B SEQ = 800, délka 200 SEQ = 800, délka 200 ACK = 1001 SEQ = 200, délka 100, ACK = 1001 SEQ = 1001, délka 500 SEQ = 1001, délka 500, ACK = 301 ACK = 1502 SEQ = 301, délka 800, ACK = 1502 SEQ = 1502, délka 100 SEQ = 1502, délka 100, ACK = a) b) Obr. 3-20: Příklad a) jednosměrné a b) obousměrné komunikace s využitím protokolu TCP Jak již bylo uvedeno, bajty zprávy jsou při komunikaci číslovány. Hodnota prvního bajtu se uvede do pole SEQ a dále je důležitá délka přijatých dat, na základě které přijímací stanice vyšle potvrzující zprávou ACK, jejíž hodnota je nastavena na v pořadí další očekávaný bajt. Na Obr. 3-20a se přenáší data pouze ve směru od Hosta A k Hostu B, Host B tedy vždy data jen potvrzuje. Na Obr. 3-20b se přenáší data obousměrně, což znamená, že existují dvě nezávislá pořadová čísla prvního odesílaného bajtu (SEQ), pro každý směr komunikace zvlášť a taktéž dvě nezávislá čísla potvrzovaného bajtu (ACK) Řízení toku dat pomocí TCP Protokol TCP poskytuje mechanizmus pro řízení toku dat, čímž se napomáhá celkové spolehlivosti přenosu. Záhlaví TCP obsahuje pole délka okna, které umožňuje, aby přijímač nastavil, kolik mu vysílač může maximálně odeslat bajtů, aniž by dostal zpátky potvrzení a povolení k odesílání dalších dat. Nedochází tak ke zbytečnému zahlcení a zahazování dat, které přijímač nestihne zpracovat. Problematika fungování tohoto mechanizmu (nazýván technika posuvného okna) přesahuje rozsah tohoto předmětu a je možné ji prostudovat např. v rámci předmětu Moderní síťové technologie.

37 Pokročilé komunikační techniky Adresování na základě portů, základní dělení portů Transportní protokoly UDP i TCP zavádí adresaci na základě portů. Přenášená jednotka (paket) dorazí na základě IP adresy do konkrétního počítače, je však třeba ještě nějakým způsobem odlišit, kterému aplikačnímu protokolu a následně aplikaci (www prohlížeč, ový klient, ftp server, ) se mají přenášená data předat, viz Obr K tomuto účelu jsou určeny porty (16-bitové číslo), v tomto případě cílový port. Porty se dělí do třech skupin, viz Tab. 7, níže je uvedeno několik málo příkladů z nejdůležitější skupiny, viz Tab. 8. Tab. 7: Základní dělení portů Rozsah čísel portů Označení portů (EN) Využití Známé (well-known) Registrované (registered) Soukromé a dynamické (private and dynamic) Vyhrazeno pro dobře známé aplikace, číslo portu zpravidla na straně serveru Pro méně používané aplikace nebo pro porty na straně klienta při komunikaci; jejich použití je registrováno u organizace IANA 6 Dynamicky přiřazované čísla portů na straně klientské aplikace Tab. 8: Vybrané well-known porty Číslo portu Transportní protokol Aplikační služba 20 tcp ftp data 21 tcp ftp řízení 22 tcp ssh 23 tcp telnet 25 tcp/udp smtp 53 tcp/udp dns 67 udp dhcp server 68 udp dhcp klient 69 udp tftp 80 tcp http 443 tcp/udp https Jak bylo uvedeno výše, port slouží k odlišení konkrétního aplikačního protokolu, resp. přímo aplikace v počítači. Jestliže tedy máme např. spuštěný Internetový prohlížeč a připojíme se na libovolný standardně nakonfigurovaný webový server, může pár 6 Kompletní seznam zaregistrovaných a známých portů je možné nalézt na Internetové stránce organizace IANA:

38 38 FEKT Vysokého učení technického v Brně transportních adres vypadat např. tak, jak vyplývá z Obr Port na straně serveru je TCP/80, jak vyplývá i z Tab. 8. Port na straně stanice je náhodný, z určitého rozsahu používaného prohlížečem. Tyto porty jsou zpravidla z rozsahu označovaného jako registrovaný. Stanice IP: IP serveru: Data (segmenty) Zdrojová IP: Zdrojový port: 1794 Cílová IP: Cílový port: 80 Server WWW Server naslouchá na portu: 80 Obr. 3-21: Transportní adresy v případě komunikace webový prohlížeč-webový server Jestliže na tom stejném počítači spustíme prohlížeč dvakrát a ve stejnou chvíli se připojíme na webový server z každého z nich, je nezbytné tyto dva prohlížeče nějakým způsobem odlišit. Jejich komunikace totiž probíhá paralelně. V souladu s výše uvedeným k tomu dojde na základě transportní adresy. Na straně serveru port změnit nelze, proto se číslo portu změní na straně stanice. Situaci ilustruje Obr V tomto případě existují dvě nezávislá transportní spojení mezi danou stanicí a webovým serverem, které jsou odlišeny pouze hodnotou portu na straně stanice, konkrétně TCP/1794 a TCP/1795. Stanice IP: IP serveru: Data 1 Zdrojová IP: Zdrojový port: 1794 Cílová IP: Cílový port: 80 Data 2 Zdrojová IP: Zdrojový port: 1795 Cílová IP: Cílový port: 80 Server WWW Server naslouchá na portu: 80 Obr. 3-22: Transportní adresy v případě dvou paralelních komunikací s jedním serverem V souvislosti s předcházejícími příklady je vhodné zmínit pojem socket, někdy též označovaný jako Internetový socket. Je tak označována kombinace IP adresy a portu a slouží k identifikaci koncového bodu komunikace, celá relace je pak definována dvěma sockety, tj. tím na straně odesílatele a na straně příjemce. Kombinace zdrojového a cílového socketu 7 je 7 V některých zdrojích se uvádí, že socket představuje kombinaci IP adresa a port zdroje i cíle komunikace dohromady, což může být matoucí. V takovém případě tedy transportní komunikace sestává z jednoho socketu. Zde budeme socketem myslet kombinaci jedné IP adresy a portu na jedné straně komunikace.

39 Pokročilé komunikační techniky 39 vždy jedinečná, tj. nikdy neexistují zároveň dvě probíhající komunikace, které by měly všechny čtyři hodnoty stejné. To je vidět i z příkladu uvedeného na Obr. 3-22, kde se dvě paralelní spojení liší pouze v jedné ze čtyř hodnot Segmentace a znovu složení uživatelských dat Některé aplikace přenášejí velké množství dat a bylo by značně nepraktické posílat všechna tato data v jednom kuse. Daleko výhodnější je data rozdělit na menší části a tyto části pak přenášet sítí samostatně. Tomuto rozdělení se říká segmentace a je naznačena na Obr Připomeňme, že jednotka na úrovni transportní vrstvy se nejčastěji nazývá segment (TCP) nebo datagram (UDP). Segmenty jsou předány síťové vrstvě, opatřeny IP záhlavím a jako pakety odeslány. Na straně příjemce jsou pakety předány transportní vrstvě a na základě portu (případně příznaku PSH - viz výše) předány aplikaci. Data aplikace, které mají být přeneseny tcp/udp záhlaví 1. část dat tcp/udp záhlaví 2. část dat tcp/udp záhlaví 3. část dat Obr. 3-23: Segmentace aplikačních dat na úrovni transportní vrstvy Protokoly TCP a UDP neprovádí segmentaci stejným způsobem. TCP přidává do záhlaví pořadové číslo odesílaného bajtu (sequence number), takže pokud segmenty dorazí k příjemci v jiném pořadí, je možné je opětovně seřadit. UDP toto neumožňuje Různé úrovně překladu adres v IP sítích Převod IP adres na fyzické adresy V kap. 3.8 jsme se zabývali IP adresami. Ty představují jednotný způsob adresace, který používá libovolný konglomerát vzájemně propojených sítí na bázi soustavy protokolů TCP/IP. Jsou však stále jen abstrakcí na úrovni síťové vrstvy, která odpovídá představě jednotné virtuální sítě. Ta je ale ve skutečnosti realizována dílčími sítěmi více či méně odlišného typu, které používají své vlastní mechanizmy adresování a formáty adres. Proto také IP adresy musí být převáděny na takové konkrétní (fyzické) adresy, jaké příslušná dílčí síť skutečně používá (na úrovni vrstvy síťového rozhraní). K lepšímu přiblížení je vhodné blíže rozebrat síťovou (Internetovou) vrstvu. Ve skutečnosti je tato vrstva rozdělena na tři podvrstvy:

40 40 FEKT Vysokého učení technického v Brně SNICP = Subnet Independent Convergence Protocol, podvrstva řízení vzájemně propojených podsítí. SNDCP = Subnet Dependent Convergence Protocol, podvrstva přizpůsobení podsítě, SNDAP = Subnet Dependent Access Protocol, podvrstva přístupu k podsíti. Toto rozdělení a funkce jednotlivých podvrstev znázorňuje Obr Právě v podvrstvě SNDCP dochází k převodu IP adresy na fyzickou adresu zvanou NPA = (sub)net Point of Attachment. Transportní vrstva SNICP podvrstva Procedura fragmentace Procedura opětovného skládání Procedura odesílání a příjímání Překladová tabulka IP adresa NPA adresa SNDCP podvrstva Překladová (směrovací) procedura nebo protokol SNDAP podvrstva Obr. 3-24: Obecný princip směrování uvnitř síťové vrstvy hostitelského počítače Způsoby řešení převodu IP adresy na fyzickou adresu a) pomocí přímého převodu Velmi jednoduchá myšlenka, která se v této souvislosti sama nabízí, je neřešit převod výčtem (tj. pomocí tabulky - např. viz Obr. 3-24), ale pomocí vhodné transformační funkce (způsobu převodu). To je ale možné jen tam, kde si zřizovatel sítě může fyzické adresy jednotlivých uzlů volit sám, podle vlastních potřeb. Má-li například volitelná fyzická adresa rozsah 8 bitů, je nejjednodušší volit ji shodně s posledním oktetem (posledními osmi bity) IP adresy. Transformace IP adresy na fyzickou se pak stává zcela triviální matematickou úlohou a není třeba udržovat tabulku odpovídajících si adres. b) pomocí dynamické vazby Možnost volit fyzickou adresu přímo na síťovém adaptéru při jeho instalaci je v praxi únosná jen pro adresy malého rozsahu. Především je ale spojena s potenciálním nebezpečím lidských chyb, které mohou vyústit v existenci dvou adaptérů resp. uzlů se stejnou fyzickou adresou v jedné síti. Většina síťových technologií se proto k celému problému staví opačně -

41 Pokročilé komunikační techniky 41 uživateli nedávají žádnou možnost ovlivnit fyzickou adresu síťového adaptéru, ta je totiž u každého adaptéru předem pevně dána 8. Takto je tomu například u lokálních sítí typu Ethernet. Ty používají fyzické adresy v rozsahu 48 bitů, které v příslušných síťových adaptérech nastavuje přímo jejich výrobce. Aby se zajistila jednoznačnost adres i mezi síťovými adaptéry různých výrobců, musí si každý z nich nechat přidělit určitý rozsah adres od centrální autority, která Ethernetovské adresy spravuje (v tomto konkrétním případě jde o americké sdružení IEEE). Jakmile je ale potřeba transformovat 32-bitové IP adresy na 48-bitové Ethernetovské (či jiné "velké" adresy, které není možné podle potřeby volit), nezbývá jinak, než se vrátit zpět k převodním tabulkám, definujícím vzájemnou vazbu mezi jednotlivými adresami. Pokud možno ale nikoli ke statickým tabulkám, ale naopak k tabulkám dynamickým, které se vytváří a modifikují průběžně, podle okamžitého stavu sítě. Komunikující uzel má obě adresy (reálnou fyzickou a imaginární síťovou) a je potřeba mít mechanizmus, jak zajistit převod mezi adresami: ARP (Address Resolution Protocol), který dokáže zjistit MAC adresu uzlu, pokud známe jeho IP adresu, více v kap , RARP (Reverse Address Resolution Protocol), reverzní ARP, více v kap Address Resolution Protocol (ARP) Problém transformace adres vyšší úrovně na adresy nižší úrovně, konkrétně nalezení odpovídající fyzické adresy k IP adrese, se označuje jako address resolution problem. Je možné jej řešit například formou tabulky, obsahující seznam vzájemně si odpovídajících adres. Je to ovšem spojeno s četnými problémy - kdo a jak zajistí počáteční naplnění tabulky, kdo ji bude udržovat a přizpůsobovat momentálnímu stavu sítě, kdo zajistí, aby její velikost nepřesáhla únosnou mez atd. Proto tam, kde je to jen trochu možné, se používají spíše jiná řešení, která jsou ovšem závislá na konkrétní povaze (dílčí) sítě a jí používanému mechanizmu adresování. ARP je protokolem, který řeší address resolution problem právě pomocí tabulky dočasných záznámů (cache). Základní vlastnosti ARP Dynamický, distribuovaný protokol, schopný reagovat na změny v síti, určen k posílání datagramů na určitý uzel (koncovou stanici nebo směrovač) v lokální síti, kde neznáme její fyzickou/linkovou (MAC) adresu, ale známe adresu IP; v obecném případě zjištění adresy druhé úrovně na základě znalosti adresy třetí úrovně. informace o odpovídajících si adresách se ukládají do tabulky, podle potřeby se obnovují, položky jsou zpravidla uloženy pouze dočasně na několik minut a pak vymazány, protože se mohly stát neaktuální anebo již nejsou potřeba, ARP pracuje mezi linkovou a síťovou vrstvou, používá rámce linkové, např. u Ethernetu je v položce typ hodnota indikující ARP rovna 0x0806. Struktura ARP paketu je znázorněna na Obr. 3-25, níže následuje popis jednotlivých položek. 8 Většina operačních systémů pak samozřejmě umožňuje fyzickou adresu přenastavit administrátorem systému.

42 42 FEKT Vysokého učení technického v Brně Bity Typ média Typ protokolu Délka fyzické adresy Délka logické adresy Operace Fyzická adresa zdroje (zpravidla MAC adresa) Logická adresa zdroje (zpravidla IP adresa) Hledaná fyzická adresa (zpravidla MAC adresa) Hledaná logická adresa (zpravidla IP adresa) Obr. 3-25: Struktura ARP paketu Typ média (Hardware type) 16 bitů, hodnota indikující typ použitého média, např. pro Ethernet je hodnota 0x0001, ATM má 0x0010. Typ protokolu (Protocol type) 16 bitů, hodnota indikuje typ vyššího protokolu, v rámci něhož se logická adresa používá, pro IP je hodnota 0x8000. Délka fyzické adresy (Hardware length) 8 bitů, délka fyzické adresy v bajtech, pro Ethernet 0x06. Délka logické adresy (Protocol length) 8 bitů, délka logické adresy taktéž v bajtech, pro IPv4 adresu 0x04. Operace (Operation) 16 bitů, specifikuje operaci, kterou odesílatel paketu provedl hodnota 0x0001 pro požadavek na zjištění fyzické adresy, hodnota 0x0002 pro odpověď. Fyzická adresa zdroje / hledaná (Sender / target hardware address) délka je specifikována v poli délka fyzické adresy, obsahuje fyzickou adresu zdroje / hledanou. Logická adresa zdroje / hledaná (Sender / target logical address) délka je specifikována v poli délka logické adresy, obsahuje logickou adresu zdroje / hledanou. Příklad 3.7 Fungování ARP (zdrojová a hledaná stanice jsou ve stejné síti) Popis situace Představme si dva hostitelské počítače A a B, které mají po řadě IP adresy IA a IB. Předpokládejme dále, že jde o uzly téže (dílčí) sítě, které díky tomu mohou mezi sebou komunikovat přímo, viz Obr V rámci své dílčí sítě přitom mají oba uzly fyzické adresy FA a FB. Jestliže nyní síťová vrstva (IP vrstva) počítače A dostane od své transportní vrstvy za úkol přenést určitá data počítači s IP adresou IB (tj. počítači B), musí být schopna zajistit převod IP adresy (IB) na fyzickou adresu (FB). Tu totiž potřebuje příslušný ovladač v bezprostředně nižší vrstvě síťového rozhraní, aby mohl přenášená data skutečně doručit. Řešení Stanice A prozkoumá svoji tabulku odpovídajících si fyzických a síťových adres (ARP cache), a pokud nenajde informaci odpovídající hledané síťové adrese IB, musí použít protokol ARP. Vyšle žádost (request) protokolu ARP s informacemi o zdrojové (tj. svojí) dvojici adres (fyzické a síťové FA a IA) a s hledanou IP adresou (IB), kterou adresuje všem stanicím v síti (na všeobecnou adresu MAC - tzv. broadcast). Žádost přijmou všechny stanice v síti, odpověď odešle pouze stanice B, ostatní paket zahodí. Stanice B tedy reaguje

43 Pokročilé komunikační techniky 43 odpovědí (reply) s vyplněným polem hledané fyzické adresy FB zaslanou na adresu (FA) zdrojové stanice (již ne broadcast) s doplněnou informací o své MAC (FB) a současně zkontroluje obsah své paměti ARP, zda ji nedoplnit o dvojici adres (IA a FA) obdržených v žádosti ARP. FB Host B WAN LAN Odchozí brána FA Host A Obr. 3-26: Ilustrace situace pro Příklad 3.7 Příklad 3.8 Fungování ARP (zdrojová a hledaná stanice nejsou ve stejné síti) Popis situace stejně jako v předcházejícím příkladu, jen stanice A a B nejsou v rámci jedné sítě, viz Obr LAN1 Odchozí brána 1 WAN Odchozí brána 2 LAN2 FA FB Host A Host B Obr. 3-27: Ilustrace situace pro Příklad 3.8 Řešení Pokud hledaná stanice není ve stejné síti (lze zjistit snadno výpočtem jako v Příklad 3.3), potom stanice zasílá rámec na fyzickou adresu výchozí brány (default gateway) a ta se chová jako zástupce hledané stanice (proxy ARP). Pokud stanice fyzickou

44 44 FEKT Vysokého učení technického v Brně adresu směrovače nezná, zjistí si ji stejně, jakoby zjišťovala adresu stanice, tj. pomocí ARP. Výchozí brána následně paket odešle do sítě, kde se nachází cílová IP adresa (IB) Reverse Address Resolution Protocol (RARP) RARP není přímo opakem ARP, jak by se nabízelo, tj. neprovádí vyhledávání libovolné logické adresy (IP) na základě fyzické adresy (MAC), to je účelem protokolu Inverse ARP. RARP se používá při znalosti vlastní fyzické adresy pro získání vlastní logické adresy, nejčastěji pro zjištění vlastní IP adresy při startu systému (např. v případě bezdiskových stanic, které potřebují zjistit svoji IP adresu od serveru v síti). Stanice vygeneruje žádost RARP na všeobecnou adresu se svou adresou fyzickou a očekává odpověď s informací o přidělené IP adrese. RARP server obsahuje databázi hardwarových adres (např. MAC) s přiřazenými IP adresami. RARP žádost obsahuje pouze vlastní hardwarovou adresu a RARP server vrací odpověď s vyplněnou korespondující IP adresou žadatele. Vzhledem k tomu, že samotná IP adresa je nedostatečná pro komunikaci v IP sítích, není protokol RARP používán. Častěji se setkáme s komplexnějšími aplikačními protokoly, jako jsou BOOTP (Bootstrap Protocol) nebo nejvíce jeho nástupce DHCP, viz kap Formát rámce je u RARP stejný jako u protokolu ARP, avšak pole operace má pro žádost hodnotu 0x0003 a pro odpověď 0x0004. RARP pracuje taktéž mezi linkovou a síťovou vrstvou, používá rámce linkové Dynamic Host Configuration Protocol (DHCP) DHCP je aplikační protokol pro dynamické nastavení parametrů sítě (IP adresa, maska sítě, výchozí brána, DNS servery, ). Funguje na principu klient-server. DHCP server propůjčí tyto parametry sítě síťové stanici na určitou dobu. Po této době musí stanice žádat o adresu znovu. DHCP server u každého klienta eviduje IP adresu a čas, do kdy ji klient smí používat (doba zapůjčení, lease time). DHCP protokol je rozšířením staršího BOOTP protokolu, který přiděloval IP adresy na neomezenou dobu. DHCP je s BOOTP obousměrně kompatibilní. To znamená, že DHCP klienti dovedou získat nastavení z BOOTP serveru a DHCP server může přidělit IP adresu BOOTP klientovi (zde je třeba opatrnosti, protože BOOTP klient bude jednou přidělenou IP adresu používat už navždy). DHCP využívá transportního protokolu UDP, klient komunikuje na UDP portu 68, server naslouchá na UDP portu 67. Výhody dynamické konfigurace parametrů sítě prostřednictvím DHCP Jednodušší správa a šetření adresního prostoru, zaručuje, že se na síti nevyskytnou dvě stejné IP adresy (tzv. konflikt IP adres), což např. u ruční konfigurace parametrů sítě na každé stanici nelze snadno zaručit, správce sítě může snadno přečíslovat celou síť nebo změnit vlastnosti sítě s minimálním zásahem do práce uživatelů uživatelé si na počítači v souvislosti s připojením k síti nemusí nic nastavovat, pouze musí mít povolené využití služeb DHCP.

45 Pokročilé komunikační techniky 45 Princip fungování DHCP Na Obr je naznačen průběh komunikace při použití protokolu DHCP. Po připojení do sítě klient vyšle broadcastem DHCP_DISCOVER paket. Na ten odpoví DHCP server paketem DHCP_OFFER s nabídkou IP adresy (unicast nebo broadcast podle nastavení příslušného příznakového bitu v předchozí zprávě discover). Klient si z nabídek (teoreticky od několika DHCP serverů v rámci sítě) vybere jednu IP adresu a o tu požádá paketem DHCP_REQUEST (taktéž broadcast). Server mu ji vzápětí potvrdí odpovědí DHCP_ACK. Jakmile klient obdrží DHCP_ACK, může už IP adresu a zbylá nastavení používat. Klient musí před uplynutím doby zapůjčení uvedené v DHCP_ACK obnovit svou IP adresu. To se provádí zkráceně, zasláním DHCP_REQUEST zprávy (běžně unicast) a server následně odpoví DHCP_ACK s novou dobou zapůjčení. Pokud lhůta uplyne, aniž by klient dostal nové potvrzení, nesmí IP adresu dále používat. Protokol DHCP definuje ještě další typy zpráv, např. DHCP_NAK pro případy, kdy server zamítne požadavek klienta nebo DHCP_RELEASE, která umožňuje klientovi vzdát se přidělené konfigurace (např. při korektním vypnutí systému). Další zpráva, DHCP_INFORM, slouží klientovi jako žádost o další informace, server pak na ni požadované informace zasílá ve zprávě DHCP_ACK. Klient DHCP Server DHCP Zahájí iniciaci DHCP_DISCOVER (broadcast) DHCP_OFFER (unicast x broadcast) Nabídne konfiguraci Vybere si konfiguraci (nabídek může dojít více, pokud je v síti více DHCP serverů) DHCP_REQUEST (broadcast) DHCP_ACK (unicast x broadcast) Zvolí konečnou konfiguraci, rezervuje IP adresu, uloží záznam Nastaví konfiguraci Vyprší více než ½ času zapůjčení Pokus o prodloužení stejné IP adresy DHCP_REQUEST (unicast x broadcast) Vyprší více než ½ času zapůjčení IP adresa zůstává, nový čas zapůjčení DHCP_ACK (unicast x broadcast) Potvrdí konfiguraci, nová doba zapůjčení, obnoví záznam Obr. 3-28: Ukázka činnosti DHCP protokolu

46 46 FEKT Vysokého učení technického v Brně Protokol definuje i roli tzv. DHCP relay agenta. Používá se v situaci, kdy existují dvě nebo více sítí oddělené směrovačem a jen jedna síť má DHCP server. V takovém případě správce na směrovači zapne relay agenta a nastaví jej tak, aby všesměrové (broadcast) DHCP dotazy ze sítí bez DHCP serveru přeposílal do té sítě, která ho má. Agent k přeposílanému dotazu přidá informaci o síti, kde klienta zaslechl, aby DHCP server poznal, ze kterého adresního rozsahu má klientovi adresu přiřadit. Možná situace je naznačena na Obr Na obrázku jsou naznačeny dvě lokální sítě LAN1 a LAN2, přičemž pouze v LAN1 se nachází DHCP server. Jestliže se některá ze stanic v LAN2 pokusí využít služeb protokolu DHCP a rozešle tedy všesměrově zprávu DHCP_DISCOVERY, obdrží ji všechny stanice v LAN2, včetně směrovače (vyznačeno modře). V síti bez DHCP relay agenta by zpráva zůstala nezodpovězena, v tomto případě ji však relay agent přepošle DHCP serveru do LAN1 (vyznačeno zeleně). Povšimněte si, že tato zpráva již není v LAN1 šířena všesměrově, ale cíleně přímo DHCP serveru (unicast). Další komunikace stanice s DHCP serverem je pak vyznačena červeně.... DHCP Server... LAN 1 WAN Odchozí brána (směrovač s dhcp relay agentem) LAN 2... DHCP discovery IP? Obr. 3-29: DHCP relay agent příklad využití

47 Pokročilé komunikační techniky Překlad síťových adres (Network Address Translation = NAT) NAT, česky překlad síťových adres, je funkce směrovače pro změnu IP adres paketů jím procházejících, kdy se zdrojová nebo cílová IP adresa převádí mezi různými rozsahy (kap ). Nejběžnější formou je, když směrovač IP adresy z nějakého rozsahu mění na svoji IP adresu a naopak tím umožňuje, aby počítače ve vnitřní síti (LAN) vystupovaly v Internetu pod jedinou IP adresou. Tuto funkci podporují prakticky všechny běžné směrovače. Technika překladu (IP) adres tedy umožňuje oddělit intranet od Internetu, což může být z bezpečnostního hlediska výhodné. Směrovač, na kterém běží NAT, musí být schopen navenek nějakým způsobem odlišit provoz jednotlivých stanic z vnitřní sítě do Internetu. To provádí na základě tabulky překladu adres, kterou si po celou dobu spojení drží v paměti. Ve většině případů má k dispozici jen jednu (veřejnou) IP adresu, která je přiřazena na jeho tzv. WAN (Wide Area Network) port a ve vnitřní síti je více (privátních) IP adres. V tomto případě si směrovač nevystačí pouze se síťovými adresami a musí použít i vyšší (transportní) adresy porty (viz kap. 3.10). Situace může vypadat například následovně: Příklad 3.9 Objasnění nejběžnějšího použití techniky NAT Stanice v lokální síti s adresou se snaží o spojení s www serverem s IP adresou Na straně stanice je vybrán port, např Tedy máme kombinaci IP adresy a portu :1794. Paket s žádosti o spojení dorazí na směrovač s funkcí NAT a ten změní zdrojovou IP adresu v paketu na svoji (veřejnou), např a číslo portu přidělí např. takovým způsobem, že má pro stanici vyhrazené porty a přidělí první volný. Směrovač si uloží překladový záznam do své tabulky. Paket odchází ze směrovače do Internetu a má již jako zdrojovou adresu a port kombinaci :4000. Pokud na směrovač dorazí odpověď na kombinaci :4000, podívá se do své tabulky a na základě záznamu předá paket do vnitřní sítě na kombinaci :1794. Situaci ilustruje Obr Je naprosto zřejmé, že spojení může být iniciováno pouze počítačem z vnitřní sítě (výhodné z hlediska bezpečnosti, ale zároveň limitující pro využití některých služeb). Stanice s privátní adresou IP: LAN IP LAN: Směrovač s NAT IP WAN: WAN (Internet) IP serveru: Server WWW Paket Zdrojová IP: Zdrojový port: 1794 Cílová IP: Cílový port: Změna paketu Zdrojová IP: Zdrojový port: 4000 Cílová IP: Cílový port: 80 Změna odpovědi Zdrojová IP: Zdrojový port: 80 Cílová IP: Cílový port: 1794 Odpověď Zdrojová IP: Zdrojový port: 80 Cílová IP: Cílový port: 4000 Obr. 3-30: Ukázka fungování techniky překladu adres (NAT)

48 48 FEKT Vysokého učení technického v Brně Pozn.: V případě využití kombinace IP adres a portů není název NAT úplně správný, v takové situaci se jedná o kombinaci služeb NAT s PAT (Port Address Translation), někdy označovanou NAPT (Network Address Port Translation). Název NAT je však běžnější. NAT můžeme dělit na dva základní druhy: SNAT = Source NAT, překlad zdrojové IP adresy a případně portu. DNAT = Destination NAT, překlad cílové IP adresy a případně portu. Předcházející Příklad 3.9 je de facto příkladem obou těchto technik NAT. Primárně se však jedná o SNAT, jelikož překlad byl zahájen záměnou zdrojové IP (a portu). Následná záměna cílové IP (a portu) už pouze souvisí s první provedenou změnou a je nezbytná pro správné fungování přenosu. DNAT se primárně používá k zveřejnění služby z interní sítě na veřejně přístupnou IP adresu. Vysvětlení je podáno na Příklad Příklad 3.10 Objasnění techniky DNAT Situaci graficky znázorňuje Obr Stanice s veřejnou IP adresou ( ) se snaží o spojení s www serverem, o kterém prostřednictvím DNS (viz kap ) zjistila, že je dostupný na IP adrese Na straně stanice je vybrán náhodný port, např Paket s žádosti projde přes síť WAN až ke směrovači s IP Na směrovači běží DNAT. Jestliže na něj dorazí zpráva adresovaná na cílový port 80, přepošle ho na www server do lokální sítě (jen za předpokladu, že byla tato operace na směrovači povolena). Přeposlání spočívá ve změně cílové IP na lokální IP ( ). (V případě, že by příchozí zpráva obsahovala cílový port 21, byla zpráva přeposlána na ftp server do lokální sítě atd.) O této záměně adres se stanice, která vysílala zprávu, nedozví. Server odpoví a na směrovači je při průchodu změněna zdrojová IP. Protože první měněná IP byla cílová, jedná se o DNAT. Z bezpečnostního hlediska je zajímavé, že vnitřní síť obsahující servery je skryta před vnějšími sítěmi. Ve vnitřní síti může např. fungovat více webových serverů, mezi které bude směrovačem rozložena zátěž. To už však přímo s NATem (DNAT) nesouvisí a tato problematika je nad rámec tohoto textu. Zdrojová IP: Zdrojový port: 3094 Cílová IP: Cílový port: 80 Paket Stanice s veřejnou IP adresou IP: WAN (Internet) Zdrojová IP: Zdrojový port: 3094 Cílová IP: Cílový port: 80 Změna paketu IP WAN: IP LAN: Změna odpovědi Směrovač s DNAT Zdrojová IP: Zdrojový port: 80 Cílová IP: Cílový port: 3094 LAN IP serveru: Odpověď Server WWW Zdrojová IP: Zdrojový port: 80 Cílová IP: Cílový port: 3094 Server ftp Obr. 3-31: Objasnění techniky DNAT

49 Pokročilé komunikační techniky 49 Pro server ve vnitřní síti představuje směrovač s DNAT de facto veřejný přístupový bod serveru. Bez DNAT by server nebyl přístupný. Je zřejmé, že bez DNAT se neobejdeme, pokud chceme ve své lokální síti s privátním adresováním provozovat veřejně přístupné služby, např. server www, ftp apod. Techniky SNAT a DNAT se často kombinují. Jestliže by v přecházejícím Příklad 3.10 byly v lokální síti spolu se servery i stanice, jejich uživatelé by bez SNAT na směrovači nemohli komunikovat s vnějšími sítěmi. Důvodem jsou jejich privátní IP adresy. Technika NAT může být použita při přenosu paketu i vícekrát. Z jednoho bodu v komunikačním řetězci nelze stanovit, zda po trase někde k překladu dojde nebo ne. Překlad adres může probíhat i mezi verzemi protokolu IP (IPv4 a IPv6) PT = protocol translation, častěji se však setkáme s technikou IP tunelování, více viz kap Překlad nemusí být vždy nutně mezi veřejnou a privátní IP, může probíhat i tak, že se změní veřejná IP na jinou veřejnou IP adresu, pokud je to výhodné. Stejně tak se může změnit privátní adresa na jinou privátní. Vždy však platí, že jsou zaměňovány adresy ze dvou různých sítí, případně dvou různých podsítí. V některých zdrojích je možné nalézt ještě další způsoby rozdělení, obecně lze konstatovat, že druhů NAT je definováno mnoho. Častým případem je, že jeden konkrétní výrobce hardware implementuje NAT s nějakým konkrétním vylepšením a marketingově ho označí upraveným názvem. Toto však z našeho pohledu není podstatné. Problémy a výhody NATu Z předcházejícího textu je zřejmé, že NAT přináší i jistá omezení. Problém spočívá v tom, že při použití techniky NAT ztrácíme jednu ze základních předností Internetových sítí postavených na sadě TCP/IP obousměrnou konektivitu typu end-to-end. Přímé spojení dvou koncových uzlů je s použitím techniky NAT vždy nějakým způsobem omezeno. To může být problematické pro některé Internetové protokoly, např. FTP. Nejvíce problematická je situace, kdy oba koncové systémy jsou odděleny od vnějších sítí prostřednictvím NATu. Za určitou nevýhodu je možné považovat i určité časové zpoždění, které s NATem nutně souvisí. Je logické, že překlad adres zabere více času, než jednoduché směrování. Navíc směrovač kromě záměny adres (a případně i portů) ještě musí následně přepočítat kontrolní součty v záhlavích (IP a UDP nebo TCP). Tyto kontrolní součty totiž berou v úvahu i IP adresy a porty. Při jejich změně bez přepočítání kontrolních součtů by došlo v cílové destinaci k zahození paketu. Bezpečnostní výhody NATu již byly uvedeny. V případě použití SNATu může komunikace vzejít pouze z vnitřní sítě. Z vnějšku nemůže být spojení zahájeno (to lze pouze s DNAT), což uživatele ochrání před mnohými škodlivými útoky. Za velmi podstatnou výhodu se také v případě IPv4 sítí považuje úspora veřejného adresního prostoru. V případě nasazení totiž mohou být za NATem schovány privátní IP adresy, jejichž použití může být v rámci celého Internetu neomezeně opakované. Samozřejmě za předpokladu, že tyto sítě jsou do veřejného Internetu připojeny prostřednictvím NATu.

50 50 FEKT Vysokého učení technického v Brně Převod IP adres na jména - Domain Name System (DNS) Obecný popis protokolu DNS DNS je aplikační protokol využívající transportní porty UDP/53 i TCP/53. Jak bylo uvedeno dříve, IP adresy představují abstrakci na úrovni síťové vrstvy. Větší počet těchto adres je však pro člověka jen těžko zapamatovatelný. DNS tak vytváří ještě vyšší úroveň abstrakce, konkrétně na aplikační úrovni. Síťovým IP adresám je přiřazeno relativně snadno zapamatovatelné jméno (DNS název). Výjimka z tohoto systému je zřejmá samotný DNS server musí být zadán IP adresou, aby bylo možné s ním komunikovat. DNS primárně zajišťuje (decentralizovaným způsobem) překlad jména hostitele (počítače) na jeho IP adresu a naopak (reverse mapping viz kap ). Systém je založen na principu klient server, jedná se o distribuovanou datovou službu. Server DNS není pouze jeden, jsou organizovány hierarchicky, stejně jako jsou hierarchicky tvořeny názvy domén, viz Obr Vazby mezi jmény počítačů a IP adresami jsou uloženy v DNS databázi, která je celosvětově distribuována. Základní jednotkou systému je tzv. jmenný server (name server), často nazývaný DNS server. (Root) (tečka) org com edu cz (Czech) fr (France) FirmaA FirmaB FirmaC STANICE1 Marketing Vyroba Vyvoj stanice1.firmac.cz STANICE1 STANICE2 stanice2.marketing.firmaa.cz Obr. 3-32: Hierarchie DNS Domény a doménová jména Počítače jsou organizovány v hierarchii domén, viz Obr Doménou je skupina počítačů, které jsou v nějakém vztahu vůči sobě (buď tvoří nějakou organizační jednotku, nebo jsou geograficky blízko sebe). Např. doména.edu (jedna z tzv. top-level domain = TLD) je vyhrazena pro americké univerzity, naproti tomu.cz sdružuje počítače patřící do České republiky. V doméně se mohou vyskytovat jak koncové počítače, tak subdomény (FirmaA.cz), které se opět mohou dělit (FirmaA.cz > Marketing, Vyroba, Vyvoj), kvůli lepší údržbě a snazší symbolické identifikaci. Doménové jméno se vždy vyhodnocuje zprava doleva, od nejvyšší úrovně (root) po nejnižší. Každý uživatel Internetu dnes považuje za samozřejmé, že doménový název je tvořen několika řetězci znaků oddělených tečkami. V základním systému DNS platí, že celková

51 Pokročilé komunikační techniky 51 délka jména může být maximálně 255 znaků a jeden dílčí řetězec maximálně 63 znaky. Takto dlouhá jména se však používají jen v ojedinělých případech, většinou jsou řetězce dlouhé 4 až 10 znaků (utko, vutbr, seznam atd.), s výjimkou domén nejvyšší úrovně, kde jsou řetězce nejčastěji dlouhé 2 až 4 znaky (cz, int, eu, arpa atd.). Povolené znaky jsou pouze písmena (bez diakritiky a nezáleží, zda velká nebo malá), číslice a pomlčky. Platí pravidlo, že pomlčka nemůže být na začátku ani na konci řetězce. Existují i rozšíření, která umožňují používat v systému DNS další znaky, zpravidla národních abeced. Řeč je o systému IDN, o kterém je stručně pojednáno v kap Zóny Jmenný prostor (name space) se rozděluje na domény. Doména však může být sama o sobě dosti velká oblast, proto existuje ještě další rozdělení na tzv. zóny, které již zpravidla obsluhují samostatné DNS servery. Data o doméně, která jsou uložena na DNS serveru, se nazývají zónou. Rozdíl mezi doménou a zónou je následující: do domény spadají všechny počítače, které mají společné jméno domény, kdežto do zóny patří pouze ty počítače, které mají společný také primární DNS server. V normálním režimu používají koncové počítače protokol UDP, délka paketu je omezena na 512 B, tak aby nehrozila jeho fragmentace. Protokol TCP je používán ke komunikaci mezi dvěma DNS servery k tzv. zónovým přenosům (zone transfer). Zónové přenosy slouží k zálohování DNS databází z primárního serveru na sekundární. (Na primárním serveru správce udržuje databázi a ta se pak automaticky a pravidelně přenáší na sekundární servery zálohy pro případ výpadku primárního serveru.) Pokud je DNS databáze poškozena, ať už náhodně nebo úmyslně, může dojít k narušení bezpečnosti, problematika bezpečnosti však není v tomto materiálu akcentována, jsou jí věnovány jiné předměty Způsob komunikace v DNS systému Ilustraci o průběhu komunikace s využitím DNS serveru poskytuje Obr DNS Server Stanice 1 3 DNS dotaz na 2 DNS odpověď Navázat spojení s ( Obr. 3-33: Komunikace s využitím DNS serveru (zjednodušeno) Stanice, která chce komunikovat s vyšle dotaz na DNS server (name server), ten se podívá do svých záznamů a v odpovědi zašle IP adresu. Stanice pak již může

52 52 FEKT Vysokého učení technického v Brně přímo kontaktovat požadovaný stroj. Pokud DNS server nenalezne potřebný záznam ve své paměti, kontaktuje nadřazený DNS server (pokud takový existuje) nebo kořenový (root) DNS server, více viz kap Tato komunikace je však klientovi systému DNS skryta a probíhá přímo mezi servery DNS Resolver Ve skutečnosti je fungování překladu mírně složitější, než bylo popsáno výše. V rámci operačního systémů existuje tzv. resolver. Je to klient, který zprostředkovává stanici (všem aplikacím ftp, www, telnet atd.) případné dotazy na DNS servery. Než resolver kontaktuje DNS server, vždy prověří, zda není požadovaný překlad definován staticky 9, případně zda daný překlad již nebyl v nedávné době proveden a není uložen v lokální dočasné paměti (cache). Dotazování na DNS server je zpravidla vícenásobné i při jediném překladu. Vysvětlení je podáno na následujícím příkladu. Příklad 3.11 Ukázka fungování resolveru Mějme stanici, která se nachází v doméně utko.feec.vutbr.cz. Uživatel prostřednictvím své aplikace požádá o překlad Jestliže se v daném počítači nenalezne odpovídající záznam v souboru statických překladů ani v dočasné paměti, resolver se pokusí o překlad odesláním dotazu na DNS server. Jelikož se však počítač nachází v doméně utko.feec.vutbr.cz, resolver nejdříve vyzkouší, zda uživatelem zadaný řetězec není lokálním názvem, platným v rámci dané domény. První dotaz o překlad tedy obsahuje požadavek na překlad Server DNS (v tomto konkrétním případě) odpoví, že takové jméno se v jeho zóně nenachází. Dalším krokem resolveru je pokus o překlad v doméně vyšší úrovně, tedy feec.vutbr.cz. Další dotaz je tedy na překlad v případě neúspěchu následuje ještě Jestliže ani na této (druhé) úrovni domény neuspěje, resolver předpokládá, že stanice s názvem je mimo danou doménu a zažádá čistě o překlad DNS názvu V tomto případě se již dočká požadované odpovědi ve formě IP adresy. Jak tuto informaci DNS server získal je uživateli skryto. Vysvětlení viz kap Systému, popsaného v tomto příkladu, lze využít k usnadnění vzájemné komunikace v rámci domény. Jestliže budeme mít ve výše uvedené doméně dva počítače, jeden s celým názvem teko.utko.feec.vutbr.cz a druhý s názvem adela.utko.feec.vutbr.cz, lze s těmito počítači (servery) komunikovat pouze pomocí názvů, platných v rámci domény, tedy teko a adela. Na DNS serveru se také vyskytuje resolver, který pracuje podobně jako ten na běžné stanici. Pracuje s lokální databází (a cache) a v případě, že při vyřizování dotazu od klienta nenalezne odpovídající záznam, kontaktuje vzdálený (např. nadřazený) DNS server. Jestliže získá odpověď, přepošle ji jako odezvu na původní dotaz klienta. 9 V případě, že je DNS překlad definován staticky, překlad přes DNS server se neprovádí. K uložení záznamů o statickém překladu slouží soubor hosts, který je možné nalézt (ve Windows XP) ve windows složce /system32/drivers/etc. Obdobný soubor existuje i v jiných operačních systémech. Ruční zásahy do tohoto souboru lze však doporučit pouze v odůvodněných případech.

53 Pokročilé komunikační techniky Primární a sekundární DNS servery Data o překladech jsou na DNS serverech uložena na pevném disku a po jeho spuštění se načtou do paměti. To platí pro primární DNS server v dané zóně. Sekundární 10 DNS server získává data tzv. zónovým transferem, který probíhá v pravidelných časových intervalech. Tato data jsou pak označována jako autoritativní (nezvratná) daný server je pro zodpovězení daného dotazu autoritou. DNS server nevystačí pouze s daty o své zóně, potřebuje i nějaké informace o svém okolí. Jsou to informace o kořenových DNS serverech a případně i dalších serverech DNS. Tato data se označují jako neautoritativní. Jako neautoritativní jsou označeny i DNS odpovědi, které DNS server získal z databáze jiné zóny. DNS server tím dává uživateli de facto najevo, že za danou informaci nemůže sám ručit Kořenové DNS servery Kořenové (root) DNS servery obsluhují root doménu. Tyto servery jsou využívány běžnými DNS servery k přesměrování na jiné (místní) doménové servery. Způsob, jakým jsou využívány kořenové DNS servery, je patrný z Obr Popis následuje. Požadavek na překlad, odpovědí odkaz na doménový serveru pro.cz 2 Root server Požadavek na překlad názvu marketing.firma.cz Klient systému DNS Výsledek překladu (IP adresa) 1 6 Místní server DNS Požadavek na překlad, odpovědí odkaz na doménový server firma.cz Server spravující doménu.cz Požadavek na překlad (marketing.firma.cz), následně odpověď (IP) Cache Server spravující doménu firma.cz Obr. 3-34: Systém DNS z pohledu místního serveru DNS využití dalších DNS serverů V prvním bodě (1) resolver zformuluje dotaz a zašle ho na místní DNS server. DNS server zkontroluje svoje záznamy a v případě, že nalezne hledaný překlad, odpověď odešle. K tomu však v tomto příkladu nedošlo. V dalším kroku (2) proto místní DNS server kontaktuje některý z kořenových serverů s dotazem na překlad, přičemž bude zpravidla odkázán na doménový server nejvyšší domény 11, v příkladu.cz. Situace se opakuje, místní server kontaktuje doménový server s dotazem na překlad (3) a ten, pokud není sám schopen překladu, provede odkázání na doménový server druhé úrovně, který spravuje konkrétní subdoménu. Pokud tento DNS server již disponuje požadovanou informací, provede se překlad (4), může však i v tomto kroku dojít na odkázání se na jiný (více zanořený) DNS 10 Vždy by měla existovat alespoň dvě místa, kde je uložena databáze, z důvodu výpadku nebo nedostupnosti jednoho z nich. Fungování DNS je totiž pro fungování síťových aplikací kritické. Proto je běžně pro stanice definován primární a sekundární DNS server v parametrech TCP/IP. 11 Kořenový DNS server zná adresy všech DNS serverů nejvyšší úrovně a je schopný na ně tázající se DNS server odkázat. To je hlavní úloha kořenových serverů.

54 54 FEKT Vysokého učení technického v Brně server. Po obdržení informace o překladu si tento záznam místní DNS server uloží do dočasné paměti (5) a poskytne ji klientovi (6), který celý proces inicioval Seznam kořenových DNS serverů Kořenové DNS servery obsluhují nejvyšší (root) DNS zónu a jejich úkolem je především přesměrovávat dotazy na DNS servery do jednotlivých TLD domén (.com,.cz,.int, ). Jedná se o 13 serverů provozovaných mimo jiné společností VeriSign, některými americkými univerzitami, NASA, ICANN, RIPE NCC, americkou armádou apod. Jejich fyzické umístění je často v USA (první kopie), spíše jsou ale tyto servery distribuovány do více lokalit ve skutečnosti serverů není 13, ale přibližně Určitá skupina DNS serverů se vzhledem ke svým uživatelům tváří jako jeden server, je distribuována. Uživatel komunikuje zpravidla s tím DNS serverem, který je mu fyzicky nejblíže. Jiný uživatel umístěný v jiné lokalitě komunikuje s fyzicky jiným serverem, než první uživatel, přestože oba používají např. služeb serveru M. DNS název serverů je vždy X.root-servers.net, kde X je písmeno označující daný server, tedy A až M Reverzní překlad domény Běžná je situace, že uživatel zadá DNS název a systém DNS se postará o jeho překlad na IP adresu. Může nastat i situace, kdy vyžadujeme opačný reverzní způsob překladu (reverse mapping) získat DNS název na základě IP adresy. Pro účely reverzního překladu byla definována pseudodoména s názvem in-addr.arpa. Jedná se o zkratku výrazu inverse address in the Arpanet. V DNS dotazu se IP adresa, ke které se hledá DNS název uvádí v následujícím zápisu: IP adresa stroje: Informace v DNS dotazu: Odpověď od DNS serveru: in-addr.arpa teko.utko.feec.vutbr.cz Ze zápisu je zřejmé, že IP adresa se zapisuje do DNS dotazu ve formátu s opačným pořadím oktetů. Typ věty RR (viz kap ) je v tomto případě PTR (Domain name pointer) Systém DNS a změna IP adres Kdyby neexistoval systém DNS, musel by uživatel při požadavku na komunikaci např. s www nebo ftp servery zadávat jejich IP adresu. Pro běžného uživatele je prakticky nemožné pamatovat si IP adresy všech používaných serverů. To však nyní pomiňme, jistě by bylo možné nalézt systém, jak tento problém řešit. Co však v situaci, kdyby se IP adresa serveru změnila? K tomu může dojít velmi snadno. Např. dojde k přečíslování stanic v síti anebo se celá síť, kde se nachází i uvažovaný server, přesune k jinému poskytovateli internetového připojení dojde k fyzickému přestěhování nebo využití alternativní nabídky připojení. V tomto případě dojde zákonitě ke změně IP adresy serveru a jeho uživatelé se to musí nějakým způsobem dozvědět, aby mohli jeho služeb i nadále využívat. Systém DNS od těchto potíží uživatele osvobozuje. Jestliže dojde ke změně IP adresy, stačí upravit záznam ve jmenném prostoru DNS serveru. Uživatelé se při pokusu 12 Mapa umístění kořenových serverů je k dispozici na

55 Pokročilé komunikační techniky 55 o komunikaci se serverem díky systému DNS dozví o platné IP adrese serveru a komunikace může bez problémů proběhnout Věty RR DNS záznamy, tj. informace (nejen) o doménových jménech a odpovídajících IP adresách, jsou uloženy v záznamech nazývaných věty RR (Resource Records). V případě, že resolver (DNS klient) požaduje po serveru získání informací, pak požaduje po DNS serveru věty RR podle svých požadavků. Vybrané typy vět RR jsou A (A host address) 32-bitová IPv4 adresa, slouží jako výsledek překladu. MX (Mail exchanger) speciální záznam pro mail servery domény. NS (Authoritative name server) doménové jméno DNS serveru, který je autoritou pro danou doménu, používá se k přesměrování na jiný DNS server. PTR (Domain name pointer) přenos doménového jména, využito k reverznímu překladu. AAAA (IPv6 address) 128-bitová IPv6 adresa, slouží jako výsledek překladu. CNAME (Canonical name for an alias) doménové aliasy (další možné názvy domény, které odkazují na stejný stroj). Dále lze také použít k odlišení dvou různých služeb na jednom stroji (jedné IP adrese), tj. např. ftp.moje-domena.cz a Na typu věty RR je závislá pouze datová část DNS zprávy, záhlaví má obecný formát, jenž je naznačen na následujícím Obr NAME (doménové jméno) TYPE (typ věty, viz výše) CLASS (třída věty IN=Internet) TTL (platnost dat) RD-LENGTH (délka datové části) RDATA (datová část, závislá na typu věty, viz výše) Obr. 3-35: Struktura věty RR Formát DNS paketu DNS protokol definuje pouze několik typů operací. Především se jedná o DNS QUERY a DNS QUERY RESPONSE. Význam je zřejmý, první typ je dotazem na překlad, druhý je odpověď. DNS využívá stejný formát paketu jak pro dotaz (query), tak pro odpověď (query response). Délka je proměnná, základních polí může být až pět, povinné je však pouze jedno. Jsou to: HEADER (záhlaví) jediná povinná položka, obsahuje mnoho polí, např. identifikaci dotazu, čísla určující počty dotazů a odpovědí v paketu, typ paketu, informaci o (ne)autoritativnosti odpovědi, případné chybě a další. QUERY (dotaz/dotazy) obsahuje název překládané domény, její typ a třídu dotazu. Třída domény je většinou IN = Internet, typ pak nejčastěji A (požadavek

56 56 FEKT Vysokého učení technického v Brně na získání IPv4 adresy), případně požadavek na jinou větu RR (viz vybrané věty RR). ANSWER (odpověď/odpovědi) odpověď se skládá ze stejných tří údajů, jaké byly v dotazu, navíc jsou přidány položky tak, jak je naznačeno na Obr. 3-34, podle toho o jako větu RR se jedná. AUTHORITY (autoritativní DNS servery) informace o autoritativních DNS serverech (uvedeno ve větách typu NS). ADDITIONAL (doplňující informace) tato sekce obvykle obsahuje IP adresy autoritativních DNS serverů. Další definované operace jsou např. DNS NOTIFY a DNS UPDATE. DNS NOTIFY je mechanizmus, který umožňuje informovat servery o změně dat v zóně. Zpravidla to funguje tak, že primární server touto zprávou vyzve sekundární server k zahájení zónového přenosu, aniž by se čekalo na vypršení dříve stanoveného časového limitu. Dojde tedy k mimořádné synchronizaci databázi mimo pevně stanovený časový rámec. Běžně se používá technika tzv. inkrementálního zónového přenosu, kdy se přenáší pouze změněná data, nikoliv celá databáze. DNS UPDATE umožňuje dynamicky opravovat záznamy v DNS databázi. Záznamy v databázi je tedy možné přidávat, editovat nebo odebírat i vzdáleně. Bližší popis paketu a fungování obou těchto mechanizmů je možné nalézt v literatuře nebo na Internetu (je nad rámec tohoto textu) Znaky národních abeced v DNS názvech Systém pro podporu diakritiky a různých národních znaků se nazývá IDN (Internationalized Domain Names) a umožňuje používat v DNS názvech prakticky libovolné znaky národních abeced a to včetně symbolů např. z řečtiny, azbuky, čínských znaků, arabštiny apod. V rámci Evropy se využívá např. v Polsku, Německu, Rakousku (dohromady více než 40 registrů DNS na světě), pro občany EU je systém dostupný např. v doméně.eu. V ČR (resp. doméně.cz) podle pravidelných průzkumů, které pořádá CZ.NIC, o zavedení není mezi uživateli ani organizacemi zájem 13, systém je však plně připraven. Důvodem nezájmu o nasazení je především obava o dostupnost domén s diakritikou ze zahraničí a také komunikační šum, který by vznikl (zadávat adresy bez nebo s diakritikou?). Navíc se dá předpokládat, že např. firma názvu Řehoř by měla v případě IDN domény registrovanou jak doménu rehor.cz tak i řehoř.cz, což by znamenalo zvýšení nákladů za registraci DNS domény na dvojnásobek. Je také důležité vzít v potaz, že význam názvu domény postupem času mírně klesá, jelikož většina uživatelů adresy stránek nepíše přímo, ale vyhledává je přes vyhledavače, i v případech, kdy se jedná o jednoduché a dobře známé adresy. Vyhledávač si pak samozřejmě s národními abecedami poradí a dokáže uživatele odkázat na správnou doménu. Přesto se systém IDN postupně rozšiřuje, především v asijských zemích. DNS je (jako většina Internetových protokolů) postaveno na použití sady ASCII znaků (resp. pouze povolené části této množiny), je tedy otázkou jakým způsobem systém rozšířit o možnost používat národní abecedy, které v ASCII nejsou. Je zřejmé, že by nebylo příliš 13 Více na zkušební doméně dostupné i přes klasickou adresu

57 Pokročilé komunikační techniky 57 vhodné přepracovat celé DNS, které je masově využíváno. Vhodnějším přístupem je pouze systém doplnit o speciální funkce, což se také v případě IDN děje. Systém je navržen tak, že úpravy jsou nutné pouze na straně registrátorů a koncových aplikací, servery DNS ani protokol se nemění. Základní princip IDN je velice jednoduchý. Řetězec v národní abecedě se nejdříve převede do tzv. formátu ACE (ASCII Compatible Encoding), což znamená zápis v ASCII kompatibilním formátu 14, který je již možné běžně uložit do DNS. S tímto řetězcem se pak již pracuje zcela běžným způsobem, tj. je možné ho posílat v DNS dotazech apod. Převod z národní abecedy do ASCII je založen na jednoduché substituční metodě, kdy se povolené non-ascii znaky kódují určitou množinou ASCII znaků. Aby bylo z převedeného řetězce jasně patrné, že se jedná o ACE, na začátek se dává vždy prefix xn--. Algoritmus, který tento převod realizuje, se nazývá ToASCII, opakem je pak ToUnicode. Převod se vždy provádí po částech adresy, tj. samostatně se pracuje s řetězci mezi tečkami. Příklad převodu je uveden na Obr Z příkladu je zřejmé, že systém IDN řetězce prodlužuje. V případě použití velkého množství non-ascii znaků můžeme narazit na omezení počtu znaků v jednom řetězci, které je i v tomto případě 63. V prohlížeči je možné zadávat jak názvy v národní abecedě (prohlížeč je konvertuje na ACE) nebo přímo ACE kódy, tj. i by mělo mít stejný výsledek, pokud bude tato stránka existovat. } Obr. 3-36: Ukázka fungování převodu ToASCII v systému IDN V souvislosti s IDN se můžeme setkat i se zkratkou IDNA (IDN in Applications), které označuje podporu v aplikacích. To existuje v současnosti ve dvou verzích, IDNA2003 a novém IDNA2008 (schváleno 2010). Novější standard je především reakcí na problémy vzniklé s provozováním systému v některých doménách a přináší dořešení některých detailů a také vyvstalých bezpečnostních problémů. Bližší seznámení je nad rámec tohoto textu Registrace domén V této kapitole se budeme zabývat registrací doménových jmen. Můžeme se rozhodnout náš webový server s IP adresou např nazývat např Aby se na něj však mohli lidé snadno připojovat přes název musí být tento název registrován v doméně, konkrétně v tomto případě v doméně.cz Někdy označováno též jako punycode. 15 Na základě pravidel registrace a především zákonů dané země je možnost registrace určitých názvů omezena (firmy, ochranné známky, obchodní značky, slavná jména, ). U volných domén samozřejmě funguje přístup kdo dřív přijde, ten dřív mele. 16 Teoreticky by samozřejmě bylo možné na všech počítačích nastavit statický překlad DNS, tj. že po zadání se má prohlížeč připojit na IP adresu , to však není příliš praktické. Ještě méně praktické pak je nemít DNS název vůbec, IP adresu si běžný uživatel internetu nezapamatuje.

58 58 FEKT Vysokého učení technického v Brně Je zřejmé, že registrace domén musí mít z technického hlediska určitá pravidla a musí existovat organizace, která bude systém zastřešovat. Celosvětově je to organizace IANA, o níž byla řeč v kap Pokud se posuneme do českých poměrů, tak narazíme na zájmové sdružení CZ.NIC, které v rámci ČR zastřešuje právě oblast registrace domén. Sdružení zabezpečuje provoz domény.cz a provozuje registr doménových jmen. CZ.NIC samo o sobě domény zákazníkům neregistruje, to provádějí jednotliví registrátoři členové sdružení (kterých je cca 40) 17. Celkově již bylo v doméně.cz zaregistrováno domén (stav k ). Pro registraci domény je potřeba zaregistrovat kontakt (jména, organizace) a sady (vlastních) jmenných serverů, kam bude doménové jméno delegováno. Registrace domény je možné ověřit ve službě WHOIS ( DNSSEC Jak vyplynulo z přecházejícího textu, DNS spočívá na jednoduchém principu dotaz odpověď, přičemž dotaz i odpověď mohou být rekurzivně předávány, dokud není požadovaná informace zjištěna. Všechny tyto pakety jsou zasílány v otevřené formě, což vzhledem k přenosu veřejně dostupných informací nemusí být samo o sobě problematické 18. Jak ale zamezit tomu, že odpověď, na kterou DNS resolver čeká, např. někdo po trase nezmění nebo nám nepošle podvrženou odpověď? V posledních letech bylo provedeno poměrně velké množství útoků různého typu na systém DNS, které měly za následek zejména přesměrování některých domén na podvržené servery, jejich znepřístupnění apod. Vzhledem k tomu, že fungování DNS je pro Internet naprosto klíčové, snahy o určité zabezpečení systému vyústily v techniku DNSSEC, která je postupně zaváděna v jednotlivých doménách. DNSSEC v principu poskytuje rozšíření stávajícího systému DNS o systém pro ověření autentičnosti obdržených RR záznamů. Základní princip vychází z asymetrické kryptografie a spočívá v digitálním podepisování RR záznamů, což v praxi zajistí, že pokud důvěřujeme autoru podpisu, můžeme důvěřovat i poskytnuté informaci. DNSSEC nešifruje přenášené informace, ty zůstávají stále otevřené. Zavádění DNSSECu do praxe lze orientačně sledovat např. na stránkách Technika DNSSEC spočívá v přidání několika dalších typů RR záznamů, k těm již existujícím, z nichž některé byly uvedeny v kap Vybrané nové jsou: RRSIG (Resource Record Signature) digitální podpis DNS odpovědi. DNSKEY (DNS Public Key) veřejný klíč ke klíči privátnímu, který je používaný k podpisu. DS (Delegation or Designated Signer) slouží k zajištění možnosti ověření DNSKEY u vyšší autority v řetězci důvěry. NSEC/NSEC3 (Next Secure) slouží jako záznam zasílaný v odpovědi zpět v případě neexistence domény; tj. aby bylo možné ověřovat pomocí DNSSEC i informaci, že např. hledaná doména je DNS serveru neznámá. Při použití DNSSECu má DNS odpověď zařazena na konec záznam typu RRSIG, který je de facto digitálním podpisem (zejména RR záznamu, který je přenášen v paketu). Ověření 17 Aktuální seznam je k dispozici na 18 Pouze ale za předpokladu, že pomineme jako nebezpečné porušení ochrany soukromí spočívající ve sledování navštěvovaných domén, prostřednictvím monitoringu DNS dotazů. Argumentem proti šifrování celého DNS je také logické zpomalení celého systému, u něhož je rychlost jedním ze základních požadavků.

59 Pokročilé komunikační techniky 59 záznamu je provedeno pomocí DNSKEY, který si klient stáhne ze serveru jako další RR. Ověření DNSKEY je provedeno prostřednictvím DS, čímž se dostáváme do řetězce důvěry. Systém DNSSEC vyžaduje i drobné úpravy v paketu DNS dotazu a odpovědi, spočívající v přidání několika příznakových bitů, které signalizují použití DNSSECu, zda je autentizace požadována a zda byla nebo nebyla autentizace u odpovědi provedena Firewally S problematikou překladu adres částečně souvisí i brány oddělující sítě firewally. Firewall může být realizován jako program spuštěný na počítači nebo jako samostatné zařízení. Primárním účelem firewallu je zabránit nechtěné komunikaci z jedné sítě (zóny) do jiné sítě (zóny) a opačně. Jeden firewall může oddělovat i více než dvě různé sítě (zóny). Pokud je firewall realizován programově, v takovém případě nabízí zpravidla vyšší komfort údržby a je možné jej obsluhovat i s poměrně malými znalostmi síťové problematiky. Daní za tento komfort je potom pomalejší vyřizování požadavků. Oproti tomu hardwarový firewall (zařízení) nabízí maximální propustnost požadavků za cenu nižšího komfortu při správě a údržbě. K obsluze hardwarového firewallu jsou zpravidla nutné hlubší znalosti. Rozlišení, která komunikace bude povolena či zakázána, je řízeno bezpečnostní politikou. Tato politika je vložena do konfigurace firewallu a pro každý požadavek na průchod firewallem jsou aplikována pravidla bezpečnostní politiky, podle nichž firewall rozhodne, zda komunikaci povolit či odmítnout. Tato činnost je často nazývána filtrování komunikace a to je příčina, proč jsou firewally někdy označovány jako síťové filtry Přehled typů firewallů Rozdělení firewallů je možné provádět podle nejvyšší vrstvy, ze které firewall sbírá informace k rozhodnutí o filtrování komunikace. Zajímavé jsou pro nás tyto vrstvy: síťová vrstva nejrychlejší a zpravidla také nejméně nákladná varianta firewallu. Filtruje jen velmi hrubě, pouze na základě zdrojové nebo cílové IP adresy obsažené v záhlaví analyzovaného paketu. Je tedy možné zakázat např. provoz pocházející z nežádoucích sítí nebo do těchto sítí naopak směřující. V dnešní době distribuovaných útoků se jedná o prakticky nepoužitelnou variantu, proto se čistě v této podobě používá jen ve speciálních případech. transportní vrstva o bezestavový kromě údajů ze síťové vrstvy (IP adresy) bere v úvahu i hodnoty transportních portů (porty viz kap ). Současná generace těchto filtrů je velmi rychlá a běžně bývá označována jako paketové firewally, přestože filtruje de facto na úrovni segmentů. Pro jejich velkou rychlost je vhodné je nasadit na místa s hustým provozem, např. vstupní brána do sítě apod. Nastavení takovéhoto firewallu vyžaduje poměrně dobré znalosti síťových technologií. o stavový tento firewall oproti bezestavovému dokáže rozlišit již navázané spojení od ostatního provozu a k němu přidruženou komunikaci snáze propustí. Funguje to tak, že každý paket je nejdříve posuzován vzhledem k seznamu existujících (a již povolených) spojení. Pokud k některému patří, je propuštěn bez další analýzy. Pokud ne, prochází standardním paketovým filtrem a může být propuštěn nebo zahozen. Nasazení stavového firewallu je důležité, v případě, že

60 60 FEKT Vysokého učení technického v Brně chceme efektivně a správně filtrovat komunikaci postavenou na transportním protokolu TCP. Tedy u většiny Internetových protokolů. Zřejmou daní za kvalitnější filtrování je nižší rychlost filtrování než u paketových filtrů, která souvisí s vyšší náročností tohoto typu firewallu a je velmi závislá na počtu aktivních spojení. aplikační vrstva nejvyšší vrstva, na které může firewall pracovat je aplikační. Tyto firewally zpravidla plně rozumí fungování aplikací a protokolů a jsou schopny detekovat např. případy jejich nestandardního chování apod. Filtrují velmi jemně, za cenu nižší rychlosti. Nejvhodnější je použít je až na koncové stanice. Firewall pracující na aplikační vrstvě může být označován jako proxy 19 firewall, což souvisí s tím, že jeho úloha je obdobná jako u proxy serverů vytvořit prostředníka v komunikaci. V oblasti firewallů se však nejedná pouze o zajištění anonymity, ale také o komplexní analýzu a filtrování komunikace. Konfigurace aplikačního firewallu může být velmi jednoduchá anebo naopak velmi složitá. Záleží na tom, do jaké hloubky nastavení je jeho uživatel schopen jít. Při filtraci komunikace je důležité provádět záznam (log) o procházejících paketech, často pouze o nepropuštěných paketech. Analýzou těchto záznamů lze donastavit politiku firewallu a dosáhnout tak co nejlepšího filtrování paketů. Někdy může být užitečné, když firewall loguje i zprávy, které propustil. Lze toho využít např. ke statistickým účelům nebo opět k donastavení pravidel firewallu, v případě, že propouští provoz, který měl být blokován. V případě, že dojde na firewallu k zahození paketu, je možné (ale ne vždy nezbytné) o této skutečnosti informovat zdrojovou stanici prostřednictvím chybového hlášení. K tomuto účelu se využívá protokol ICMP (více viz kap. 3.9), konkrétně zpráva nedoručitelný IP datagram (destination unreachable). Zřejmou nevýhodou zasílání této odpovědi je, že se útočník dozví o existenci obranného systému a že získává potenciální možnost, jak zařízení zahltit. Z tohoto důvodu se možnosti informovat zdroj o zahození paketu příliš nevyužívá. Při filtrování komunikace je třeba pamatovat na oba možné směry komunikace. Někdy je dostatečné, když se zabezpečí pouze příchozí směr. Tento způsob je aplikován u základních typů firewallů. Jestliže budeme provozovat např. webový server, naším základním cílem je ochránit ho před nechtěnou komunikací z vnějšku. Takový webový server by neměl generovat žádná odchozí spojení, pouze očekává požadavky pocházející od klientů. Jestliže však nějaké spojení generovat bude, je pravděpodobné, že něco není v pořádku a je tedy dobré mít nakonfigurovaný firewall i v odchozím směru, který této komunikaci buď zabrání anebo ji alespoň zapíše do záznamu (logu) Příklady pravidel firewallu Paketové firewally bývají konfigurovány pomocí skupiny pravidel. Na pořadí těchto pravidel záleží. Při příchodu zprávy se tento paket testuje postupně vůči každému pravidlu, dokud se nenajde vyhovující pravidlo, podle kterého je paket propuštěn nebo naopak zahozen. 19 Naproti tomu, proxy server je server počítačové sítě, který umožňuje klientům nepřímé připojení k jinému serveru. Proxy server funguje jako prostředník mezi klientem a cílovým serverem, překládá klientské požadavky a vůči cílovému serveru vystupuje jako klient. Přijatý požadavek následně odesílá zpět na klienta. Může se jednat jak o specializovaný hardware, tak o software běžící na počítači klienta. Aplikační proxy server je server speciálně určený pro určitý protokol resp. aplikaci. Za pomocí něj lze analyzovat obsah komunikace, případně ji pozměňovat (např. odstraňování reklam z http požadavků, blokování webových stránek podle obsahu, ).

61 Pokročilé komunikační techniky 61 Jestliže se dojde na konec seznamu, aniž by jedno z definovaných pravidel vyhovovalo, použije se tzv. výchozí (implicitní) pravidlo. To může být nakonfigurované tak, že všechny pakety neodpovídající předchozím pravidlům jsou zahozeny nebo naopak propuštěny. Častějším případem je, že výchozí pravidlo obsahuje politiku zahazování paketů. Předcházející pravidla pak konfigurují služby, které jsou exaktně povoleny, vše ostatní je zakázáno. Jednoduchý příklad poskytuje Tab. 9, vysvětlení významu jednotlivých položek je zřejmé z jejich popisu. Tab. 9: Příklad jednoduché konfigurace paketového firewallu směr protokol zdrojová IP direction protocol source address ven (out) IP dovnitř (in) dovnitř/ven (in/out) TCP IP libovolná (any) libovolná (any) zdrojový port source port libovolný (any) libovolný (any) libovolný (any) cílová IP cílový port akce destination address libovolná (any) destination port libovolný (any) libovolná (any) libovolný (any) action povolit (allow) povolit (allow) zakázat (deny) 3.12 Protokoly zálohování výchozí brány lokální sítě Podstata problému Páteřní (tranzitní) počítačové sítě jsou od svých počátků budovány tak, že v topologii existuje mezi dvěma uzly více než jedna cesta. V případě výpadku by tak měla existovat vždy záložní trasa. Toho lze zpravidla docílit prostřednictvím zvýšeného počtu linek a také aktivních prvků. Situace je demonstrována na Obr Jestliže dojde k výpadku jedné z linek nebo jednoho ze směrovačů v tranzitní části sítě, přenos paketů mezi LAN1 a LAN2 je stále možný. O používání funkčních tras a deaktivaci nefunkčních se postará použitý směrovací protokol. Pro fungování lokální sítě je však důležitá i dostupnost výchozí brány, která zprostředkovává komunikaci stanic s okolním světem. Bylo by tedy dobré zálohovat i gateway sítě. Situace je znázorněna na Obr Více směrovačů můžeme do sítě zapojit snadno. Problém nastává v konfiguraci koncových stanic, jelikož IP konfigurace obsahuje pouze jednu IP adresu výchozí brány Když chce stanice komunikovat se svojí výchozí bránou, kterou zná pouze pod IP adresou, využívá k tomu protokol ARP, viz kap Díky zjištění fyzické adresy 20 Ve standardní IP konfiguraci je z podstatných parametrů možná duplicita pouze u DNS serverů, čehož se hojně využívá, jelikož systém DNS je stejně kriticky důležitý, jako dostupná výchozí brána. 21 Triviálním, ale pouze částečným řešením problému je rozdělení stanic do skupin, přičemž každá skupina bude mít vlastní výchozí bránu. Při výpadku jedné z bran pak nebude fungovat pouze určitá část sítě, nikoliv síť celá. Toto řešení je značně nedokonalé a mimo jiné přináší některé dodatečné problémy, proto se příliš nevyužívá.

62 62 FEKT Vysokého učení technického v Brně směrovače (přes protokol ARP), je možné následně odesílat pakety ven ze sítě. V případě, že výchozí brána neodpovídá, nedokáže stanice zjistit sama od sebe, že má komunikovat s jinou výchozí bránou, i pokud taková na síti je. Automatickou konfiguraci zálohování výchozích bran umožňují protokoly pro zálohování brány, anglicky jednoduše redundancy protocols, resp. specifičtější first hop redundancy protocols. Základní myšlenkou všech protokolů je, že řešení těchto problémů provádí síť, resp. směrovače, bez jakékoliv kooperace s koncovými stanicemi. Protokoly redundance výchozí brány dělíme na dvě základní skupiny: protokoly, které umožňují pouze zálohování dostupnosti výchozí brány (HSRP = Hot Standby Router Protocol, VRRP = Virtual Router Redundancy Protocol), protokoly, které umožňují nejen zálohovat zdroje, ale i rozkládat zátěž mezi aktuálně dostupné výchozí brány (load-balancing) (GLBP = Gateway Load Balancing Protocol). LAN1 x LAN2.. GW1 GW2.. Obr. 3-37: Výhody redundance v globální topologii sítě... GW1... x GW2 LAN Obr. 3-38: Výhody redundance v lokální topologii sítě Protokoly nadbytečnosti umožňují dvěma (a někdy i více) směrovačům sdílet jednu virtuální IP adresu a virtuální MAC adresu. Tato virtuální IP je pak konfigurována na koncových stanicích a virtuální MAC je odesílána jako fyzická adresa výchozí brány stanicím, prostřednictvím odpovědi na ARP dotazy. Kdo ze směrovačů bude aktuálním držitelem virtuálních parametrů, je následně záležitostí protokolů redundance. Virtuální IP adresy brány je stanicím zpravidla poskytována prostřednictvím standardního DHCP procesu.

63 Pokročilé komunikační techniky Hot Standby Router Protocol HSRP je proprietárním protokolem firmy Cisco, který je možné využívat na směrovačích 22 Cisco. HSRP je aplikačním protokolem, který běží nad UDP/1985 portem a k přenosu využívá multicast. HSRP pakety nemohou opustit danou síť, jelikož mají nastaven TTL na 1. Protokol umožňuje sdružit dva a více směrovačů do skupiny za účelem zálohování výchozí brány pro koncové stanice v síti. Každý ze směrovačů má svoji IP adresu a skutečnou fyzickou adresu, skupina jako celek pak disponuje jednou virtuální IP (v4 nebo v6) adresou a jednou virtuální MAC adresou, které se od skutečných adres zpravidla liší. V každé takto vytvořené skupině je pak zvolen jeden aktivní (active) směrovač, který bude aktuálně sloužit jako výchozí brána pro stanice, tj. bude vlastníkem virtuálních adres. Ve skupině bude dále zvolen jeden záložní (standby) směrovač, který v případě výpadku prvního směrovače rychle převezme jeho úlohu. Ostatní směrovače (pokud se ve skupině nachází více než dva) pouze naslouchají komunikaci dvou hlavních směrovačů a v případě výpadku jsou schopny jejich role zastoupit. Rámce zaslané na virtuální MAC adresu jsou vždy zpracovávány pouze aktivním směrovačem, ostatní členové skupiny rámec ignorují. Pokud by tak neučinili, došlo by vytváření duplicit paketů, což není žádoucí. Z předcházejícího textu vyplývá, že aktivní a záložní směrovač si musí pravidelně vyměňovat zprávy, aby každý z nich znal stav dostupnosti toho druhého. Ve výchozí konfiguraci jsou tyto zprávy posílány každé 3 sekundy (hello interval), a pokud více jak 10 sekund (hold interval) nepřijde odpověď od druhého směrovače, je považován za nedostupný. Z důvodu bezpečnosti může být komunikace mezi směrovači určitým způsobem autentizována. Do zpráv protokolu jsou pak přidávány hash (MD5) otisky, které umožňují ověřit si, že se do skupiny nepokouší zapojit nežádoucí směrovač. Může nastat i situace, že směrovač, který je aktivním, je plně funkční a z pohledu stanic dostupný, ale jeho linka ven ze sítě, přes kterou pakety posílá, přestane být funkční. I v takovémto případě je dobré, aby směrovač přestal být aktivním a HSRP protokol tuto konfiguraci umožňuje. Bity Verze protokolu Kód operace Role směrovače Hello inverval Hold interval Priorita Číslo skupiny Rezerva Autentizace Virtuální IP adresa skupiny Obr. 3-39: Formát zprávy HSRP protokolu Aby vše fungovalo podle očekávání, stanice v síti musí ve své konfiguraci mít nastavenou jako výchozí bránu virtuální IP adresu skupiny. Stanice nemají možnost ovlivnit, přes který směrovač jejich pakety budou směrovány. Virtuální MAC adresa, kterou dostanou jako odpověď na svoje ARP dotazy, není libovolně konfigurovatelná. Formát adresy na Ethernetu je (platí pro HSRPv1) 00:00:0c:07:ac:XX, kde XX je hexadecimálně zapsané identifikační číslo dané skupiny. 22 Protokol je možné využívat také na L3 přepínačích, které umožňují fungovat de facto stejně jako směrovače.

64 64 FEKT Vysokého učení technického v Brně Formát zprávy protokolu HSRP je velmi jednoduchý, viz Obr Všechny položky již byly popsány, s jedinou výjimkou. Priorita směrovače je konfigurovatelný parametr, který ovlivňuje, který směrovač se stane ve skupině aktivním a který záložním. Platí, že čím vyšší číslo, tím vyšší priorita. Pozn.: Protokol HSRP lze za určitých podmínek využít nejen k zálohování prostředků, ale také k rozdělování zátěže mezi více směrovačů. V případě, že máme v síti dvě výchozí brány, lze toho docílit tak, že se vytvoří dvě skupiny nad těmito směrovači a role směrovačů ve skupinách budou opačné. Jeden směrovač bude pro jednu skupinu aktivní a pro druhou jako záloha a druhý směrovač bude konfigurován (prostřednictvím priorit) opačným způsobem. Rozdělení zátěže samozřejmě nebude optimální, pokud nebude přenos v síti také rovnoměrně rozložen mezi vytvořené skupiny Virtual Router Redundancy Protocol VRRP (Virtual Router Redundancy Protocol) poskytuje navenek prakticky stejné funkce jako HSRP, odlišnosti jsou jen velmi malé. Protokol není proprietární, jedná se otevřený standard IEEE. Protokol VRRP je výhodné použít, pokud máme v síti zařízení od různých výrobců. VRRP pracuje přímo nad IP a nevyužívá tedy služeb žádného transportního protokolu. Směrovače, které tvoří skupinu, si zvolí nositele virtuální IP (v4 nebo v6) a MAC adresy, který se nazývá Master. Všichni ostatní členové jsou pak ve stavu Backup a negenerují žádný provoz protokolu VRRP. Komunikace mezi členy probíhá taktéž přes multicast (jiná adresa než u HSRP). Časové intervaly protokolu (hello, hold) jsou ve výchozí konfiguraci nižší (1 s, 3 s) než u HSRP, což může zapříčinit dojem, že protokol je rychlejší. Stejně jako HSRP, i VRRP umožňuje komunikaci mezi směrovači autentifikovat prostřednictvím hashe. VRRP Group 1 VRRP Master VRRP Backup GW1 GW2 IP /24 IP /24 Virtual IP /24 Virtual MAC 00:00:5e:00:01:01 IP Maska Brána Obr. 3-40: Zjednodušená ukázka fungování protokolu Virtual Router Redundancy Protocol Skupina MAC adres, kterou používá VRRP je 00:00:5e:00:01:XX, kde XX je číslo konkrétní skupiny. Ze zápisu je patrné, že skupin může být u protokolu VRRP až 256. Rozložení zátěže lze u protokolu VRRP realizovat stejným způsobem jako u HSRP, tedy vytvořením více skupin a u každé skupiny nastavením jiného Master směrovače. Některé

65 Pokročilé komunikační techniky 65 stanice pak budou mít jako výchozí bránu první Master směrovač, další stanice druhý Master atd. Fungování sítě při nasazení protokolu VRRP je zjednodušeně demonstrováno na následujícím Obr V síti jsou dva směrovače, jeden byl zvolen jako Master, druhý jako Backup, z čehož vyplývá, že stanice aktuálně pro komunikaci ven ze sítě využívá první bránu, což je vyznačeno červeně. V obrázku je naznačena konfigurace adres směrovačů i stanice Gateway Load Balancing Protocol Nevýhodou protokolů HSRP a VRRP je, že směrovače, které nejsou aktuálně používány jako aktivní, jsou nevyužity, stejně tak jako jejich linky. V předcházejících kapitolách byly sice stručně uvedeny postupy, jak zajistit určité rozložení zátěže u těchto protokolů, řešení však není optimální. Z hlediska rozkládání zátěže je, jak už vyplývá z jeho názvu, vhodný protokol Gateway Load Balancing Protocol - GLBP. Protokol GLBP je od firmy Cisco. Jeho cílem je umožnit několika směrovačům hladce sdílet zátěž síťového provozu a zároveň překonávat případné výpadky některého z nich. GLBP využívá taktéž multicastového přenosu dat a transportním protokolem je UDP (port 3222). Směrovač ve skupině pak může mít jednu nebo dvě role, které jsou v protokolu definovány. První role je Active Virtual Gateway (AVG), druhá pak Active Virtual Forwarder (AVF). AVG se stará o správu skupiny, což v praxi znamená, že přiděluje členům skupiny virtuální MAC adresy (těch se u GLBP využívá více, až 4 na jednu skupinu) a také že odpovídá vhodným způsobem stanicím na ARP dotazy. Každý AVF se pak stará o přenos paketů, v případě, že jsou zaslány na virtuální MAC adresu, kterou má přidělenou k obsluze. Virtuální IP adresa je pro všechny pouze jedna, tato je pak konfigurována na stanicích jako jejich výchozí brána. Směrovače se ve svých rolích vzájemně zálohují. GLBP vychází z HSRP, z čehož vyplývá i stejné výchozí nastavení časovačů (3 s, 10 s), možnost autentizace pomocí hashe, či sledování stavu linek. GLBP využívá MAC adresy formátu 00:07:b4:XX:XX:XX, kde v dolních 24 bitech jsou definovány číslo skupiny a identifikační číslo AVF. GLBP umožňuje tři způsoby rozkládání zátěže: Per-host konkrétní koncová stanice využívá vždy ten stejný AVF (případně jeho zálohu, když dojde k výpadku). Round-robin AVG odpovídá na ARP dotazy cyklickým střídáním přidělených virtuálních MAC adres. Weighted round-robin rozdělení mezi routery není rovnoměrné, ale závislé na váze, kterou daný směrovač ohlašuje. Výhodné použít, když máme různě rychlé směrovače. Z předcházejícího popisu je patrné, že ani jeden z tří možných mechanizmů není ideální a žádný nikdy nedokáže rozdělit zátěž zcela rovnoměrně. To by bylo možné pouze za cenu mnohem složitějších mechanizmů. Výhodou prezentovaných řešení je zachování určité úrovně jednoduchosti a použitelnosti v běžné síti.

66 66 FEKT Vysokého učení technického v Brně 4 Multicastový přenos dat 4.1 Typy přenosu Unicast Přenos z jednoho bodu do druhého (one-to-one), z přesně specifikovaného zdroje do jednoznačně identifikovaného cíle. Jedná se pravděpodobně o nejpoužívanější způsob přenosu dat. V případě více příjemců stejných dat je tento způsob neefektivní, viz Obr Broadcast Přenos z jednoho bodu sítě do všech ostatních v rámci sítě nebo podsítě (one-to-all). K tomuto účelu se využívají všesměrové adresy, viz kap Všechny stanice na síti obdrží tuto zprávu a všechny se musí zabývat jejím zpracováním. Výhodou je úspora přenosového pásma a komunikačně snadná dostupnost všech přítomných stanic, nevýhodou je zatížení stanic, kterých se zpráva netýká. V případě velkého podílu všesměrových zpráv na celkovém objemu provozu může jít o velmi významné zatížení, které je třeba omezit. Cestou je rozdělení sítě na podsítě s dílčími broadcastovými zónami. Multicast Tradičně se jedná o přenos z jednoho zdroje ke skupině příjemců (one-to-many). Může však nastat i situace, kdy je zdrojů více, viz dále (many-to-many). Přenos je praktikován s maximální možnou efektivitou, co se týká spotřeby pásma, jelikož se od zdroje vysílá pouze jedna kopie dat, která se postupně cestou k adresátům podle potřeby větví vytvářením kopií. Vytváření kopií je úlohou směrovačů a přepínačů, které musí pro správné fungování celého systému multicast podporovat. To způsobuje vyšší požadavky na síťové prvky. Rozdílnost přenosu dat metodou unicastu a multicastu od jednoho zdroje dat ke skupině příjemců je znázorněna na Obr Jak je patrné z obrázku, efektivita multicastového přenosu má vliv na šířku blokovaného pásma mezi zdrojem dat a R1, dále mezi R1 a R2 a také mezi R2 a S1 a také mezi R2 a S2. Na koncových segmentech již samozřejmě není možné dosáhnout úspory. Ušetřené pásmo je enormní zejména v případech, kdy je počet příjemců na jedné síti vysoký. Využití multicastu tak často významně zvyšuje počet možných (souběžných) příjemců dat, který je v případě unicastu limitován šířkou pásma nejpomalejší linky. Model one-to-many je výhodný zejména pro přenos audia, videa, monitorovací a oznamovací systémy. V případě, že některý z přijímačů potřebuje přenést data zpátky ke zdroji, model přechází v many-to-one. Častější je však many-to-many, kdy může být provoz generován prakticky kýmkoliv ze skupiny.

67 Pokročilé komunikační techniky 67 S1 S1 R1 R2 S2 R1 R2 S2 a) unicast b) multicast Obr. 4-1: Odlišnosti unicastu (a) a multicastu (b) v případě skupiny příjemců a jednoho zdroje dat Anycast Tento méně známý způsob přenosu, česky nazývaný jako výběrový přenos je více popsán až v souvislosti se sadou IPv6, viz kap a Spočívá v tom, že více míst v síti vystupuje pod jednou adresou a komunikace vždy probíhá se zařízením, které je nám nejblíže, případně nejlépe dostupné (one-to-nereast). 4.2 Výhody a nevýhody multicastu Multicast je řešením dvou spolu souvisejících otázek: Jak co nejefektivněji doručit stejná data více příjemcům tak, aby docházelo k maximálně efektivnímu využívání linek, tj. aby každý datový proud tekl každou linkou maximálně v jedné kopii a duplicity se vytvářely pouze tam, kde je to nezbytně nutné? Jak zajistit, aby uzly a linky, kde není žádný příjemce dat, nebyly příslušným datovým proudem zahlcovány? Výhody multicastu Efektivita oproti unicastu, která je více než zřejmá. Optimalizace zpracování méně paketů znamená jejich rychlejší zpracování na přenosové trase Distribuované aplikace, které jsou často bez multicastu nerealizovatelné Multicastové aplikace zpravidla jako transportní využívají protokol UDP, tj. přenos bez spojení a potvrzování o doručení (best-effort). Z principu není možné použít protokol TCP, který je postaven na mechanizmu budování spojení mezi dvěma komunikujícími stranami. Nevýhody pramení především z nevyhnutelnosti použití protokolu UDP:

68 68 FEKT Vysokého učení technického v Brně Multicast postrádá řízení proti zahlcení nestará se o to, zda svojí datovou náročnosti neblokuje kapacitu celé linky, nezpůsobuje zahlcení sítě Vznik nežádoucích duplicitních paketů mohou vzniknout při změně multicastové topologie, aplikace s tím musí počítat Doručení paketů v jiném pořadí ke kterému může dojít taktéž při změně topologie multicastového přenosu Nespolehlivost přenosu pokud je potřeba určitá míra spolehlivosti, musí být řešena na aplikační vrstvě. U některých aplikací určitá míra ztrátovosti nemusí vadit. Možnost nežádoucího odposlechu souvisí s možností snadno se připojit ke skupině a data tak přijímat 4.3 Adresování multicastu v sítích IPv4 Pro účely multicastu je v adresním prostoru IPv4 vyhrazena celá třída D s rozsahem až V binární podobě jsou první čtyři bity vždy rovny Tato skupina je členěna na tři základní skupiny, viz Tab. 10. V tabulce lze nalézt i dva příklady lokálně platných multicastových adres. Pakety adresované první skupině multicastových adres nikdy neopustí lokální síť, bez ohledu na hodnotu TTL, přestože bývá většinou nastavena na jednotkovou hodnotu. Kompletní přehled adres je možné nalézt na Tab. 10: Skupiny multicastových adres, příklady Rozsah adres, adresa Popis Určené pro použití v rámci lokální sítě (odpovídá TTL = 1) Určené pro použití v rámci Internetu Určené pro privátní použití uvnitř domén Všechny stanice na lokální síti Všechny multicastové směrovače Z předcházejícího textu je patrné použití multicastových adres na síťové (Internetové) vrstvě. Nelze však opomenout i multicastové adresování na nižší vrstvě, jehož úloha je taktéž klíčová. Bez technik pro stanovení správných fyzických adres by nebylo možné pakety v rámci sítě doručit na správné koncové uzly. V případě klasické unicastové adresy se pomocí protokolu ARP a za pomoci adresátovy IP adresy zjistí odpovídající fyzická adresa (zpravidla MAC adresa), viz kap V případě, že chceme paket poslat více adresátům, nejjednodušší metodou je broadcast, který odpovídá MAC adrese ff:ff:ff:ff:ff:ff. Zřejmou nevýhodou je, že zprávu obdrží všechny stanice, tedy i ty, které o přenos nemají zájem. Proto byla vyvinuta technika jak z multicastové IP adresy vytvořit multicastovou MAC adresu. Jak již bylo popsáno dříve, MAC adresa se skládá ze dvou stejně dlouhých částí, kódu výrobce a kódu karty. MAC adresa tedy může vypadat např. takto: 00:22:15:9F:1B:48, kód

69 Pokročilé komunikační techniky 69 výrobce je v tomto případě 00:22:15. Pro multicast IPv4 je vyhrazen speciální kód výrobce 01:00:5e (pro IPv6 multicast je to 33:33:xx, kde xx již reprezentuje první část adresy skupiny, viz kap ). Navíc platí, že další (25.) bit musí být nula. Podle tohoto kódu se snadno pozná, že se jedná o multicastový paket. Zbývá zaplnit zbývajících 23 bitů, do kterých se namapuje IP adresa multicastové skupiny, resp. pouze její část. IPv4 adresa má 32 bitů, ale u multicastové adresy platí, že první čtyři bity jsou vždy stejné (1110) a není tedy třeba je mapovat do fyzické adresy. Ve skutečnosti je tedy potřeba mapovat 28 bitů IPv4 adresy do 23 bitů MAC adresy. Je zřejmé, že nelze mapovat adresy v režimu 1:1, poměr je takový, že 32 multicastových IP adres je reprezentováno jedinou MAC adresou. Konverze funguje tak, že nejnižších 23 bitů IP adresy se vezme a beze změny převede do MAC adresy, vyšších 5 bitů je ztraceno. Stanice tedy v případě přijetí multicastového rámce nedokáže pouze na základě MAC adresy ihned určit, zda je paket určen i pro ni a musí prověřit i vyšší vrstvy (cílovou IPv4 adresu v paketu). Tento způsob je přes všechny uvedené nevýhody lepší než pakety odesílat broadcastem a zahlcovat všechny stanice bez rozdílů. 4.4 Multicastové protokoly Z předcházejícího textu by měly být patrné hlavní myšlenky a parametry multicastu. Bystrého čtenáře bezpochyby napadlo, že sám o sobě nemůže multicast fungovat a že musí existovat nějaké komunikační protokoly, které budou systém spravovat. Nejdůležitějšími protokoly jsou IGMP (Internet Group Management Protocol) (kap ) a PIM (Protocol Independent Multicast) (kap ). Nejzásadnější rozdíl mezi těmito protokoly je, že IGMP je určen na výměnu informací mezi koncovými stanicemi a směrovači, zatímco PIM na komunikaci mezi směrovači, jak je vidět z příkladu na Obr LAN Zdroj multicastových dat Multicast Směrovač Lokální multicast Směrovač Přepínač s IGMP snooping Příjemce multicastových dat PIM IGMP IGMP UDP multicast provoz Obr. 4-2: Oblasti použití multicastových protokolů Druhy multicastového přenosu Multicastový přenos zpravidla klasifikujeme dle počtu a přesnosti určení zdrojů dat. Rozlišujeme dva druhy

70 70 FEKT Vysokého učení technického v Brně any source multicast (ASM) neboli multicast s různými zdroji dat, také many-to-many. Identifikace skupiny ASM je prováděna prostřednictvím notace (*, G), kde * reprezentuje libovolný zdroj dat, G (group) pak adresu multicastové skupiny. Podrobněji viz dále. specific source multicast (SSM) neboli multicast se specifickým zdrojem dat, také one-tomany. Identifikace skupiny SSM bývá zapisována ve formátu (S, G), kde S značí zdroj dat (source) a G značí obdobně jako u typu ASM adresu skupiny (group). Podrobněji viz dále Any Source Multicast (ASM) Tento druh je používán zejména pro případy, kdy není ve skupině pevně dáno, kdo bude zdroj a kdo příjemce. Příkladem jsou online hry, hlasové a videokonference, systémy sdílení elektronických tabulí apod. V těchto typech komunikace se zpravidla úlohy zdroje a příjemce dat u jednotlivých členů skupiny střídají podle konkrétní situace, příklad je naznačen na Obr (V tomto příkladu je v síti přítomen tzv. RP router, o kterém je pojednáno níže v kap ) Síť (směrovací protokoly) však musí být vždy schopna rozlišovat zdroj dat a data distribuovat ostatním členům. Pokud se do skupiny připojí nový člen, síť musí určit všechny zdroje dat a data od nich dopravit k tomuto příjemci. Struktura směrování není triviální a systém je poměrně složitý. ASM má mnohé nevýhody, z nichž mezi podstatné patří, že přijímač nemá možnost stanovit si, od kterých zdrojů chce a od kterých nechce přijímat data. Další je, že do skupiny může vysílat prakticky kdokoliv. Zdroj a příjemce multicastových dat Zdroj a příjemce multicastových dat Zdroj a příjemce multicastových dat RP Zdroj a příjemce multicastových dat Zdroj a příjemce multicastových dat RP Zdroj a příjemce multicastových dat Zdroj a příjemce multicastových dat Zdroj a příjemce multicastových dat a) b) Obr. 4-3: Any Source Multicast čtyři členové skupiny jako zdroje (a) a příjemci (b) multicastových dat se směrovačem RP v síti, který funguje jako centrální bod Specific Source Multicast (SSM) Tento druh multicastového přenosu je možné použít pouze tehdy, jestliže je možné přesně specifikovat zdroj dat. Využívá se např. pro systém IPTV, kde je poměrně zřejmé, že nebude každý člen skupiny zdrojem dat. Pokud by do skupiny vysílal i jiný zdroj, bude ignorován, jelikož do procesu směrování je kromě adresy skupiny (G) zapojena i unicastová adresa (S) jednoznačně identifikující zdroj dat. Systém SSM je tak již na první pohled jednodušší, jelikož počet zdrojů je omezen. Obecně platí, že zdroj nemusí být pouze jeden, ale příjemce má vždy možnost vybrat si, který z nich chce přijímat. Stanice se může do skupiny

71 Pokročilé komunikační techniky 71 SSM registrovat pouze prostřednictvím IGMPv3 zprávy, viz kap Pro skupiny SSM se používá specifický blok adres /8 (s výjimkou /24) Internet Group Management Protocol (IGMP) Základní úlohou protokolu IGMP je umožnit koncovým stanicím připojení do multicastové skupiny. Protokol tedy slouží ke komunikaci mezi stanicemi a směrovači. Zprávy protokolu IGMP nejsou směrovány Internetem, jejich platnost je omezena pouze na lokální síť. Protokol IGMP existuje v současné době ve třech verzích, přičemž verze 1 je dnes již historická (RFC 1112) a používá se převážně verze 2 (RFC 2236). Tyto dvě verze mohou spolu za určitých okolností koexistovat. Verze 3 je plně funkční, ale oficiálně v tzv. fázi navrhovaného standardu (RFC 3376, resp. RFC 4604 z roku 2006, které popisuje i MLDv2 (Multicast Listener Discovery), což je obdoba IGMP pro IPv6 (konkrétně součást protokolu ICMPv6), více viz kap. 5.8) IGMPv1 První verze protokolu je postavena na jednoduchém principu, že směrovač zasílá do lokální sítě periodicky paket membership query (dotaz na členství) na multicastovou adresu Stanice pak odpovídají na tento dotaz zprávou membership report (zprávy o členství) postupně na všechny adresy skupin, ke kterým se chtějí připojit. V případě, že již stanice nechce být v dané skupině, žádným způsobem o tom router přímo v IGMPv1 neinformuje. Stanice pouze nereaguje na další zprávu membership query. Z předcházejícího je patrné, že každá zpráva směrovače membership query by měla spustit lavinu zpráv membership report od všech členských koncových stanic. To samozřejmě není žádoucí, takže byla vyvinuta technika, která tento jev potlačuje. Klíčovou myšlenkou je, že každá stanice pracuje s určitým náhodným zpožděním pro každou skupinu, jíž je členem. Zprávu membership report tedy neodesílá hned, ale až po vypršení tohoto náhodně zvoleného intervalu. Pokud však stanice zachytí zprávu vyslanou jinou stanicí, která zvolila kratší zpoždění, automaticky nastavuje nový časovač a čeká na jeho vypršení. Tím se zprávy membership report rozprostřou co nejvíce mezi dvě následující membership query. Dokonce může dojít i k tomu, že zprávu membership report nestihnou v daném intervalu odeslat všechny stanice, to však není problém z pohledu směrovače. Pro něj je důležité především, zda existuje alespoň jeden příjemce, a ne už tak jejich celkový počet. Z pohledu přepínačů a funkce IGMP snooping, viz kap , to však není žádoucí. K zastavení multicastového přenosu do lokální sítě dochází z pohledu směrovače až v situaci, kdy nebyla na několik (počet není pevně stanoven) zpráv membership query žádná odpověď od stanic lokální sítě IGMPv2 Druhá verze vznikla jako odezva na problémy, které ukázalo prvotní nasazení IGMPv1. Hlavním přínosem druhé verze je zpráva, která umožňuje okamžité opuštění skupiny. To je důležité zejména v případě širokopásmových multicastových přenosů a také v situacích, kdy se členství skupin rychle mění. IGMPv2 má velmi jednoduché záhlaví, viz Obr Možné typy zprávy jsou následující čtyři:

72 72 FEKT Vysokého učení technického v Brně Membership query dotaz na přijímané skupiny koncových stanic na lokální síti, případně dotaz pouze na konkrétní skupinu, která je specifikována v poli Adresa skupiny Version 2 Membership Report nová verze zprávy, kterou stanice ohlašuje zájem zapojit se do multicastové skupiny Leave group opuštění skupiny Version 1 Membership Report zpráva z první verze protokolu z důvodu kompatibility a možné koexistence obou verzí protokolu. Bity Typ zprávy Časový limit odezvy Adresa skupiny Kontrolní součet Obr. 4-4: Záhlaví protokolu IGMP ve verzi 2 Pole časový limit odezvy obsahuje informaci o čase, který stanice mají jako limit pro odeslání své odezvy (membership report). Jednotkou jsou desetiny sekundy. Toto pole má smysl pouze ve zprávě od směrovače, tj. membership query a v ostatních by měla být hodnota tohoto pole nulová. Kontrolní součet je v případě IGMPv2 paketu počítán z celé datové části IP paketu, tedy s výjimkou IP záhlaví. Pole Adresa skupiny nese informaci o adrese multicastové skupiny, v případech, kdy je to smysluplné. To jsou všechny typy zpráv s výjimkou obecného membership query. Popis fungování protokolu ve verzi 2 je obdobný jako pro verzi 1, některé oblasti fungování jsou rozebrány dále. Směrovače využívají protokol IGMP k zjišťování jaké skupiny mají své členy na lokální síti. Směrovač si udržuje seznam takovýchto skupin, informaci o tom, zda existuje alespoň jeden člen skupiny a odpovídající hodnoty časovače. Směrovač ve výchozím stavu posílá do sítě periodicky zprávy membership query a bývá nazýván z pohledu IGMP jako Querier. Obecně platí, že pokud je do lokální sítě připojeno více směrovačů, pouze jeden z nich by měl do této sítě vysílat zprávy membership query. Výchozí hodnota pro opakování zprávy query je 125 sekund, z počátku po (re)startu směrovače, je však žádoucí tento interval výrazně zkrátit, aby se co nejdříve zjistilo, jaké skupiny mají na lokální síti aktivní členy. Z pohledu stanice je pak po přijetí této obecné zprávy (membership query general) zahájen časovač s náhodnou hodnotou zpoždění pro každou skupinu, které je stanice členem. Náhodná hodnota je vybrána z intervalu až do hodnoty uvedené v poli časový limit odezvy zprávy membership query. Standardně je limit 10 sekund. Jestliže je tedy stanice jediným členem dvou skupin na lokální síti, po zprávě membership query odešle první membership report např. po dvou sekundách, druhý např. po osmi sekundách. Na Obr. 4-5 je zachycen provoz reálné stanice na síti. Z obrázku je patrné, že interval mezi dvěma zprávami

73 Pokročilé komunikační techniky 73 Obr. 4-5: IGMPv2 zachycená komunikace stanice (člena dvou skupin) a směrovače membership query od směrovače byl skutečně 125 sekund, v okně jsou vidět celkem tři tyto zprávy a vždy i dvě odezvy stanice na tuto výzvu po náhodném časovém intervalu v rozmezí 0 až 10 s. Ve spodní části obrázku je jako ukázka detail obsahu zprávy query od směrovače. Pokud by na síti byl další člen stejné skupiny, také by reagoval na zprávu query. Jedna ze stanic by zvolila menší hodnotu časovače a odeslala tak daný report dříve. Druhá stanice obdrží tento report také a v tuto chvíli zastaví vlastní časovač a zprávu membership report již z důvodu zbytečné duplicity neodesílá. Pokud po nějakou (ne přesně danou) dobu na zprávu směrovače (query) žádná stanice neodpovídá, směrovač to vyhodnotí tak, že skupina již nemá lokální členy a případný provoz této skupiny z vnějšku již nebude do lokální sítě posílat. Z předcházejícího by se mohlo zdát, že stanice musí na možnost nového připojení k multicastové skupině čekat dokud neobdrží zprávu query, a pak teprve odeslat zprávu report. V nejhorším případě by stanice čekala 125 sekund. To je samozřejmě neúnosně dlouhá doba a proto stanice, která se chce nově připojit k nějaké skupině, vysílá zprávu Version 2 Membership report okamžitě a bez vyzvání. Zpravidla se zpráva odesílá pro jistotu několikrát za sebou, z důvodu předcházení chyby způsobené ztrátou paketu. Pokud chce stanice opustit multicastovou skupinu, měla by odeslat jako odezvu na query zprávu leave group. Tato zpráva se odesílá na adresu všechny lokální směrovače, takže ostatní stanice ve skupině ji neobdrží. Z důvodu dlouhého časového prodlení však i zde existuje možnost odeslat zprávu leave group okamžitě bez jakékoliv výzvy IGMPv3 Poslední verze IGMP protokolu je opět navržena tak, aby byla umožněna určitá míra zpětné kompatibility s nižšími verzemi, viz dále. Základním přínosem IGMPv3 je rozšíření schopností příjemců o možnost požadovat nebo filtrovat provoz z individuálních zdrojů v rámci multicastové skupiny. Stanice si tedy mohou vybírat, od koho budou nebo nebudou provoz přijímat, v případě že je těchto zdrojů více. Implementace IGMPv3 musí obsahovat podporu pro následující zprávy:

74 74 FEKT Vysokého učení technického v Brně Membership query nová verze s více informačními poli, viz dále Version 3 Membership Report nová verze zprávy se složitější strukturou. Umožňuje stanici informovat směrovač o stavu příjmu multicastu, případně o změnách. Zpráva je členěna na tzv. group records, jejichž počet odpovídá počtu skupin, kterých je stanice příjemcem (INCLUDE mode). Slouží také k opouštění skupin (EXCLUDE mode), tj. ukončení příjmu multicastu. Tento typ zprávy je zasílán na adresu , na které naslouchají všechny směrovače schopné zpracovat IGMPv3. Ostatní stanice (členové skupiny) ji tedy neobdrží a musí na zprávu query vždy reagovat. V režimu kompatibility se staršími verzemi jsou zprávy membership report zasílány na multicastové adresy skupin specifikovaných v reportu. Z důvodu kompatibility a beze změn jsou v IGMPv3 zahrnuty i následující tři zprávy: Version 1 Membership Report Version 2 Membership Report Version 2 Leave Group Význam a použití zpráv je analogické verzi 1 a 2. Struktura zprávy membership query byla rozšířena a její podobu lze nalézt na Obr Typ zprávy je v tomto případě samozřejmě membership query (resp. odpovídající hexadecimální kód 0x11). Dále je patrné, že první položky záhlaví verze 3 jsou stejné jako u verze 2 a 1, což opět umožňuje určitou míru zpětné kompatibility. Položky časový limit odezvy, kontrolní součet a adresa skupiny mají stejný význam. Pole Resv (Reserved) není využíváno. Pole S je příznak, který říká směrovači, že má potlačit standardní aktualizace časovačů, které běžně při přijetí provádí. QRV znamená Querier s Robustness Variable a toto pole může obsahovat hodnotu s názvem Robustness Variable. Tato hodnota se využívá pro ladění hodnot časovačů vzhledem k očekávané ztrátovosti paketů na trase. Další pole s názvem QQIC (Querier's Query Interval Code) obsahuje informaci o hodnotě odstupu (počet sekund) mezi vysláním dvou po sobě jdoucích zpráv query směrovače. Položka počet zdrojů obsahuje podle očekávání informaci o počtu zdrojů přítomných ve zprávě specifikovaných v dalších položkách, jejichž počet právě závisí na hodnotě zmiňovaného pole. Bity Typ zprávy Časový limit odezvy Adresa skupiny Kontrolní součet Resv S QRV QQIC Počet zdrojů [N] Zdrojová adresa [1] Zdrojová adresa [2] Zdrojová adresa [N] Obr. 4-6: Struktura zprávy Membeship query v IGMPv3

75 Pokročilé komunikační techniky 75 Zpráva membership query má v IGMPv3 tři možné podtypy: Obecný dotaz (general query) směrovač zjišťuje kompletní stav v lokální síti, co se týká existence příjemců multicastu a skupin. Zpráva je odesílána na všeobecnou multicastovou adresu Dotaz na konkrétní skupinu (group-specific query) směrovač zjišťuje stav příjmu pouze jedné konkrétní multicastové skupiny. Zpráva je odesílána na adresu konkrétní skupiny. Dotaz na konkrétní skupinu a zdroj (group-and-source-specific query) směrovač zjišťuje, zda jsou na lokální síti zájemci o příjem konkrétní multicastové skupiny od zdroje(ů), který(é) jsou specifikovány v polích zdrojová adresa [1] až [N]. Stejně jako v předcházejícím případě, zpráva je odeslána na adresu konkrétní skupiny. Fungování IGMPv3 není třeba detailně popisovat, jelikož v základních myšlenkách je totožné s IGMPv2, které již bylo popsáno. Pouze jsou přidány některé nové možnosti a je také při implementaci v souvislosti s vývojem posledních let myšleno i na určité způsoby obrany proti útokům, např. možností zapouzdřit zprávy do IPsec. Z důvodu poměrně velké složitosti se v praxi častěji setkáme spíše s IGMPv2, než s třetí verzí IGMP snooping Z předcházejícího popisu by mělo být patrné, jak s multicastem pracují směrovače z pohledu lokálních sítí a také koncové stanice. V moderních lokálních sítích se však potkáváme také s přepínači, které jsou přímo propojeny s koncovými stanicemi, spojují je mezi sebou a také na směrovač, který je schopen následně data směrovat ven/dovnitř lokální sítě. Na Obr. 4-1b je naznačen princip multicastového přenosu dat. K dělení resp. kopírování dat do větví, kde je aktivní příjemce multicastu dochází nejen na směrovačích, ale i na přepínačích. Vyvstává tedy otázka, jak přepínače rozpoznají, do kterých větví multicast posílat (kopírovat) a do kterých ne. Snoop znamená v překladu špehovat a přesně to vystihuje funkci přepínačů z hlediska protokolu IGMP. Současné přepínače dokážou do určité míry analyzovat obsah rámců (konkrétně zde záhlaví IGMP), které přenášejí, a na základě jejich obsahu rozpoznat, kde se (ne)nachází příjemce konkrétní skupiny. Bez této funkce by musel switch kopírovat multicast na všechny své porty, jelikož by nevěděl kde (ne)má která skupina příjemce 24. To by samozřejmě bylo velmi neefektivní a v krajních případech by to vedlo k blokování veškeré kapacity linek. IGMP snooping tak výrazně zefektivňuje celý provoz multicastu (v IPv4 sítích). Obecně jde však IGMP snooping ještě dále. Switch dokáže rozpoznávat zprávy typy membership report a zasílá je pouze na port, kde je připojen směrovač, nikoliv ke všem členům skupiny. Tím opět dochází k úspoře šířky pásma. 23 Existuje i odlehčená verze IGMPv3 lite, kterou prosazují někteří výrobci. Zájemce o bližší seznámení odkazujeme na Internet. 24 Jelikož multicastový provoz je na fyzické vrstvě adresován na multicastové MAC adresy (viz kap. 4.3), nepomůže klasická tabulka MAC adres, s kterou switch pracuje v případě unicastového provozu a bez IGMP snoopingu musí tak kopírovat provoz na všechny porty (s výjimkou toho, z kterého přišel).

76 76 FEKT Vysokého učení technického v Brně Směrování multicastu Distribuční stromy Předcházející kapitoly popisovaly práci s multicastem na lokální síti, provoz se však musí nějakým způsobem dostat na hraniční směrovač LAN. Cestě od zdroje dat k adresátům přes směrovače s podporou multicastu se říká strom (tree), případně distribuční strom. Tvorba takovéhoto stromu není jednoduchá úloha a provádí ji zpravidla multicastový směrovací protokol, jako je např. Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), Core-Based Trees (CBT) nebo zejména Protocol Independent Multicast (PIM), viz kap Obecně je cílem těchto protokolů vytvořit co nejefektivnější strom. Pohledů na efektivitu takovéhoto stromu je hned několik (vzdálenost resp. počet skoků, cena, spolehlivost, šířka pásma) a proto nelze říct, který protokol je nejlepší, jelikož vždy záleží na konkrétní aplikaci a podmínkách. Důležité je, aby ve stromu neexistovaly žádné směrovací smyčky, které by způsobily cyklení paketů bez šance na dosažení adresátů. Stromy dělíme bez ohledu na multicastové směrovací protokoly na dva základní druhy: Shortest Path Tree (SPT) neboli strom nejkratší cesty, někdy též nazývaný jako source rooted tree, což znamená, že kořenem (root) stromu je vždy zdroj dat, resp. přesněji řečeno první směrovač připojený ke zdroji dat. Tento kořenový směrovač pak data posílá nejkratší cestou dál přes další směrovače až k příjemcům dané skupiny. Z popisu je zřejmé, že takovýto strom pak musí existovat pro každý zdroj dat. Ilustrativní situace je znázorněna na Obr Shared Tree sdílený strom u nějž je kořen umístěn někde uprostřed stromu a zdroje svá data posílají nejdříve na tento kořen (např. u PIM-SM je to zpráva PIM Register, viz kap ), který se pak stará o jejich distribuci prostřednictvím jediného stromu. Strom existuje jeden pro všechny zdroje. Kořenu se někdy také říká rendezvous point (RP). Je zřejmé, že pak veškerý multicastový provoz prochází vždy přes tento bod, což na něj samozřejmě klade zvýšené výpočetní nároky. Přenos navíc nemusí vždy probíhat příliš efektivně, jelikož může existovat lepší cesta mezi zdrojem a příjemcem dat, než ta přes RP. Směrovače, které mají v sítích na svých rozhraních nějaké příjemce skupiny se u RP hlásí o příjem dané skupiny. (Např. u protokolu PIM-SM je to zpráva PIM Join, viz ). Tato zpráva je posílána na unicastovou adresu RP směrovače. Jak tato zpráva prochází sítí přes dílčí směrovače, tak si tyto routery ukládají informaci o tom, že opačně touto cestou pak mají danou skupinu distribuovat. Sdílený strom vzniká tedy poměrně snadno, jelikož zpráva žádosti o příjem skupiny je směrována standardně na základě unicastových směrovacích protokolů. Ukázková situace je znázorněna na Obr SPT stromy jsou používány v případech, kdy hlavním argumentem pro přenos je jeho rychlost a minimální počet skoků od zdroje k členům skupin. Směrovače si však musí pamatovat (pro každý zdroj zvlášť) informace o cestě. U sdílených stromů je pak hlavním přínosem úspora procesorového času a hlavně paměti na běžných směrovačích, které se nemusí zabývat tvorbou a ukládáním distribučních stromů pro jednotlivé zdroje, existuje pouze jeden, který však nemusí být vždy optimální. Z prvního obrázku (SPT) je patrné, že cesta od zdroje k příjemci je vždy co nejkratší, zatímco na druhém obrázku je vidět, že v případě použití pevného RP velmi záleží na jeho umístění vzhledem ke zdrojům dat. Může pak i docházet k paradoxní situaci, že data jsou po jedné lince přenášena tam i zpět, aniž by šlo o chybu. Správná volba umístění RP je tedy velmi podstatná. Tak je tomu v případě zdroje dat č. 1 na Obr U dílčích protokolů, např.

77 Pokročilé komunikační techniky 77 PIM-SM pak existují techniky, jak tento nežádoucí jev potlačit a po zahájení přenosu přes RP cestu zefektivnit, to je však již nad rámec tohoto textu. Příjemce multicastových dat č.2 Příjemce multicastových dat č.1 a č. 2 Příjemce multicastových dat č.1 Zdroj multicastových dat č. 1 Zdroj multicastových dat č. 2 Příjemce multicastových dat č.2 Příjemce multicastových dat č.1 Příjemce multicastových dat č. 1 Obr. 4-7: Distribuční strom nejkratší cesty (Shortest Path Tree SPT) se dvěma zdroji dat a dvěma skupinami příjemců Příjemce multicastových dat č.2 Příjemce multicastových dat č.1 a č. 2 Příjemce multicastových dat č.1 Zdroj multicastových dat č. 1 RP Zdroj multicastových dat č. 2 Příjemce multicastových dat č.2 Příjemce multicastových dat č.1 Příjemce multicastových dat č. 1 Obr. 4-8: Distribuční sdílený strom s pevným kořenem (rendezvous point RP), dvěma zdroji dat a dvěma skupinami příjemců

78 78 FEKT Vysokého učení technického v Brně Technika Reverse Path Forwarding Základní myšlenkou unicastového směrování je přeposílání informací směrem k příjemci a na základě adresátovy IP adresy, která je v paketu uložena jako cílová IP. V multicastovém přenosu je situace odlišná. Důvodem je zejména to, že cílová adresa je v tomto případě reprezentována adresou skupiny. Základní myšlenka směrování multicastu spočívá v směrování provozu pryč od zdroje a nazývá se Reverse Path Forwarding (RPF), což je možné přeložit jako směrování na základě zpáteční cesty. Standardní unicastové směrování probíhá tak, že směrovač ve své směrovací tabulce hledá záznam, podle kterého by mohl paket předat na jedno ze svých rozhraní a v jedné kopii odeslat. Ochrana proti vzniku směrovacích smyček je dána použitým směrovacím protokolem. (V případě, že ke vzniku smyčky přesto dojde, zafunguje mechanizmus doby života paketu (TTL), jež způsobí, že paket bude po nějaké době cyklení vždy zahozen.) RPF je mechanizmus, který multicastovým směrovačům umožňuje správně předávat pakety skrz distribuční stromy a navíc se vyvarovat vzniku směrovacích smyček. Směrovač s RPF u každého paketu sleduje, zda směr, odkud paket přišel, odpovídá cestě ke zdroji dat dané skupiny 25. Pokud ano, tak se podívá, které jeho další rozhraní směřují k příjemcům, a na ty pošle kopie paketu. Pokud paket dorazí ze směru, který neodpovídá cestě ke zdroji dat, paket je zahozen. K určení, kterým směrem se nachází zdroj dat, se využívají standardní směrovací protokoly, resp. záznamy v aktuální platné unicastové směrovací tabulce směrovače. Zdrojem se v tomto případě myslí buď přímo zdroj dat v případě SPT stromů a nebo RP v případě sdíleného stromu. Situaci zjednodušeně demonstruje Obr Zdroj multicastových dat x x Příjemce multicastových dat Příjemce multicastových dat Obr. 4-9: K vysvětlení techniky Reverse Path Forwarding (RPF) 25 RPF vyžaduje, aby unicastové směrování, o jehož informace se opírá, bylo symetrické, tj. aby komunikace mezi zdrojem a příjemcem šla po stejných trasách tam i zpět.

79 Pokročilé komunikační techniky Protocol Independent Multicast (PIM) PIM je jeden z nejpoužívanějších multicastových směrovacích protokolů, který je výrobci směrovačů poměrně dobře podporován. Hlavním úkolem PIM je tvorba distribučních stromů, jak sdíleného typu, tak nejkratší cesty jak bylo popsáno v kap Protokol PIM neobsahuje žádný vlastní mechanizmus na zjišťování topologie sítě, ale využívá informace standardních unicastových směrovacích protokolů. PIM tedy nezasílá mezi směrovači žádné multicastové směrovací aktualizace tabulek apod. Jak vyplývá z názvu protokolu, PIM je nezávislý na použitém směrovacím protokolu, může fungovat stejně dobře nad OSPF nebo např. RIP. Protokol PIM aplikuje směrovací informace především v rámci mechanizmu RPF (Reverse Path Forwarding), jenž byl popsán v kap V IPv4 pak ještě existuje Multicast Source Discovery Protocol (MSDP), který umožňuje výměnu PIM informací mezi jednotlivými doménami autonomními systémy (AS) (o AS je pojednáno v kap. 6). PIM totiž sám o sobě není schopen pracovat přes autonomní systémy, ale pouze uvnitř nich a aby bylo možné pracovat i se skupinami se členy ve více AS, musí existovat právě protokol MSDP, který umožňuje výměnu informací o skupinových zdrojích. Úloha MSDP 26 je tedy podobná úloze protokolu Border Gateway Protocol (BGP, kap. 6.4) v klasickém směrování. Jelikož členství ve skupině se v čase mění, mění se skupina příjemců a protokol PIM na tuto situaci musí umět reagovat. Je to dynamický protokol. Základní dva režimy protokolu PIM jsou PIM Sparse Mode (PIM-SM) PIM Dense Mode (PIM-DM) Dense a Sparse v překladu znamená hustý resp. řídký a váže se k množství příjemců multicastu v dané oblasti. Pokud je pravděpodobnost výskytu alespoň jednoho člena skupiny vysoká, skupina se považuje za dense, v opačném případě za sparse 27. Při nasazení PIM-DM se předpokládá, že síť byla vystavěna tak, že bude možné směrovat mnoho multicastových přenosů a zejména se v ní bude nacházet mnoho příjemců. Síť je na začátku zaplavena multicastovým přenosem (nazývá se push mechanizmus) a ve větvích, kde se nenachází žádný příjemce, musí dojít k následnému potlačení (prune) tohoto přenosu. Funguje to následovně: Jestliže se za daným směrovačem nenachází žádný příjemce konkrétní multicastové skupiny, směrovač to musí dát vědět svému sousedovi a přenos do této větve bude následně zastaven. Situace se periodicky opakuje, jelikož potlačení má z důvodu dynamiky systému pouze časově omezenou platnost (3 minuty). Směrovač, který příjme multicast provoz také vždy testuje, zda přišel od zdroje po optimální trase (RPF) a pokud ne, pakety zahazuje. Lze totiž předpokládat, že tyto pakety dorazí nebo spíše již dorazily po optimální trase. Primárně je PIM-DM určen pro tvorbu stromů nejkratší cesty (SPT) a standardně není možné ho nasadit na tvorbu sdílených stromů. PIM-DM je vhodné použít v případech, kdy zdroj a příjemci jsou blízko v rámci topologie nebo i geograficky, nejlépe přímo na lokální sítí. PIM-DM je již v současné době považován za překonaný a není masově využíván. 26 Pozn.: v IPv6 protokol MSDP nebo jeho obdoba neexistuje a není zapotřebí díky dlouhým IPv6 adresám. 27 Moderní směrovače dokážou provozovat oba režimy (sparse-dense) zároveň za předpokladu, že je nakonfigurováno, pro kterou skupinu se má který režim použít.

80 80 FEKT Vysokého učení technického v Brně Při nasazení PIM-SM se primárně předpokládá, že multicast nebude v síti převažovat a každá větev se v případě aktivního příjemce musí explicitně přidat do stromu (zpráva PIM join) a také případně odebrat (zpráva PIM prune), pokud již nejsou aktivní příjemci. Navíc platí, že zpráva join se musí zasílat opakovaně po určité době, aby se potvrdila platnost příjmu skupiny v dané větvi. PIM-SM je primárně založen na distribučním stromu sdíleného typu (ale je možné ho využívat i pro stromy nejkratší cesty, v který může přenos přejít několika kroky). PIM-SM je založen na tzv. pull mechanizmu. V případě nasazení PIM-SM nedochází k pravidelnému zaplavování sítě a PIM-SM je proto doporučován k nasazení zejména pro rozsáhlé sítě. V praxi je možné ho využívat jak pro sítě s intenzivním, tak i občasným multicastovým provozem. Informace o RP by měla být nakonfigurována na každém routeru sítě. Směrovače, za kterými jsou zdroje multicastových dat, mají tedy informaci o RP a multicastová data od zdrojů zasílají na RP. Data jsou zabalena do zprávy, která je poněkud nešťastně označovaná jako PIM Register. RP tuto zprávu rozbalí a zasílá prostřednictvím distribučního stromu k příjemcům, resp. z pohledu RP pouze na koncové směrovače, které pak lokální distribuci již řeší samostatně. Každý směrovač je schopen informovat RP o aktivních příjemcích ve svém okolí (o kterých ví prostřednictvím IGMP v IPv4 sítích a prostřednictvím MLD v IPv6 sítích (viz kap )). RP tak ví, do kterých větví má zahájit multicastový přenos. PIM-SM je v současné době asi nejpoužívanějším protokolem. Protokol PIM existuje celkem ve čtyřech variantách, další dvě, které rozebereme pouze stručně, se nazývají: Bidirectional PIM (BIDIR-PIM) vhodný pro aplikace typu many-to-many, varianta PIM-SM. Distribuční stromy jsou v tomto případě obousměrné, zatímco u PIM-SM jsou jednosměrné. Zjednodušení stromu si vysvětlíme na příkladu. Pokud budeme mít videokonferenci s deseti účastníky, u PIM-SM bude vytvořeno celkem 11 stromů. Deset stromů odpovídá cestám od zdrojů (všichni účastníci) k RP (upload) a poslední strom pak představuje sdílený strom pro distribuci dat k účastníkům (download). Naproti tomu u BIDIR-PIM bude vytvořen pouze jeden sdílený a obousměrný strom. To zjednodušuje implementaci, efektivita směrování však může být nižší. PIM source-specific multicast (PIM-SSM) varianta PIM-SM, při které se vytváří pouze SPT pro konkrétní zdroje a nevyžaduje aktivní RP pro tyto skupiny. Při doručování hraje roli adresa zdroje a tato technika je určena především pro přenosy, kde vysílá jeden zdroj a příjemců je celá řada, typicky IPTV nebo IP rádio. PIM-SSM skupiny mají vlastní adresní rozsah, což umožňuje jejich snadné rozlišení.

81 Pokročilé komunikační techniky 81 5 IP verze Motivace zavádění nového protokolu Rozšiřitelnost sítí podle budoucích požadavků a vzrůstající počet zařízení s potřebou konektivity (v posledních letech zejména mobilních) vyžaduje dostatek IP adres a také vylepšení dalších parametrů. Od počátku 90. let zvolna vyvstával problém s budoucím vyčerpáním adresního prostoru 28 při použití protokolu IPv4 a začalo se uvažovat o náhradě. Dalšími problémy, které postupně narůstají, pak jsou rozsah internetových směrovacích tabulek a neexistence skutečného end-to-end modelu komunikace (kvůli technice NAT a jejímu velkému rozšíření). Problémy s množstvím adres IPv4 nejsou v současnosti pouze z pohledu velikostí celého adresního rozsahu, ale i v konkrétních sítích z hlediska maximálního možného počtu uzlů. U opravdu velkých sítí (typicky mobilních) se pak můžeme setkat i s problémy nedostatku privátních adres 29. Aktivity spojené s řešením těchto problémů vyústily v IP protokol verze 6 (IPv6). IPv6 není jen novým protokolem síťové vrstvy, ale celou sadou protokolů, podobně jako původní TCP/IP, s tím rozdílem, že IPv6 řeší především úkoly síťové vrstvy. IPv6 kombinuje zvýšené množství adres s efektivnější hlavičkou protokolu, a jak bude popsáno dále, lépe splňuje i požadavky na hierarchické adresování. Již na začátek je důležité konstatovat, že v současné době dominatní IPv4, není v ohrožení v tom smyslu, že by zmizelo přes noc. Bude koexistovat s IPv6 a lze předpokládat, že časem bude nahrazeno. Současní a i budoucí síťoví odborníci budou nuceni pracovat s oběma protokoly. 5.2 Základní vlastnosti IPv6 Kromě rozšíření adresního prostoru došlo k diskuzi nad dalšími vlastnostmi IPv6 (které je s IPv4 nekompatibilní), jako např.: možnost autentizace a kryptografické zabezpečení mělo by být součástí implementace, připraveny mechanizmy pro přímé zajištění QoS, tj. značkování toků dat v záhlaví paketů, zjednodušení formátu záhlaví méně povinných položek (viz kap. 5.5), umožňuje zredukování velikosti směrovacích tabulek ve směrovačích podpora hierarchického směrování, malé snížení hodnoty zpoždění při zpracování ve směrovačích (nepřepočítává se CRC paketu, žádná fragmentace paketu v průběhu cesty), 28 V souvislosti s vyčerpáním IPv4 adres je zajímavý text a také grafy na 29 Jeden německý telekomunikační operátor s mezinárodní působností se potýká ve své mobilní síti s problémy s privátním adresním rozsahem sítě /8, kam lze čistě teoreticky umístit ( ,8 miliónů) uzlů, což však již vzhledem k vysokému počtu zákazníků nedostačuje.

82 82 FEKT Vysokého učení technického v Brně promyšlená mobilita stanic autokonfigurační mechanizmy, nové podpůrné protokoly ICMPv6 a DHCPv6, možnost větší teoretické maximální délky paketu až 4 GB/jednotka (tzv. jumbo pakety), pro speciální účely, jednotné adresní schéma pro celý Internet i vnitřní sítě, tři druhy adres individuální, skupinové a výběrové (unicast, multicast, anycast), lepší (nativní) podpora multicastových přenosů, a již zmiňované rozšíření adresního prostoru, z 32 bitů na 128 bitů, tedy z 2 32 adres na adres, poznámka 30. Tento rozsah byl navržen tak, aby byl pokud možno dostatečný již navždy a nemusel se dále rozšiřovat. 5.3 Historie a současnost IPv4 a IPv6 Základní myšlenkou Internetu byla možnost přímé komunikace dvou libovolných koncových stanic. To je v současné době v souvislosti s masivním nasazením NATu znesnadněno. Ztrácí se tak přímočarost komunikace, jelikož je vždy nezbytné vytvářet nějaké pomocné prostředky, které komunikaci zprostředkují. Naproti tomu uživatelé stále více využívají služby, které koncové spojení mezi stanicemi potřebují, např. komunikační systémy pro přenos zpráv, internetová telefonie a videokonferenční systémy, sítě pro výměnu dat. V souvislosti se zavedením IPv6, tak bylo plánováno vrátit Internet do původně zamýšleného stavu, bez NATu, což se ale zároveň jeví jako nepříliš reálné vzhledem k tomu, jak je již NAT zakořeněn v síťových technologiích i myšlení. Reálné nasazení IPv6 je spíše pozvolné a probíhá jen v některých sítích. Přibližně do konce roku 2010 platilo, že díky mnoha vylepšením, rozšířením a úpravě managementu adresace (NAT, viz , přísnější kritéria při přidělování) bylo IPv4 stále poměrně konkurenceschopné a uspokojovalo většinu současných požadavků. IPv4 adresování má skryty velké rezervy. V počátcích Internetu se přidělovaly adresy po velkých blocích (třída A), které nejsou zcela využity. Navíc platí, že pouze cca 70% rozdělených adres je ve směrovacích tabulkách, tj. globálně dostupných, a je otázkou kolik z těchto teoreticky dostupných adres je reálně použito. Další velkou rezervou je experimentální třída IP adres označována jako E (rozsah od /8 po /8), která není stále využita. Nicméně i kdyby se všechny tyto adresy podařilo využít, znamenalo by to pouze oddálení problému s vyčerpáním adres, přičemž další problémy IPv4 by zůstaly nevyřešeny. Celý problém se tedy dařilo poměrně úspěšně odsunovat, jak vyplývá i z Obr Zlom křivky způsobený NATem je poměrně výrazný. K očekávanému vyčerpání adresního prostoru (na globální úrovni) došlo počátkem roku 2011 (což již není součástí grafu). IPv6 se však stále rozšiřuje poměrně pomalu, což je způsobeno několika faktory. Jedním z nich je, že v IPv6 stále nejsou některé detaily dořešeny (není zcela dokončena standardizace), dále lze konstatovat, že IPv6 nerespektuje některé principy zažité z IPv4 (je v některých ohledech jiné) a zejména pak nasazení IPv6 znamené nemalé náklady. Nicméně situace se začíná měnit zejména díky silné podpoře velkých hráčů (Google, Facebook, Microsoft, ). 30 Teoretická hustota IPv4 adres: je přibližně 8 na 1 km 2 povrchu Země, zatímco u IPv6 je to cca na 1 m 2 povrchu Země.

83 Pokročilé komunikační techniky 83 Obr. 5-1: Časový vývoj spotřeby IPv4 adresního prostoru (globální alokace bloků /8) Jako vše, i IPv6 přináší i nevýhody. Dvě poměrně nepříjemné souvisí zejména s obrovským adresním prostorem. První je, že z pohledu správce nelze adresní prostor jedné sítě (v rozumném čase) propingat a zjistit tak (ne)přítomnost určitých IP adres. To může být z hlediska bezpečnosti považováno i za výhodu. Bezpečnost není primárním tématem tohoto textu, nicméně s velkým adresním rozsahem souvisí spousta nových L2 problémů. Druhá nevýhoda je znesnadnění využívání reverzního DNS pro IPv6, která vyplývá především z velkého množství IPv6 adres u jedné stanice, přičemž tyto adresy jsou navíc v čase proměnné. Další nevýhoda spočívá v tom, že v IPv4 byla postupem času vyřešena (zejména na hw úrovni přepínačů a také routerů) spousta drobných (např. bezpečnostních) problémů, které se však v IPv6 dosud nedořešily 31 nebo prvky, které tuto problematiku řeší, nejsou standardem na trhu. Příkladem je L2 snooping, účelné filtrování multicastů apod. IPv6 také přináší nové náklady na hardware, software a v neposlední řadě také lidské zdroje. Jak vyplyne z dalších kapitol, všeobecně se předpokládá, že dlouhou dobu poběží (ať už fyzicky nebo spíše logicky) dvě paralelní sítě (IPv4 a IPv6) a všechny aspekty komunikace (L3 směrování, firewally, ) budou tedy muset být řešeny dvakrát a zároveň bude náročné udržet obě tyto sítě funkční stejným způsobem tak, aby pro koncového uživatele bylo irelevantní, zda bude komunikovat přes IPv4 nebo IPv6. Z obchodního hlediska se pak u IPv6 jen těžko obhajuje návratnost investic (zejména na lokální úrovni a tam kde je dost IPv4 adres v rezervách). Z hlediska setrvačnosti je pak nevýhodou IPv6 i nerespektování základních pořádků IPv4 sítí, které hodně staví na NATu a DHCP. Jak bude popsáno dále v této kapitole, IPv6 přistupuje k těmto věcem jinak. Přes všechny uvedené fakty je IPv6 realitou, existují funkční globální, regionální poskytovatelské i lokální IPv6 sítě a např. v operačních systémech je podpora již delší dobu standardem, což má za následek, že bez znalosti IPv6 se již neobejdeme (a to ani v čistě IPv4 síti). Velkým problémem je existence obrovského množství software a hardware vytvořených na míru pro konkrétní použití nebo instituci. 31 Nemusí se vždy jednat o známé problémy. Některé komplikace vyjdou na povrch až při větším a masovějším nasazení IPv6 do praxe a IPv6 si bude muset na počátku projít určitými bolestmi nevyladěného protokolu.

84 84 FEKT Vysokého učení technického v Brně 5.4 Zavádění IPv6 Základní překážkou v rychlém zavádění IPv6 je především jeho nekompatibilita s IPv4. Bylo proto navrženo několik mechanizmů umožňujících hladký přechod od IPv4 k protokolu IPv6. Souvisí zejména s následujícími technikami: Souběh Internetových protokolů IPv6 a IPv4 (dual stack) software a hardware podporuje plně oboje. To samozřejmě vede k zvýšení nákladů na vývoj zařízení, ladění a tím pádem i koncovou cenu. Na Obr. 5-2 je pro aplikační protokol 1 použit IPv6 a naopak pro aplikační protokol 3 použit IPv4. Souběh IPv6 a IPv4 představuje jedinou možnou cestu pro nejbližší roky, problémem však zůstává neustávající potřeba adres IPv4, stanice mají totiž adresy obojího typu (IPv4 i IPv6). Tunelování, tedy většinou zapouzdření IPv6 paketu do IPv4. Tunelování bylo popsáno v kap Technika umožňuje komunikaci přes sítě s odlišnou verzí protokolu IP. Existují dva základní typy tunelů a to explicitně konfigurované a automaticky vytvářené. Jak název napovídá, explicitní tunel musí správce ručně nakonfigurovat a zprovoznit, např. pro konkrétní požadovanou trasu, zatímco automatický tunel se vytváří samočinným mechanizmem, bez přímého zásahu administrátora. Nejznámějším zástupcem automaticky vytvářeného tunelu je technika 6to4, což je zkrácený název pro Connection of IPv6 Domains via IPv4 Clouds, dále se můžeme setkat s tunelovacími protokoly Teredo, ISATAP a 6rd (IPv6 rapid deployment), více viz literatura nebo Internet. Na Obr. 5-2 je pro aplikační protokol 2 přímo na straně hosta prováděno tunelování IPv6 protokolu přes IPv4. Tunelování IPv6 do IPv4 je všeobecně problematické 32. Překlad adres podobný technice NAT, s tím rozdílem, že při překladu se zaměňuje IPv4 adresa za IPv6 adresu nebo opačně. Obecně se technika nazývá NAT-PT (Network Address Translator - Protocol Translator), zajímavý je především nástupce NAT64, více lze nalézt na Internetu. Hlavním cílem NAT64 je především zpřístupnit čistě IPv6 sítím původní svět IPv4. Tento protokol musí spolupracovat s DNS64, což je protokol, který provádí nezbytné manipulace s IPv6 adresami (které potřebuje čistě IPv6 stanice) a IPv4 adresami cílů (reálnými v IPv4 Internetu). NAT64 nemusí vůbec spolupracovat s celou řadou end-to-end aplikací, u kterých jsou např. využívány proprietární komunikační protokoly. Aplikační protokol 1 Aplikační protokol 2 Aplikační protokol 3 TCP/UDP IPv6 IPv4 Vrstva síťového rozhraní Obr. 5-2: Příklad na souběh IPv6 a IPv4 (dual stack) a také tunelování na straně hosta 32 Např. z pohledu poskytovatele připojení mohou tunelovaná spojení přinášet četné problémy jako nefunkční konektivitu zákazníků, kterou nelze poskytovatelem ovlivnit, jelikož tunel končí běžně vně sítě poskytovatele (u 6to4, Teredo a ISATAP). Dalším velkým problémem je bezpečnost, pomocí tunelu se mohou obcházet nastavená bezpečnostní pravidla sítě. Dočasným řešením má být navrhovaná technika 6rd (IPv6 rapid deployment), která představuje techniku tunelování pouze v rámci dosahu dané sítě resp. daného providera. Tato síť pak musí nutně alespoň částečně podporovat IPv6, více viz Internet.

85 Pokročilé komunikační techniky IPv6 datagramy (pakety) Struktura základního záhlaví IPv6 je schematicky naznačena na Obr. 5-3, popis jednotlivých položek následuje. Verze (version) 4 bity, stejně jako u IPv4 obsahuje verzi a zajišťuje, aby ostatní systémy, které zpracovávají datagram během přenosu, mohly různé pole datagramu správně použít. Verze IPv6 zde má samozřejmě hodnotu 6. Třída provozu (traffic class) 8 bitů, toto pole umožňuje nastavit prioritu paketu přepravní třídu. Cílem je, aby prostřednictvím této položky dokázala IP síť zaručovat kvalitu služeb. Využití tohoto pole však ještě není přesně definováno a hrozí proto, že dopadne podobně jako pole ToS u IPv4, jehož využití bylo ze začátku minimální. Identifikace toku dat (flow label) 20 bitů, označení toku dat, umožňuje zjednodušení směrování, protože spolu související pakety mají nastavenou stejnou hodnotu, a na jejím základě může tedy směrovač paket odeslat stejnou cestou, jako ty předcházející. Jedná se však o experimentální záležitost, která ještě není standardně implementována. Přidělení této značky probíhá u odesílatele paketu a tato hodnota se nesmí v průběhu přenosu změnit. Hodnota 0 značí, že paket nepatří k žádnému toku. Bity Verze IP Třída provozu Identifikace toku dat Celková délka přenášených dat Další záhlaví Limit počtu skoků IPv6 adresa odesílatele paketu IPv6 adresa příjemce paketu Přenášená data Obr. 5-3: Základní záhlaví IP datagramu verze 6 Celková délka přenášených dat (payload length) 16 bitů, délka přenášených dat bez velikosti základního záhlaví. Informace je o počtu bajtů. Maximální délka tedy může být až 64 kb. Pokud to nedostačuje, je nutno použít rozšiřující záhlaví tzv. jumbo obsah, viz dále. Další záhlaví (next header) 8 bitů, informace o vnořeném záhlaví, např. rozšiřující záhlaví pro přenos informace mezi směrovači, které (volitelně) následuje za IPv6 adresami (konec základní hlavičky). Pokud se další záhlaví nepoužívá, ukazuje na přítomnost protokolu vyšší vrstvy (zpravidla TCP nebo UDP).

86 86 FEKT Vysokého učení technického v Brně Limit počtu skoků (hop limit) 8 bitů, odpovídá položce TTL u IPv4. Maximální počet skoků, které smí paket absolvovat, směrovače tuto hodnotu postupně dekrementují. Základním cílem je, aby nedošlo k zacyklení paketů a ty, které není možné doručit, byly vždy rychle odstraněny ze sítě. IPv6 adresa odesílatele/příjemce paketu (source/destination address) každá 128 bitů. Z popisu je zřejmé, že celková délka základního záhlaví je 40 B. Tato délka je pevně dána, na rozdíl od protokolu IPv4, kde byla délka proměnná. Základní část záhlaví IPv4 má délku 20 B, což je polovina velikosti IPv6 záhlaví. Vzhledem k čtyřikrát delším adresám u IPv6 to však neznamená velký nárůst. Malý přírůstek velikosti záhlaví je dán vyřazení nadbytečných položek ze základního záhlaví. Konkrétně se jedná o pole rozšiřujících voleb, délka záhlaví, kontrolní součet a fragmentace. Některé operace lze provádět pomocí rozšiřujících záhlaví. Tyto záhlaví se řetězí za sebe a jedno vždy odkazuje na následující, podobně jako v základním záhlaví. Nejedná se přímo o odkaz (ukazatel), tak jak ho známe z některých programovacích jazyků. Informace spočívá v číselné hodnotě, která identifikuje typ dalšího záhlaví. Fragmentace je v současné době poměrně málo častý jev. Většinou se totiž na lokální úrovni používá Ethernet, který zvládá pakety až do délky 1500 B. IPv6 počítá s tím, že sítě zvládnou alespoň 1280 B. Proto se fragmentace nepředpokládá a byla odsunuta (pro speciální případy) do zvláštního rozšiřujícího záhlaví. Kontrolní součet na IP vrstvě verze 6 již není prováděn vůbec. Výpočet a jeho kontrola v každém uzlu zbytečně zpomalovaly směrovací proces. Za dostatečnou je považována kontrola, která je standardně prováděna na linkové vrstvě. Pokud by tato kontrola nestačila, je nutné implementovat ještě další na vyšší než síťové vrstvě. 5.6 Rozšiřující záhlaví U protokolu IPv6 je koncepce rozšiřujících záhlaví zcela odlišná od IPv4. U starší verze protokolu bylo rozšiřující záhlaví pohyblivou součástí standardního záhlaví. U IPv6 je pro každou rozšiřující operaci zřízena samostatná jednoúčelová hlavička. V případě, kdy je nezbytné použít v jednom paketu více rozšiřujících záhlaví, se tyto hlavičky skládají jednoduše za sebe. Nutnou podmínkou je, aby v každém rozšiřujícím záhlaví byla informace o typu následujícího záhlaví, jak již bylo uvedeno výše. Tato informace je vždy na začátku rozšiřujícího záhlaví. Poslední záhlaví pak obsahuje v tomto poli informaci o typu přenášených dat. Toto pole tedy zastupuje i dřívější pole Protokol, v kterém byla informace o typu přenášených dat protokol vyšší vrstvy. Vybrané typy viz Tab. 11. Ukázky různého složení paketů poskytuje Obr Pořadí, v jakém jsou rozšiřující záhlaví řazeny, nemůže být náhodné, ale je pevně dáno. Hlavní myšlenkou je, že informace, které mohou být potřeba už v průběhu přenosu paketu, jsou uvedeny dříve než ty, které jsou důležité až pro koncové uzly. Myšlenka zřetězování záhlaví přináší i určité komplikace, např. pro firewally, které musí tyto zřetězené záhlaví procházet, pokud se chtějí dostat do datové části paketu.

87 Pokročilé komunikační techniky 87 Tab. 11: Vybrané typy rozšiřujících záhlaví / typů nesených dat Identifikace Rozšiřující záhlaví / typ nesených dat (použití) 0 volby pro všechny (hop-by-hop options) (např. jumbo paket) (pouze IPv6) 43 směrování (pouze IPv6) 44 fragmentace (pouze IPv6) 50 šifrování obsahu (IPv6 i IPv4) 51 autentizace (IPv6 i IPv4) 59 poslední hlavička (IPv6) (no next header) 135 mobilita (IPv6 i IPv4) 6 TCP (Transmission Control Protocol) 8 EGP (Exterior Gateway Protocol) 9 IGP (Interior Gateway Protocol) 17 UDP (User Datagram Protocol) 58 ICMPv6 (Internet Control Message Protocol) IPv6 záhlaví Další záhlaví=17 (UDP) UDP datagram IPv6 záhlaví Další záhlaví=44 (frag.) Fragmentace Další záhlaví=17 (UDP) UDP datagram a) b) IPv6 záhlaví Další záhlaví=43 (směr.) Směrování Další záhlaví=44 (frag.) Fragmentace Další záhlaví=17 (UDP) UDP datagram c) Obr. 5-4: a) IPv6 paket bez rozšiřujících záhlaví b) IPv6 paket s jedním rozšiřujícím záhlavím c) IPv6 paket s dvěma rozšiřujícími záhlavími 5.7 Adresace IPv Adresní prostor a způsoby adresování Sada IPv6 rozšiřuje adresní prostor na což je přibližně 3, , tedy téměř IPv6 adres na 1 m 2 povrchu Země (včetně moří), resp. stále těžko představitelných IPv6 adres na 1 mm 2 povrchu. Pro srovnání, IPv4 adres je přibližně 8 na 1 km 2 a to jen když počítáme celý rozsah, včetně adres, které jsou určeny pro speciální použití. Adresní prostor IPv6 je tedy prakticky nevyčerpatelný a není nezbytně nutné ho využívat maximálně efektivně. Hospodaří se s ním spíše velmi neefektivně, viz dále. V IPv6 jsou definovány tři druhy adresování, které mají odlišné chování:

88 88 FEKT Vysokého učení technického v Brně individuální (unicast) adresy identifikující jednotlivá síťová rozhraní, tak aby na ně mohly být zasílány pakety. skupinové (multicast) jsou určeny pro adresování skupin. Platí, že pakety odeslané na tuto adresu by měly být doručeny všem členům skupiny. Tyto adresy zastupují i všesměrové (broadcast) adresy, které nejsou v rámci IPv6 definovány samostatně. V rámci adresního prostoru jsou definovány speciální skupiny, které reprezentují např. všechny uzly na dané lince atd. výběrové (anycast) také označují skupinu adresátů, rozdíl je však v tom, že pakety se posílají pouze jedinému jejímu členu, zpravidla tomu, který je nejblíže. Tento typ existuje i v IPv4. Podstatnou změnou v IPv6 je, že jedno rozhraní běžně využívá více než jednu IPv6 adresu, více viz kap Zápis adres Adresy IPv6 jsou skutečně velmi dlouhé. Jejich vhodný zápis představuje problém. Nakonec se přistoupilo k tomu, že adresy jsou zapisovány jako 8 skupin 4 hexadecimálních číslic oddělených dvojtečkou, např.: 8000:0000:0000:0000:0ABC:DEF1:0345:789A Každá část (mezi dvojtečkami) představuje 16 bitů. Jestliže adresa obsahuje mnoho nul (souvislý blok), je umožněno užívat zkrácený zápis: 8000::0ABC:DEF1:0345:789A Znak :: se může ve zkráceném zápisu objevit pouze jednou. Navíc je definována i možnost v zápisu neuvádět úvodní nuly v každé čtveřici, tedy nejkratší možný zápis výše uvedené adresy je: 8000::ABC:DEF1:345:789A Hexadecimální formát připomíná fyzické adresy, např. u Ethernetu je však jejich délka pouze 48 bitů. Ze zápisu IPv6 adresy je zřejmé, že se nepočítá s tím, že by si ji člověk mohl běžně pamatovat. Ještě se tak zvyšuje důležitost protokolu DNS, který běžné uživatele od těchto adres osvobodí, správci sítí se však těmto adresám nikdy úplně nevyhnou. Některé z přechodových mechanizmů mezi IPv4 a IPv6 vyžadují možnost zapsat do IPv6 adresního pole IPv4 adresu. Tyto adresy se nazývají IPv4-mapované adresy. Pravidlo pro jejich zápis je takové, že prvních 80 bitů jsou nuly, dalších 16 bitů 1, zbývajících 32 bitů je IPv4 adresa. Formální zápis je tedy např.: ::FFFF: Podobně jako u IPv4 je i u IPv6 definován tzv. prefix, tj. začátek adresy, který představuje adresu sítě (nebo podsítě). Jeho délka se pak běžně zapisuje za lomítko umístěné za IP adresou, např. 8000::ABC:DEF1:345:789A / 64 znamená, že první polovina adresy je adresa sítě a zbytek je adresa stanice.

89 Pokročilé komunikační techniky Typy adres V rámci adresního rozsahu IPv6 jsou definovány speciální (pod)typy adres. Jejich základní rozdělení shrnuje následující Tab. 12, popis následuje. Pro přehlednost je na Obr. 5-5 uvedeno i grafické znázornění jednotlivých typů, o kterých bude dále pojednáno. IPv6 adresace Unicast Multicast Anycast Přiřazená adresa (ff00::/8) Vyzývaný uzel (ff02::1:ff00:0000/104) Globální unikátní (2000::/3) Linkové unikátní (fe80::/10) Lokální smyčka (::1/128) Nespecifikovaná adresa (::/128) Lokální unikátní (fc00::/7) IPv4 kompatibilní (::/80) Obr. 5-5: Grafické znázornění základních typů IPv6 adres a jejich příslušnosti do tří existujících druhů adres Nedefinovaná adresa její použití poskytuje informaci, že dosud nebyla přiřazena žádná platná adresa. Lokální smyčka má stejný význam jako u IPv4, umožňuje počítači komunikovat sám se sebou. Pakety s touto adresou neopustí počítač. Rozdílnost spočívá v tom, že se jedná však pouze o jednu adresu, ne o celý rozsah jako u IPv4. Lokální linkové adresy (fe80::/10) mají stejný význam jako adresy /16 u IPv4. Jedná se o adresy s lokální platností v rámci dané linky (Ethernet síť, wifi buňka). Tyto adresy jsou nastaveny u každého aktivního rozhraní. Dosah této adresy je tedy pouze lokální, jak vyplývá už z názvu. Datagramy s touto adresou neprojdou přes žádný směrovač. Adresa složena z fe80, pak následují binární 0 až do 64. bitu, dále následuje adresa dle EUI- 64 (viz ). Stanice si tedy tuto adresu vytvoří sama a automaticky. To je její hlavní výhodou adresa je k dispozici vždy. Tyto adresy lze pak např. využít ke komunikaci mezi stanicemi propojenými přepínačem, dále jsou využívány např. v protokolu automatické konfigurace DHCPv6 pro výměnu zpráv mezi klientem a serverem. Lokální unikátní adresy (fc::/7) jsou ve většině případů generovány taktéž lokálně, poté mají prefix fd::/8 (o jedničku na dalším bitu vyšší hodnota). Dalších 40 bitů adresy reprezentuje globální identifikátor, kterým je ve skutečnosti náhodně vygenerované číslo. Pravděpodobnost, že dvě sítě zvolí stejnou hodnotu těchto bitů, je velmi nízká. Dalších 16 bitů je adresa podsítě (viz dále) a posledních 64 bitů je již identifikátor konkrétního rozhraní typu EUI-64 (viz ). U těchto adres se předpokládá, že nejsou směrovány Internetem. Jak z názvu vyplývá, mají pouze lokální platnost. Přesto ale musí být unikátní. Problém totiž spočívá v definici pojmu, co je lokální. Tyto adresy mohou být použity pro případy, kdy se více lokálních sítí v různých lokalitách, např. budovy univerzit ve městě, tváří jako jedna lokální síť. Správci těchto sítí mohou mít důvody k tomu, že pro lokální použití se nebudou využívat globální adresy, ale právě tyto lokální unikátní adresy. Z určitého pohledu se jedná o obdobu privátních adres z rozsahu IPv4. Skupinové adresy (ff00::/8) slouží především k distribuci multimediálního obsahu, jako je zvuk a obraz, a to v reálném čase. Adresa je strukturovaná na následující části. Prvních

90 90 FEKT Vysokého učení technického v Brně 8 bitů jsou vždy jedničky (ff, hexadecimálně), další čtyři bity jsou určité volby, dále čtyři bity definují dosah platnosti adresy a zbývajících 112 bitů je vyhrazeno pro adresu skupiny. Příklady dosahu jsou hodnoty: 2, kdy má skupinová adresa platnost pouze pro danou linku a hodnota E, kdy není dosah omezen skupinová adresa je platná globálně. Ve skutečnosti má 112 bitů vyhrazených pro adresu skupiny ještě další povinné členění, které způsobuje, že identifikátor skupiny je finálně pouze 32 bitů dlouhý. I to je ale poměrně vysoká a plně dostačující hodnota. Globální adresy jsou adresy pro běžné použití, které principiálně zastupují dnešní IPv4 adresy veřejného typu. Více viz kap Tab. 12: Základní (pod)typy IPv6 adres Prefix Význam ::/128 nedefinovaná adresa ::1/128 lokální smyčka (loopback) fe80::/10 (individuální) lokální linkové adresy fc00::/7 (individuální) lokální unikátní adresy ff00::/8 skupinové (multicast) adresy ostatní (individuální) globální adresy (většina rozsahu) Přehledné členění celého IPv6 adresního rozsahu z hlediska využití prvních dvou bajtů poskytuje Tab. 13. Z ní je velmi dobře patrné, jak je adresní prostor využíván neefektivně a jaké má obrovské rezervy. V současnosti (2012) panuje názor, že nepřiřazené rozsahy již nebudou nikdy využity. Tab. 13: Přehledné členění celého adresního prostoru IPv6 Adresy od do (první dva bajty) Význam (procenta uvedena jen částí nad 10 % rozsahu) 0000 až 00ff Nespecifikované, lokální smyčka, IPv4 kompatibilní adresy 0100 až 01ff Nepřiřazeno 0200 až 03ff Speciální adresy, význam je nad rámec textu 0400 až 1fff Nepřiřazeno (11 % celého rozsahu) 2000 až 3fff Agregovatelné globální unicastové adresy (12,5 %) 4000 až fbff Nepřiřazeno (75 %) fc00 až fdff (individuální) lokální unikátní adresy fe00 až fe7f Nepřiřazeno fe80 až febf (individuální) lokální linkové adresy fec0 až feff Site local adresy (zrušeny, proto jim není věnována pozornost) ff00 až ffff skupinové (multicast) adresy

91 Pokročilé komunikační techniky Globální individuální adresy Skladba adresy Globální individuální adresy jsou adresy pro běžné použití, zastupující dnešní IPv4 adresy veřejného typu. Slouží tedy k identifikaci určitého síťového rozhraní v celém Internetu. Přidělování těchto adres mají na starost stejné organizace jako přidělování IPv4 adres, tedy IANA prostřednictvím svých regionálních zastoupení (viz kap. 3.3). Při přidělování rozsahů adres zákazníkům je nezbytné, aby probíhalo hierarchicky. Snahou je, aby číselně blízké rozsahy byly i v rámci fyzické topologie blízko sebe. To následně umožňuje při pohledu zvenčí efektivně agregovat směrovací tabulky a zrychlit tak celý směrovací proces. Více k této problematice je možné nalézt v kap IPv6 adres může být obrovské množství, což samo o sobě znamená enormní nárůst směrovacích tabulek a zpomalení celé směrovací úlohy (na globální úrovni). Právě kvůli maximálnímu možnému zjednodušení byla zavedena pevná struktura globální individuální adresy, která je naznačena na Obr Délky jednotlivých částí jsou definovány obecně, v obrázku uvedené hodnoty jsou ty, které jsou v současné době platné. 48 bitů 16 bitů 64 bitů Globální směrovací prefix Identifikátor podsítě Identifikátor rozhraní Veřejná topologie Místní topologie Lokální síť Obr. 5-6: Struktura globální individuální adresy Globální směrovací prefix odpovídá de facto adrese sítě v IPv4. Celkem těchto prefixů může být 2 48, tedy 2, Pro přiblížení, tento počet odpovídá přibližně globálním sítím na jednoho obyvatele Země. Identifikátor podsítě je určen k rozlišení jednotlivých podsítí v rámci celé sítě. Rozdělení na podsítě je důležité např. z pohledu rozdělení celé sítě na o něco menší a lépe spravovatelné jednotky. V rámci každé sítě může být až 2 16 podsítí, tedy celkem podsítí, což je poměrně vysoké číslo. Rozdělení na podsítě je plně v kompetenci dané organizace. Identifikátor rozhraní slouží k odlišení koncových stanic v rámci lokální sítě. V této koncové sítí pak může být až 2 64 stanic (1, ). Poznámka k počtu stanic je níže 33. Toto číslo je tak velké, že nemůže nastat situace, že by společnost v rámci své lokální sítě adresy vyčerpala. Samozřejmě je možné i v rámci tohoto velkého rozsahu vytvářet další podsítě, tj. podsíťovat i v rámci těchto dolních 64 bitů. Nepočítá se ale s tím, že by to byla běžná praxe. Informace o těchto podsítích se však nesmí (a ani nemohou) dostat až na globální úroveň. Na globální úrovni je totiž maximální možná délka prefixu stanovena pevně na 64 bitů. Důvod je zřejmý čím kratší prefix, tím méně možných kombinací a záznamů ve směrovacích tabulkách a tím rychlejší je směrování. Z výše uvedeného je patrné, že adresním prostorem se nesmírně mrhá. Vzhledem k jeho velikosti si to však můžeme bez problémů dovolit. Ve skutečnosti je však situace ještě o něco složitější, než jak bylo uvedeno výše. Při přidělování IPv6 rozsahu totiž záleží na 33 V IPv6 platí, že je možné využít skutečně všechny bity, tj. není vyhrazena první adresa rozsahu jako adresa sítě a poslední adresa jako všesměrová. Tj. na rozdíl od IPv4 nemusíme odečítat dvě adresy, abychom získali skutečný počet možných adres v daném rozsahu

92 92 FEKT Vysokého učení technického v Brně velikosti zákazníka. Jen opravdu velcí zákazníci obdrží rozsah s prefixem délky 48 bitů. Menší zákazníci dostanou delší prefix (typicky /56), v případě těch nejmenších dokonce jen 64-bitový. I tento malý rozsah je však prakticky nevyčerpatelný, takže to (alespoň z dnešního pohledu) nepředstavuje žádný problém. Pozn.: Bohužel také platí, že ne vždy musí být respektovány výše uvedené hranice. Vysoké učení technické v Brně disponuje prefixem 2001:67c:1220::/46. Nicméně lze na to nahlížet i tak, že má vlastně čtyři bloky /48 vedle sebe, které je možné sumarizovat do uvedeného rozsahu / Přidělování globálních prefixů Přidělováním IPv6 adres (resp. pouze prefixů) se zabývá (stejně jako u IPv4 adres) organizace IANA (Internet Assigned Numbers Authority), o které bylo pojednáno v kap Prostřednictvím svých regionálních částí - RIR (Regional Internet Registry) (a ty pak prostřednictvím svých lokálních částí, tzv. LIR = Local Internet Registry) jsou přidělovány 48-bitové globální prefixy. Rozvržení bitů je znázorněno na Obr bitů 16 bitů IANA RIR LIR Globální směrovací prefix Obr. 5-7: Struktura globálního směrovacího prefixu z hlediska toho, kdo přiděluje jednotlivé části Jiný pohled na členění horních 64 bitů adresy je možné interpretovat následujícím obrázkem. Veškerý popis je součástí obrázku. Globální směrovací prefix ID podsítě ID rozhraní IANA /3 RIR* /23 /32 /48 /56 /64 LIR (ISP)* Prefix lokality (sítě) Možný prefix malé sítě (domácí) Konkrétní podsíť * = hranice není pevná Obr. 5-8: Délky prefixů dle jednotlivých úrovní (běžné hodnoty) Přístupy k volbě identifikátoru rozhraní Identifikátor rozhraní slouží k odlišení koncových stanic v rámci lokální sítě. Je to nejméně významných 64 bitů IPv6 adresy. Stanovení hodnoty této části adresy je vždy závislé až na koncovém zákazníkovi. Existují dva základní způsoby stanovení konkrétní hodnoty:

93 Pokročilé komunikační techniky 93 Standard IEEE EUI-64 Jestliže má dané rozhraní již nějaký identifikátor (např. fyzickou adresu), tak se tato hodnota převezme a případně doplní na potřebnou délku. Pro nejběžnější sítě (Ethernet) je definováno pravidlo, že 64 nejméně významných bitů IPv6 adresy - identifikátoru rozhraní je vytvořeno za pomoci fyzické adresy (délky 48 bitů) a konstanty (délky 16 bitů). Funguje to tak, jak je naznačeno na Obr Ethernet 0 0 : 8 C : A 0 : C 4 : 3 E : 1 6 MAC EUI C: A 0 F F : F E C 4 : 3 E 1 6 Obr. 5-9: Způsob vytvoření IPv6 adresy pomocí MAC adresy (EUI-64) Aby se získala potřebná délka, doprostřed adresy se vloží konstanta (FFFE). Dále se jeden bit v prvním bajtu změní z 0 na 1, což indikuje to, že adresa je určena pro globální použití. Jednoznačnost adresy by měla být zaručena, jelikož fyzické adresy by měly být samy o sobě vždy unikátní. Problémem tohoto přístupu je ochrana soukromí. Je totiž možné identifikovat konkrétní počítač, ať je připojen kdekoliv po celém světě. Vždy bude totiž mít nejnižších 64 bitů IPv6 adresy stejných. Při změně sítě (lokality) se změní pouze prefix část lokálního identifikátoru zůstane nezměněna. Je tak možné sledovat pohyb konkrétní stanice. Z tohoto důvodu byl navržen ještě zcela odlišný princip, viz dále. Náhodně generovaná adresa Z důvodu ochrany soukromí byl (v RFC 4941) navržen přístup, že identifikátor rozhraní bude generován náhodně (v koncové stanici). Dále platí, že se bude po určitém časovém intervalu generovat nová adresa. Adresa má tedy pouze omezenou platnost. Nevýhodou tohoto přístupu je, že není možné se na tento stroj s proměnnou adresou dostat zvenčí (problém pro servery a služby). Musí tedy být definován nějaký pevný bod, zpravidla záznam v DNS, který obsahuje pevnou adresu typu EUI-64. Adresa tohoto typu bude používána pro příchozí spojení. Pro odchozí pak náhodná adresa, která samozřejmě nebude ukládána do DNS systému (to by celý efekt znehodnotilo). Jedno rozhraní má tedy více než jednu IPv6 adresu, které jsou pro různé účely. Při použití náhodně generované adresy existuje jisté (byť velmi nízké) riziko, že vygenerovaná adresa je již v síti používána. Proto je nezbytné, aby stanice, než začne tuto adresu používat, zjistila, zda někdo už tuto adresa nevyužívá. K tomu slouží ICMPv6 zprávy, více viz kap Globální unikátní adresy mohou vznikat různými způsoby, zejména z pohledu přístupu k dolním 64 bitům adresy. Základní členění na základě způsobu konfigurace je ukázáno na Obr Dosud nezmíněné postupy budou popsány v dalších kapitolách.

94 94 FEKT Vysokého učení technického v Brně Globální unikátní (2000::/3) Konfigurované na základě lokálních informací Konfigurované na základě informací ze sítě EUI-64 adresy Ručně konfigurované Náhodně generované Automatická bezestavová konfigurace DHCPv6 Obr. 5-10: Možné přístupy k vytvoření globální unikátní IPv6 adresy Výběrové adresy Mějme velmi žádanou službu, kterou využívá velké množství uživatelů. Typickým příkladem je systém DNS, resp. kořenové servery, o nichž bylo pojednáno v kap Zřejmou snahou je rovnoměrně rozložit zátěž mezi více serverů. Toho lze dosáhnout tak, že se těmto serverům přiřadí výběrová adresa. Následně je klient při přístupu ke službě, kterou servery zajišťují, směrován na jemu nejbližší server. Výhodou řešení je i flexibilita - složení skupiny lze měnit podle toho, jak se mění naše požadavky. Velkou výhodou tohoto řešení je i slušná ochrana proti útokům typu DoS (Denial of Service) a DDoS (Distributed Denial of Service), jelikož potenciální útočníci jsou schopni vždy dosáhnout jen na jim blízké servery. Výběrové adresy nemají vyhrazen speciální rozsah a není možné je rozlišit od běžných individuálních adres. To že se bude jednat o výběrovou adresu je dáno její konfigurací ve směrovacích protokolech, což je však nad rámec tohoto textu Povinné adresy IPv6 U koncové stanice jsou povinné tyto IPv6 adresy: Lokální linková adresa pro každé rozhraní, všechny individuální a výběrové adresy, které byly přiděleny, lokální smyčka, skupinové adresy pro všechny uzly, což je registrovaná adresa, na kterou uzly pravidelně posílají zprávy, že stále chtějí multicast přenos přijímat, skupinová adresa pro vyzývaný uzel pro všechny přidělené individuální a výběrové adresy; adresa, na které daný uzel přijímá multicast, všechny skupinové adresy, jejichž je členem. Vysvětlení je podáno na následujícím Příklad 5.1 (převzato a částečně modifikováno z lit [ 33] ). Je z něj patrné, že stanice může být ve více podsítích zároveň, což počet adres ještě zvyšuje. U směrovače k povinným adresám, které musí mít koncová stanice, přibývají ještě tyto: výběrová adresa pro směrovače v podsíti (pro každé rozhraní) skupinové adresy pro všechny směrovače

95 Pokročilé komunikační techniky 95 Příklad 5.1 Adresy IPv6 koncového uzlu Mějme počítač s MAC adresou 00:2a:0f:32:5e:d1. Odvozený identifikátor rozhraní (podle postupu v kap ) je 22a:fff:fe32:5ed1. Počítač má dvě individuální adresy je totiž členem dvou podsítí v rámci své organizace. První z nich má prefix 2001:db8:a319:15::/64, druhá 2001:db8:a319:3::/64. Dále je tato stanice členem skupiny ff15::ac07. Kromě těchto adres pak ještě bude zpravidla stanice mít dočasnou adresu, která má náhodně generovanou část. Následující Tab. 14 shrnuje seznam adres, na nichž je stanice povinna přijímat nebo odesílat data Výběr adresy k použití Z předcházejícího textu je patrné, že jedno rozhraní disponuje vždy více IPv6 adresami. V paketu však může být uvedena pouze jedna adresa, resp. dvě jedna zdrojová a druhá cílová. Výběr adresy pro konkrétní typy použití definuje RFC 3484 (Default Address Selection for IPv6). Rozhodovací proces je založen na místní tabulce preferencí. Funguje to podobně jako směrovací tabulka hledá se nejlepší kandidát. Nastavení preferencí je často závislé na konkrétní implementaci sady IPv6 (výrazná preference dočasných adres ve Windows Vista a vyšších). Nutno podotknout, že v některých případech se musí vybírat nejen zdrojová adresa, ale i cílová. Zájemce o podrobnější seznámení odkazujeme na literaturu nebo již zmíněné RFC Tab. 14: K příkladu na povinné adresy pro koncovou stanici Typ Adresa lokální linková Přidělená individuální (první podsíť) Přidělená individuální (druhá podsíť) fe80::22a:fff:fe32:5ed1 2001:db8:a319:15:22a:fff:fe32:5ed1 2001:db8:a319:3:22a:fff:fe32:5ed1 Lokální smyčka ::1 Všechny uzly v rámci rozhraní multicast v rámci rozhraní Všechny uzly v rámci linky multicast v rámci linky Vyzývaný uzel příjem multicastu Přidělená skupinová Dočasná náhodná globální (první podsíť) Dočasná náhodná globální (druhá podsíť) ff01::1 ff02::1 ff02::1:ff32:5ed1 ff15::ac :db8:a319:15:a:5:32a:a :db8:a319:3:b:e5:302c:8adc Podsíťování v IPv6 Princip podsíťování je při IPv6 adresaci stejný jako u IPv4. Vytváření podsítí probíhá tak, že bity, které byly původně určeny k adresování stanic, využijeme k definování oddělených podsítí. Situace je komplikována pouze tím, že IPv6 adresy jsou poněkud delší, což lze ale brát i jako výhodu. Jak je patrné z předcházejících kapitol, globální IPv6 adresa má

96 96 FEKT Vysokého učení technického v Brně již přímo 16 vyhrazených bitů pro definici podsítí, avšak obecně můžeme mluvit o podsíťování i v úrovni bitů pro identifikaci stanice. Uveďme si nejdříve příklad na podsíťování v rámci vyhrazeného rozsahu bitů. Mějme přidělený globální směrovací prefix: 2001:aaaa:bbbb::/48 Představme si, že chceme vytvořit 4 podsítě. V IPv4 bychom použili dva bity, aby počet bitů zbývajících na adresy stanic byl co nejvyšší. V IPv6 ovšem v tomto případě problém s počtem stanic nemáme i když použijeme pro podsítě prefix /64. Čtyři vytvořené podsítě tedy mohou být například: 2001:aaaa:bbbb:0000::/64, tj. 2001:aaaa:bbbb:0::/ :aaaa:bbbb:0001::/64, tj. 2001:aaaa:bbbb:1::/ :aaaa:bbbb:0002::/64, tj. 2001:aaaa:bbbb:2::/ :aaaa:bbbb:0003::/64, tj. 2001:aaaa:bbbb:3::/64 Je zřejmé, že kapacita pro další podsítě je velmi vysoká. Jak bylo již uvedeno, můžeme vytvořit celkem podsítí (máme 16 bitů). Vytvořené podsítě nemusí ani nutně být v adresním prostoru vedle sebe (pokud je nechceme uvnitř naší sítě sumarizovat). Proto se běžně využívá pravidlo, že do identifikace podsítě se uloží hodnota, která koresponduje s IPv4 adresou podsítě. Tj. pokud by např. čtyři podsítě měly IPv4 adresy /23, /23, /23 a /23, bylo by možné IPv6 podsítě nastavit jako: 2001:aaaa:bbbb:dc::/64, kde dc (hex) = 220 (dec) 2001:aaaa:bbbb:de::/64, kde de (hex) = 222 (dec) 2001:aaaa:bbbb:e0::/64, kde e0 (hex) = 224 (dec) 2001:aaaa:bbbb:e2::/64, kde e2 (hex) = 226 (dec) Nyní si představme, že máme k dispozici pouze prefix konkrétní podsítě, který chceme dále podsíťovat na čtyři menší podsítě: 2001:dddd:1111:eeee::/64 Ani v tomto případě nemusíme s bity nijak šetřit a je výhodné a následně i velmi přehledné použít na podsíťování celých 16 bitů bez ohledu na to, kolik podsítí potřebujeme. Tj. vytvořené podsítě by mohly mít adresy např.: 2001:dddd:1111:eeee:0::/ :dddd:1111:eeee:1::/ :dddd:1111:eeee:2::/ :dddd:1111:eeee:3::/80 V každé z těchto podsítí může stále být prakticky nevyčerpatelných 2 48 stanic, což je přibližně rovno unikátních adres. Pozn.: V praxi se můžeme setkat i s tím, že je podsíť vytvořena záměrně tak, aby její adresní rozsah byl velmi malý a tedy i snadno procházený a chránitelný. Pokud víme, že v uvedené síti je pouze jedno zařízení (a chci si nechat do budoucna nějakou rezervu), můžu použít např. prefix délky /124, což znamená, že síť bude mít kapacitu stanic rovnu pouze 16.

97 Pokročilé komunikační techniky Protokol ICMPv6 ICMP (Internet Control Message Protocol) je i ve verzi 6 režijním (servisním) protokolem Internetu. Nepřenáší žádná uživatelská data, jeho zavedení je ve všech implementacích a aktivních prvcích s podporou IPv6 povinná. Bez ICMPv6 je IPv6 nefunkční. Protokol ICMP se využívá pro ohlašování chybových stavů, testování dostupnosti síťové vrstvy a také k výměně určitých provozních informací. V rámci IPv6 se tento protokol používá také k tzv. objevování sousedů (viz kap. 5.9), podpoře správy multicastových skupin, překladu adres a zajištění mobility. Základní formát ICMPv6 zprávy je naznačen na Obr Položka typ určuje základní druh zprávy, další položka (kód) pak umožňuje tento typ blíže specifikovat vytváří se tzv. podtypy. Položka tělo zprávy pak závisí na konkrétním typu a délka tohoto pole je tudíž proměnná. Přehled vybraných typů ICMPv6 zpráv je možné nalézt v Tab. 15. Bity Typ Kód Kontrolní součet Tělo zprávy Obr. 5-11: Základní formát ICMPv6 zprávy Problematiku hlášení chybových stavů a echo již obsahoval původní ICMP protokol. Oblast Multicast Listener Discovery (MLD) se týká práce s multicastovým skupinami, která spadala v IPv4 sítích do působnosti protokolu IGMP (Internet Group Management Protocol). MLD protokolu je věnována kap Problematice objevování sousedů je věnována kap Novinkou v ICMPv6 je možnost získat základní informace o uzlu k tomuto účelu jsou vyhrazeny dva typy zpráv (139 a 140). Tento mechanizmus je ve stádiu experimentů a umožňuje dotaz (a odpověď) na jméno uzlu nebo adresu (jak IPv6 tak IPv4). Inverzní objevování sousedů je obdobou inverzního ARP protokolu, pro případy, kdy potřebujeme na základě znalosti fyzické adresy zjistit síťovou (logickou) adresu. Podpora mobility stanic, o níž již byla řeč, je zajišťována také protokolem ICMPv6, konkrétně zprávami ICMPv6 má po mnoha negativních zkušenostech s ICMP protokolem ze sítí IPv4 přímo implementovaná i určitá bezpečnostní opatření. Není totiž žádoucí, aby bylo ICMP z důvodu potenciálního rizika blokováno, jako je tomu u mnohých serverů v současné době. Implementace ICMPv6 protokolu by správcům měla umožňovat nastavit určité kvantitativní parametry protokolu. Jsou to povolený průměrný počet ICMP zpráv za jednotku času anebo maximální podíl zpráv ICMP na celkové šířce pásma. Prostřednictvím těchto nastavení lze zabránit zahlcení prvku nebo linky. Další možností je, že ICMP zpráva může mít bezpečnostní záhlaví, které poskytuje možnost autentizace komunikující strany. Lze pak nastavit, že pokud ICMP zpráva není s autentizací, bude se zahazovat.

98 98 FEKT Vysokého učení technického v Brně Tab. 15: Vybrané typy ICMPv6 zpráv Skupina Číslo typu Popis chyby 1 cíl je nedosažitelný 2 příliš velký paket 3 vypršela životnost paketu 4 problém s parametry (chybný datagram) echo 128 požadavek na odezvu (echo) 129 odpověď na požadavek o odezvu MLD (skupinové 130 dotaz na členství ve skupině adresování) 131 ohlášení členství ve skupině (viz kap. 5.13) 132 ukončení členství ve skupině objevování sousedů 133 výzva směrovači (viz kap. 5.10) (ND = Neighbor Discovery) 134 ohlášení směrovače (viz kap. 5.10) 135 výzva sousedovi (viz kap. 5.9) 136 ohlášení souseda (viz kap. 5.9) 137 přesměrování (viz kap. 5.10) informace o uzlu 139 dotaz na informace 140 odpověď na dotaz o informace inverzní objevování sousedů 141 inverzní objevení souseda výzva 142 inverzní objevení souseda ohlášení mobilita 144 žádost o adresy domácích agentů (viz kap. 5.12) 145 odpověď s adresami domácích agentů 146 žádost o mobilní prefix 147 odhlášení mobilního prefixu objevování skupinových 151 ohlášení skupinového směrovače směrovačů 152 výzva skupinového směrovače 153 ukončení skupinového směrovače 5.9 Objevování sousedů (Neighbor Discovery) Pod pojmem objevování sousedů se skrývají funkce používané na lokální úrovni v rámci jedné sítě. Nejznámějším případem je překlad logických adres na skutečné, který je v sítích IPv4 zajišťován samostatným protokolem ARP. Fyzické adresy potřebujeme,

99 Pokročilé komunikační techniky 99 abychom byli schopni komunikovat v rámci lokální sítě. Neighbor Discovery (ND) slouží však i k dalším účelům: již zmiňované zjišťování fyzických adres v rámci lokální sítě, aktualizace neplatných položek a zjišťování změn ve fyzických adresách, hledání směrovačů, přesměrování, zjišťování prefixů, parametrů sítě a dalších údajů pro automatickou konfiguraci adresy (viz kap. 5.10), ověření dosažitelnosti sousedů, detekce duplicitních adres. Ve všech případech jsou k přenosu využívány ICMPv6 zprávy, jejichž přehled poskytuje Tab. 15. Hledání sousedů funguje velice podobně, jako u protokolu ARP. Kosmetická změna spočívá v přejmenování zpráv (výzva sousedovi = neighbor solicitation a ohlášení souseda = neighbor advertisement). Důležitější změnou je adresa, na kterou se zpráva zasílá. U ARP protokolu to bylo na všesměrovou lokální fyzickou adresu ff:ff:ff:ff:ff:ff a protokol neobsahuje žádné IP záhlaví. U ND je pro tyto účely vyhrazena IP multicastová skupina s prefixem ff02:0:0:0:0:1:ff00::/104. Spodních 24 bitů adresy se poté vytvoří tak, že se z hledané IPv6 adresy odebere právě nejnižších 24 bitů. Této adrese se pak říká adresa pro vyzývaný uzel (solicited node address). Aby tento mechanizmus fungoval, musí stanice při startu síťového rozhraní vstoupit do všech skupin odpovídajících adresám vyzývaného uzlu. To musí udělat pro všechny adresy, které má dané rozhraní přiděleno. Ve svém důsledku tento mechanizmus znamená, že zprávu výzva sousedovi nedostane každý v síti (broadcast), ale jen stanice, které mají poslední tři bajty IPv6 adresy shodné. Zpravidla je to v rámci lokální sítě jen jedna (hledaná) stanice a ostatní uzly nejsou zbytečně zatěžovány provozem, který se jich netýká. Z hlediska řešení linkové vrstvy je ještě důležité poznamenat, že rámec s ND není zasílán na všesměrovou fyzickou adresu, ale na skupinovou adresu 33:33:xx:xx:xx:xx, kde dolních 32 bitů jsou dolní bity z vytvořené multicastové adresy vyzývaného uzlu. Více o fungování multicastu v IPv6 je možné nalézt v kap Uveďme si příklad. Jestliže má uzel např. lokální linkovou adresu fe80::aaaa:bbbb:cccc:dddd, IPv6 adresa vyzývaného uzlu bude ff02::1:ffcc:dddd a fyzická adresa, na které bude stanice taktéž naslouchat, bude 33:33:ff:cc:dd:dd. Obdobně by bylo možné odvodit jednotlivé adresy i např. pro globální unikátní adresu. Daná stanice pak na výzvu reaguje ohlášením, což je zpráva, která obsahuje především fyzickou adresu stanice. Kromě toho má uzel možnost informovat protějšek o tom, že je router (příznak R = Router), že oznámení bylo vyžádáno (S = Solicited) anebo, že se má přepsat dosavadní informace spojená s danou adresou (O = Override). Z toho vyplývá, že oznámení může být zasíláno i bez předchozí výzvy. To dává stanicím možnosti informovat ostatní o případné změně. Základním nástrojem pro ověření platnosti fyzické adresy je mechanizmus s názvem detekce dosažitelnosti souseda. Uzel v IPv6 aktivně monitoruje stav svých sousedů, resp. těch, s kterými alespoň občas komunikuje. K potvrzení dostupnosti uzlu slouží dva mechanizmy. Prvním z nich je, že komunikace mezi sousedy právě probíhá a pak se nemusí

100 100 FEKT Vysokého učení technického v Brně nic dalšího testovat. Další možností je, že si stanice ověří dosažitelnost vlastními silami. Udělá to tak, že zašle výzvu sousedovi a ten (v ideálním případě) odpoví ohlášením. Toto ohlášení signalizuje, že vše funguje, jak má. Mechanizmy pro objevování sousedů představují poměrně velké bezpečnostní riziko a jejich předchůdci v IPv4 sítích jsou zneužíváni k mnoha nežádoucím účelům. Z tohoto důvodu byla definována možnost, jak ND (neighbor discovery) operace provádět i zabezpečeně. Nazývá se SEcure Neighbor Discovery, zkráceně SEND. Základním principem je napojení na šifrovací algoritmus RSA, který umožňuje, aby každá zpráva související s objevováním sousedů byla digitálně podepsaná. Tím se zajistí její autentičnost, tj. máme jistotu, že komunikujeme s tím, s kým si myslíme. V současné době jsou stanice povinny přijímat jak zabezpečené, tak i nezabezpečené zprávy související s objevováním sousedů. Do budoucna se původně počítalo pouze se zabezpečenou variantou, nyní (2012) však již přehodnoceno tak, že SEND je nepovinný. Varianta SEND přináší dvě další ICMPv6 zprávy, konkrétně se jedná o typ 148 žádost o certifikační cestu a typ 149 ohlášení certifikační cesty. Používají se v případě, kdy stanice chce ověřit autenticitu směrovače, první je žádost, druhá zpráva je odpověď směrovače Automatická konfigurace adres Sada IPv6 přichází s poměrně revoluční myšlenkou jak automaticky konfigurovat koncové stanice. Z IPv4 sítí známe především protokol DHCP (o jeho nástupci je řeč v kap. 5.11), který je založen na jednoduchém principu klient-server. Tomuto způsobu získání síťových parametrů se říká stavová konfigurace. Zcela novou myšlenkou IPv6 je však bezestavová adresní konfigurace (Stateless Address AutoConfiguration = SLAAC). Základním principem je, že směrovač do sítě vysílá opakovaně (ale v náhodně stanovených okamžicích) potřebné informace (viz dále) pomocí ICMPv6 zprávy 134 ohlášení směrovače. Stanice má možnost o tyto informace i aktivně požádat, opět pomocí ICMPv6 zprávy, konkrétně výzvy směrovači (133). Stanici si pak na základě těchto informací sama stanoví svoji (globální) IPv6 adresu, resp. její část identifikátor rozhraní (nejnižších 64 bitů). Tato adresa může být dvojího typu buď EUI-64 nebo náhodná, jak bylo popsáno v kap Parametry, které jsou obsaženy v ohlášení směrovače, jsou následující Životnost implicitního směrovače údaj o čase, jak dlouho bude tento směrovač ještě implicitní. Omezení počtu skoků údaj, který mají stanice ve svých paketech používat. Příznakové bity o M (Managed address configuration) signalizuje, že v síti je přítomen DHCPv6 server, který přiděluje adresy. Pokud je tento příznak nastaven, stanice kontaktují DHCPv6 a pokusí se získat adresu (ta však může mít nízkou prioritu používání oproti např. dočasné adrese). o O (Other stateful configuration) pokud je tento příznak nastaven a není nastaven předchozí, pak to znamená, že konfigurace se provádí kombinovaně, tj. že adresa a prefix se nastavuje automaticky a další parametry ve spolupráci s DHCPv6 (např. adresy DNS serverů).

101 Pokročilé komunikační techniky 101 o Pokud jsou bity M i O nastaveny na 0, není DHCPv6 přítomno. o H (Home agent) slouží pro podporu mobility, směrovač dává najevo, že může pracovat ve funkci domácího agenta pro místní síť. Více v kap. o mobilitě (kap. 5.12). Trvání dosažitelnosti parametr ovlivňuje, jak dlouho po ověření dostupnosti určité stanice bude tato dostupnost ještě považována za platnou. Interval opakování je interval mezi dvěma výzvami sousedovi. Volby další údaje, které může směrovač ohlašovat. Jsou to např. MTU (Maximum Transfer Unit) dané sítě, fyzická adresa směrovače, adresa (prefix) sítě, případně i více prefixů, doba platnosti prefixu jak dlouho se adresa, která je na něm založena může používat, příznakové bity související s prefixem, z nichž asi nejzajímavější (A = Autonomous address-configuration) umožňuje zakázat stanicím automatickou bezestavovou konfiguraci. Tyto parametry umožňují stanicím v síti vědět, kde se nacházejí, jak se mají chovat, aby komunikace probíhala optimálně, a kdo je implicitní směrovač, tj. kam mají směrovat provoz, který míří mimo lokální síť. Kromě výše uvedeného je možné využívat ohlášení směrovače i k zlepšení fungování sítě v oblasti směrování. Uzel si udržuje tyto parametry: Cache paměť cílů směrovací informace pro konkrétní cílové adresy, záznamy typu <cíl; další skok>, tak jako v běžné směrovací tabulce. Seznam prefixů seznam získaný od směrovače nebo směrovačů, který následně slouží především k posuzování, zda je daná stanice ve stejné síti Seznam implicitních směrovačů informace o všech směrovačích, které o sobě tvrdí, že jsou implicitní. Jestliže tedy chce stanice odeslat paket, nejdříve se podívá do paměti cílů, zda nenalezne odpovídající (explicitní) záznam. Pokud ne, na základě seznamu prefixů zjišťuje, zda je stanice lokální nebo vzdálená. Jestliže je lokální, předání je pak založeno na zjištění fyzické adresy stanice, jak bylo popsáno dříve. Jestliže je vzdálená, je třeba zvolit vhodný směrovač ze seznamu implicitních směrovačů a na ten pak paket poslat. Pokud je zvolený směrovač nevhodný, má směrovač možnost o tom stanici informovat zprávou ICMPv6 přesměrování (137). V této zprávě je pak i informace o tom, kudy by měly být pakety správně zasílány a uzel by si měl tento údaj správně uložit do své paměti cílů. K normálnímu fungování většiny stanice v síti chybí již pouze jedna věc adresa(y) DNS serveru(ů). Základní mechanizmy automatické konfigurace (ND) tuto věc postihují teprve nedlouho. Do ohlášení směrovače je možné přidat rožšiřující pole obsahující adresy rekurzivních DNS serverů, což celý proces velmi usnadňuje, pokud je toto v konkrétní implementaci již dostupné. Jinou variantou pak je, že informace o DNS je doplněna stavovou cestou, tj. pomocí protokolu DHCPv6.

102 102 FEKT Vysokého učení technického v Brně 5.11 Protokol DHCPv6 Protokol DHCP (Dynamic Host Configuration Protocol) zajišťuje koncovým stanicím stavovou konfiguraci potřebných síťových parametrů. V sítích IPv4 je tato konfigurace nastavena zpravidla jako výchozí a hojně používána. U nového DHCPv6 se nevyužívají broadcastové adresy, na které se u DHCPv4 zasílaly zprávy (discovery, request). Systém je podle očekávání postaven na multicastu, tak jako většina hromadných služeb v IPv6. V systému zůstávají tři základní role, a to klient (ten, který chce získat informace), server (ten, který je poskytuje) a případně i zprostředkovatel (relay), který může zajišťovat spojení mezi klientem a serverem, pokud nemůže probíhat přímo (klient a server nejsou v rámci stejné lokální sítě - linky). Identifikace stanic je u DHCPv6 postavena na tzv. DUID (DHCP Unique IDentifier). Tento identifikátor by měl být jednoznačný a stálý pro všechny klienty a servery. U DHCP (v4) byla jednoznačná identifikace zajištěna prostřednictvím fyzických adres. To přináší jisté problémy. Především fyzickou adresu lze relativně snadno změnit, duplikovat nebo odcizit. Navíc je tato adresa vždy vztažena ke konkrétní síťové kartě/rozhraní, ne k celé stanici. U DHCPv6 je definováno několik způsobů, jak může být DUID vytvořen: 1. První je, že DUID bude určen výrobcem stanice na způsob výrobního čísla. 2. Druhý způsob využívá fyzickou adresu, která je kombinována s časovým údajem, a pevně uložena. 3. Poslední možnost je založena pouze na fyzické adrese, jeden DUID by však měl být využíván pro všechny rozhraní. Pro rozlišení jednotlivých rozhraní v rámci jednoho klienta je pak využíván další identifikátor IA (Identity Association). IA představuje shluk konfiguračních informací přidělených jednomu rozhraní. Tento shluk je opatřen jednoznačným identifikátorem IAID. Skupinové adresy DHCPv6 používané DHCP systémy: všichni DHCP relay agenti a servery všechny DHCP servery ff02::1:2 ff05::1:3 První zpráva, kterou při aktivaci DHCPv6 systému stanice vyšle na první z multicastových adres (ff02::1:2), je výzva (solicit). Tato zpráva má stejný význam jako DHCP discovery z verze 4. K odeslání stanice použije svoji lokální linkovou IPv6 adresu, kterou si generuje sama. Odpověď na tuto výzvu se jmenuje ohlášení serveru (advertise). V tomto ohlášení jsou již obsaženy konfigurační parametry, které je server ochoten následně klientovi přidělit. Těchto ohlášení může klient obdržet i více a následně si z nabídek vybírá. Přednost by měl dát nabídkám od serverů s nejvyšší prioritou, pokud je takových nabídek více, tak si může vybrat podle potřeby. V další fázi klient zašle žádost (request) o jím vybranou nabídku. Tato žádost se opět zasílá na skupinovou adresu ff02::1:2. Server, který nabízel vybranou konfiguraci, odpoví (reply). Tato zpráva obsahuje definitivní konfigurační parametry a povoluje stanici tyto parametry použít. Stejně jako u DHCPv4 i zde je časová platnost parametrů omezena a klient musí před jejím uplynutím žádat o obnovení. Definovaných typů zpráv je ještě více, většinu z nich shrnuje následující Tab. 16.

103 Pokročilé komunikační techniky 103 Protokol DHCPv6 přináší volitelnou možnost autentizace. Ta umožňuje klientovi ověřit pravost serveru, s kterým komunikuje a zabrání to výskytu falešných DHCP serverů v síti. Její použití je ale vzhledem k nepříliš šťastné koncepci celého systému spíše teoretické. Je definována také maximálně zjednodušená verze DHCPv6, tzv. bezestavové DHCP. Zprávy mají stejný formát jako u klasického DHCPv6, ale systém definuje pouze dva typy zpráv žádost o informace (information request) a pak odpověď (reply). Bezestavové DHCP je určeno především pro případy, kdy si stanice samy nakonfigurují svoji IPv6 adresu (autokonfigurace) a chybí jim pouze informace o adresách DNS serverů. Pomocí žádost o informace si stanice požádá o tyto adresy a následně je v odpovědi obdrží. Tab. 16: Vybrané typy zpráv u protokolu DHCPv6 Typ Název Popis 1 výzva (solicit) Klient hledá servery 2 ohlášení serveru (advertise) Servery se ohlašují 3 žádost (request) Klient požaduje parametry 5 obnovení (renew) Prodloužení platnosti konfigurace klienta u serveru 7 odpověď (reply) Odpověď serveru na žádost 8 uvolnění (release) Klient se vzdává své adresy odmítnutí (decline) žádost o informace (information request) předání (relay forward) zprostředkovaná odpověď (relay reply) Klient odmítá nějakou adresu, zjistil, že už ji někdo používá (mechanizmus detekce duplicitních adres) Klient žádá o konfigurační parametry bez přiřazování IP adresy Zapouzdření zprávy u relay agenta a její poslání na server Odpověď na zprostředkovanou zprávu 5.12 Mobilita Sada IPv6 je již od svého počátku zamýšlena tak, aby mobilita zařízení byla co nejjednodušší. V IPv6 se počítá nejen s mobilními počítači, ale i s mobilními telefony a podobnými zařízeními. Bohužel standardizace v této oblasti probíhá velmi pomalu a složitě. Základní myšlenkou systému je, že každé mobilní zařízení má nějaké domovské místo domácí síť. Tento pohybující se stroj má tedy domácí adresu IPv6, která je v rozsahu domácí sítě a je zaregistrovaná v systému DNS. Důležité je, že přes tuto registrovanou adresu je stanice dostupná i když se zrovna nachází úplně jinde. Pro pobyty v jiných sítích stanice používá dočasné adresy, z rozsahu konkrétní použité sítě. Tuto adresu je pak třeba někde při každé její změně registrovat, aby bylo možné se na mobilní stanici dostat. Změna přímo v systému DNS nepředstavuje nejlepší možnost, především z důvodu nízké flexibility.

104 104 FEKT Vysokého učení technického v Brně V rámci IPv6 je definována role tzv. domácího agenta (home agent). Domácí agent zpravidla běží na některém ze směrovačů organizace. Tento agent je průběžně informován o aktuální poloze (adrese IPv6) mobilní stanice. K tomu slouží speciální skupina ICMPv6 zpráv, viz Tab. 15. Jestliže se někdo snaží o komunikaci s mobilní stanicí, která se aktuálně nenachází ve své domovské síti, domácí agent pakety přijme a následně je předává tunelem cílové mobilní stanici. Toto je základní režim mobility, který funguje za každých okolností. Je však zřejmé, že není optimální z hlediska směrování a také zbytečného zatížení domácí sítě, která zprostředkovává veškerý provoz. Lepší postup tedy je, že stanice, která podporuje mobilitu a snaží se komunikovat s mobilní stanicí, dostane při pokusu o zahájení komunikace informaci o aktuálně platné IPv6 adrese a spojení pak již probíhá přímo, bez zprostředkování domácí sítí. Toto přesměrování pak probíhá na IP vrstvě (záhlaví Mobilita), z pohledu vyšších vrstev a uživatele zcela transparentně. Základní princip fungování mobility je graficky naznačen na Obr (Ve skutečnosti je však situace ještě o něco komplikovanější, protože z bezpečnostních důvodů jsou do procesu komunikace zapojeny autentizační mechanizmy, které zaručí, že se nebude za stanici na cestách vydávat někdo jiný.) cizi-stanice.jinde.cz 3 Optimalizace cesty (dočasná adresa) mobil.doma.cz (na cestách) Záhájení komunikace - úvodní datagram (domácí adresa) 2 1 tunel router.doma.cz (domácí agent) Domácí síť mobil.doma.cz (domácí adresa) Obr. 5-12: Princip navázání spojení s mobilním uzlem Obecně stanice v IPv6 síti nemohou tušit, zda jsou nebo nejsou jejich partneři při komunikaci mobilní stanice, u kterých se může platná IPv6 adresa měnit. Proto je nezbytné, aby si každý uzel v IPv6 udržoval paměť o platných (dočasných) adresách, tzv. cache vazeb. Zde jsou uloženy informace o mobilitě stanic. Každý záznam obsahuje především tyto údaje: domácí adresa, odpovídající dočasná adresa, doba životnosti. Jelikož vyšší vrstvy (aplikační, transportní) nemají o mobilitě stanic informace, pracují vždy s domácími adresami. Před směrováním (odesláním) paketu pro určitou stanici se však vždy ještě ověřuje, zda daná stanice nemá již v cache vazeb zaznamenanou dočasnou adresu, na kterou by se měl paket odeslat. V rámci IPv6 se vyvíjí i prostředky, které umožní nejen mobilitu jednotlivých stanic, jak bylo popisováno dosud, ale i mobilitu celých sítí. Typickým použitím je připojení

105 Pokročilé komunikační techniky 105 k Internetu v dopravním prostředku (letadlo, autobus, vlak), který se pohybuje a může se tak měnit i prefix sítě. Síťová mobilita technologie NEMO (NEtwork MObility) poskytuje prostředky, jak tuto problematiku ošetřit. Informace k této problematice je možné nalézt na Internetu nebo v literatuře Fungování multicastu v IPv Přenos multicastu po Ethernetu (a Wi-Fi) V kap. 4.3 bylo popsáno, jak jsou multicastové pakety v IPv4 přenášeny přes Ethernet a Wi-Fi (pro obě technologie platí totéž). Na ethernetu existuje nativní podpora multicastu. Skupinová multicast adresa je identifikována jedničkou na pozici prvního bitu fyzické adresy MAC, nula pak značí unicastové adresy. Tzv. kód výrobce (první 3 B MAC adresy), podle kterého se také pozná, že se jedná o multicastový rámec, je u IPv4 01:00:5e. U IPv6 je pevný kód dlouhý pouze 2 B a má hodnotu 33:33. Jak bylo již popsáno, u IPv4 druhá polovina MAC adresy nedokáže pojmout celou adresu multicastové skupiny, 5 bitů adresy je ztraceno. U IPv6, kde je adresa podstatně delší, by se mohlo zdát, že situace bude ještě složitější. K dispozici máme celkem 4 B, tedy 32 bitů. Ze skupinové IPv6 adresy, např. ff02::1:ff31:5ee2, se odeberou poslední čtyři bajty, tedy ff31:5ee2 a dosadí se do MAC adresy. Skupinová MAC adresa pro uvedenou multicast skupinu tedy bude 33:33:ff:31:5e:e2. Je zřejmé, že převod je poměrně přímočarý, je však třeba dát pozor a neplést si IPv6 adresy a MAC adresy, protože jejich zápis je na první pohled dosti podobný. Obdobně jako v IPv4, i zde platí, že jedna skupinová MAC adresa reprezentuje více možných multicastových skupin, protože celý identifikátor skupiny se do 4 B nevejde. Obecně se ale tato situace nepovažuje za běžnou a v případě, že k ní přece jen dojde, je úkolem vyšších vrstev (IPv6) vypořádat se s tímto problémem. Platí tedy, že pokud chce stanice přijímat data multicastové skupiny, musí začít přijímat rámce adresované na odpovídající fyzickou adresu Multicast Listener Discovery (MLD) Práce se skupinami příjemců mezi směrovači a koncovými stanicemi je v IPv4 zajištěna protokolem IGMP, o kterém bylo pojednáno v kap Multicast Listener Discovery (MLD) představuje obdobu protokolu IGMP pro IPv6 sítě. Jak již bylo uvedeno v kapitolách o IGMP, i MLD existuje ve více verzích. MLDv1 je obdobou IGMPv2, MLDv2 pak obdobou IGMPv3. O druhé verzi platí, že umožňuje především filtrovat zdroje, tedy přijímat určitou skupinu pouze z konkrétního zdroje nebo naopak konkrétní zdroj odmítnout, zatímco v první verzi je možné pouze ohlásit zájem o příjem určité skupiny. Z Tab. 15 je zřejmé, že MLD není samostatným protokolem, ale podmnožinou ICMPv6. Pakety MLD mají nastavený maximální počet skoků pouze na 1, což znamená, že se dostanou pouze na nejbližší směrovač, v případě že je vyslala stanice, nebo pouze k stanicím dané sítě, v případě že odesílatelem je směrovač. Jako IPv6 adresa odesílatele je využita lokální linková adresa daného rozhraní (prefix fe80::/10)., adresátem pak je IPv6 adresa multicastové skupiny (u MLDv1). U MLD paketu musí být vždy přítomno rozšiřující IP záhlaví označované v Tab. 11 volby pro všechny (hop-by hop options), konkrétně jeho forma Upozornění směrovače, které má zapříčinit, že zprávu vyhodnocují i směrovače, které aktuálně nejsou členy multicastové skupiny, na kterou byl paket adresován. Příklad zprávy MLD je možné si prohlédnout na Obr

106 106 FEKT Vysokého učení technického v Brně Jak bylo uvedeno v Tab. 15, existují tři ICMP zprávy typu MLD (platí pro verzi 1): dotaz na členství ve skupině (query) typ 130 slouží směrovači k výzvě, zda jsou na síti příjemci multicastové skupiny; tak jako u IGMPv2 existují dva podtypy obecný dotaz (general query) bez specifikace konkrétní skupiny a dotaz na konkrétní skupinu (multicast-address-specific query). ohlášení členství ve skupině (report) typ 131 slouží stanicím k ohlášení členství v určité skupině. ukončení členství ve skupině (done) typ 132 k odhlášení stanic z určité skupiny. U druhé verze MLD neexistuje samostatná zpráva ukončení (done) a zpráva report má jiný typ (143), jelikož její struktura a možný obsah je odlišný v souvislosti s možnostmi, které přináší druhá verze MLD. Z předcházejícího popisu je zřejmé, že paket zachycený na Obr. 5-13, reprezentuje zástupce MLDv1. Obr. 5-13: Ukázka zachyceného paketu typu Multicast Listener Report Multicast Listener Discovery verze 1 MLDv1 neobsahuje mechanizmy pro práci s konkrétními odesilateli. Z tohoto důvodu je dostatečné, když směrovače pracují se skupinami, resp. s informací, zda pro danou skupinu existuje nějaký příjemce (alespoň jeden) na daném rozhraní. Na základě těchto informací se pak budují distribuční stromy pro jednotlivé skupiny. Směrovač je povinen přijímat pakety adresované libovolné multicastové skupině. Struktura zprávy MLDv1 je poměrně dobře patrná již z Obr. 5-13, základní struktura je pro všechny typy (query, report, done) stejná a je přehledně naznačena na Obr. 5-14, rozbor položek následuje.

107 Pokročilé komunikační techniky 107 Bity Typ (130;131;132) Kód = 0 Kontrolní součet Časový limit odezvy Rezerva Skupinová adresa Obr. 5-14: Formát zprávy pro MLDv1 Typ dle typu zprávy query, report, done, jak již bylo popsáno Kód se v tomto případě podtypu ICMP nevyužívá, proto je nulový Kontrolní součet standardní kontrolní součet ICMPv6 zprávy, který je počítán z celé MLD zprávy a také pseudo-hlavičky IPv6 (vybrané pole). Časový limit odezvy toto pole používá pouze směrovač při zprávě query, dává najevo jaký je limit času na odezvu pro stanice. Standardně 10 sekund. Rezerva nevyužívané pole, které je nastaveno na 0, a příjemci ho ignorují. Pozn.: program Wireshark, který posloužil k zachycení paketu naznačeného na Obr toto pole v přehledu ani nezobrazuje, pole je patrné až v bajtovém výpisu paketu, který však již není součástí obrázku. Skupinová adresa pole nulové při obecném dotazu (general query), kdy směrovač dotazuje příjemce všech multicastových skupin, jinak nastavena skupina, které se paket týká, tj. např. kterou skupinu chce stanice přijímat nebo opustit nebo na kterou konkrétní skupinu se směrovač dotazuje. Vstup do skupiny Pokud chce stanice vstoupit do multicastové skupiny, pošle na její adresu MLD zprávu typu report (nejlépe několikrát, aby se předešlo chybě v případě ztráty paketu). Směrovač si tuto skutečnost zaeviduje u příslušného rozhraní. Vystoupení ze skupiny Pokud chce stanice multicastovou skupinu opustit, posílá MLD zprávu typu done, adresátem jsou všechny směrovače na dané lince (tedy multicastová adresa ff02::2), nikoliv daná multicastová skupina. Směrovač vyhodnotí, zda existuje ještě nějaký jiný příjemce skupiny. Podle výsledku (ne)přestane posílat pakety dané skupiny na uvažované rozhraní. Obecný dotaz na členství ve skupině od směrovače Pro obecný dotaz na členství u MLDv1 platí stejné principy jako pro IGMPv2. Zprávu query zasílá směrovač na skupinu všech uzlů na lince (ff02::1). Každá stanice, která obdrží dotaz, si nastaví pro všechny skupiny, kterých je členem, samostatný časovač na náhodný interval až do úrovně časový limit odezvy v dotazu. Po vypršení intervalu pošle na adresu skupiny ohlášení svého členství (pro každou skupinu). Pokud však bude jiná stanice rychlejší, tj. nastavila si kratší interval čekání, dostanou její ohlášení i ostatní členové. Ti následně časovač zruší a své ohlášení už na tuto výzvu (a pro uvažovanou skupinu) posílat nebudou. V praxi to znamená, že ze skupiny odpoví vždy jen jeden náhodně vybraný člen, čímž se šetří kapacita linek.

108 108 FEKT Vysokého učení technického v Brně Celá situace se cyklicky opakuje (perioda 125 sekund). Protože nelze předpokládat, že se stanice vždy korektně odhlásí ze skupin, kterých byly členy, je periodicita nezbytná k eliminaci stavů, kdy žádný skutečný příjemce dané skupiny již na síti nebude, ale směrovač o tom nebyl explicitně informován. Obecně může být situace ještě o něco složitější, jelikož může v síti vystupovat více multicastových směrovačů. V takovém případě platí pravidlo, že dotazy posílá pouze jeden z nich a to ten, který má nejmenší IP adresu. Ostatní však zprávy také zpracovávají a udržují si tak konzistentní informace o členství ve skupinách na síti Multicast Listener Discovery verze 2 Jak již bylo uvedeno, tak druhá verze MLD přináší obdobné vylepšení, jako IGMPv3 v IPv4 sítích. Výhodou je možnost filtrovat příjem multicastu na základě zdroje. Je možné buď požadovat příjem pouze od vybraných zdrojů, což je označováno jako INCLUDE() nebo pak přijímat multicast ze všech stanic kromě zdrojů specifikovaných v EXCLUDE(). Tyto dva filtry lze navíc i vzájemně kombinovat. U MLDv2 již neexistuje samostatná zpráva, která by stanicím umožňovala opuštění konkrétní skupiny (done). Zpráva typu report ve druhé verzi MLD (typ 143) je z hlediska významu do češtiny překládána vhodně jako Změna příjmu skupin, což umožňuje využití jak pro přihlašování, tak odhlašování členství. Do tohoto jednoho hlášení lze vložit větší množství informací, je tedy zřejmé, že došlo ke zvýšení složitosti zpracování zpráv, za cenu snížení počtu těchto zpráv. Základní struktura zprávy je znázorněna na Obr. 5-15, detail dílčí části záznamu pak na Obr S takto složitým paketem lze již provádět poměrně komplikované kroky v oblasti příjmu multicastu, detailní popis je nad rámec tohoto textu a je možné ho najít např. v RFC 3810 (nebo jeho případném nástupci). Zde rozebereme pouze pole Typ záznamu, které nám poskytne představu o možnostech, které paket přináší více viz Tab. 17. Tab. 17: Možné typy záznamů u MLDv2 zprávy report Typ Název Popis 1 MODE_IS_INCLUDE Informace o současném stavu, jako odezva na zprávu směrovače query 2 MODE_IS_EXCLUDE Informace o současném stavu, jako odezva na zprávu směrovače query 3 CHANGE_TO_INCLUDE Změna filtru u existujícího příjmu na include 4 CHANGE_TO_EXCLUDE Změna filtru u existujícího příjmu na exclude 5 ALLOW_NEW_SOURCES Režim zachován, ale přidány další adresy 6 BLOCK_OLD_SOURCES Režim zachován, končí příjem ve zprávě specifikovaných zdrojů Zjišťování skupin (query) provádí směrovač MLDv2 stejným způsobem jako ve verzi 1, pouze je přidána možnost ptát se nejen na konkrétní skupinu, ale i na konkrétní zdroj nebo zdroje.

109 Pokročilé komunikační techniky 109 Odpovědi na dotaz stanice podobně jako u MLDv1 náhodně zpožďují. Obdobně jako u IGMPv3 však platí, že tyto odpovědi se již neposílají na adresu skupiny, ale na skupinovou adresu všech MLDv2 směrovačů (ff02::16), takže ostatní stanice tyto zprávy neobdrží. Proto musí na dotaz reagovat všechny stanice (což je výhodné z hlediska práce přepínačů (snooping)). Není však třeba zasílat pro každou skupinu samostatnou zprávu, jak vyplynulo ze struktury zprávy report, je možné (a povinné) sloučit vše do jedné zprávy Lightweight MLDv2 Jak je patrné z předcházejícího popisu, MLDv2 je již poměrně složité. Občas se v praxi ukáže, že je výhodnější vyvinout odlehčenou variantu protokolu, která sice nemusí mít zcela plnou funkčnost, avšak výrazně urychlí a usnadní celý mechanizmus. Zpravidla je nějakým způsobem i vyřešena kompatibilita s plnou verzí protokolu. Z těchto důvodů byla vyvinuta odlehčená verze MLDv2 (Lightweight MLDv2 = LW- MLDv2) a i IGMPv3 (LW-IGMPv3), která jsou popsány v RFC Detailní popis usnadnění mechanizmů je však již nad rámec tohoto textu Směrování v IPv6 sítích O směrování v IPv4 sítích bylo pojednáno v kap a o směrovacích protokolech je zmínka v kap. 6.2, která se soustřeďuje na IGP protokoly, a v kap. 6.4, která pojednává o BGP protokolu. Směrování v IPv6 je založeno na totožných principech, pouze se pracuje s poněkud delšími adresami. Tomu se musely přizpůsobit i směrovací protokoly, proto se prakticky u všech používaných IGP protokolů setkáváme s verzemi pro IPv6. Jsou to zejména (uvedeno pro přehledovou znalost): RIPng (Router Information Protocol Next Generation) verze směrovacího protokolu RIP pro IPv6 EIGRP for IPv6 (Enhanced Interior Gateway Routing Protocol) směrovací protokol firmy Cisco ve verzi pro IPv6 OSPFv3 (Open Shortest Path First) OSPF pro IPv6 sítě. IS-IS for IPv6 (Intermediate System to Intermediate System) verze IS-IS pro IPv6 V oblasti směrování mezi autonomními systémy se využívá BGP (Border Gateway Protocol) protokolem. Pro IPv4 sítě se využívá verze 4, označovaná jako BGP4, pro IPv6 existuje modifikovaná verze označovaná jako BGP4+.

110 110 FEKT Vysokého učení technického v Brně Bity Typ (143) Kód = 0 Kontrolní součet Časový limit odezvy = 0 Počet záznamů = X Záznam [1] Záznam [2] Záznam [X] Obr. 5-15: Základní struktura zprávy typu report protokolu MLDv2 Bity Typ záznamu Délka přílohy Počet zdrojů = N Skupinová adresa Zdrojová adresa [1] Zdrojová adresa [N] Příloha (doplňková data) Obr. 5-16: Detail záznamu ve zprávě typu report protokolu MLDv IPv6 v praxi Fungování IPv6 ve Windows 34 IPv6 je nativně podporováno od Windows Vista 35. Do Windows XP je možné IPv6 doinstalovat, až na detaily bude fungovat správně. Ve Windows Vista a vyšších nelze IPv6 úplně vypnout, jelikož je plně integrován do systému a také má vždy vyšší prioritu než IPv4. V případě, že je adresát komunikace (zjištěný např. přes DNS) dostupný jak přes IPv6, tak IPv4, tak se vždy systém pokusí o spojení s IPv6 adresou. K práci s IPv6 je vyhrazen příkaz 34 Linuxové komunitě se omlouváme, že o IPv6 v Linuxu není také zařazena samostatná kapitola. Podpora IPv6 je do distribucí zahrnuta již poměrně dlouho. 35 Bezchybně je IPv6 podporováno až od verze Vista SP2 nebo ve Windows 7.

111 Pokročilé komunikační techniky 111 netsh, který může mít např. pro případ konfigurace IPv6 adresy, konfigurace výchozí brány nebo DNS serveru následující tvary: netsh interface ipv6 add address Local Area Connection 2001:db8:290c:1291::1 netsh interface ipv6 add route ::/0 Local Area Connection fe80::2aa:ff:fe9a:21b8 netsh interface ipv6 add dnsserver Local Area Connection 2001:db8:99:4acd::8 IPv6 je ve Windows Vista a novějších samozřejmě plně podporován také příkazy ipconfig, route, ping, tracert, pathping a netstat. Po povolení síťového rozhraní v IPv6 síti dojde u stanice k následující proceduře: Nakonfiguruje se link-local IPv6 adresu a ověří se, zda nedošlo ke kolizi s adresou jiné stanice v síti. Adresa za prefixem je odvozována na základě určitých ID rozhraní a může se tak opakovat stejná adresa i např. po restartu. Pokud dosud stanice neobdržela Router Advertisement (RA), zkusí odeslat směrovači výzvu Router Solicitation Jakmile obdrží zprávu Router Advertisement o a je v ní nastaveno Managed Address configuration, zkusí protokolem DHCPv6 získat IPv6, případně při bitu Other kontaktuje DHCPv6 server pouze za účelem získání adres DNS serverů. Na základě prefixu v RA si nastaví první náhodnou adresu, která bude mít nejnižší bity stejné jako ta, co se již používá jako link-local (použití jako veřejná adresa příchozí spojení) 36. Pokud není v RA ani jeden bit nastaven (M & O), očekává získání DNS přes IPv4 a i komunikace s DNS přes IPv4. Autokonfigurace IPv6 je ukončena. o Stanice si ještě nastaví jednu další nově vygenerovanou náhodnou a dočasnou IPv6 adresu (běžně nejvyšší priorita používání při komunikaci ven ze sítě, lokálně se používá zpravidla ta link-local). Obecně byl výběr adresy pro použití stručně popsán v kap Mechanizmy přechodu komunikace mezi IPv6 a IPv4 S rozšiřováním IPv6 postupně vystupují na povrch problematické situace, případně specifické problémy. Jeden z těchto problémů souvisí s tím, že IPv6 je prakticky ve všech operačních systémech preferováno na úkor IPv4. To v praxi znamená, že pokud si operační systém myslí, že je cílová destinace dostupná přes oba protokoly, použije jako první IPv6 a trvá poměrně dlouho, než snahu o komunikaci po IPv6 vzdá (i v řádu desítek sekund). Je však zřejmé, že IPv6 jako nová sada protokolů nemusí vždy fungovat na sto procent. Jestliže z nějakého důvodu komunikace po IPv6 nebude zcela funkční, bylo by dobré, kdyby operační systém, případně konkrétní aplikace, se co nejdříve pokusila o komunikaci přes IPv4. Z tohoto pohledu se můžeme potkat s funkcí http.fast-fallback-to-ipv4, které, jak 36 Princip tvorby adresy EUI-64 se tedy ve Windows standardně nevyužívá.

112 112 FEKT Vysokého učení technického v Brně vyplývá z názvu, přináší to, že se v případě neúspěchu komunikace po IPv6 rychle přejde na IPv4 (pokud je dostupné) a uživatelská odezva by i tak měla být poměrně rychlá. Např. u prohlížeče Firefox lze nainstalovat rozšíření 4or6, které umožní ovládat nastavení této funkce, případně prohlížeči striktně zakázat IPv6. Z technické stránky je toto řešeno velice jednoduše, a to tak, že se použijí pouze DNS záznamy typu A, které odkazují na IPv4 adresy.

113 Pokročilé komunikační techniky Autonomní systémy 6.1 Fungování autonomních systémů Směrování paketů v IP sítích bylo popsáno v kap Z popisu vyplývá, že se nejedná o jednoduchou úlohu a že klíčová pro směrování je vždy IP adresa adresáta paketu. V příkladech bylo vždy jen několik směrovačů, v této kapitole se však posuneme do měřítek celého Internetu. Jak vyplývá z názvu, Internet je propojením dílčích sítí, resp. by se přesněji dalo říct propojením autonomních systémů, viz dále. Na Obr. 6-1 je velmi zjednodušeně 37 znázorněna část struktury Internetu, uzly představují směrovače jednotlivých sítí. Jestliže se chce zákazník v síti ISP (Internet Service Provider) (vpravo dole) připojit na webový server (vlevo dole), musí všechny mezilehlé směrovací prvky vědět kudy jeho pakety poslat, aby dorazily k cíli a následně pak i zpět. Počet směrovačů po cestě může běžně dosáhnout až několika málo desítek. Protože je v souvislosti s masivním rozvojem Internetu naprosto nemožné, aby každý směrovač věděl přímo o všech sítích v celém Internetu (a byl tak schopen samostatně směrovat do celého Internetu) a jeho směrovací tabulky by navíc měly obrovskou velikost, byl Internet rozdělen na z určitého pohledu samostatné jednotky autonomní systémy (AS). Autonomní systém představuje souhrn sítí pod společnou správou, kde se používá společná (vnitřní) směrovací strategie. Celý AS se obvykle skládá z menších oblastí (sítí). Každý autonomní systém musí mít přiřazeno unikátní 16-bitové číslo (přiděluje organizace IANA, viz kap. 3.3). V rozsahu 16-bitového čísla může být teoreticky maximálně pouze autonomních systémů, což již nedostačuje, proto v poslední době začalo číslování i prostřednictvím 32-bitových ASN (AS Number) 38. Aktualizovaný seznam obsazených čísel autonomních systémů jak pro 16-bit, tak pro 32-bit verzi lze najít na webových stránkách organizace IANA, Aby mělo rozdělení na AS smysl, musí mezi nimi existovat jednotný systém předávání směrovacích informací, v pevně daném formátu. Lze to jednoduše shrnout slovy: v rámci svého vlastního (autonomního) systému má každý možnost zajistit si přenos a aktualizaci směrovacích údajů podle svého, ale navenek musí všichni postupovat jednotně. Autonomní systém si lze také představit jako jeden distribuovaný směrovač, jehož porty jsou reprezentovány porty všech hraničních směrovačů celého AS. 37 V obrázku se vyskytuje pojem páteřní síť kontinentu, od techniky páteřních (regionálních, národních) sítí se však již do značné míry ustupuje, protože tato páteř je pak velmi kritickým bodem celé struktury. Důležitých spojů, které by se daly označit za páteřní, tedy na každém kontinentu existuje mnohem více. 38 Z 16-bitových AS čísel jsou navíc hodnoty vyhrazeny pro privátní účely, takže jejich použití v rámci Internetu není možné. Dále ASN 0, a jsou vyhrazeny organizací IANA a není taktéž možné je použít v běžném prostředí Internetu. Zbývá tedy mnohem méně než možných autonomních systémů a tento počet se blíží svému vyčerpání. Proto IANA začala nedávno alokovat i 32-bitové čísla autonomních systémů, ve formě X.Y, kde X je 16-bitové číslo, stejně tak jako Y. Původní autonomní systémy se tak stávají 0.Y, kde Y je původní číslo autonomního systému v 16-bitovém prostředí. Přechod na 32- bitové prostředí však vyžaduje podporu (nejen) směrovacích protokolů, které informace o AS přenášejí.

114 114 FEKT Vysokého učení technického v Brně Páteřní síť kontinentu Mezikontinentální linky Páteřní síť jiného kontinentu Síť ISP s webovými servery Regionální síť Národní síť Webový server ADSL, PSTN, wi-fi, cabel,... Síť ISP (Ethernet LAN) Zákazník Přístupový server ISP Obr. 6-1: Vzájemné propojení lokálních sítí se schematicky znázorněnou celosvětovou sítí 6.2 IGPs (Interior Gateway Protocols) Všechny protokoly, používané pro přenos směrovacích informací mezi jednotlivými bránami (směrovači) uvnitř autonomního systému, se souhrnně označují jako protokoly IGP (Interior Gateway Protocol). Mezi používané IGP protokoly patří např.: RIPv2 (Routing Information Protocol verze 2), EIGRP (Enhanced Interior Gateway Routing Protocol), OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System). Zájemcům o podrobnější seznámení se s IGP protokoly doporučuji např. volitelný předmět Cisco akademie 1, kde se této problematice (v rámci CCNA Exploration 4.0 Routing Protocols and Concepts) věnuje značná pozornost. 6.3 Protokol EGP (Exterior Gateway Protocol) Pro vzájemnou komunikaci mezi autonomními systémy byl navržen protokol EGP (Exterior Gateway Protocol). Ten vychází z představy, že v rámci každého autonomního

115 Pokročilé komunikační techniky 115 systému je minimálně jedna brána pověřena předáváním směrovacích informací navenek. Tato brána, jejíž výběr je plně v moci správce příslušného autonomního systému, je pak označována jako externí brána (exterior gateway). Prostřednictvím protokolu EGP pak tato brána komunikuje s externími bránami jiných autonomních systémů. Protokol EGP umožňuje, aby se jeden autonomní systém nejprve dohodl s jiným, že si směrovací informace vůbec budou vyměňovat (nebo si je také mohou odmítnout předávat). Dále umožňuje, aby jednotlivé autonomní systémy pravidelně testovaly dostupnost druhých autonomních systémů (tj. testovaly, zda spojení s nimi je průchodné). Hlavním úkolem protokolu EGP však je pravidelný přenos směrovacích údajů a informací o průběžných změnách mezi autonomními systémy. Protokol EGP je tedy prostředkem, pomocí kterého může autonomní systém informovat jiné autonomní systémy o dostupnosti dílčích sítí v rámci vlastního autonomního systému, a naopak získávat informace o cestách do dílčích sítí v jiných autonomních systémech. 6.4 Protokol BGP (Border Gateway Protocol) Obecný popis protokolu BGP Protokol EGP je v současné době nahrazen protokolem BGP (Border Gateway Protocol), aktuálně ve verzi 4 (dokument RFC 4271). Protokol BGP je pro fungování Internetu jako celku nesmírně důležitý, přestože se s ním běžný koncový uživatel nesetkává. Hlavním cílem BGP je dosažení flexibility a možnosti snadné volby propojení a výměny směrovacích záznamů mezi AS. BGP je založeno na výměně informací mezi BGP sousedy. Spojení mezi těmito směrovači je nakonfigurováno ručně (nevzniká automaticky, je nezbytný zásah administrátora) a pro přenos se využívá spolehlivý protokol TCP (což je mezi směrovacími protokoly unikátní), konkrétně TCP port 179. Protokol BGP je tedy aplikačním protokolem. BGP je schopné provozu v plně decentralizovaném prostředí současného Internetu a podporuje přenos směrovacích informací o sítích s beztřídní (classless) maskou, tj. i o podsítích vzniklých rozdělením původních tříd A, B, C. AS svým sousedním AS prostřednictvím protokolu BGP sděluje k jakým IP sítím je schopen doručit IP pakety. Okolní AS se (podle své vlastní nastavené směrovací politiky) rozhodnou, zdali použijí konkrétní AS pro směrování k dané síti. V opačném směru hraniční BGP směrovače přijímají BGP informace od sousedních BGP směrovačů, jiných AS, které je informují, jaké sítě jsou přes ně dostupné. Směrovačům, které mezi sebou komunikují prostřednictvím protokolu BGP se říká peer, výměna směrovacích informací prostřednictvím BGP bývá nazývána peering (více viz kap. 6.6). BGP může být využito i ke směrování v rámci autonomního systému, potom se nazývá vnitřní (Internal) BGP ibgp. Nejčastějším případem interního použití je potřeba přenosu směrovacích informací mezi dvěma nebo více externími (hraničními) branami v rámci jednoho AS. To umožňuje, aby BGP mohlo správně rozhodnout, jaký směr pro směrování zvolit, pokud existuje více možností. Nutnou podmínkou je v takovém případě, aby byly hraniční směrovače propojeny každý s každým. To může být u opravdu velkých sítí problematické, proto vznikla technika tzv. reflektorů, ta je však nad rámec tohoto textu.

116 116 FEKT Vysokého učení technického v Brně V případě použití BGP protokolu mezi autonomními systémy se pak někdy využívá název ebgp (Exterior BGP), většinou však postačí jednoduše BGP. Možná situace pěti propojených autonomních systémů je naznačena na Obr Interně v rámci jednotlivých autonomních systémů se používá některý z IGP protokolů (viz kap. 6.2), např. v AS1 je to OSPF. Pro přenos mezi autonomními systémy je nasazeno ebgp. V případě, že je nezbytné přenášet směrovací informace v rámci AS, využije se ibgp, jako např. v AS3, který by pravděpodobně představoval tranzitní AS (viz kap , která se věnuje tranzitu). AS2 EIGRP ebgp OSPF AS4 AS1 ebgp ibgp ibgp ibgp ebgp ebgp AS5 RIPv2 OSPF ebgp AS3 ibgp ebgp Obr. 6-2: Objasnění nasazení ibgp, ebgp a IGP protokolů Čistě teoreticky nic nebrání tomu používat BGP protokol jako jediný směrovací protokol v Internetu a využívat ho tedy i jako vnitřní protokol autonomních systémů IGP. V některých případech je možné a vhodné tento způsob využít. Situace kdy to není vhodné nebo možné jsou: síť má jen jedno připojení k ISP tzv. stub network, směrovače sítě nejsou dostatečně výkonné, aby zvládly náročnost protokolu BGP, správci sítě neznají nebo nerozumí fungování BGP. Vhodnost použití BGP vyvstává analogicky v situacích: síť (AS) je připojen k více ISP (AS), hardware sítě je schopen zvládnout běh protokolu BGP, stejně jako správci sítě, vnitřní směrovací politika sítě je konzistentní a je možné ji umístit do BGP Formát záhlaví protokolu BGP Zpráva protokolu BGP může mít maximální délku až 4096 B, nejkratší zprávou je typ keep-alive (viz dále), která má pouze 19 B (pouze základní záhlaví protokolu, žádná datová část). Základní struktura je naznačena na Obr. 6-3, objasnění následuje pod obrázkem.

117 Pokročilé komunikační techniky 117 Marker Délka Typ Datová část Obr. 6-3: Základní struktura BGP zprávy Marker 16 B pole, přítomno z důvodů kompatibility se staršími verzemi, vyplněno binárními jedničkami. Délka (length) 2 B, celková délka zprávy v bajtech, včetně záhlaví. Jak již bylo uvedeno, maximální povolená hodnota je 4096, minimální 19. Typ (type) 1 B, zde je uložen kód reprezentující typ zprávy. Ve standardu definované typy jsou následující čtyři: o Open je úvodní inicializační zpráva přenášená po vytvoření TCP spojení. Oznamuje tedy otevření nového spojení, přenáší se informace o AS, ID směrovače, apod. Musí být potvrzena zprávou Keep-Alive. o Update též NLRI Update. Obsahuje aktualizaci směrovacích informací (výjimkou je stav po navázání spojení, kdy není co aktualizovat a tabulka se musí přenést celá). Aktualizace může spočívat jak ve zrušení, tak i vzniku nových cest (rout). Více informací viz kap o Notification zpráva používána pro zrušení TCP spojení (obsahuje i důvod zrušení spojení). Je také zasílána v případě, chyby nebo jiné mimořádné situace. o KeepAlive je posílána pravidelně. Oznamuje, že směrovač stále pracuje. Ve výchozí konfiguraci se posílá každých 60 sekund. Datová část nepovinná část délky až ( ) = 4077 B Zpráva NLRI Update Zpráva přenášející aktualizaci směrovacích informací protokolu BGP se nazývá Network Layer Reachability Information Update (NLRI Update), tj. aktualizace informace o dostupnosti sítě, resp. přesněji o dostupnosti její síťové vrstvy. NLRI není přenášeno periodicky, ale pouze při změně topologie, dostupnosti apod. Datová část BGP má v případě zprávy Update základní formát takový, jako je naznačený na Obr. 6-4, bližší popis jednotlivých polí následuje pod obrázkem. Délka pole informujícího o stažených (neplatných) routách Neplatné (stahované) routy Celková délka pole atributy routy Atributy routy NLRI (Network Layer Reachability Information) Obr. 6-4: Základní formát zprávy NLRI Update (datová část základní zprávy)

118 118 FEKT Vysokého učení technického v Brně Délka pole informujícího o stažených (neplatných) routách 2 B, délka následujícího pole (neplatné routy) v bajtech. Pokud není přenášena žádná neplatná (stažená) routa, hodnota v poli je 0 a následující pole není přítomno. Neplatné (stahované) routy pole proměnné délky obsahující seznam stahovaných (zneplatňovaných) rout. Jsou to routy, do kterých již daný směrovač není schopen směrovat pakety (např. výpadek spojení) a proto o tom informuje svého souseda. Celková délka pole atributy routy 2 B, délka následujícího pole (atributy routy), pokud je hodnota 0, ve zprávě nejsou žádné další pole a Update slouží pouze ke stažení určité routy nebo případně více rout. Atributy routy délka specifikována v předcházejícím poli. Každý přenášený atribut se skládá ze tří podčástí (typ atributu [2 B], délka atributu [1 B], hodnota atributu). Vybrané typy atributu o ORIGIN definuje původce směrovací informace, přenášenou hodnotou jsou číselné kódy reprezentující buď IGP protokol, BGP protokol nebo jiný způsob zjištění směrovací informace. Hodnota se při přenosu zprávy mezi směrovači nemění. o AS_PATH cesta k cílové síti (informace o síti je v poli NLRI, viz dále), seznam autonomních systémů (zpravidla v pořadí, kterými zpráva prošla). Použití k rozhodnutí o směrování viz Příklad 6.1. o NEXT_HOP unicastová IP adresa dalšího skoku, který by měl být použit při směrování k cílové síti. Hodnota se při přenosu zprávy zpravidla mění, tak jak prochází mezi autonomními systémy, při přenosu v rámci jednoho AS se měnit nemusí. o LOCAL_PREF parametr umožňující nastavit v rámci interního AS stupně preference pro jednotlivé oznamované routy, použití viz Příklad 6.3. o MULTI_EXIT_DISC volitelný parametr umožňující ovlivnit směrování provozu do autonomního systému, použití viz Příklad 6.4. Parametr je přenášen pouze do sousedního AS, do dalšího AS již ne. NLRI (Network Layer Reachability Information) pole proměnné délky (jeho délku lze určit na základě znalosti délek předchozích polí a celkové délky zprávy). V poli může být uloženo jedna a více informací NLRI. Více jich může být jen za předpokladu, že pro všechny zároveň přenášené informace o dostupnosti sítě platí všechny ve zprávě nastavené atributy. Formát jednotlivé informace NLRI je (délka [1 B], prefix). o Délka indikuje délku prefixu IP adresy v bitech. o Prefix de facto adresa cílové sítě, začátek adresy Směrovací proces u protokolu BGP U IGP protokolů bývají při rozhodovacím procesu o směrování podstatné údaje jako vzdálenost, rychlost linky, počet skoků apod. Při směrování mezi autonomními systémy vystupují i jiné požadavky. Směrovací tabulky obsahují stovky tisíc záznamů, nejdůležitějším kritériem nebývá čistě vzdálenost, ale posuzují se nastavitelné parametry zohledňující například cenu přenosu a dodatečná pravidla aplikovaná v závislosti na zdroji, cíli, seznamu tranzitních autonomních systémů a dalších atributech. Rozhodnutí o politice

119 Pokročilé komunikační techniky 119 směrování je tak často závislé na administrátorovi, který ovlivňuje konfiguraci priorit u svého AS. Protokol BGP si v paměti směrovače vytváří svoji vlastní směrovací tabulku nazývanou Loc-RIB (Local Routing Information Base), odděleně od hlavní směrovací tabulky směrovače, kde mohou být uloženy případně i záznamy dodané jiným směrovacím protokolem. Pro každého svého souseda, s kterým má BGP router navázané spojení si udržuje tabulku Adj-RIB-In (Adjacent Routing Information Base, Incoming), která obsahuje NLRI obdržené od tohoto souseda (resp. pouze ty záznamy, které dosud nebyly zpracovány) a také udržuje tabulku Adj-RIB-Out (Adjacent Routing Information Base, Outgoing), kde se nachází průběžně připravované NLRI k odeslání tomuto sousedovi. Jestliže do tabulky Adj-RIB-In při komunikaci se sousedním směrovačem přibude nová cesta do určité destinace, proces BGP se musí rozhodnout, zda aktualizovat starší záznam v Loc-RIB (pokud se tam již nějaký nachází). Rozhodovací proces souvisí s parametry, které jsou popsány níže. Základním testem, na základě kterého může BGP přidat cestu přijatou v NLRI Update do Loc-RIB, je dostupnost následujícího uzlu (NEXT_HOP), který je uveden v této zprávě. K tomuto směrovači tedy již musí mít rozhodující se směrovač aktivní cestu, již umístěnou ve směrovací tabulce celého směrovače. Pokud taková cesta neexistuje, nemůže být NLRI informace z příchozí zprávy použita. Protokol BGP využívá k rozhodnutí o směrování tyto parametry: druh cesty k dané síti počet procházených AS parametr AS_PATH, viz Příklad 6.1. skupina administrátorem definovaných pravidel o váha (weight) viz Příklad 6.2, o místní preference (local preference) parametr LOCAL_PREF, viz Příklad 6.3. o výstupní diskriminátor MED (Multi Exit Discriminator) parametr MULTI_EXIT_DISC, viz Příklad 6.4. Příklady na použití těchto parametrů jsou uvedeny dále. Atributy váha a místní preference ovlivňují, kudy půjde provoz ven z konfigurované sítě (stejně jako AS_PATH), parametr MED ovlivňuje, kudy půjde provoz dovnitř konfigurované sítě. Příklad 6.1 Použití parametru AS_PATH a jeho využití k rozhodnutí o směrování Mějme pět autonomních systémů, propojených jako na Obr V rámci AS1 se nachází lokální síť /24. Hraniční router R1 se o dostupnosti této sítě dozví prostřednictvím provozovaného IGP protokolu. Směrovač R1 o dostupnosti této sítě informuje sousední hraniční router R2, který se nachází v AS3 prostřednictvím NLRI Update. V parametru AS_PATH bude uložena informace AS1. Prostřednictvím ibgp protokolu se tato informace dostane i na ostatní externí směrovače v AS3 (routery R3 a R4). Router R3 pak informuje AS2, R4 aktualizaci předá do AS4 a AS5. Při opouštění AS3 bude do AS_PATH přidán záznam o AS3: AS1, AS3. V dalším kroku AS2 informuje AS4, že zná cestu k síti /24, stejně tak jako AS4 pošle AS2 oznámení o tomtéž. V prvním případě je AS_PATH = AS1, AS3, AS2, ve druhém AS_PATH = AS1, AS3, AS4. Všechny směrovače na obrázku by v tuto chvíli měly přehled o možných cestách k dané lokální síti. V případě, že ze sítě /16 v AS4 vzejde požadavek na komunikaci s IP adresou spadající do rozsahu /24, bude na R6, aby rozhodl o směrování. Má na

120 120 FEKT Vysokého učení technického v Brně výběr dvě cesty, buď AS1, AS3 nebo přes AS1, AS3, AS2. Pokud by byl AS4 nastaven tak, aby rozhodoval na základě délky AS_PATH, je zřejmé, že by pakety směrovaly kratší cestou přes AS3. AS /16 AS2 R6 R5 AS5 AS1 R3 R4 R7 R1 R /24 AS3 R8 Obr. 6-5: Pět autonomních systémů k vysvětlení parametru AS_PATH Mechanizmus zápisu pořadí autonomních systémů poskytuje (mimo jiné) jednoduchý nástroj, jak zabránit vzniku směrovacích smyček. Jestliže se v seznamu AS objeví jeden AS vícekrát, je zřejmé, že došlo k vytvoření nežádoucí smyčky a záznam se ignoruje. Příklad 6.2 Použití atributu váha (weight) k ovlivnění směrovacího procesu Váha představuje lokální parametr, kterým lze v rámci jednoho routeru preferovat routy získané od jednoho AS na úkor rout získaných od druhého AS. Parametr váha se nepřenáší mezi routery prostřednictvím BGP, jeho význam je pouze lokální na daném zařízení. Jak je zřejmé z Obr. 6-6, router R1 v autonomním systému AS1 se o cestě do AS6 (např. do konkrétní sítě /24) dozví jak od AS2, tak AS7. Pokud bude váha AS7 nastavena (na R1) na vyšší hodnotu, dojde ke směrování paketů po trase vyznačené fialovou čárou. Příklad 6.3 Použití parametru lokální preference (LOC_PREF) Parametr lokální preference má stejný účinek jako parametr váhy dojde k preferování cest získaných od určitého autonomního systému. K použití dochází tehdy, jestliže je daná síť dostupná od více sousedů, ale na jiných místech daného autonomního systému. Tento parametr se přenáší jako součást BGP zprávy NLRI Update mezi směrovači v rámci autonomního systému (protokol ibgp). Bez přenosu této hodnoty by nebylo možné zjistit, který odchozí směrovač se bude preferovat. Zjednodušeně lze tvrdit, že pomocí LOC_PREF dochází k preferenci určitého směrovače, to však nemusí být přesné, jelikož parametr vždy souvisí pouze s konkrétní NLRI. Grafické znázornění je na Obr. 6-7.

121 Pokročilé komunikační techniky 121 k AS5 k AS /24 k AS8 AS7 AS4 AS1 R1 Nakonfigurována vyšší váha AS7 než AS2 k AS3 AS2 PC Obr. 6-6: K vysvětlení použití parametru váha k AS5 k AS /24 k AS8 AS7 AS4 AS1 Nakonfigurována vyšší hodnota lokální preference (preference směrovače) k AS3 AS2 PC Nakonfigurována nižší hodnota lokální preference (preference směrovače) Obr. 6-7: K vysvětlení použití parametru lokální preference

122 122 FEKT Vysokého učení technického v Brně Příklad 6.4 Použití parametru výstupní diskriminátor (MED) Parametr MED (Multi Exit Discriminator) se využívá k ovlivnění směrování směrem do spravované sítě. MED představuje de facto hodnotu metriky přiřazené sítím v NLRI. Atribut může ovlivnit rozhodnutí sousedů, na který směrovač prvního AS budou směrovat provoz mířící do určité sítě v rámci prvního AS. Vyšší preferenci má nižší hodnota. Ukázka je naznačena na k AS4 Zpráva pro PC v síti /24 k AS5 k AS3 Zpráva o dostupnosti sítě /24 s atributem MED 100 AS2 Zpráva o dostupnosti sítě /24 s atributem MED 50 AS /24 Obr V rámci AS1 administrátor preferuje, aby do sítě /24 šel provoz přes určitý hraniční směrovač. Toho lze docílit parametrem MED, jak je vyznačeno na obrázku. Pokud bude sousední AS2 tuto informaci respektovat, ze dvou cest k dané síti využije tu s nižším atributem MED.

123 Pokročilé komunikační techniky 123 k AS4 Zpráva pro PC v síti /24 k AS5 k AS3 Zpráva o dostupnosti sítě /24 s atributem MED 100 AS2 Zpráva o dostupnosti sítě /24 s atributem MED 50 AS /24 Obr. 6-8: K vysvětlení parametru výstupní diskriminátor (MED) Možné problémy BGP BGP jako takové mělo a má během své existence mnoho méně nebo více závažných problémů, které byly a jsou postupně řešeny. Největším z nich pravděpodobně je exponenciální růst Internetové směrovací tabulky, se kterou pracují nejvýznamnější směrovače v Internetu. Internetovou směrovací tabulkou, neboli globální BGP tabulkou se myslí souhrn všech autonomních systémů, které nepotřebují ke správnému fungování směrovacího procesu mít nakonfigurovanou také výchozí bránu (default gateway, též někdy gateway of last resort), která by se použila v případě, že by žádný exaktní záznam ve směrovací tabulce nevyhovoval při hledání cesty do cílové destinace 39. Těmto autonomním systémům se často říká default-free zone (DFT). Neznamená to však, že by směrovače v této zóně měly ve svých směrovacích tabulkách cesty do všech sítí Internetu a že by ve všech těchto směrovačích byla směrovací tabulka stejná. Díky technikám jako je filtrování cest (route filtering) (kap ) a agregace cest (route aggregation/summarization) (kap ) je však možné držet velikosti směrovacích tabulek v relativně přijatelné míře. Pro představu, globální BGP tabulka má zhruba záznamů (IPv4 rout), které jsou přibližně z cca autonomních systémů (údaj z 2/2012). 39 U menších sítí (nebo AS), zpravidla koncových sítí (stub networks) je směrovací tabulka vzhledem ke globální BGP tabulce zanedbatelná. Koncovými sítěmi myslíme ty, které mají do Internetu pouze jedno propojení a je tedy možné nakonfigurovat směrování pro adresy nacházející se mimo tuto síť prostřednictvím výchozí brány. Ve směrovacích tabulkách těchto sítí se tedy nachází pouze záznamy o interních sítích a výchozí bráně.

124 124 FEKT Vysokého učení technického v Brně Filtrování rout Filtrování rout (cest) je proces, při kterém se některé routy vyloučí z možnosti být zařazeny do lokální směrovací tabulky a být poslány sousedním směrovačům. Důvody vedoucí k tomuto filtrování jsou ekonomické, bezpečnostní anebo technické. Ekonomické důvody souvisí s technologií multihoming, která je popsána v kap Jestliže nějaká (koncová) síť využívá multihomingu, může mít současně aktivní propojení na dva (nebo více) autonomní systémy (dva poskytovatelé konektivity). Není žádoucí, aby se díky propojení tvořenému touto sítí, stala koncová síť tranzitní sítí, přes kterou bude přenášen provoz mezi těmito dvěma poskytovateli. Tomu se vyhneme na základě filtrování směrovacích cest na straně koncové sítě. Bezpečnostní důvody souvisí s filtrováním směrovacích cest, které poskytovatel konektivity získá ze sítě/sítí svého zákazníka. Tím poskytovatel de facto brání zákazníka před útoky typu únos adres. Technické důvody souvisí s omezenou kapacitou paměti směrovačů, která nemusí stačit na udržování celé globální BGP tabulky. Jednou z možností je filtrování na základě délky prefixu, které spočívá v ignorování rout, které mají delší prefix než nastavená hodnota. Další možností je možnost omezit maximální počet autonomních systémů na určitou hodnotu. Tyto techniky však nejsou příliš doporučovány Agregace směrovacích cest Agregace směrovacích cest je jednou ze základních technik, které mají za cíl redukci velikosti směrovacích tabulek a tedy i zrychlení směrovacího procesu. Spočívá v shrnutí několika směrovacích informací do jedné souhrnné. Vysvětlení je podáno na Příklad 6.5. Příklad 6.5 Agregace směrovacích cest Mějme výchozí situaci, která je naznačena na Obr Z pohledu směrovače R1 jsou za směrovačem R2 sítě /24 až /24, připojené přes směrovače R3 až R258. Při neaktivní agregaci směrovacích cest bude mít směrovač R1 ve své směrovací tabulce informaci o každé z těchto sítí zvlášť, přestože jsou všechny (z jeho pohledu) v jednom směru a všechny dostupné skrz směrovač R2. Je zřejmé, že toto řešení není příliš efektivní, jelikož routeru R1 by postačoval jeden záznam, že všechny tyto sítě (souhrnně /16) jsou dostupné přes R2. Toho lze dosáhnout agregací (sumarizací) směrovacích údajů. (Tuto funkci mohou směrovače vykonávat automaticky nebo na základě nastavení administrátora.) V případě aktivní sumarizace tedy situace z pohledu směrovače R1 (a případně i z celé připojené WAN) vypadá tak, jak je naznačeno na Obr

125 ... Pokročilé komunikační techniky 125 Adresa sítě /24 WAN R3 Adresa sítě /24 R4 R2 R1 Adresa sítě / 24 R258 Obr. 6-9: Výchozí situace pro ukázku agregace směrovacích cest WAN Adresa sítě /16 R2 R1 Obr. 6-10: Pohled směrovače R1 na sítě vlevo od R2 při aplikované agregaci Výše uvedený příklad je záměrně vybrán tak, aby sítě měly standardní masky sítě podle dřívějšího rozdělení na třídy. Agregace adres však může fungovat (a velmi účinně funguje) i v případě implementace podsítí. Při sumarizaci se vždy hledá nejbližší nadřazený adresní prostor, do kterého spadají všechny (pod)sítě, které chceme agregovat. Lze konstatovat, že agregace cest je také možnost, jak izolovat určité routery od informací o změnách topologie, které pro tento router nejsou podstatné. Tento efekt může být velmi přínosný z hlediska stability směrovacího procesu v celé síti dojde k navýšení rychlosti konvergence. 6.5 Multihoming Multihoming je technika zajišťující zvýšení spolehlivosti Internetové konektivity pro konkrétní síť, většinou koncového zákazníka, nikoliv poskytovatele služeb. Do kapitoly o AS je zařazena, protože patří do problematiky velkých sítí. Multihoming se zpravidla nenasazuje u domácích uživatelů, ale u velkých firem, institucí, apod., celých AS. Prostřednictvím multihomingu se snažíme eliminovat možnost ztráty konektivity, ke které by mohlo dojít prostřednictvím chyby jediného bodu (single point of failure = SPOF). Existuje několik variant multihomingu: jedna fyzická linka, více IP adres (rozsahů) nejméně bezpečná varianta. Host má k dispozici více IP adres, od různých poskytovatelů, připojen je prostřednictvím jedné fyzické linky. Jestliže připojení přes jednoho poskytovatele přestane být funkční,

126 126 FEKT Vysokého učení technického v Brně využije se druhý. Je však zřejmé, že při výpadku fyzické linky je veškerá konektivita ztracena. více fyzických linek, jedna IP adresa (rozsah) na každou z nich při výpadku jednoho poskytovatele nebo jedné z linek zůstává druhá linka funkční a konektivita je ztracena pouze na krátké období přechodu z jedné linky na druhou. Přechodové období je způsobeno tím, že např. protokol TCP neumí již navázané spojení převést na jinou linku (kde je použita jiná IP adresa) a musí se tedy (po vypršení časovače) navázat nové spojení přes jinou linku. více fyzických linek, jedna IP adresa (rozsah) tato technika je považována za čistý multihoming. Koncová síť používá jednu IP adresu (rozsah), který je používán na jedné z linek. Pokud tato linka přestane fungovat, je provoz převeden na jinou fyzickou linku. Směrovač na straně koncové stanice o tom musí informovat prostřednictvím směrovacího protokolu (zpravidla BGP). Toto přepnutí linky nemusí být na probíhající přenos natolik fatální jako předchozí varianta. více fyzických linek, více IP adres (rozsahů) nejrobustnější varianta, dochází k současnému využití služeb několika poskytovatelů konektivity a dojde tak k zvýšení spolehlivosti i kapacity celé konektivity. Může být použita kombinace s load balancing, v takovém případě se zátěž rozděluje rovnoměrně mezi jednotlivé linky. Možné problémy při aplikaci multihomingu I při využití multihomingu může dojít k jistým problémům, které nemusí být vždy na první pohled zřejmé. Základním předpokladem úspěchu je více než jedna linka vedoucí z/do koncové sítě, zpravidla k/od dvěma nebo více poskytovatelům. Problémem však může být, že tyto linky nemusí být ve skutečnosti fyzicky různé. Oba poskytovatele mohou pro připojení svých zákazníků v určité lokalitě využívat jednu a tutéž fyzickou linku, zpravidla formou určitého multiplexu. Při jejím výpadku tedy přestanou fungovat všechna připojení. Další věcí je, že pro každé připojení (poskytovatele) by i v koncové síti měly existovat vyhrazené zařízení (směrovače, přepínače), které budou zajišťovat konektivitu pouze k jednomu poskytovateli. V koncové síti by tedy měly být vlastně dvě nebo více samostatných sítí, podle počtu připojení. Nejvýhodnější v takovém případě je, když tyto zařízení jsou i fyzicky oddělena, např. ve dvou různých serverových místnostech. Není přípustné, že by jeden směrovač fungoval jako výchozí bod k více poskytovatelům. To by se pak sám stal bodem možné chyby jednoho uzlu (SPOF). Další problematickou věcí může být systém DNS. Jestliže na serveru v koncové síti poběží např. www server, uživatelé z vnějšku na něj budou přistupovat za pomoci systému DNS, který jim zjistí potřebnou IP adresu. Server DNS tedy musí znát IP adresu tohoto serveru. V situaci, kdy se tato adresa může změnit (některé typy multihomingu), je však potřeba mít tuto situaci ošetřenou a musí být definovaný mechanizmus, jak DNS server o této změně efektivně informovat 40. Z předcházejícího textu je možné učinit hlavní závěr, že k eliminaci SPOF dochází pouze v situaci, kdy každá komponenta podílející se na konektivitě, která by mohla selhat, je duplikována. 40 Lepším řešením je pak v této situaci využití tzv. PI (Provider Independent) adres (IPv4 i IPv6). Jak vyplývá z názvu, adresy jsou nezávislé na poskytovateli připojení, neměnné při aktuálním (i paralelním) připojení přes libovolného z providerů, kterého využíváme k zajištění multihomingu.

127 Pokročilé komunikační techniky 127 Multihoming autonomního systému, protokol BGP a IGP protokoly Existují tři základní způsoby jak při nasazení multihomingu do autonomního systému konfigurovat protokol BGP a jeho případnou vazbu na IGP protokoly. Každý ISP předává do našeho AS pouze informaci o default route do svého AS a tato informace je předávána směrovačům našeho AS. Ven z našeho AS se předává kompletní informace o existujících sítích tak, aby byly z vnějšku dostupné. Každý ISP předává do našeho AS kromě informace o default route také specifické (částečné) směrovací informace, nejčastěji o dostupnosti sítí ve svém AS. V tomto případě mohou být všechny tyto informace předány (redistribuovány) interním směrovačům našeho AS prostřednictvím transformace směrovacích informací do některého z IGP protokolů nebo může na interních směrovačích AS běžet také BGP. Každý ISP předává všechny směrovací informace, které má k dispozici, do našeho AS. Všechny směrovače pracují s BGP a předávají si informace o routách. V této situaci je pak velmi vhodné využít technik vhodného filtrování rout tak, aby se zákaznický AS nestal tranzitním mezi svými poskytovateli. 6.6 Peering Veřejný a privátní peering Peering je další z technik souvisejících s problematikou velkých sítí. Peering představuje pojem pro přímé propojení administrativně samostatných sítí, zpravidla propojení nezávislých autonomních systémů. Typickým příkladem jsou poskytovatelé Internetového připojení (ISP = Internet Service Provider). Hlavním důvodem tohoto propojení je umožnit výměnu dat mezi uživateli propojených sítí, což je vzájemně výhodné. Základním předpokladem k peeringu dvou sítí je jejich fyzické propojení a dohoda o výměně směrovacích informací, zpravidla prostřednictvím protokolu BGP. Peering datových sítí se liší od propojování sítí v telekomunikacích ve způsobu financování. V telekomunikacích jsou běžné poměrně vysoké propojovací poplatky, které mají pokrýt náklady související s přenosem hovoru v jiné síti, účtované na základě délky hovoru. Při peeringu se žádné poplatky přímo za přenášený datový provoz z/do jiné sítě neúčtují. Peering se dělí na dva druhy: veřejný peering (public peering) propojení více než dvou stran, na úrovni druhé vrstvy, často je využit Ethernet. Tato místa se nazývají exchange points nebo častěji Internet exchanges (IX). Do těchto uzlů jsou pak připojeny až stovky sítí (autonomních systémů). Uzel může být v nejjednodušším případě tvořen pouze jedním přepínačem, ve skutečnosti je však zpravidla topologie uzlu mnohem složitější. V situaci, kdy je připojeno velké množství sítí do jednoho bodu, je zřejmé, že nemůže být nikdy dosaženo maximálních hodnot přenosových rychlostí. Veřejný peering je tedy vhodný především pro snadné propojení s velkým množstvím (často menších) sítí. privátní peering (private peering) přímé propojení pouze dvou sítí, zpravidla také na druhé vrstvě. Propojovací linka je v tomto případě vyhrazena pouze pro jedno konkrétní spojení a není sdílena dalším stranám. Přímé spojení má význam, jestliže je mezi dvěma konkrétními sítěmi velký datový provoz, kvůli kterému stojí za to provozovat přímé

128 128 FEKT Vysokého učení technického v Brně propojení. Není však možné, aby byly všechny autonomní systémy propojeny navzájem privátně, počet spojení by totiž byl obrovský Peeringové uzly V Evropě nejvýznamnější peeringový uzel je AMS-IX (Amsterdam Internet Exchange) v Amsterdamu. Následují DE-CIX (Deutscher Commercial Internet Exchange) ve Frankfurtu a LINX (London Internet Exchange) v Londýně. Po světě je podobných center velké množství. Je zřejmé, že pro peeringové uzly je nezbytná vysoká rychlost používané přenosové technologie. Dříve se často využívalo FDDI, ATM, případně gigabit Ethernet, dnes už je to především technologie 10 Gbit Ethernet. Souhrnné datové přenosy v těchto uzlech se pohybují v řádu stovek Gbit/s a lze předpokládat, že brzo prolomí hranici 1 Tbit/s. Počty členů (propojených AS) se pohybují v řádu stovek. Za členství se zpravidla platí určitý poplatek, na základě kterého pak centrum inovuje technické vybavení apod. Příkladem takového uzlu na území ČR je NIX (Neutral Internet exchange), který sdružuje poskytovatele Internetových služeb působících v rámci ČR 41. Pro zajímavost je na následujícím obrázku znázorněno celkové zatížení uzlu NIX v běžný den (převzato z nix.cz, ), osa X představuje čas, jednotkou jsou hodiny. Z grafů je patrné, že oba směry (In zeleně a Out modře) pracují stejnou rychlostí. To je logické, protože všechen provoz, který do uzlu vstoupí, směřuje ven z uzlu, do některé z připojených sítí. Tento graf poskytuje (s jistou mírou nepřesnosti např. nereflektuje privátní peering) informaci o běžném denním provozu českého Internetu. Z grafu je vidět, že ve špičce dosahuje provoz úrovně přes 200 Gbit/s a tato maximální hladina dlouhodobě roste, tak jak rostou přípojné rychlosti jednotlivých uživatelů a roste jejich nárok na datový tok Tranzit Obr. 6-11: Denní zatížení celého uzlu NIX ( ) Kromě peeringu existuje ještě starší způsob, jak mohou být dvě nezávislé sítě (autonomní systémy) propojeny. Nazývá se tranzit. Tranzit spočívá v představě, že všechny koncové autonomní systémy jsou připojeny k velké páteřní sítí, která zajišťuje tranzit datového provozu a přímé propojení těchto koncových sítí neexistuje. Páteřní síť je samozřejmě také autonomním systémem. Dnes již pojem tranzit nutně nesouvisí s topologií tzv. páteřní sítě, ale spíše způsobem přenosu dat mezi dvěma autonomními systémy, kdy jeden z nich poskytuje druhému připojení do dalších autonomních systémů. 41 Další peeringové uzly na území ČR jsou např. nfx a cbix. Informace o nich jsou dostupné na a

129 Pokročilé komunikační techniky 129 Tranzit se skládá ze dvou souvisejících služeb. Mějme situaci, kdy máme síť jednoho ISP, ke které jsou připojeni zákazníci se svými sítěmi. Tento ISP je připojen k jinému autonomnímu systému za účelem tranzitu. První službou je, že poskytovatel (zastupující své zákazníky) oznamuje připojenému autonomnímu systému (zastupujícímu de facto zbytek Internetu) informace o routách k sítím svých zákazníků a tím umožní provoz do sítě zákazníků (inbound traffic) z celého Internetu. Druhou službou je informování sítí zákazníků o routách do Internetu, často formou informace o výchozí bráně. Tato služba umožní zákazníkům odchozí provoz (outbound traffic). Rozdílnost od peeringu spočívá v tom, že přes peeringové spojení dvou ISP prochází pouze přenos mezi zákazníky těchto dvou sítí, zatímco při tranzitu přes toto propojení může procházet i přenos směřující z/do jiného autonomního systému. Tranzit zpravidla není zdarma, je poskytován za úplatu. 6.7 Příklad autonomního systému sdružení CESNET Sdružení CESNET bylo založeno českými vysokými školami a Akademií věd ČR v roce Zkratka CESNET má význam Czech Education and Scientific NETwork. Jeho hlavním úkolem je provoz a rozvoj páteřní akademické počítačové sítě České republiky. Sdružení je financováno veřejnými rozpočty. Významnou částí činnosti sdružení je výzkum a vývoj informačních a komunikačních technologií, zejména v oblasti pokročilých síťových technologií. Současná generace (2012) této počítačové sítě se nazývá CESNET2 a nabízí na páteřních optických trasách přenosové rychlosti v řádu gigabitů až desítek gigabitů za sekundu. Tato síť je z pohledu celého Internetu jedním samostatným autonomním systémem s identifikačním číslem Připojit se k ní může každá instituce splňující podmínky přijatelného užití sítě, tj. vysoké školy, výzkumná pracoviště apod., čistě komerční nebo soukromé subjekty jsou vyloučeny. Sdružení reprezentuje Českou republiku v projektu budování panevropské akademické počítačové sítě GÉANT a GÉANT2. Páteřní linky sítě CESNET2 využívají optické spoje s technologií DWDM (Dense Wavelength Division Multiplex). Objasnění techniky DWDM je nad rámec tohoto textu. Pro základní přiblížení postačí, že na jednom optickém vlákně se provádí vícenásobný přenos na základě multiplexování. V případě WDM se jedná o multiplex na základě odlišné vlnové délky jednotlivých přenosových kanálů. V případě DWDM jsou tyto kanály velmi blízko u sebe, díky čemuž jich může být poměrně velké množství. Spoj DWDM o dvou vláknech poskytuje přenosovou rychlost až N x 10 Gbit/s pro každý směr, kde N je počet kanálů (obvykle až 32). Rychlost 10 Gbit/s je základní rychlost jednoho kanálu. V dohledné době bude tato rychlost navýšena na 40 Gbit/s. Maximální rychlosti páteřní sítě jsou skutečně vysoké a je tedy možné mimo běžného provozu zkoumat a provozovat i aplikace s velmi vysokými nároky na šířku pásma přenosové soustavy. Příkladem jsou distribuované výpočetní systémy (tzv. gridy) a multicastové přenosy. Topologie sítě CESNET2 (převzato ze stránek cesnet.cz) je naznačena na Obr Z obrázku je zřejmá snaha o kruhovou topologii, tj. aby každý významný uzel byl propojen s ostatními body sítě alespoň dvěma cestami. Redundance topologie zvyšuje spolehlivost sítě. Z mapky je také patrné propojení sítě s ostatními významnými sítěmi a partnery. Předně se jedná o akademické sítě sousedních států ACONET (Austrian Academic Computer Network), SANET (Slovenská akademická síť), PIONIER (Polish Optical Internet) a dále evropského projektu GÉANT (Gigabit European Academic Network),

130 130 FEKT Vysokého učení technického v Brně evropského uzlu světového významu AMS-IX (Amsterdam Internet Exchange), světového (neakademického) Internetu (linka do USA) a zejména propojení s uzlem NIX (Neutral Internet exchange), který sdružuje poskytovatele Internetových služeb v ČR s cílem propojení jejich Internetových sítí. Jedná se tedy de facto o hlavní uzel českého Internetu a síť CESNETu zde nemůže chybět. Jak je patrné z Obr. 6-12, CESNET je k uzlu NIX připojen pomocí dvou linek 10 Gbit/s. Pro zajímavost jsou na následujících obrázcích uvedeny grafy zatížení těchto dvou linek v běžný všední den (převzato z nix.cz, ). Z grafů je patrné, že obě linky jsou poměrně značně vytížené, především v denní době (osa X představuje čas, jednotkou jsou hodiny). Nejmenší provoz je mezi čtvrtou a šestou hodinou ranní, široká špička je přibližně v čase hod. Z grafů je taktéž patrné, že linky jsou využívány každá pro oba směry. Obr. 6-12: Topologie sítě CESNET2 (stav k 2/2012) Obr. 6-13: Zatížení první 10 Gbit/s linky propojující síť CESNET s uzlem NIX

131 Pokročilé komunikační techniky 131 Obr. 6-14: Zatížení druhé 10 Gbit/s linky propojující síť CESNET s uzlem NIX