IP protokoly 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. Data jsou od odesilatele k příjemci dopravována (směrována) přes směrovače (router). Na cestě od odesilatele k příjemci se může vyskytnout cela řada směrovačů - každý směrovač řeší samostatně směrování k následujícímu směrovači. Data jsou tak předávána od směrovače k směrovači. Z angličtiny se počeštil v tomto kontextu termín následující hop (next hop), jako následující uzel kam se data předávají. Hopem se rozumí buď následující směrovač nebo cílový stroj. V linkovém protokolu mělo každé síťové rozhraní (network interface) svou fyzickou (tj. linkovou) adresu, která je v případě LAN zpravidla šestibajtová, v IP-protokolu má každé síťové rozhraní alespoň jednu IP-adresu, která je v případě IP-protokolu verze 4 čtyřbajtová, a v případě IP-protokolu verze 6 šestnáctibajtová.

Představa fungování protokolu IP protokol IP rozhoduje o dalším směru předání datagramu (routing), řeší vkládání do linkových rámců a odesílání (forwarding)…. síť síť síť směrovač směrovač IP datagram IP datagram IP datagram I P IP datagram IP datagram IP datagram link ová vrs tva linkový rámec linkový rámec linkový rámec linkový rámec linkový rámec linkový rámec přenos přenos přenos

Sada IP protokolů IP-protokol je tvořen několika dílčími protokoly: Vlastním protokolem IP. Služebním protokolem ICMP sloužícímu zejména k signalizaci mimořádných stavů. Služebním protokolem IGMP sloužícímu 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.

Charakteristika protokolu IP jde o přenosový protokol síťové vrstvy zajišťuje: přenos datagramů realizuje směrování je implementován v hostitelských počítačích ve směrovačích je: nespolehlivý nespojovaný dnes používaná verze má číslo 4 (IPV4) a v rámci ní 32-bitové IP adresy je připravena verze 6 se 128-bitovými adresami a vylepšenými vlastnostmi

Vlastnosti protokolu IP je univerzální, nabízí jednotné přenosové služby pro různé fyzické přenosové technologie vytváří jednotné prostředí pro všechny aplikace pracuje s proměnnou velikostí paketu (datagramu) velikost určuje odesilatel (aplikace) problém: datagram se musí „vejít“ do linkového rámce - může docházet ke fragmentaci je zaměřen na jednoduchost, efektivnost a rychlost na úkor spolehlivosti je nespojovaný nečísluje přenášené pakety negarantuje pořadí doručení negarantuje dobu doručení ….. je nespolehlivý negarantuje doručení negarantuje nepoškozenost dat nepoužívá potvrzování nepodporuje řízení toku smí zahodit datagram když: má chybný kontrolní součet překročil svou životnost hrozí zahlcení sítě

velikost hlavičky je také proměnná Formát IP datagramu velikost je proměnná max. 64 K (65535 bytů) minimální podporovaná velikost: 576 bytů bez toho, aby docházelo k fragmentaci odpovídá to 512 bytům užitečného "nákladu", ostatní je režie hlavička (header) datová část HLEN velikost hlavičky je také proměnná (typická velikost 20 B) (Header LENgth, 4 bity) TOTAL LENGTH (16 bitů), max. 65535 bytů

IP-datagram

Formát hlavičky IP datagramu 4 8 16 31 VERSION LENGTH TYPE OF SERVICE TOTAL LENGTH VERSION: dnes = 4 (Ipv4) LENGTH: velikost hlavičky v jednotkách 32-bitů při typické velikosti 20 bytů je LENGTH rovno 5 TYPE OF SERVICE dnes ignorováno TOTAL LENGTH celková délka datagramu v bytech, včetně hlavičky!

Formát hlavičky IP datagramu 4 8 16 31 IDENTIFICATION FLAGS FRAGMENTATION OFFSET IDENTIFICATION slouží potřebám fragmentace všechny fragmenty ze stejného celku mají v této položce stejnou hodnotu podle toho se pozná že patří k sobě FRAGMENTATION OFFSET offset fragmentu dat od začátku původního celku DON´T FRAGMENT MORE FRAGMENTS 1=nefragmentuj 1=jsou ještě další fragm. 0 = poslední fragment

Formát hlavičky IP datagramu 4 8 16 31 TTL PROTOCOL HEADER CHECKSUM TTL (Time To Live) čítač průchodů přes směrovače HEADER CHECKSUM kontrolní součet hlavičky (!!) PROTOCOL udává typ užitečného nákladu, kterému protokolu patří - kterému protokolu vyšší vrstvy ho má předat): 1 = ICMP 6 = TCP 17 = UDP …..

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. Není-li už možné hodnotu snížit, IP-datagram se zahazuje a odesilateli IP-datagramu je tato situace signalizována protokolem ICMP.

Formát hlavičky IP datagramu 4 8 16 31 povinné INTERNET SOURCE ADDRESS (IP adresa odesilatele) INTERNET DESTINATION ADDRESS (IP adresa příjemce) OPTION FIELD(S) PADDING nepovinné OPTION FIELD(S) umožňuje rozšířit hlavičku o další funkce např. source routing, záznam cesty, záznam času …. dnes se nepoužívá, směrovače obvykle zahazují datagramy s tímto rozšířením PADDING vycpávka, aby hlavička měla velikost, která je násobkem 4 bytů

Problém fragmentace příčina problému: různé přenosové technologie pracují s různými velikostmi linkových rámců velikost udává parametr MTU (Maximum Transfer Unit) znalost MTU se týká jen místní sítě (segmentu), netýká se celé cesty !!! ten, kdo určuje velikost datového paketu, se může přizpůsobit známé velikosti MTU díky nespojovanému charakteru IP protokolu (nenavazuje spojení) nelze fragmentaci vyloučit, i když bude respektováno "místní" MTU !!

menší velikost linkového rámce Problém fragmentace tento směrovač musí rozdělit (fragmentovat) IP datagram na více částí, protože původní by se nevešel do menšího linkového rámce IP datagram síť síť síť směrovač směrovač IP dat. IP dat. IP dat. IP dat. IP datagram IP datagram IP dat. IP dat. IP dat. IP dat. linkový rámec linkový rámec link. rám. link. rám. link. rám. link. rám. přenos link. rám. link. rám. link. rám. link. rám. přenos přenos menší velikost linkového rámce

Řešení fragmentace směrovač, který zjistí že "následující síť" má příliš malé MTU, rozdělí IP datagram na několik menších IP datagramů (fragmentů) každému dá stejnou hodnotu IDENTIFICATION jako má mateřský datagram lze fragmentovat fragmenty - je garantována minimální velikost IP datagramu (576 B) která by neměla být nikdy fragmentována odpovídá to "užitečnému nákladu" nejméně 512 B .. zpětné sestavení zajišťuje až koncový příjemce !!!! datagram je sestaven pouze pokud dorazí všechny fragmenty, v opačném případě je vše zahozeno pomocí příznaku DON'T FRAGMENT lze požadovat aby datagram nebyl fragmentován, pak musí být zahozen

ICMP (Internet Control Message Protocol) pro potřeby informování o nestandardních situacích byl vyvinut protokol ICMP ICMP zpráva je umístěna v datové části IP datagramu. protokol IP nezahazuje datagramy bezdůvodně má právo zahodit datagram při nestandardních situacích zacyklení, chybný kontrolní součet hlavičky, přetížení, když nelze fragmentovat, … když něco zahodí, nemusí se starat o nápravu snaží se ale informovat o tom, že se něco stalo

(závisí na druhu zprávy) Formát ICMP paketu 8 16 31 TYPE CODE CHECKSUM ICMP message (závisí na druhu zprávy) TYPE: určuje druh ICMP zprávy 0 Echo reply (odpověď na požadavek, při PINGu) 3 Destination unreachable (nedoručitelný datagram ) 4 Source Quench (žádosti o zpomalení) 5 Redirect (přesměrování) 6 Alternate host address 8 Echo Request 9 Router Advertisement 10 Router Selection 11 Time Exceeded (čas vypršel) 12 Parameter Problem 13 Timestamp Request 14 Timestamp Reply 15 Information Request 16 Information Reply 17 Address Mask Request 18 Address Mask Reply …… 30 Traceroute …. CODE: upřesňuje význam položky TYPE

ICMP Echo Request/ Echo Reply Zprávu ICMP Echo Request (TYPE = 8) může poslat kterýkoli host nebo router. Odpověď generuje přímo ICMP software, Dotázaný pošle ICMP Echo Reply (TYPE=0) slouží k: testu dostupnosti (konektivity) změření doby přenosu (RTT, Round Time Trip) zjištění zda dochází k fragmentaci určení počtu hopů k cíli (pozná se podle TTL ve výpisu odpovědi) Kombinace ICMP zpráv 0 a 8 (Echo Request a Echo Reply) je známa jako Ping. Jde o jednoduchý testovací mechanismus pro zkoušení dostupnosti uzlu.

ipconfig (MSWindows) / ifconfig (linux) ping IP adresa brány - odezva uzlu

3 Destination unreachable - nedoručitelný datagram vyjadřuje pomocí kódů (pole Code) příčinu vzniku problému nedostupná síť (CODE=0), nedostupný uzel (CODE=1), neexistující adresy (CODE=2), porty (CODE=3), překročení MTU při nastaveném příznaku že se nemá fragmentovat (CODE=4) chyby routerů, chyby SW nesprávné cesty (cykly, neexistující cesty apod.) výpadky uzlů zakázaný přístup pro určitý druh paketů / služeb 4 - žádosti o zpomalení (Source Quench) pokud datagramy přicházejí na směrovač příliš rychle a směrovač je nestíhá zpracovávat, musí je rušit. Při tom posílá zdrojovému uzlu ICMP zprávy Source Quench, jimiž žádá uzel o zpomalení. 5 - přesměrování (Redirect) ICMP redirect je mechanismus, kterým může směrovač upozornit na to, že jiný směrovač v síti umí lepší cestu k cíli; 11 - Time Exceeded – čas vypršel přijmeli směrovač datagram, jehož TTLl=0 nebo TTL=1 k nule, má právo datagram zahodit, ale má povinnost o tom informovat odesilatele zahozeného datagramu

3 Destination unreachable - nedoručitelný datagram 4 - žádosti o zpomalení (Source Quench) pokud datagramy přicházejí na směrovač příliš rychle a směrovač je nestíhá zpracovávat, musí je rušit. Při tom posílá zdrojovému uzlu ICMP zprávy Source Quench, jimiž žádá uzel o zpomalení. 3 Destination unreachable - nedoručitelný datagram vyjadřuje pomocí kódů (pole Code) příčinu vzniku problému nedostupná síť (CODE=0), nedostupný uzel (CODE=1), neexistující adresy (CODE=2), porty (CODE=3), překročení MTU při nastaveném příznaku že se nemá fragmentovat (CODE=4) chyby routerů, chyby SW nesprávné cesty (cykly, neexistující cesty apod.) výpadky uzlů zakázaný přístup pro určitý druh paketů / služeb 5 - přesměrování (Redirect) ICMP redirect je mechanismus, kterým může směrovač upozornit na to, že jiný směrovač v síti umí lepší cestu k cíli; 11 - Time Exceeded – čas vypršel přijmeli směrovač datagram, jehož TTLl=0 nebo TTL=1 k nule, má právo datagram zahodit, ale má povinnost o tom informovat odesilatele zahozeného datagramu

traceroute odešle zprávu s hodnotou TTL=1 od prvního směrovače dostane ICMP 11 a pak u každé další zprávy zvýší hodnotu TTL o jedna takovým způsobem od každého směrovače, kterým datagram projde dostane ICMP 11 … tj. ozve se mu každý směrovač na cestě k cíli

tracert (MS Windows), traceroute (linux)

Address Resolution symbolická jména připomenutí: IP adresy jsou abstraktní (virtuální), nemají "fyzickou" analogii v linkových adresách hardwarových adresách musí existovat převodní mechanismy AR, Address Resolution převod z IP na HW adresu RAR, Reverse Address Resolution opačně, z HW na IP adresu překlad: DNS IP adresy překlad: ARP, RARP linkové adresy (HW adresy)

ARP (Address Resolution Protocol) Mechanismus zjišťování MAC adresy pro IP protokol Předpokládejme, že stanice A má IP adresu 192.168.1.21 a chce komunikovat s adresou 192.168.1.1. Stanice si v první fázi zkontroluje zda má v ARP Cache MAC adresu dané IP adresy. Pokud ne, musí si MAC adresu zjistit metodou dotaz&odpověď ARP není IP  protokol v pravém slova smyslu protože nemá IP hlavičku – tím nemůže ani opustit logickou síť neboť nemůže projít přes směrovač. Pokud stanice spolu nedávno komunikovali, má uzel MAC adresu uloženu v tzv. ARP Cache. ARP Cache je paměťový segment v němž je držena tabulka s relacemi IP adresa x MAC adresa. Důvodem je snížení množství požadavků na zjišťování MAC adres. Údaj je v ARP Cache je však držen omezenou dobu. Hodnoty ARP Cache vypíšeme na většině systémů pomocí příkazu arp –a 00-00-64-65-73-74      192.168.1.21

? … 192.168.1.1 …? 192.168.1.21 192.168.1.1

ARP - zjišťování MAC adresy 1. stanice A odesílá ARP Request - pošle dotaz všem v dané síti (pomocí broadcastu) zdrojovou adresou je její MAC adresa a adresou určení je broadcast; zdrojová adresa i adresa určení protokolu IP odpovídají konkrétním hodnotám 2. všechny uzly se musí broadcastu věnovat a porovnat svoji IP adresu s adresou určení, ten uzel jehož IP adresa odpovídá adrese z požadavku, posílá tzv. ARP Response, tedy odpověď s vyplněnou svojí MAC adresou. dotazy jsou vkládány přímo do linkových rámců rozesílány jsou všem uzlům (broadcast) dotaz je typu: "kdo má takovouto IP adresu?" odpovídá pouze ten uzel, který rozpozná svou IP adresu, do odpovědi vloží svou HW adresu odpověď je zasílána cíleně, nikoli jako broadcast