| Piecu slāņu TCP/IP modelis |
|---|
| Lietojumslānis |
| Transporta slānis |
| Tīkla slānis |
| Datu posma slānis |
| Fizikālais slānis |
IPv4 jebInterneta protokols, versija 4 (angļu:Internet Protocol version 4)[1] irinterneta protokola 4. versija un pirmā tā plaši lietotā versija. IPv4 ir dominējošaistīkla slāņa protokolsinternetā. Otrs tīkla slāņa protokols, kuru lieto internetā, irIPv6. IPv4 ir definētsRFC 791 (1981 gada septembrī), aizvietojot iepriekšējā protokola aprakstuRFC 760 (1980 gada janvārī). IP negarantēpakešu nogādi līdz galam, paketes var pienākt sajauktā secībā, dublēties vai pazust. Šīs problēmas risinatransporta slāņa protokoli (TCP un daļējiUDP). 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.
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šaNAT 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.
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ē.
Sākotnēji IP adresi sadalīja 2 daļās:
Šā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:
D klasi bija paredzēts lietotmulticast vajadzībām,(D klases adreses tiek rezervētas grupām ar vairākpunktu adresāciju (saskaņā ar oficiālu dokumentuRFC 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 arCIDR 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. gadsimta 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 uzraugaIANA un tās apakšorganizācijas (Eiropai un tuvajiem austrumiem (arī Latvijai) šī organizācija ir RIPE), kas tālāk adreses iedala interneta provaideriem, kuri tālāk tās iedala atsevišķiem lietotājiem.
| CIDR adrešu bloks | Apraksts | attiecīgais rfc |
|---|---|---|
| 0.0.0.0/8 | Esošais tīkls (lietojams tikaisource 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 IPv4relay | 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 |
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.
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 atcilpaslocalhost 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.
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 veicDNS. 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.
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 un C 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:
Daļu no tiem var apvienot. 2007. gada maijā saskaņā ar dažādām prognozēm uzskatīja, ka IPv4 adreses izbeigsies kaut kad starp 2010. gada martu un maiju.
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 savienojumiem. UDP gadījumā no ārpuses ienākošās paketes pārsūta uz iekšējās adresessource 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.
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.
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 (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 izmantotIP 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ēloMAC 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.
IP pakete sastāv no divām daļām: galvenes (header) un datiem.
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 (tagadDiffServ unECN) | 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 | |||||||||||||||||||||||||||||||
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:
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 nolasadestination address un pēc tās izvēlas izejošo interfeisu. Katram tīkla interfeisam (parastitī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:
Piem. ja IP galvene ir 20 baiti un ethernet MTU ir 1500, tad fragmentuoffseti 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 | jā | 0 | |
| 20 | 2480 | |||
| 2 | 2040 | nē | 310 | |
| 20 | 2020 | |||
Ja nākamajā 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 | jā | 0 | |
| 20 | 1480 | |||
| 2 | 1020 | jā | 185 | |
| 20 | 1000 | |||
| 3 | 1500 | jā | 310 | |
| 20 | 1480 | |||
| 4 | 560 | nē | 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:
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.
|
