Přednáška č.6
Síťová vrstva a ethernet (rámec ethernet) IP protokol IP paket & datagram Služební protokol ICMP Fragmentace Protokoly ARP & RARP Služební protokol IGMP IPv6
Na úrovni vrstvy síťového rozhrání funguje větší množství protokolů, které mohou fungovat na SW či HW bázi Příkladem mohou být protokoly PPP, LIP nebo také například ATM či EHTHERNET Ethernet je technologií, která je v současné době nejvíce používána pro výstavbu počítačových sítí, důležitou otázkou však je, jaký je konkrétní vztah mezi TCP/IP a technologií ETHERNET Kdykoli transportní vrstva předává vrstvě síťové nějaká data k odeslání, připojuje k nim pouze informaci o tom, kdo má být jejich konečným příjemcem
Pro každý samostatně přenášený blok dat, který se na úrovni síťové vrstvy označuje jako paket (zatímco na úrovni linkové vrstvy jako rámec), pak musí síťová vrstva rozhodnout, kterým "směrem" jej má skutečně odeslat. Jakmile toto rozhodnutí učiní, předá příslušný paket vrstvě linkové spolu s údajem o zvoleném směru Přesnější označení než paket u nespojované služby je datagram Nejdůležitějším úkolem síťové vrstvy je tedy tzv. směrování (routing), které představuje právě ono zmíněné rozhodování o směru odesílání jednotlivých paketů
Detailní struktura rámce sítě ethernet závisí na konkrétní normě Preambule a kontrolní součet slouží k synchronizaci přijímaných paketů klienty spolu s kontrolním součtem dále umožňují zjistit, zda nedošlo k poškození rámce Fyzická adresa je šestibitová, přičemž první tři bity charakterizují výrobce síťové karty a zbylé unikátní fyzickou adresu síťové karty
IP-protokol na rozdíl od linkových protokolů dopravuje data mezi dvěma libovolnými počítači v internetu, tj. i přes mnohé LAN. IP protokol je dán protokolem IP, který existuje ve dvou nejpoužívanějších verzích IPv4 & IPv6, zároveň jej doprovází služební protokoly. Služební protokol ICMP slouží zejména k signalizaci mimořádných stavů. Služební protokol IGMP sloužící pro dopravu adresných oběžníků. Služební protokoly ARP a RARP, které jsou často vyčleňovány jako samostatné na IP nezávislé protokoly, protože jejich rámce nejsou předcházeny IP-záhlavím.
Vlastnosti IP protokolu negarantuje doručení negarantuje konzistentnost dat nepoužívá potvrzení nepodporuje řízení toku smí zahodit datagram, když: má chybný kontrolní součet překročil svou životnost hrozí zahlcení sítě
Pro přenos dat slouží protokoly na linkové i síťové úrovni, řešením otázky využití více protokolů je zejména rychlost, modulárnost a nezávislost na konkrétní platformě Směrovač volí trasu, obaluje rámec a vkládá jej do konkrétního linkového protokolu, respektive protokolu síťového rozhrání
Maximální velikost 65535 bytů a minimální podporovaná velikost 576 bytů TTL - omezení životnosti datagramu zajišťuje, že se datagram nebude nekonečně dlouho putovat sítí Verze (version) je první položkou záhlaví IPdatagramu. Tato položka dlouhá 4 bity (půl bajtu) obsahuje verzi IP-protokolu. V této přednášce hovoříme o IP-protokolu verze 4, tudíž tato položka je v našem případě rovná hodnotě 4 Typ služby (type of service TOS) v současnosti se nepoužívá.
Délka záhlaví (header length) obsahuje délku záhlaví IP-datagramu. Maximální délka záhlaví IPdatagramu je tedy omezena tím, že položka délka záhlaví má k dispozici pouze 4 bity (11112=F16=1510). Délka záhlaví IP-datagramu je tedy maximálně 60 B (=15x4). Jelikož povinné položky mají 20 B, tak na volitelné položky zbývá maximálně 40 B. Celková délka IP-datagramu (total length) obsahuje celkovou délku IP-datagramu v bajtech. Jelikož je tato položka pouze dvojbajtová, tak maximální délka IP-datagramu je 65535 bajtů.
Identifikace IP-datagramu (identification) obsahuje identifikaci IP-datagramu, kterou do IP-datagramu vkládá operační systém odesílatele. Tato položka se společně s položkami příznaky (flags) a posunutí fragmentu (fragment offset) využívá mechanizmem fragmentace datagramu. Doba života datagramu (time to live TTL) slouží k zamezení nekonečného toulání IP-datagramu Internetem. Každý směrovač kladnou položku TTL snižuje alespoň o jedničku. Obecně se však jedná o parametr jádra operačního systému, pokud ji tvůrci programu nenastaví explicitně).
Čísla protokolů vyšších vrstev přiřazuje tvůrcům protokolů vyšších vrstev organizace IANA. Pokud je třeba transportovat datagramy protokolu IP verze 6 přes síť podporující pouze IP-protokol verze 4, je nutné využít tunelování. Kontrolní součet z IP-záhlaví (header checksum) obsahuje kontrolní součet, avšak pouze ze záhlaví IP-datagramu a nikoliv z datagramu celého. Jeho význam je tedy omezený. IP-adresa odesilatele a IP-adresa příjemce (source and destination adress) obsahuje čtyřbajtovou IPadresu odesílatele a příjemce IP-datagramu. Volitelné položky jsou využívány ojediněle.
ICMP Internet Control Message Protocol vyžadovaný služební protokol definovaný v RFC 792. Základním účelem ICMP je informování zdrojového uzlu o chybách při přenosu datagramů: směrovač musí zrušit paket při překročení TTL směrovač nemá dostatečný buffer pro přeposlání datagramu směrovač musí fragmentovat datagram, ale ten má nastaven příznak "Don t Fragment" směrovač nebo uzel zjistí chybu v syntaxi IP hlavičky směrovač nemá v tabulce záznam o cílové síti
ICMP zpráva je umístěna v datové části IP datagramu. Datagram je směrován stejným způsobem jako přenášel data. Není použit mechanismus potvrzení převzetí zprávy, není garantováno, že ICMP zpráva dorazí k adresátovi. Pro řešení problému informací o ztrátě nebo zrušení ICMP zprávy, nejsou o nich informace předávány. Pro další zjednodušení jsou ICMP zprávy odesílány pouze v případě, že se vyskytl problém s nefragmentovaným datagramem nebo v případě fragmentace pouze u prvního fragmentu.
Fyzická vrstva má omezení na velikost přenášených dat závislé na standardu. Ethernet (Ethernet II encapsulation) 1500 Ethernet (IEEE 802.3 SNAP encapsulation) 1492 FDDI 4352 X.251600 Frame Relay 1600 ATM (Classical IP over ATM) 9180 minimum MTU 576
Řešením je směrovač poskytující fragmentaci paketů. při odesílání paketu dojde k fragmentaci na více IP paketů při přijímání čeká IP protokol, dokud nedorazí všechny pakety a provede rekonstrukci (reassembly) ztráta jednoho fragmentu = ztráta celého datagramu vyšší protokol musí poslat data znovu (ale pravděpodobnost ztráty paketu je stále stejná)
Fragmentace a velikost MTU zásadně ovlivňuje rychlost rozsáhlých sítí. Zajímavá a rozsáhlá problematika ladění výkonu sítí.
Protokol ARP (Address Resolution Protocol) řeší problém zjištění linkové adresy protější stanice ze znalosti její IP-adresy. Protokol je vcelku jednoduchý. Počítač, který se chce dozvědět MAC adresu druhého počítače na stejné síti, pošle broadcast (jak MAC, tak IP) paket s otázkou: "Kdo z vás má adresu 124.1.4.8?" a dotyčný počítač odpoví "Převod adresy 124.1.4.8 na MAC adresu je 00:54:65:23:EF:04."
Útočník tedy může poslat falešnou ARP odpověď a přesměrovat všechen tok dat na sebe a buď nasimulovat chování cílového počítače nebo pakety posílat dále k cílovému počítači. Zamezit takovým problémům je možné pomocí statického mapování v přepínači (pokud to umožňuje).
ARP filtrace : Používá se v případě, že na jedné LAN jsou části, které je třeba již na nižších vrstvách zabezpečit Zabezpečení spočívá v zamezení přístupu klienta z jedná části lokální sítě do druhé Příkladem může být síť poskytovatele Internetu, do kterého je zapojena kancelář Řešení spočívá ve statickém naplnění ARP-cache. Server pak bude odpovídat stále na linkovou adresu PC klienta se stejnou adresou, aniž by použil ARP-protokol Význam filtrace ARP je ale omezený, protože zaměstnanec firmy B může podvrhnout i linkovou adresu, to však není tak triviální a začínajícího hackera to odradí
RARP : Protokolem ARP je také možné odeslat žádost s vyplněnou IPadresou odesílatele i příjemce a také s oběma vyplněnými linkovými adresami Tento postup může sloužit jako diagnostika zdvojení IP adres To pochopitelně signalizuje chybu v konfiguraci jedné ze stanic používajících tuto adresu
RARP má smysl zejména je u bezdiskových stanic. Po svém zapnutí se potřebuje dozvědět svou IP-adresu. Protokol RARP používá stejný formát paketu jako protokol ARP Hodnota pole operace je zvětšena o jedničku. V RARP žádosti pochopitelně není vyplněna ani IP-adresa žadatele Protokol RARP se v praxi téměř nepoužívá, nahradil jej protokol DHCP, který je komplexnější
Proxy ARP Protokol ARP pracuje pouze v rámci LAN, tj. mezi dotazovaným a odpovídajícím počítačem nemůže být směrovač V dotazu s adresou příjemce všeobecný oběžník, který směrovače nešíří Proxy ARP běží na směrovači Počítač chce ARP-dotazem zjistit linkovou adresu k IP-adrese X, která leží v jiné LAN za směrovačem Směrovač nemůže propustit takový dotaz, avšak pokud je nakonfigurován jako proxy ARP, pak odpoví, že IP-adrese X odpovídá linková adresa samotného směrovače
Potřeba zajištění služeb jako jsou videokonference, televize a další multimediální přenosy v počítačových sítích sebou nese nutnost realizace odpovídajícího přenosového mechanizmu Klasický proud IP datagramů není vhodný datagagramy se vysílají vícekrát není zaručeno doručení potřeba odeslat jeden datagram více klientům (IP multicasting) riziko zahlcení sítě Multicasting je možné realizovat na vrstvě síťového rozhrání (ethernet má polovinu adresového prostoru vyhrazenou pro multicastové skupiny)
IP multicasting je jen abstrakcí multicastu na druhé vrstvě. Počítač (přesněji tedy síťové rozhraní) má možnost se začlenit do multicastové skupiny hostitel se může libovolně do skupiny přihlašovat a odhlašovat může být současně členem více skupin členové multicastové skupiny mohou být na různých fyzických sítích nutná účast směrovačů na přenosu multicastové datagramy se doručují stejně jako IP datagramy, mají stejné vlastnosti a podléhají stejným vlivům počítač může poslat multicastový datagram do libovolné skupiny
Základní koncepty multicastingu multicastové adresové schéma efektivní notifikace a doručování multicastových datagramů efektivní mezisíťové přeposílání multicastových datagramů
Multicastové adresové schéma : IP adresy třídy D jsou vyhrazeny pro multicastové skupiny. Třída D je v rozmezí 224.0.0.0 až 239.255.255.255. Permanentně přiřazené známé skupiny jsou 224.0.0.0/23 pro směrování a údržbu skupin 239.192.0.0 až 239.251.255.255 je privátní prostor adres pro jednu organizaci od 239.252.0.0 do 239.255.255.255 je privátní prostor adres pro jednu lokalitu. Speciální významné adresy jsou: 224.0.0.1 všechny systémy na lokální síti 224.0.0.2 všechny směrovače na lokální síti Multicastová adresa je určena pouze pro cíl, nesmí se nikdy objevit ve zdrojové adrese datagramu. Navíc se nedoručují ICMP pakety při chybě směrování. Pro komunikaci mezi počítačem a směrovačem slouží Internet Group Management Protocol (IGMP)
Ačkoliv je nesen v IP datagramu, pohlížíme na něj jako na součást IP protokolu. IGMP pracuje ve dvou fázích: když počítač vstupuje do jisté multicastové skupiny, zašle IGMP zprávu na adresu 224.0.0.2 deklarující jeho členství lokální směrovače zprávu přijmou a ustanoví příslušnou cestu k hostiteli dalším propagováním jeho členství protože členství je dynamické, směrovač pravidelně počítá počítače na lokálních sítích, aby zjistil, zda ještě k dané skupině někdo patří jestli počítač odpovídá kladně, směrovač udržuje informace o navázaných cestách po několika nezodpovězených dotazech přestane propagovat členství ve skupině do okolí Protokol IPv6 používá protokol MLD jako speciální druh ICMP zprávy
IPv6 vzniklo jako reakce na nedostatky a problémy IPv4. Nejvýznamnější cíle, které si jeho autoři stanovili, byly: dostatečně bohatý adresní prostor pokud možno, aby už nikdy neměla nastat nouze o adresy podpora služeb se zaručenou kvalitou design odpovídající vysokorychlostním sítím bezpečnostní mechanismy přímo v IP podpora mobilních zařízení automatická konfigurace kooperace s IPv4 a co nejhladší přechod ze stávajícího protokolu na nový
Hlavním motorem IPv6 byl původně nedostatek adres. Časem se hledala se (a nacházela) řešení i na bázi klasického IPv4 Vzniklo beztřídní přidělování adres, mechanismy pro nahrazení celé lokální sítě jedinou adresou (NAT, zvaný též IP maškaráda) Najednou se zjistilo, že se starým adresným prostorem dokážeme ještě nějaký ten rok vydržet Také pro ostatní z výše uvedených cílů se začínají objevovat řešení v IPv4 S postupujícím časem se asi nejzávažnějším argumentem ve prospěch IPv6 stává podpora mobilních počítačů, která je zde vyřešena podstatně lépe než v jeho předchůdci
Současně s ní se vrací problém s nedostatkem adres Počet mobilních zařízení utěšeně roste a berličky pro snížení počtu konzumovaných adres (jako například NAT) se pro ně používají jen obtížně Právě přenosná zařízení totiž často vyžadují čisté spojení mezi oběma komunikujícími konci
Konec