IPv4

Vikipēdijas lapa
Pārlēkt uz: navigācija, meklēt

IPv4 (interneta protokols versija 4) ir interneta protokola 4. versija un pirmā tā plaši lietotā versija. IPv4 ir dominējošais tīkla slāņa protokols internetā. Otrs tīkla slāņa protokols, kuru lieto internetā, ir IPv6. IPv4 ir definēts rfc760 1981. gadā. IP negarantē pakešu nogādi līdz galam, paketes var pienākt sajauktā secībā, dublēties vai pazust. Šīs problēmas risina transporta slāņa protokoli (TCP un daļēji UDP). Galvenā IP funkcija ir nodrošināt unikālu globālu datoru adresāciju, lai nodrošinātu, ka divi datori, kas sazinās caur internetu varētu viennozīmīgi identificēt viens otru.

Adresācija[labot šo sadaļu | labot pirmkodu]

IPv4 lieto 32 bitu (4 baitu) garas adreses, kas nozīmē to, ka adresācijas telpā ir 4 294 967 296 unikālas adreses. Daļa no šīm adresēm ir rezervētas īpašiem mērķiem (privātiem tīkliem (~18 miljoni), multicast (~1 miljons)). Tas samazina lietojamo adrešu skaitu. Tā, kā pieejamo adrešu skaits samazinās, tās kaut kad beigsies. Plaša NAT izplatība, gan šo laiku ir nobīdījusi tālāk. Šis ierobežojums bija viens no galvenajiem iemesliem IPv6 izstrādes sākšanai.

Adrešu attēlojums[labot šo sadaļu | labot pirmkodu]

Parasti IPv4 adreses (IP adreses) norāda formā a.b.c.d, kur a, b, c, d - skaitļi robežās no 0 līdz 255. Tā, kā adrese būtībā ir 32 bitu skaitlis, to var norādīt arī vienā gabalā. Šādu formātu parasti lieto programmu iekšienē.

Iedalījums (allocation)[labot šo sadaļu | labot pirmkodu]

Sākotnēji IP adresi sadalīja 2 daļās:

  • Tīkla adrese (Network id) - pirmie 8 biti
  • Datora adrese (Host id) - pēdējie 24 biti

Šādā veidā bija iespējami tikai 256 neatkarīgi tīkli un ātri bija skaidrs, ka tas ir par maz.

Pēc tam nodefinēja vairākas tīklu klases ar dažādiem tīkla adreses (un attiecīgi datora adreses) garumiem. Tika nodefinētas 5 klases (A, B, C, D un E), no kurām reāli lietojamas bija pirmās 3:

  • A - 8biti tīkla adrese un 24 biti datora adrese, iespējami 256 tīkli ar ~16 miljoniem datoru katrā;(A klases adreses galvenokārt ir paredzēti izmantošanai ar vairākiem ļoti lieliem tīkliem, jo tie nodrošina tikai 7 bitus tīkla adreses laukam)
  • B - 16 biti tīkla adrese un 16 biti datora adrese, iespējami ~65500 tīkli ar ~65500 datoriem katrā;(B klases adreses izdala 14 bitus tīkla adreses laukam un 16 bitus resursdatora adreses laukam. Šī adrešu klase nodrošina labu kompromisu starp tīkla un resursdatora adreses telpu.)
  • C - 24 biti tīkla adrese un 8 biti datora adrese, iespējami ~16 miljoni tīkli ar 256 datoriem katrā.(C klases adreses izdala 22 bitus tīkla adreses laukam. Taču C klases adreses nodrošina tikai 8 bitus resursdatora adreses laukam, tāpēc resursdatoru skaits vienā tīklā var kļūt par ierobežojošu faktoru.)

D klasi bija paredzēts lietot multicast vajadzībām,(D klases adreses tiek rezervētas grupām ar vairākpunktu adresāciju (saskaņā ar oficiālu dokumentu RFC 1112). D klases adresēs četri augstākās kārtas biti tiek uzstādīti uz vērtībām 1,1,1 un 0.) un E klase bija rezervēta. Šī metode arī ar laiku vairs nebija optimāla, jo bija iespējami tikai šie 3 tīklu izmēri, piem. ja bija jāpieslēdz datortīklu ar 70000 datoriem, nācās ņemt A klases tīklu un vairāk kā 99,5 % adrešu atstāt neizmantotas un neizmantojamas citiem.

Ap 1993. gadu šīs 3 klases aizstāja ar CIDR shēmu, kur galvenā atšķirība ir tāda, ka tīkla adrese un datora adrese var būt ar jebkādu garumu (32 bitu robežās). Šī metode ļauj sadalīt A, B un C klases tīklus mazākos tīklos un samazināt adrešu zudumus. To ieviesa tāpēc, ka lietojot A un B klases tīklus, adreses sāka beigties jau 20. gs. 90. gadu sākumā. CIDR tīkla adreses bieži vien norāda formātā a.b.c.d/n, kur n ir bitu skaits tīkla adresē, jo n ir mazāks, jo lielāks tīkls. Tīklā lietojamās datoru adreses sākas no norādītā skaitļa (piem. 192.168.122.0/23 tīklā datoriem var būt adreses no 192.168.122.0 (reāli 1) līdz 192.168.123.255 (reāli 254)). Operētājsistēmām parasti norāda IP adresi un tīkla masku (subnet mask), kur tīkla maska ir tādā pašā formātā kā IP adrese, tikai visi tīkla adreses daļas biti ir 1. Iepriekšapskatītajā piemērā tīkla maska būtu 255.255.128.0

Adrešu iedalījums nav patvaļīgs jo adreses satur maršrutēšanas informāciju (routing), par datora atrašanās vietu tīklā. Internetā lietotās IP adreses iedala un iedalījumu uzrauga IANA un tās apakšorganizācijas (Eiropai un tuvajiem austrumiem (arī Latvijai) šī organizācija ir RIPE), kas tālak adreses iedala interneta provaideriem, kuri tālāk tās iedala atsevišķiem lietotājiem.

Rezervētie IP adrešu bloki
CIDR adrešu bloks Apraksts attiecīgais rfc
0.0.0.0/8 Esošais tīkls (lietojams tikai source adresēs) RFC 1700
10.0.0.0/8 Privātie tīkli RFC 1918
14.0.0.0/8 Public data networks RFC 1700
127.0.0.0/8 localhost RFC 3330
128.0.0.0/16 Rezervēti (IANA) RFC 3330
169.254.0.0/16 zeroconf RFC 3927
172.16.0.0/12 Privātie tīkli RFC 1918
191.255.0.0/16 Rezervēti (IANA) RFC 3330
192.0.0.0/24 Rezervēti (IANA) RFC 3330
192.0.2.0/24 Dokumentācijai un piemēriem RFC 3330
192.88.99.0/24 IPv6 uz IPv4 relay RFC 3068
192.168.0.0/16 Privātie tīkli RFC 1918
198.18.0.0/15 Network benchmark tests RFC 2544
223.255.255.0/24 Rezervēti (IANA) RFC 3330
224.0.0.0/4 Multicast (Bijušais D klases tīkls) RFC 3171
240.0.0.0/4 Rezervēti (Bijušais E klases tīkls) RFC 1700
255.255.255.255 Broadcast

Privātie tīkli[labot šo sadaļu | labot pirmkodu]

No visām iespējamajām IPv4 adresēm 4 apglabali ir rezervēti privātajiem tīkliem. Šie apgabali nav tieši maršrutējami ārpus attiecīgā tīkla un tie datori nevar tieši sazināties ar internetu (bet caur NAT var).

Nosaukums IP adrešu apgabals IP adrešu skaits klases apraksts lielākais CIDR bloks
24-bitu bloks 10.0.0.0 — 10.255.255.255 16 777 216 1 A klases bloks 10.0.0.0/8
20-bitu bloks 172.16.0.0 — 172.31.255.255 1 048 576 16 secīgi B klases bloki 172.16.0.0/12
16-bitu bloks 192.168.0.0 — 192.168.255.255 65 536 1 B klases bloks 192.168.0.0/16
16-bitu bloks 169.254.0.0 — 169.254.255.255 65 536 1 B klases bloks 169.254.0.0/16

No šajiem te 169.254.0.0/16 bloku lieto arī zeroconf vajadzībām, tas ir ja datoram nav norādīta IP adrese un tas nespēj sazināties ar DHCP serveri, tiek paņemta nejauša adrese no šī bloka. Windowā zeroconf ir pieejams sākot ar windows 2000.

Atcilpa (Localhost)[labot šo sadaļu | labot pirmkodu]

Galvenais raksts localhost

Papildus privātajiem tīkliem, IP adrešu apgabals 127.0.0.0 — 127.255.255.255 (127.0.0.0/8) ir rezervēts atcilpas localhost komunikācijām. Šī adresēm nevajadzētu parādīties nevienā reālā tīklā un IP paketēm, kas nosūtītas uz kādu no šīm adresēm nevajadzētu pamest datoru, no kura tās nosūtītas.

Domēnu vārdu sistēma[labot šo sadaļu | labot pirmkodu]

Galvenais raksts DNS (protokols)

Lielāko daļu adrešu internetā pazīst nevis pēc to cipariskajām IP adresēm, bet gan pēc domēnu vārdiem (lv.wikipedia.org, www.draugiem.lv). IP adrešu maršrutizācija caur tīklu nav saistīta ar šiem vārdiem, tāpēc nepieciešams pārveidot vārdus par IP adresēm. To veic DNS. Tāpat kā CIDR adresācija, DNS arī ir hierarhisks. Eksistē arī reversīvais DNS, kas no dotās IP adreses mēģina iegūt tai atbilstošo domēna vārdu, taču tas bieži vien nedarbojas.

IP adrešu izbeigšanās[labot šo sadaļu | labot pirmkodu]

Sākotnējās IP adrešu iedalīšanas shēmas bija visai neefektīvas (taču tur varēja lietot primitīvus maršrutētājus (router), jo varēja iztikt ar maziem daudzumiem atmiņas. Augot internetam adreses sāka beigties. Sākumā ieviesa klašu tīklus (A, B unC klases tīkli), bet tas ilgi nepalīdzēja un nācās iet vēl tālāk un ieviest CIDR. Šis progress palielināja prasības galveno rūteru atmiņas ietilpībai. Tā, kā interneta lietotāju (pieslēgumu) skaits pieaug un palielinās pastāvīgo pieslēgumu skaits (kur IP adrese ir aizņemta 24/7/356), brīvo IP adrešu skaits samazinās.

Galīgais risinājums šai problēmai droši vien būs pilnīga pāreja uz IPv6, jo tur ir garākas adreses. Vēl dažas lietas, kas novilcina IPv4 adrešu izbeigšanos ir:

  • NAT
  • DHCP
  • Privāto tīklu lietošana
  • Uz domēnu vārdiem bāzēts virtuālais hostings (serveriem (no vienas IP adreses atver dažādas interneta lapas, atkarībā no lietotā DNS vārda))
  • Stingrāka IP adrešu iedalīšnas kontrole

Daļu no tiem var apvienot. 2007. gada maijā saskaņā ar dažādām prognnozēm uzskatīja, ka IPv4 adreses izbeigsies kaut kad starp 2010. gada martu un maiju.

NAT[labot šo sadaļu | labot pirmkodu]

Galvenais raksts NAT

Viena no metodēm, kā uzlabot esošo adrešu lietošanas efektivitāti un drošību ir lietot NAT (network address translation). Šajā gadījumā vienu ārējo adresi uzliek rūterim un iekšējā tīklā lieto privātās adreses. NAT pārraksta izejošo un ienākošo IP pakešu headerus (adreses un portus). TCP gadījumā NAT seko līdzi konnekcijām. UDP gadījumā no ārpuses ienākošās paketes pārsūta uz iekšējās adreses source portu. NAT, pēc definīcijas, bloķē visas ienākošās komunikācijas. Ja augšējā līmeņa protokols IP adrešu datus ievieto paketes datu apgabalā, NAT vai nu nedarbojas, vai arī tam vajag protokola specifisku paplašinājumu.

Virtuālie privātie tīkli[labot šo sadaļu | labot pirmkodu]

Interneta maršrutētāji ignorē privātās adreses, tāpēc lai savienotu tīklus, kas lieto šādas adreses lieto VPN (virtual private network).

VPN ievieto pārsūtāmā tīkla paketi ārējā tīkla paketē kā datus. VPN var lietot ne tikai IP, bet arī jebkuru tīkla slāņa protokolu. Pirms ievietošanas (enkapsulācijas), datu paketi var nošifrēt. Otrā galā pēc tam izvelk sākotnējo paketi. Parasti VPN darbojas caur UDP vai GRE protokoliem.

ARP[labot šo sadaļu | labot pirmkodu]

Galvenias raksts ARP

IP ir tīkla slāņa protokols. Tā sasaisti ar kanāla slāņa adresēm nodrošina ARP (address resolution protocol) protokols. ARP iegūst datus par attālināto sistēmu MAC adresēm zinot IP adreses.

RARP/DHCP[labot šo sadaļu | labot pirmkodu]

Galvenais raksts DHCP

RARP (reverse address resolution protocol) bija protokols, kas darbojās pretējā virzienā kā ARP. RARP - (Reversais adreses noteikšanas protokols), kuri dinamiski nosaka fizikālo (aparatūras) adrešu atbilstību IP adresēm un otrādi. ARP izmanto apraides paziņojumus aparatūras adreses noteikšanai (MAC slānis), kura atbilst konkrētai IP tīkla slāņa adresei. ARP protokolam ir pietiekoši universāls, lai ļautu izmantot IP ar praktiski jebkuru vides pieejas mehānisma tipu. RARP izmanto apraides paziņojumus IP adreses noteikšanai, kura saistīta ar konkrēto aparatūras adresi. RARP ir īpaši nozīmīgs mezgliem, kuriem nav diska un kuri var nezināt savu IP adresi, kad tie tiek sākotnēji iedarbināti. RARP paļaujas uz RARP servera esamību ar tabulas ierakstiem, kuri attēlo MAC apakšslāņa adreses IP adresēs. Vēlāk tika izstrādāta funkcionāli paplašināta jaunāka versija DHCP (dynamic host configuration protocol). Šie visi protokoli iegūst esošās sistēmas IP adresi (kura līdz tam nav zināma), zinot tās MAC adresi. DHCP galvenokārt lieto lai datoriem nebūtu IP adreses jānorāda katram atsevišķi.

Pakešu struktūra[labot šo sadaļu | labot pirmkodu]

IP pakete sastāv no divām daļām: galvenes (header) un datiem.

Galvene[labot šo sadaļu | labot pirmkodu]

Galvene (header) sastāv no 13 laukiem, no kuriem 12 ir obligāti.

+ Bits 0—3 4—7 8—15 16—18 19—31
0 Versija Galvenes garums Type of Service
(tagad DiffServ un ECN)
Kopējais garums
32 Identification Flags Fragment Offset
64 Time to Live Protokols Galvenes kontrolsumma
96 Source Address
128 Destination Address
160 Options
160
vai
192+
 
Dati
 
  • Versija - pirmais headera lauks IP paketē satur datus par protokola versiju. IPv4 gadījumā tā lauka vērtība vienmēr ir 4.
  • Galvenes garums (internet header length (IHL)) - Šis lauks apraksta 32 bitu vārdu skaitu galvenē (header). Minimālais garums ir 5 (pirmie 12 lauki aizņem 5*32=160 bitus). Options lauka garums var būt mainīgs. Šis ir 4 bitu lauks un tā maksimālā vērtība var būt 15, tāpēc galvenes (header) maksimālais garums var būt 480 biti
  • type of service (TOS) - sākotnējā variantā šis lauks bija paredzēts lai noteiktu vai vai svarīgāk ir paketi nosūtīt pēc iespējas ātrāk (low delay) vai arī pēc iespējas drošāk (high reliability), ja ir izvēle. Rūteri lielākoties šo lauku ignorē. Ir bijuši mēģinājumi šo lauku lietot citiem mērķiem (Diffserv un ECN). Diffserv ir apmēram analoga funkcionalitāte sākotnējam mērķim. ECN dažreiz lieto lai noteiktu savienojuma caurlaidību, ja abi galapunkti to atbalsta. (kaut kas līdzīgs ir iebūvēts jau TCP) Šīs tehnoloģijas jebkurā gadījumā netiek plaši lietotas.
  • Kopējais garums - šis 16 bitu lauks definē visas paketes izmēru (baitos). Minimālais paketes izmērs ir 20 baiti (pirmie 12 galvenes (header) lauki). Datoriem ir jāspēj saņemt vismaz 576 baitus garas paketes, parasti var vairāk. Maksimālais paketes izmērs var būt 65535 baiti. Bieži vien apakšējā līmeņa protokoli izvirza tālākas prasības maksimālajam paketes izmēram un paketi ir jāfragmentē. (piem. ethernet paketes izmērs ir 1500 baiti).
  • Identification - šis lauks viennozīmīgi identificē paketi. To galvenokārt lieto lai identificētu fragmentētas paketes fragmentus. (tiem tas būs vienāds)
  • Flags - tas ir 3 bitu lauks, kuru lieto lai kontrolētu fragmentāciju, šo bitu funkcijas ir:
    • Rezervēts, tam jābūt 0.
    • Nefragmentēt (don't fragment)(DF)
    • Vēl ir fragmenti (more fragments)(MF)
Ja DF ir aktīvs un paketei ir nepieciešama fragmentācija, lai to varētu pārsūtīt tālāk, paketi izmet un atpakaļ aizsūta kļūdas paziņojumu. Šo lieto lai sūtītu paketes uz datoriem, kas nespēj sagremot fragmentāciju (lielākoties boot rom, lādējot operētājsistēmu no tīkla)
Ja MF ir aktīvs, tad tas nozīmē ka pakete ir bijusi fragmentēta un šis nav pēdējais fragments. Nefragmentēta pakete vienmēr ir pēdējais fragments, tāpēc tai MF nav aktīvs.
  • Fragment offset - fragmentētām paketēm šis lauks satur informāciju par paketes sākuma attālumu (blokos pa 8 baitiem) no nefragmentētās paketes sākuma.
  • Time to live (TTL) - 8 bitu lauks lai novērstu bezgalīgu pakešu cirkulāciju tīklos, ja kādā vietā nobrūk maršrutizācija. Sākotnēji šis lauks limitēja paketes dzīves laiku sekundēs, taču vēlāk sāka lietot hop count. Katrs routeris, kam pakete iet cauri, samazina šī lauka vērtību par 1. Rūteris, kurā TTL sasniedz 0, paketi izmet. Traceroute (tracert) bāzējas uz šī lauka palielināšanu, sākot no 1, kamēr sasniedz otru galu, un attēlotie dati sastāv no saņemtajiem kļūdas ziņojumiem.
  • Protokols - šis lauks definē datu daļā ievietoto transporta slāņa protokolu. Šis ir 8 bitu lauks.
  • Galvenes kontrolsumma - šo 16 bitu lauku lieto lai pārbaudītu vai galvene (header) nav izmainījusies pārsūtīšanas laikā. Ja kontrolsumma neatbilst, paketi izmet. Datu atbilstību pārbauda attiecīgie transporta slāņa protokoli. Tā, kā katrā rūterī mainās TTL un ir iespējama fragmentācija, šo lauku nākas pārrēķināt katrā rūterī.
  • Source address - nosūtītāja IP adrese. Ja paketi nākas izmest, uz turieni nosūta kļūdas paziņojumu. Šī var nebūt nosūtītāja adrese, ja lieto NAT.
  • Destination address - saņēmēja IP adrese. Uz turieni paketi mēģina piegādāt.
  • Options - šo lauku lieto ļoti reti.

Dati[labot šo sadaļu | labot pirmkodu]

Datu daļa nav daļa no galvenes (header) un tai neaprēķina IP kontrolsummu. Datu daļas saturs var būt jebkurš transporta slāņa protokols, tas ir norādīts galvenes protokola laukā. Daži izplatītākie protokoli (un tiem atbilstošie numuri, kurus lieto protokola laukā) ir:

Fragmentācija[labot šo sadaļu | labot pirmkodu]

Lai IP labāk darbotos heterogēnos tīklos (ar dažādiem MTU (maximum transmission unit)), tam pielika fragmentāciju. Fragmentācija ir vajadzīga, kad paketes izmērs ir lielāks par lietojamā tīkla MTU. Piem. ethernet MTU parasti ir 1500 baiti, IP galvene (header) aizņem 20 baitus, IP datiem atstājot 1480 baitus, šādā veidā maksimālā izmēra IP paketei (65535 baiti datu) vajag 45 paketes (65535/1480 = 44,28). Tīkla slānī fragmentācija ir efektīvāka kā augšējo un apakšējo līmeņu slāņos.

Kad ierīce (rūteris) saņem IP paketi pārsūtīšanai tālāk, tas nolasa destination address un pēc tās izvēlas izejošo interfeisu. Katram tīkla interfeisam (parasti tīkla karte, bet var būt arī PPP interfeisi) ir zināms tā MTU, kas nosaka maksimālo vienā piegājienā nosūtāmo datu izmēru. Ja MTU ir mazāks kā ienākošā pakete, paketi ir jāfragmentē. Rūteris pēc tam sadala ienākošos datus paketēs, kur katra ir vienāda vai mazāka par izejošā interfeisa MTU (kopā ar galveni). Katru segmentu tad ieliek atsevišķā paketē, ar sekojošām izmaiņām:

  • Kopējā garuma laukā ieliek attiecīgā segmenta garumu,
  • MF (more fragments) flagu uzliek uz 1 visiem segmentiem, izņemot pēdējo,
  • Norāda fragment offsetu, atbilstoši segmenta sākuma attālumam no sākotnējās paketes sākuma.

Piem. ja IP galvene ir 20 baiti un ethernet MTU ir 1500, tad fragmentu offseti būs 0, (1480/8) = 185, 2960/8) = 370, (4440/8) = 555, (5920/8) = 740, utt. Ja MTU-galvenes garums nedalās ar 8, tad paketes izmērs var būt mazāks par MTU. (šie zudumi ir 4 baiti vai mazāk).

Ja kādā no tālākajiem rūteriem MTU (maximum transmission unit) samazinās vēl vairāk, fragmentus nākas fragmentēt vēl tālāk. Fragmentus savieno kopā tikai beigās, saņēmēja datorā. Fragmentācija parasti notiek rūteros pa ceļam, lai arī ar dažiem protokoliem (ICMP) var notikt jau nosūtītāja datorā.

Piem. ja 4500 baitus datu ievieto vienkāršā IP paketē (kopējais garums (dati + galvene) 4520) un pārsūta caur savienojumu ar MTU 2500, tad to safragmentēs 2 fragmentos:

# Kopējais garums More fragments (MF)
aktīvs?
Fragmenta offsets
Galvene Dati
1 2500 0
20 2480
2 2040 310
20 2020

Ja nākošajā rūterī MTU samazināsies līdz 1500, katru fragmentu būs jāsadala vēl 2 gabalos:

# Kopējais garums More fragments (MF)
aktīvs?
Fragmenta offsets
Galvene Dati
1 1500 0
20 1480
2 1020 185
20 1000
3 1500 310
20 1480
4 560 495
20 540

Kopējais datu daudzums nemainās: 1480 + 1000 + 1480 + 540 = 4500 un pēdējais fragments + offsets 3960 + 540 = 4500 ir arī kopējais garums. 3. un 4. fragments šeit tikai iegūti no sākotnējā 2. fragmenta. Tad, kad routerim ir jāfragmentē pēdējo fragmentu, tas uzliek MF aktīvi visiem fragmentiem, izņemot pēdējo (šajā gadījumā 3.) (fragmentējot jebkuru iepriekšējo fragmentu, tie jau visiem ir MF aktīvs).

Kad saņēmējdators saņem IP paketi, kurai ir spēkā jebkurš no šiem kritērijiem:

  • MF ir aktīvs
  • fragment offset lauks nav 0

tad saņēmējs zin, ka pakete ir fragments. Saņēmējs tad saglabā datus ar identifikācijas lauku, fragment offset un aktīvu MF. Kad saņēmējs saņem fragmentu bez aktīva MF, ir zināms sākotnējās paketes garums. (fragment offset + data length). Tad, kad ir pieejami visi fragmenti, datus var sakārtot sākotnējā secībā un pakete ir saņemta veiksmīgi.