IPv4

IPv4 je verzia 4 Internet Protocolu (IP). Bola prvou široko používanou verziou a tvorí základ väčšej časti súčasného Internetu (2005).

Je opísaný v IETF RFC 791, ktorý bol prvýkrát zverejnený v septembri 1981.

IPv4 používa 32-bitové adresy, čo obmedzuje adresný priestor na 4 294 967 296 jedinečných adries, z ktorých je množstvo vyhradených pre zvláštne účely ako lokálne siete alebo multicastové adresy, čo redukuje počet adries použiteľných ako verejné internetové adresy. Viac v článku Vyčerpanie adresného priestoru IPv4.

Toto obmedzenie pomohlo stimulovať presadzovanie IPv6, ktorý v súčasnosti prechádza skorými štádiami nasadenia a plánuje sa, že postupne celkom nahradí IPv4.

Reprezentácia IPv4 adries 

IPv4 adresy sa zvyčajne zapisujú v bodkovej desiatkovej notácii. Tu je príklad: 207.142.131.235.
Je tiež možné zapísať ju v nasledovných tvaroch:

Hore uvedené IP adresy by mali fungovať vo väčšine prehliadačov a v čase písania článku ukazujú na wikipedia.org.

Formát hlavičky paketu IPv4 

Prvé pole v hlavičke IPv4 paketu je 4-bitové pole s verziou.

Druhé pole (4-bity) určuje dĺžku internetovej hlavičky (IHL) oznamujúca počet 32-bitových(4Bajtových) slov v hlavičke IPv4. Keďže IPv4 hlavička môže obsahovať niekoľko voliteľných súčastí, toto pole zvyčajne špecifikuje offset na dátovú časť IPv4 datagramu.
Minimálna dĺžka IPv4 hlavičky je 20 bajtov (160bitov), takže minimálna hodnota v IHL poli by bola 5 (5x4=20 bajtov). To znamená, že reprezentuje celkový počet bajtov, ktoré zaberá hlavička ako násobky štyroch bajtov.

V RFC 791 bolo nasledujúcich 8 bitov vyhradených pre pole Typ služby (ToS), dnes DiffServ a ECN. Pôvodný zámer bol, aby paket mohol špecifikovať preferencie, ako bude doručený internetovou sieťou. Bolo napríklad možné nastaviť hodnotu ToS na nízke zdržanie alebo vysokú spoľahlivosť. V praxi nebolo použitie ToS nikdy široko implementované, hoci sa využitie týchto ôsmich bitov zameriavalo množstvo experimentálnej a výskumnej práce. Tieto bity boli preddefinované a v súčasnosti ich využíva DiffServ, pracovná skupina IETF a kódové body ECN (pozri RFC 3168)

Ďalšie 16-bitové pole definuje veľkosť celého datagramu – hlavičky aj dát, v 8-bitových bajtoch. Minimálna dĺžka datagramu je 20 bajtov a maximálna 65 535. Maximálna veľkosť datagramu, s ktorou musí byť schopný zaobchádzať každý stroj je 576 bajtov, ale moderné stroje pracujú s oveľa väčšími paketmi. Niekedy podsiete určujú dodatočné obmedzenia na veľkosť, v takom prípade sa používa fragmentácia datagramov. Fragmentácia sa implementuje buď v stroji alebo prepínači paketov (pozri nižšie).

Ďalšie 16-bitové pole je identifikačné. Toto pole sa využíva na jedinečnú identifikáciu fragmentov originálneho datagramu. Niektoré experimentálne práce navrhovali iné využitie tohto poľa ako pridanie informácie na stopovanie datagramu, aby bolo možné spätne vystopovať pakety s nepravou adresou.

Nasleduje 3-bitové pole použité na riadenie alebo identifikáciu paketov. Sú to (v poradí od najvyššieho po najnižší):
 rezervovaný, musí byť 0
 nefragmentuj (ak je nastavený)
 viac fragmentov

Pole offsetu fragmentu je 13-bitov dlhé a umožňuje prijímateľovi zistiť umiestnenie jednotlivého fragmentu v originálnom IP datagrame. Meria sa v jednotkách 8-bajtových blokov.

8-bitové time to live (TTL) pole pomáha zamedziť blúdeniu paketov (cykleniu po rovnakej trase) v rámci siete. Z historického hľadiska bolo TTL pole obmedzené na životnosť v sekundách, ale stalo sa poľom počítadla skokov (hops). Každý switch (alebo router), ktorým paket prejde dekrementuje hodnotu TTL poľa o jednotku. Keď počítadlo TTL dosiahne nulu, paket sa ďalej nepreposiela, ale sa zahodí.

Nasleduje 8-bitové pole protokolu. Definuje protokol použitý v rámci dátovej časti IP datagramu. IANA udržiava zoznam čísel protokolov. Bežné protokoly s ich desiatkovými hodnotami sú ICMP (1), TCP (6) a UDP (17).

Nasledujúce pole je 16-bitový kontrolný súčet pre hlavičku IPv4 datagramu. Niektoré hodnoty v hlavičke sa môžu zmeniť po každom skoku paketu, takže kontrolný súčet musí byť po ceste prepočítavaný.

Po kontrolnom súčte nasleduje 32-bitová zdrojová adresa a 32-bitová cieľová adresa.

Dodatočné polia v hlavičke (voliteľné) môžu nasledovať za poľom cieľovej adresy, ale nie sú často používané. Všimnite si, že hodnota v poli IHL musí zahŕňať dodatočné 32 bitové polia, aby uložila všetky nepovinné polia (Plus zarovnanie potrebné na zabezpečenie, aby hlavička obsahovala celočíselný počet 32-bitových slov). Zoznam nepovinných polí môže byť ukončený poľom EOL (End of Options List) -- to je jediné potrebné na zamedzenie kolízie s koncom hlavičky.

Použitie volieb LSSR a SSRR (Loose and Strict Source and Record Route) sa neodporúča z bezpečnostných dôvodov; takéto pakety bývajú blokované routrami.

Fragmentácia a znovuzloženie 
IPv4 podporuje použitie sieťových prvkov (napr. point-point spojení) s podporou malých veľkostí paketov. Namiesto toho, aby vyžadoval fragmentáciu a znovuzloženie lokálne pre spojenie, čo by vyžadovalo, aby router na vzdialenom konci spojenia pozbieral oddelené kúsky a znovu zložil paket (komplikovaný proces, obzvlášť keď sa po ceste stráca množstvo paketov), router, ktorý objaví takýto paket príliš veľký na spracovanie ďalším spojením ho môže rozbiť na fragmenty (jednotlivé IP pakety, z ktorých každý nesie časť dát originálneho paketu) použitím štandardného postupu umožňujúceho znovuzložeanie originálneho paketu cieľovým strojom z fragmentov, ktoré oddelene prijme.

Keď sa veľký IPv4 paket rozdelí na menšie fragmenty (čo sa zvyčajne, ale nie vždy deje na routri v strede cesty paketu) všetky fragmenty sú normálnymi IP paketmi; t. j. majú plnú IPv4 hlavičku. Dátová časť originálneho paketu sa rozdelí na dostatočne malé časti, ktoré sa (po pridaní nepostrádateľnej hlavičky) zmestia do ďalšieho spojenia; jedna časť originálnych dát sa uloží do každého fragmentu. Takmer všetky polia hlavičky obsahujú rovnaké hodnoty ako v originálnom pakete. Predovšetkým majú všetky fragmenty rovnakú „identifikačnú“ hodnotu. Rozdiely sú:
 pole „celková dĺžka“ bude menšie; bude nastavené na veľkosť fragmentu
 bit „viac fragmentov“ bude nastavený v každom fragmente okrem posledného fragmentu
 pole „offset fragmentu“ bude nenulové vo všetkých okrem prvého fragmentu
Všimnite si, že každý paket prijatý cieľovým strojom ktorý má buď
 bit „viac fragmentov“ nastavený alebo
 pole „offset fragmentu“ nenulové
je fragmentom.
Stroj hľadá medzi prichádzajúcimi paketmi také, ktoré majú rovnakú hodnotu identifikačného poľa – tie patria do rovnakého originálneho paketu – a tie môže zložiť. Polia offset a celková dĺžka mu povedia kam ktorý fragment patrí a koľko z originálneho paketu zapĺňa. Vie zistiť celkovú dĺžku originálneho paketu pretože vo fragmente s vynulovaným bitom „viac fragmentov“ hodnota veľkosti poľa (samozrejme bez dĺžky IP hlavičky) plus hodnota v poli offsetu vynásobená 8-bajtovou veľkosťou fragmentačného poľa dáva veľkosť originálneho paketu.

Všimnite si, že router môže zopakovať proces fragmentácie iba ak má jediný fragment (napríklad ďalší router na ceste) – vezme fragment, rozdelí ho hore uvedeným spôsobom na dva alebo viac nových fragmentov a nastaví potrebné hodnoty offsetov a dĺžky. jediná komplikácia je, že ak bol bit „viac fragmentov nulový“, treba ho nastaviť vo všetkých okrem posledného paketu. (Je relatívne jednoduché zabezpečiť, aby router nemusel sledovať, či je paket fragmentom alebo úplným paketom.)

Tiež si všimnite, že ak je paket fragmentovaný a niektorý z fragmentov sa stratil, je znova odoslaný s rovnakým identifikačným číslom a táto druhá kópia je rovnako fragmentovaná (znova s potenciálom straty niektorých fragmentov). Takto je možné paketmi z druhej kópie zaplniť prázdne miesta pri skladaní originálneho paketu.

Pozri aj 
 Balík internetových protokolov
 Vyčerpanie adresného priestoru IPv4
 Zoznam známych portov
 IANA
 IPv6
 Internet Protocol

Ďalšie čítanie 
 RFC 791 – Internet Protocol
 RFC 3168 – Explicit congestion notification

Internetové protokoly
Internetové štandardy