Ero sivun ”IPv4” versioiden välillä
Ei muokkausyhteenvetoa |
Ei muokkausyhteenvetoa |
||
Rivi 1: | Rivi 1: | ||
'''IPv4''' neljäs versio Internet Protokollasta (IP). Se on ensimmäinen versio Internet Protokollasta, joka on otettu laajemmassa mitassa käyttöön. Sen päälle rakentuu nykyinen [[Internet]]. | '''IPv4''' neljäs versio [[IP|Internet Protokollasta (IP)]]. Se on ensimmäinen versio Internet Protokollasta, joka on otettu laajemmassa mitassa käyttöön. Sen päälle rakentuu nykyinen [[Internet]]. | ||
Protokollan rakenne kuvaillaan [IETF:n|[IETF]] [[RFC:ssä|RFC]] 791, joka julkaistiin Syyskuussa 1981. | Protokollan rakenne kuvaillaan [IETF:n|[IETF]] [[RFC:ssä|RFC]] 791, joka julkaistiin Syyskuussa 1981. |
Versio 22. elokuuta 2005 kello 21.54
IPv4 neljäs versio Internet Protokollasta (IP). Se on ensimmäinen versio Internet Protokollasta, joka on otettu laajemmassa mitassa käyttöön. Sen päälle rakentuu nykyinen Internet.
Protokollan rakenne kuvaillaan [IETF:n|[IETF]] RFC 791, joka julkaistiin Syyskuussa 1981.
IPv4 käyttää 32-bittistä osoitteistusta, joka rajoittaa sen osoitemäärän 4.294.967.296 yksittäiseen osoitteeseen. Useat näistä osotteista on määritetty lähiverkko tai multicast osotteiksi, vähentäen julkisesti käytettävissä olevien osoitteiden määrää.
Internetin laajentuessa, osoitepula tulee pahenemaan tulevaisuudessa, kun vapaana olevien IPv4 osoitteiden määrä vähenee.
Osoitepulaa yritetään ratkaista ottamalla käyttöön seuraava versio Internet Protokollasta IPv6, jonka käyttöönotto on vasta alkuasteilla, mutta sen odotetaan korvaavan IPv4 tulevaisuudessa.
IPv4 osotteiden esitysmuodot
IPv4 osoitteet esitetään yleensä pisteytetyssä desimaalimuodossa. Esimerkiksi: 207.142.131.235. Osoitteet voidaan esittää myös muissa muodoissa:
Pisteytetty desimaali (normal) | 207.142.131.235 |
Pisteytetty heksa | 0xCF.0x8E.0x83.0xEB |
Pisteytetty oktaali | 0317.0216.0203.0353 |
Desimaali | 3482223595 |
Heksa | 0xCF8E83EB |
Ylläolevien osoitteiden pitäisi toimia melkein kaikissa selaimissa, ja osoite osoittaa wikipedia.org:iin.
IPv4 otsikkomuoto
+ | Bitit 0 - 3 | 4 - 7 | 8 - 15 | 16 - 18 | 19 - 31 | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | Versio | Otsikon pituus | Palveluluokka (nykyisin DiffServ and ECN) |
Kokonaispituus | ||||||||||||||||||||||||||||
32 | Tunniste | Liput | Fragmentointikohta | |||||||||||||||||||||||||||||
64 | Elinikä | Protokolla | Otsikon tarkistussumma | |||||||||||||||||||||||||||||
96 | Lähdeosoite | |||||||||||||||||||||||||||||||
128 | Kohdeosoite | |||||||||||||||||||||||||||||||
160 | Valinnat | Täyte | ||||||||||||||||||||||||||||||
192 | Datakenttä |
Ensimmäinen 4 bittiä pitkä kenttä IPv4 otsikossa ilmoittaa paketin versionumeron.
Toinen kenttä ilmoittaa paketin otsikon pituuden(IHL). Otsikon pituus kertoo montako 32-bittistä kenttää otsikossa on. IPv4 otsikko voi sisältää vaihtelevan määrän valintoja, joten tällä kentällä ilmoitetaan kohta josta data alkaa paketissa. Kentän arvo on otsikon pituus jaettuna 32:lla, maksimiarvo on 15 ja minimiarvo 5.
RFC 791 dokumentissa määritettiin seuraavat 8 bittiä palvelutyyppi (ToS) kentälle. Nykyisin DiffServ and ECN. Alkuperäinen tarkoitus oli määritellä kuinka pakettia käsitellään matkalla internetin läpi. Kentän arvolla voitiin määritellä joko matalalatenssinen siirto tai korkea luotettavuus, ToS kenttää ei kuitenkaan otettu yleisesti käyttöön verkoissa. Tämän kentän merkitystä on määritelty uudelleen DiffServin ja Ruuhkan tunnistuksen käyttöön (tarkemmin RFC 3168). Reaaliaikaiset protokollat, kuten VoIP hyödyntävät ToS kenttää datansiirrossa.
Seuraava 16-bittiä pitkä kenttä määrittelee koko paketin koon. Minimipituus paketille on 20 tavua ja maksimipituus 65535. Minimikoko paketille, jonka mikä tahansa laite pitää osata käsitellä, on 576 tavua, mutta nykyiset laitteet osaavat käsitellä paljon suurempia paketteja. Joskus aliverkot asettavat tarkempia määrityksiä siirrettävien pakettien koolle, jolloin suurempia paketteja pitää fragmentoida. Fragmentointi tapahtuu joko työasemalla tai kytkimellä.
Seuraava 16-bittinen kenttä on Tunniste. Tällä kentällä kuvataan mikä fragmentti kuuluu mihinkin alkuperäiseen pakettiin. Tunniste kenttää on ehdotettu myös käytettäväksi pakettien alkuperän varmenteena, jolloin kentällä voitaisiin ehkäistä pakettien lähdeosoitteen väärentäminen.
Seuraavaa 3-bittistä kenttää käytetään tunnistamaan ja hallitsemaan fragmentteja. Kentän mahdolliset arvot ovat:
- Varattu, arvo 0
- Älä fragmentoi (jos asetettu)
- Lisää fragmentteja tulossa.
Fragmentointikohta on 13 bittiä pitkä kenttä, jolla vastaanottaja voi määritellä fragmentin paikan alkuperäisessä paketissa. Kohta ilmaistaan 64-bitin jaksoissa.
8-bittiä pitkä elinikä (TTL) kenttä estää pakettien jäämisen verkkoon ikuisesti. Ennen TTL kentällä määritettiin paketin elinikä sekunneissa, mutta nykyisin se kuvaa montako hyppyä paketti voi tehdä reitittimeltä toiselle siirryttäessä. Kun elinikä kentän arvoksi muuttuu 0, sitä ei enää välitetä.
8-bittiä pitkä protokolla-kenttä määrittelee mitä protokollaa käytetään IP paketin data osiossa. IANA ylläpitää listaa määritellyistä protokollanumeroista. Yleisiä protokollia ja niiden vastaavia desimaaliarvoja ovat esim. ICMP (1), TCP (6), UDP (17) ja IPv6 (41).
16-bittiä pitkä tarkistussumma lasketaan IPv4 paketin otsikosta. Jotkut arvot muuttuvat paketin siirtyessä verkossa, joten tarkistussumma lasketaan joka laitteella uudelleen paketin edetessä verkossa.
Seuraavat kentät ovat lähde ja kohdeosoite, molemmat pituudeltaan 32-bittiä.
Kohdeosoitetta voi seurata valintakenttä, mutta sen käyttö on harvinaista. IHL kentän arvon pitää kattaa valintojen tarvitsema datamäärä sekä mahdollinen täyte, mikäli valinnat eivät vie täyttä 32 bittiä. Valinnat voidaan päättää EOL valinnalla.
LSSR ja SSRR valintojen käyttöä ei suositella, koska ne voivat muodostaa tietoturvariskejä, ja useimmat reitittimet estävät paketit joissa ne on määritelty.
Fragmentointi ja uudelleenjärjestely
IPv4 mahdollistaa pakettien pilkkomisen pienempiin osiin, mikäli siirrossa käytettävä välityskerros ei salli suurimman mahdollisen pakettikoon käyttöä. Paketin siirtyessä verkkoon, jossa MTU on pienempi kuin lähettävässä verkossa, paketti fragmentoidaan pienempiin osiin, jotka voidaan lähettää verkon yli. Paketit uudelleenjärjestetään kohdekoneella ehjiksi kun kaikki palaset ovat saapuneet perille.
Kun suuri paketti pilkotaan pieniin palasiin, yleensä reitittimessä koneiden välillä, kaikki palaset säilyttävät IPv4 rakenteen. Niillä on täydelliset otsaketiedot, mutta paketin data pilkotaan niin pieneksi ettei se ylitä verkon MTU arvoa. Palaseen sisällytetään tunnistetietoina sama ID joka on muilla samaan ehjään pakettiin kuuluvilla osilla. Erona ehjään pakettiin on:
- Paketin kokonaispituus, palasella pienempi, kertoo palasen koon, ei koko paketin kokoa.
- Lisää palasia-lippu, on määritetty arvoon 1 kaikilla paitsi viimeisellä paketilla.
- Fragmentointikohta, muuta kuin nolla muilla kuin ensimmäisellä paketilla.
Kohdekoneella, mikäli sisääntulevalla paketilla:
- Lisää palasia lippu asetettuna tai
- Fragmentointikohta on muuta kuin nolla
niin paketti on fragmentti suuremmasta paketista.
Jotta palasista voidaan kasata ehjä paketti kohdekoneella, se etsii sisääntulevista paketeista samalla tunnisteella olevat. Fragmentointikohta ja kokonaispituus kenttien perusteella nähdään minne mikäkin paketti kuuluu, ja kuinka paljon se täydentää alkuperäistä pakettia. Kohdekone voi laskea alkuperäisen paketin kokonaispituuden siitä paketista, missä lisää palasia-lippu on asetettu nollaksi. Kyseisen paketin pituus-headerin koko, kerrottuna fragmentointikohdalla(kerrottuna 8-bittisellä fragmenttiosan koolla), antaa alkuperäisen paketin koon.
Reitittimet voivat fragmentoida paketin uudelleen vaikka niillä olisi vain yksi fragmentti alkuperäisestä paketista. Paloittelu tapahtuu vain toisen kerran noudattaen samaa järjestelmää. Ongelmana on vain Lisää palasia-lippu, sen pitää olla päällä kaikissa paitsi viimeisessä uusista fragmenteista. (Reitittimen ei yleensä tarvitse tietää paloitteleeko se olemassa olevaa fragmenttia vai kokonaista pakettia)
Jos paketti on fragmentoitu, ja osa palasista hukkuu siirrossa, uudelleenlähetetyn samalla tunnisteella paloitellun paketin palasilla voidaan täydentää alussa saatua dataa.
Katso myös
Lisälukemistoa
- RFC 791 - Internet Protocol
- RFC 3168 - Explicit congestion notification
Ulkoiset linkit
Lähde
Suomennettu mukaillen Wikipediasta