IPv4
Vikipēdijas raksts
Piecu slāņu TCP/IP modelis |
5. Lietojuma slānis |
DHCP • DNS • FTP • HTTP • IMAP4 • IRC • MIME • POP3 • SIP • SMTP • SNMP • SSH • TELNET • BGP • RPC • RTP • RTCP • TLS/SSL • SDP • SOAP • L2TP • PPTP • … |
4. Transporta slānis |
3. Tīkla slānis |
IP (IPv4 • IPv6) • ARP • RARP • ICMP • IGMP • RSVP • IPSec • … |
2. Kanāla slānis |
1. Fizikālais slānis |
Ethernet physical layer • ISDN • Modemi • PLC • RS232 • SONET/SDH • G.709 • Wi-Fi • … |
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.
Satura rādītājs |
[izmainīt šo sadaļu] Adresācija
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.
[izmainīt šo sadaļu] Adrešu attēlojums
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ē.
[izmainīt šo sadaļu] Iedalījums (allocation)
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ā;
- B - 16 biti tīkla adrese un 16 biti datora adrese, iespējami ~65500 tīkli ar ~65500 datoriem katrā;
- C - 24 biti tīkla adrese un 8 biti datora adrese, iespējami ~16 miljoni tīkli ar 256 datoriem katrā.
D klasi bija paredzēts lietot multicast vajadzībām, 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.
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 |
[izmainīt šo sadaļu] Privātie tīkli
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.
[izmainīt šo sadaļu] Localhost
- 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 localhost komunikācijām. Šī adresēm nevajadžetu 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.
[izmainīt šo sadaļu] Domēnu vārdu sistēma
- 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, tapēc nepieciešams pārveidot vārdus par IP adresēm. To veic DNS. Līdzīgi 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.
[izmainīt šo sadaļu] IP adrešu izbeigšanās
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.
[izmainīt šo sadaļu] NAT
- Galvenais raksts NAT
Viena no metodēm, kā uzlabot esošo adrešu lietošanas efektivitāti un drošību (uz šā un tā rēķina) 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.
[izmainīt šo sadaļu] Virtuālie privātie tīkli
Interneta maršrutētāji ignorē privātās adreses, tapē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.
[izmainīt šo sadaļu] ARP
- 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.
[izmainīt šo sadaļu] RARP/DHCP
- Galvenais raksts DHCP
RARP (reverse address resolution protocol) bija protokols, kas darbojās pretējā virzienā kā ARP. 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.
[izmainīt šo sadaļu] Pakešu struktūra
IP pakete sastāv no divām daļām: galvenes (header) un datiem.
[izmainīt šo sadaļu] Galvene
Galvene (header) sastāv no 13 laukiem, no kuruem 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, tapē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, tapē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.
[izmainīt šo sadaļu] 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:
[izmainīt šo sadaļu] Fragmentācija
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 | jā | 0 | |
20 | 2480 | |||
2 | 2040 | nē | 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 | 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:
- 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.