5 IP protokol

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.

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.

5.1 IP-datagram


Obr. 5.7 IP-datagram

Verze (version) je první položkou záhlaví IP-datagramu. Tato položka dlouhá 4 bity (půl bajtu) obsahuje verzi IP-protokolu. V této kapitole hovoříme o IP-protokolu verze 4, tudíž tato položka je v našem případě rovná hodnotě 4.

Délka záhlaví (header length) obsahuje délku záhlaví IP-datagramu. V  případě odchyceného IP-datagramu na obr. 5.8 je délka záhlaví 20, ale jak je vidět z hexadecimálního výpisu z MS Network Monitoru, tak položka délka záhlaví nabývá hodnoty 5 (nikoliv 20). Vysvětlení je prosté. Délka není uváděna v bajtech, ale v čtyřbajtech a 5x4=20. Délka záhlaví musí tak být i v případě použití volitelných položek násobkem čtyř. V případě, že by záhlaví nevyšlo na násobek čtyř, pak se na násobek čtyř doplní nevýznamnou výplní.

Maximální délka záhlaví IP-datagramu je tedy omezena tím, že položka délka záhlaví má k dispozici pouze 4 bity (1111₂=F₁₆=15₁₀). 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.

Typ služby (type of service – TOS) je položka, která v praxi nenašla svého naplnění. V normách RFC-791 a RFC-1349 lze nalézt konkrétní návrhy využití. Záměr spočíval v jistém nedostatku IP-protokolu jehož podstatou je skutečnost, že v Internetu není zaručena šíře přenosového pásma mezi účastníky. Jistého vylepšení se mělo dosáhnout právě touto položkou, pomocí které je možné označit některé IP-datagramy tak, aby byly dopravovány přednostně či aby byla zaručena rychlá odezvat atp.

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 odesilatele. Tato položka se společně s položkami příznaky (flags) a posunutí fragmentu (fragment offset) využívá mechanizmem fragmentace datagramu.
 


Obr. 5.9 Příznaky

Do češtiny se názvy bitů pole příznaky překládají v negaci (viz obr. 5.9). Je-li DF bit nastaven na 1, pak je fragmentace zakázána. Nastavení na 0 naopak znamená, že fragmentace je možná. Je-li nastaven bit MF na jedničku, pak vyjadřuje, že není posledním fragmentem.

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.

Jak se hodnota položky TTL nastavuje? U příkazů ping a traceroute je ji možné explicitně nastavit. Obecně se však jedná o parametr jádra operačního systému, pokud ji tvůrci programu nenastaví explicitně).

Protokol vyšší vrstvy (protocol) obsahuje číselnou identifikaci protokolu vyšší vrstvy, který využívá IP-datagram ke svému transportu. V praxi se nesetkáváme s případem, že by se komunikovalo přímo IP-protokolem. Vždy je použit protokol vyšší vrstvy (TCP nebo UDP) nebo jeden ze služebních protokolů ICMP či IGMP. Protokoly ICMP a IGMP jsou sice formálně součástí protokolu IP, avšak chovají se jako protokoly vyšší vrstvy, tj. v přenášeném paketu je záhlaví IP-protokolu následované záhlaví protokolu ICMP (resp. IGMP).

Čísla protokolů vyšších vrstev přiřazuje tvůrcům protokolů vyšších vrstev organizace IANA. Přiřazená čísla lze najít na http://www.iana.org. Pro zajímavost jsou některá čísla protokolů popisovaných v této publikaci uvedena v tab. 5.1.

Tab. 5.1

Číslo protokolu vyšší vrstvy	Protokol
1	ICMP
2	IGMP
6	TCP
1710=1116	UDP

Jako protokol vyšší vrstvy může být i protokol, který je tunelován přes Internet (encapsulation). Tunelovány mohou být např. protokoly, které Internet nepodporuje jako je např. protokol IPX. Nebo může být tunelován sám protokol IP (IP over IP). Tunelování IP přes IP se může na první pohled jevit jako nesmyslné plýtvání. Avšak v případě, že přes Internetem chceme přenášet data mez dvěma částmi privátní sítě o adrese 10.0.0.0 pak je takový tunel nezbytností. Navíc je možné vnitřní IP-datagramy zabezpečit šifrováním a vznikne nám tak jednoduchá virtuální privátní síť (VPN).

Tab. 5.2

Číslo protokolu vyšší vrstvy (desítkově)	Protokol
4	IP over IP
97	Ethernet within IP
111	IPX in IP

Pokud je třeba transportovat datagramy protokolu IP verze 6 přes síť podporující pouze IP-protokol verze 4, pak také nezbývá opět nic jiného než tunelování. V tab. 5.2 jsou uvedena některá čísla pro tunelované protokoly.

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ý. Bližší informace o výpočtu kontrolního součtu lze nalézt v normách RFC-1071 a RFC-1141.

Problém s kontrolním součtem spočívá v tom, že když směrovač změní nějakou položku v záhlaví IP-datagramu (např. TTL změnit musí), tak musí změnit i hodnotu kontrolního součtu, což vyžaduje jistou režii směrovače.

IP-adresa odesilatele a IP-adresa příjemce (source and destination adress) obsahuje čtyřbajtovou IP-adresu odesilatele a příjemce IP-datagramu.

Volitelné položky jsou využívány ojediněle a zpravidla směrovače bývají nakonfigurovány tak, aby IP-datagramy s použitými volitelnými položkami byly bez okolků zahozeny.
 
 

5.2 Protokol ICMP


Protokol ICMP je služební protokol, který je součástí IP-protokolu. Protokol ICMP slouží k signalizaci mimořádných událostí v sítích postavených na IP-protokolu. Protokol ICMP svoje datové pakaty balí do IP-protokolu, tj. pokud budeme prohlížet přenášené datagramy, pak v nich najdeme za linkovým záhlavím záhlaví IP-protokolu následováno záhlavím ICMP paketu.

Obr. 5.10 ICMP-paket

 

---

Echo

Je jednoduchý nástroj protokolu ICMP, kterým můžeme testovat dosažitelnost jednotlivých uzlů v Internetu. Žadatel vysílá ICMP-paket “Žádost o echo” a cílový uzel je povinen odpovědět ICMP-paketem “ Echo”.

Všechny operační systémy podporující protokol TCP/IP obsahují program ping, kterým uživatel může na cílový uzel odeslat žádost o echo. Program ping pak zobrazuje odpověď.

Význam pole identifikátor v záhlaví ICMP-paketu spočívá ve spárování žádosti s odpovědí (aby se dalo zjistit ke které žádosti paří příslušná odpověď).

Např. ve Windows NT chceme zjistit dostupnost uzlu 194.149.105.18:

D:\>ping 194.149.105.18

Pinging 194.149.105.18 with 32 bytes of data:
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63

Systém odeslal čtyřikrát žádost o echo. Odpověď měla 32 bajtů dlouhou dataovou část a získal ji do 10 ms. V odpovědi měla položka TTL hodnotu 63.
 

Nedoručitelný IP-datagram

Nemůže-li být IP-datagram předán dále směrem k adresátovi, pak je zahozen a odesilatel je protokolem ICMP o tom uvědomen zprávou “Nedoručitelný IP-datagram”.

Sniž rychlost odesílání

Jestliže je síť mezi odesilatelem a příjemcem v některém místě přetížena, pak směrovač, který není schopen předávat dále všechny IP-datagramy signalizuje odesilateli “Sniž rychlost odesílání”. Odesilatel pak v případě, že používá protokol TCP snižuje rychlost odesílání TCP segmentů. V případě protokolu UDP se zprávy “Sniž rychlost odesílání” ignorují.

Změň směrování (Redirect)

Pomocí tohoto ICMP-paketu se provádí dynamické změny ve směrovací tabulce.


Obr. 5.11 Redirect

Na obr. 5.11 směrovač 1 má předávat IP-datagram na stejné síťové rozhraní (interface), kterým IP-datagram přišel, pak jej sice předá, avšak upozorní adresáta ICMP-paketem, aby si změnil vlastní směrovací tabulku a takovou podivnou službu už více nežádal.

Tato situace nejčastěji nastává tehdy, když máme na lokální síti více směrovačů, ale jednotlivé počítače na LAN mají po svém startu pouze položku default ukazující na jeden ze směrovačů.
 

Žádost o směrování

Jedná se o poměrně novou záležitost, pomocí které nemusíme do směrovací tabulky počítačů na LAN ručně konfigurovat vůbec žádnou položku default. Počítač po svém startu vyšle oběžníkem “Žádost o směrování” a směrovač mu odpoví ICMP-paketem “Odpověď na žádost o směrování”, která obsahuje: počet adres směrovače, délku adresy a pak dvojice IP-adresa a preference. Z odpovědi může počítač automaticky vygenerovat položku default.

Čím má preference vyšší hodnotu, tím je IP-adresa více preferována. Hodnota preference 80000000₁₆ signalizuje, že tato adresa se má ze směrovací tabulky vypustit.

Směrovače odpovídají na žádost o směrování, avšak v náhodném intervalu mezi 450 a 600 vteřinami by měly oběžníkem sami do lokální sítě generovat ICMP-pakety “odpověď na žádost o směrování”.

Položka “doba života” udává čas, po který je informace platná, tj. po který má být položka ve směrovací tabulce udržována.
 

Čas vypršel (time exceeded)

 
Tento typ zahrnuje dva velmi odlišné případy.

Pro kód=0 signalizuje, že položka TTL by byla na směrovači snížena na nulu, tj. že je podezření, že IP-datagram v Internetu zabloudil, proto bude zlikvidován.

Pro kód=1 signalizuje, že počítač adresáta není schopen v daném čase sestavit z fragmentů celý IP-datagram.

ICMP-paket čas vypršel kód=0 využívá ke své činnosti program traceroute (UNIX) i program tracert (Microsoft).

Program tracert je jednodušší. Tento program odesílá ze zdrojového počítače na cílový uzel ICMP-pakety “Žádost o echo”, avšak v prvním paketu nastaví položku TTL na jedničku. První směrovač na cestě paket zahodí a vrátí ICMP-paket “Čas vypršel”, protože musí zmenšit TTL alespoň o jedničku, ale tímto zmenšením už dostane nulu.

Zdrojový počítač tak od prvního směrovače na cestě dostane v IP-datagramu ICMP-paket “čas vypršel”. Z položky adresa odesilatele v IP-záhlaví lze zjistit adresu prvního směrovače na cestě. Změří se časový interval od odeslání po příjem paketu a zjistí se tak čas procházky paketu od odesilatele k příjemci a zpět. Toto se opakuje třikrát a všechny tři časy zobrazí. Na konec řádku ještě zobrazí jméno směrovače a v hranatých závorkách jeho IP-adresu. Jméno získá z reverzního překladu v DNS.
 


Obr. 5.12 Příkaz tracert

Nezíská-li v časovém limitu odpověď zobrazí místo času hvězdičku (*).

Pote vše opakuje s hodnotou TTL=2 atd. Svou činnost ukončí, když od cílového uzlu obdrží ICMP-zprávu “Echo”. K ukončení může pochopitelně také dojít, když nějaký směrovač nezná cestu k cílovému počítači, pak zdrojovému počítači zašle zprávu “nedoručitelný IP-datagram”.

D:\>tracert kula.usp.ac.fj

Tracing route to kula.usp.ac.fj [144.120.8.11]
over a maximum of 30 hops:

1 <10 ms 10 ms <10 ms cbuN002e00.pvt.net [194.149.104.193]
2 10 ms 10 ms 10 ms phucbu.pvt.net [194.149.96.13]
3 601 ms 561 ms 641 ms 951.Hssi5-0.GW1.NYC2.ALTER.NET [157.130.0.117]
4 591 ms 571 ms 571 ms 143.ATM2-0.XR1.EWR1.ALTER.NET [146.188.177.50]
5 591 ms 581 ms 571 ms 193.ATM1-0-0.BR1.EWR1.ALTER.NET [146.188.176.49]
6 400 ms 381 ms 360 ms sl-pen-11-h3.sprintlink.net [137.39.44.130]
7 811 ms 591 ms 661 ms sl-bb10-pen-0-1.sprintlink.net [144.232.5.5]
8 500 ms 651 ms 731 ms sl-bb22-stk-6-0.sprintlink.net [144.232.8.178]
9 871 ms 831 ms 932 ms sl-bb23-stk-8-0.sprintlink.net [144.232.4.110]
10 691 ms 650 ms 611 ms sl-bb10-sj-6-0.sprintlink.net [144.232.8.193]
11 811 ms 771 ms 771 ms sl-gw2-sj-0-0-155M.sprintlink.net [144.232.3.38]
12 641 ms 651 ms 641 ms sl-cais-1.sprintlink.net [144.228.111.18]
13 801 ms 811 ms 861 ms hssi9-0-0.hk-T3.hkt.net [202.84.128.253]
14 801 ms * 811 ms f5-0.yck06.hkt.net [205.252.130.201]
15 821 ms 831 ms 822 ms a6-0.tmh08.hkt.net [205.252.130.81]
16 1402 ms 1342 ms 1362 ms s4-3b.tmh08.hkt.net [205.252.128.158]
17 1381 ms 1362 ms 1352 ms 202.84.251.6
18 1362 ms 1362 ms 1352 ms 202.62.120.6
19 1422 ms 1372 ms 1392 ms 202.62.125.134
20 1412 ms 1382 ms 1412 ms kula.usp.ac.fj [144.120.8.11]

Trace complete.

Program traceroute pracuje na obdobném principu, avšak neodesílá ICMP-pakety “Echo request”, ale generuje protokolem UDP datagramy (UDP-port je možné modifikovat parametrem –p). Je-li na cestě k cílovému počítači použita filtrace na směrovači, pak vhodnou volbou čísla UDP-portu lze mnohdy nalézt “díru” ve filtru a objevit cestu až k cílovému počítači. Dobrým typem je pro takový případ číslo portu 53 (-p 53), který používá DNS.

$ /usr/sbin/traceroute -p 20000 libor.pvt.net
traceroute to libor.pvt.net (194.149.104.198), 30 hops max, 40 byte packets

1 cbuN003f00.pvt.net (194.149.105.17) 1 ms 1 ms 1 ms
2 Libor.pvt.net (194.149.104.198) 1 ms 1 ms 1 ms

Cílový počítač zpravidla odpoví ICMP-paketem “Port unreacheble” (typ=3, kód=3). Kromě času a hvězdičky program traceroute ještš může vypsat !H (nedostupný uzel), !N (nedostupná síť), !A (síť administrativně uzavřena) či !S (explicitní směrování selhalo).
 
 

Žádost o masku

Tímto ICMP-paketem může bezdisková stanice žádat o masku své sítě poté co protokolem RARP obdržela svou IP-adresu.

Tento mechanizmus je praxi dnes již málo běžný. Stanice může získat masku své sítě protokolem BOOTP, kterým získá i další informace. Avšak i protokol BOOTP je dnes vytlačován protokolem DHCP, který je komplexnější, tj. poskytuje více informací. Protokoly BOOTP a DHCP jsou aplikační protokoly.
 
 

Časová synchronizace

Tímto ICMP-paketem se žádá cílový počítač o čas. Mechanismus je znázorněn na obr. 5.13.

Zdrojový počítač do ICMP-paketu “Požadavek na časovou synchronizaci (timestamp request)” vyplní čas odeslání žádosti.

Cílový počítač vyplní do své odpovědi “Odpověď na časovou synchronizaci (timestamp reply)” dva časy:

1. Čas přijetí žádosti.
2. Čas odeslání odpovědi.
Zdrojový počítač si zjistí čas přijetí odpovědi (ten se pochopitelně nepřepravuje v žádném ICMP-paketu). Odečtením času odeslání požadavku od času přijetí odpovědi se získá doba procházky od zdrojového počítače k cílovému a zpět (anglicky Round Trip Time – RTT).

Obr. 5.13 Časová synchronizace

5.3 Fragmentace

Každý IP-datagram má ve záhlaví svou identifikaci, kterou dědí i jeho fragmenty. Díky identifikaci příjemce pozná, ze kterých fragmentů má datagram složit. Nikdo jiný než příjemce není oprávněn z fragmentů skládat původní datagram, tj. ani např. směrovač ze kterého vede linka s takovým MTU do kterého by se celý datagram již vešel. Důvod je prosty, Internet negarantuje, že jednotlivé fragmenty půjdou stejnou cestou (ani negarantuje pořadí v jakém dojdou). Takže směrovač, který by se pokoušel datagram sestavit by mohl být na závadu spojení, protože fragmentů, které by šly jinou cestou by se nikdy nedočkal.

Identifikace IP-datagramů může být jednoznačná pouze v rámci jednoho protokolu vyšší vrstvy, protože záhlaví IP-datagramu obsahuje ještě pole “Protokol vyšší vrstvy”. Globální identifikace může být brána jako sřetězení polí identifikace a protokol vyšší vrstvy (+ pochopitelně IP-adresa odesilatele a příjemce). Takže teoreticky mohou být za sebou odeslány dva IP-datagramy o stejné identifikaci, jeden však nese TCP-paket a druhý UDP-paket. Toto je opět méně běžná implementace.

Každý fragment tvoří samostatný IP-datagram. Při fragmentaci je nutné vytvořit pro každý fragment nové IP-záhlaví. Některé údaje (jako protokol vyšší vrstvy, či IP-adresa odesilatele a příjemce) se získají ze záhlaví původního IP-datagramu.

Při fragmentaci vstupuje do hry pole “Posunutí fragmentu od počátku IP-datagramu (fragment offset)”, které vyjadřuje kolik bajtů datové části původního IP-datagramu bylo vloženo do předchozích fragmentů. Pole “Celková délka IP-datagramu (total length)” obsahuje délku fragmentu, nikoliv délku původního datagramu. Aby příjemce poznal jak je původní datagram dlouhý, tak je poslední fragment opatřen příznakem “Poslední fragment”. Celý mechanismus je znázorněn na obr. 5.17.

Síť nerozlišuje mezi přenosem fragmentu a přenosem celého (nefragmentovaného) IP-datagramu. Nefragmentovaný datagram je fragment s posunutím nula a příznakem “Poslední fragment”. Proto se často slovo IP-datagram a fragment často zaměňují.

Mechanizmus fragmentace umožňuje i fragmentovat fragment dorazí-li na směrovač jehož odchozí linka má ještě mensí MTU.
 

Obr. 5.17 Fragmentace IP-datagramu
.

5.4 Volitelné položky IP-záhlaví

1. Zaznamenávej směrovače (record route).
2. Zaznamenávej čas (timestamp).
3. Explicitní směrování (loose source routing).
4. Striktní explicitní směrování (strict source routing).
5. Upozornění pro směrovač (IP Router Alert Option).
6. Bezpečnostní omezení dle normy RFC-1108. Jelikož zabezpečení na úrovni IP-protokolu je jen doplňkovou formou zabezpečení, tak v praxi (mimo armádu USA) nenašlo toto rozšíření uplatnění.

Obr. 5.18 Volitelné položky záhlaví IP-datagramu

Kde bit Kopírovat specifikuje, je-li nastaven na 1, že tato volba má být kopírována do všech fragmentů vzniklých z tohoto datagramu. Je-li bit nastaven na 0, pak se kopíruje pouze do záhlaví prvního fragmentu.

Dva bity tvořící pole Třída nabývají:

• Hodnoty 0 v případě, že se jedná o IP-datagram nesoucí běžná data nebo data určená pro řízení sítě.
• Hodnoty 2 (=10₂) v případě, že se jedná o IP-datagram sloužící k ladění nebo měření sítě.

Tab. 5.5

Kód	Šestnáctkově	Desítkově	Délka	Volba
00000000	00	0	Není	Konec voleb (End of options list). Použije se v případě, že volby nekončí s koncem IP-záhlaví. Pole délka a data se nepoužijí.
00000001	01	1	Není	Prázdná volba – výplň záhlaví na násobek čtyř bajtů. Pole délka a data se nepoužijí.
00000111	07	7	Proměnná	Zaznamenávej směrovače (Record route).
01000100	44	68	Proměnná	Zaznamenávej čas (Timestamp).
10000011	83	131	Proměnná	Explicitní směrování (Loose source routing).
10001001	89	137	Proměnná	Explicitní striktní směrování (Strict source routing).
10010100	94	148	4	Upozornění pro směrovač (IP Router Alert Option).

 

5.5 Protokoly ARP a RARP


Jsem-li stanice na lokální síti a chci protokolem IP komunikovat s jinou stanicí na téže síti, pak ji v protokolu IP adresuji čtyřbajtovou IP-adresou. Pro komunikaci znám IP-adresu odesilatel (svou IP-adresu) a IP-adresu příjemce. Jsem tedy schopen sestavit IP-datagram. Jenže potíž je v tom, že tento IP-datagram musí být zabalen do Linkového rámce – např. do ethernetového rámce. Abych vytvořil ethernetový rámec, tak potřebuji linkovou (6B) adresu příjemce i odesilatele. Odesilatel jsem já a svou linkovou adresu znám, avšak neznám linkovou adresu příjemce. Jak takovou adresu zjistím?, to řeší protokol ARP.

Protokol ARP (Address Resolution Protocol) řeší problém zjištění linkové adresy protější stanice ze znalosti její IP-adresy. Řešení je jednoduché, do LAN vyšle linkový obježník (linková adresa FF:FF:FF:FF:FF:FF) s prosbou: “Já stanice o linkové adrese HW1, IP-adrese IP1, chci komunikovat se stanicí o IP-adrese IP2, kdo mi pomůže s na nalezením linkové adresy stanice o IP-adrese IP2? Stanice IP2 takovou žádost uslyší a odpoví. V odpovědi uvede svou linkovou adresu HW2.


Obr. 5.27 Protokol ARP

ARP-paket je balen přímo do Ethernetu, tj. nepředchází mu žádné IP-záhlaví. Protokol ARP je vlastně samostatný na IP nezávislý protokol. Proto jej mohou používat i jiné protokoly, které s protokoly TCP/IP nemají nic společného.


Obr. 5.28 Paket protokolu ARP

Pole typ linkového protokolu specifikuje linkový protokol používaný na LAN. Linkovému protokolu Ethernet II je vyhrazeno číslo 1. Seznam přidělených čísel je uveřejněn na http://www.iana.org.

Typ síťového protokolu specifikuje typ síťového protokolu, používají se stejná čísla jako pro pole protocol v protokolu Ethernet II, tj. IP-protokol má přiděleno číslo 80_{16 .}

Pole HS určuje délku linkové adresy a pole PS délku síťové adresy. Standardně je tedy HS=6 a PS=4.

Pole operace určuje o jakou operaci jde. Žádost (ARP request) má hodnotu 1 a odpověď (ARP reply) má hodnotu 2. Toto pole je definováno rovněž pro reverzní překlad (protokol RARP), kdy RARP žádost používá hodnotu 3 a RARP odpověď hodnotu 4.

Pak již následuje linková adresa odesilatele, IP-adresa odesilatele, linková adresa příjemce (v dotazu vyplněna nulami) a IP-adresa příjemce.

Žádost je posílána linkovým oběžníkem a v poli příjemcova linková adresa má vyplněny nuly. Odpověď pak má již vyplněny všechny pole a nemusí být odesílána oběžníkem. Je třeba zdůraznit, že v odpovědi je odesilatelem dotazovaný a příjemce tazatel (došlo k výměně příjemce a odesilatele).
 

5.6 IGMP

Pole typ nabývá hodnot:

Hodnota (šestnáctkově)	Význam
11	Dotaz směrovače: “Jsou na LAN ještě nějací členové” (Membership query)
16	Požadavek na členství ve skupině (Membership report)
17	Opuštění skupiny (Leave group)
12	Požadavek IGMP v1 na členství ve skupině (Version 1 membership report)

Pole MRT (Maximum response time) se používá pouze v dotazu směrovače a specifikuje v desetinách sekundy čas do kterého musí členové skupiny opakovat požadavky na členství ve skupině. Ve všech ostatních případech má pole MRT hodnotu 0.

Kontrolní součet se počítá stejně jako u protokolu ICMP. Pole IP-adresa adresného oběžníku je nulové u všeobecného dotazu, v ostatních případech specifikuje konkrétní IP-adresu adresného oběžníku.

IP-adresy adresných oběžníků jsou v intervalu 224.0.0.0 až 239.255.255.255. Interval 224.0.0.0 až 224.0.0.255 je určen pro vyhrazené účely na LAN (viz tab. 5.7). Jelikož jsou oběžníky s těmito adresami určeny výhradně pro LAN, tak mívají v položce TTL nastavenu hodnotu 1.
 

IP-adresa	Vyhrazeno pro adresaci
224.0.0.1	Všechny systémy na LAN
224.0.0.2	Všechny směrovače na LAN
224.0.0.4	Distannce Vector Mulitcast Routing Protocol – viz RFC-1075
224.0.0.5	OSPF All Routers – viz RFC-1583
224.0.0.6	OSPF Designated Routers – viz RFC -1583
224.0.0.9	RIP-2 atd.

Všechny IGMP pakety mají v IP-záhlaví nestavenu položku TTL=1. Pakety protokolu IGMP verze 2 používají volbu (rozšíření) IP-záhlaví “Upozornění pro směrovač (IP Router Alert Option)”.
 

5.7 Všeobecné oběžníky a linkový protokol

Protokol ARP určil jednoznačný vztah mezi jednoznačnou IP-adresou příjemce (unicast) a linkovou adresou příjemce. To je možné tehdy, když mezi IP-adresami a linkovými adresami existuje jednoznačný vztah. Tento vztah se anglicky nazývá mapping, který se česky (asi ne zcela správně) označuje za mapování IP-adres na linkové adresy.

Jiným případem na LAN je všeobecný oběžník (broadcast), který se posílá všem systémům na LAN. Pro tyto účely slouží linkovému protokolu všeobecný oběžník, který pro ethernet, FDDI apod. je ff:ff:ff:ff:ff:ff.

Jenže jak to udělat na LAN v případě adresného oběžníku (multicast), který není určen jednou adresátovi na LAN ani všem systémům na LAN, nýbrž několika konkrétním adresátům.

V čem je problém? Příjemce z normálních okolností zpracovává pouze rámce, které jsou všeobecnými oběžníky nebo adresovány příjemcovou linkovou adresou. (Je možné síťovou kartu realizující síťové rozhraní přepnout do tzv. promiskuitního módu, kdy přijímá vše, ale tento případ není považován za běžný.)

Linkové protokoly umožňují též linkové adresné oběžníky (multicast). Jsou to takové linkové adresy, kde nejnižší bit prvního bajtu linkové adresy je nastaven na 1, tj. všeobecný linkový oběžník je zvláštním případem takovéhoto adresného oběžníku. Jenže jak mapovat IP-adresu adresného oběžníku na linkový adresný oběžník.

Není to však tak jednoduché jak to vypadá na první pohled. Šestibajtová linková adresa se skládá ze tří bajtů specifikujícího výrobce a tří bajtů čísla karty v rámci výrobce.

IANA (nejvyšší autorita Interčnetu) si nechala zaregistrovat jako fiktivní výrobce síťových karet a obdržela pro sebe identifikaci 00:00:5e. První polovinu těchto adres použila pro mapování adresných IP-oběžníků na adresné linkové oběžníky (viz obr. 5.36). Bohužel tato polovina má pouze 23 bitů, takže mapování nemůže být jednoznačné.

Obr. 5.36 Mapování adresných oběžníků na linkové adresy

První bajt linkové adresy musí mít nastaven nejnižší bit na jedničku, protože se jedná o adresný linkový oběžník. Takže prefix ve skutečnosti nebude 00:00:5e ale 01:00:5e.

Část A IP-adresy specifikuje adresný oběžník, je tedy vždy konstantní. Část B není mapována.

Takže pokud se dva adresné oběžníky liší pouze v části B, pak jsou mapovaný na stejnou linkovou adresu. Např. IP-adresy 224.0.1.1, 224.128.1.1 a 225.0.1.1 jsou mapovány vždy na 01:00:5e:00:01:01.

Linková vrstva počítače akceptuje linkové rámce.

• Adresované jednoznačnou linkovou adresou počítače (unicast).
• Všeobecné linkové oběžníky (broadcast).
• Adresné linkové oběžníky, jejichž seznam je linkové vrstvě předán vyššími vrstvami.