IPv4

Fra Wikipedia, den frie encyklopedi

IPv4 (Internet Protocol version 4) er versjon 4 av Internett-protokollen og var den første versjonen som oppnådde vidstrakt bruk. IPv4 opererer på nettverkslaget i OSI-modellen for datanett og er en forbindelsesløs og upålitlig pakkeleveringstjeneste.

IPv4 er spesifisert i IETF RFC 791, som ble publisert i september 1981.

IPv4 bruker 32-bit adresser, som begrenser antall unike adresser til 4 294 967 296. En del av disse adressene er reservert for spesielle foremål som lokale nettverk eller multicast-adresser, noe som reduserer antall adresser som kan tildeles vanlig bruk.

Etterhvert har store deler av de tilgjengelige adressene blitt delt ut til ulike organisasjoner, og det har ført til en mangel på IP-adresser. Mangelen på adresser er noe av motivasjonen bak neste versjon av IP protokollen, IPv6.

Innhold 1 IPv4 adresse-representasjoner 2 IPv4 hode-format 3 Fragmentering og sammensetting 4 Referanser 5 Eksterne lenker

[rediger] IPv4 adresse-representasjoner

IPv4 adresser skrives vanligvis i dotted decimal notasjon. Her er et eksempel: 207.142.131.235. Det er også mulig å uttrykke adressene på følgende måter:

Dotted Decimal (normal)	207.142.131.235
Dotted Hexadecimal	0xCF.0x8E.0x83.0xEB
Dotted Octal	0317.0216.0203.0353
Decimal	3482223595
Hexadecimal	0xCF8E83EB

Adressene ovenfor skal fungere i de fleste nettlesere og peker til wikipedia.org.

[rediger] IPv4 hode-format

Som vist i figuren til høyre er det første feltet i IPv4-hodet version feltet som er på 4 bit. Dette feltet viser hvilken versjon av IP-protokollen det er snakk om.

Videre følger Internet header length (IHL) som også er på 4 bit. Dette feltet inneholder lengda på IPv4-hodet i 32-bits ord. Som vist i figuren over så har IPv4 et valgfritt opsjonsfelt, Options. Dette feltet kan inneholde et variabelt antall opsjoner, noe som fører til at lengda på IPv4 hodet kan variere. IHL-feltet fungerer derfor som en peker til begynnelsen av nyttelasta i ip-pakka. Minimum Ipv4 hodelengde er på 20 tegn, så minimum verdien uttrykt i 32-bits ord i IHL feltet er 5. Hvis Options feltet benyttes må dette omfatte kun hele 32-bits ord, så hvis kun en del av et ord benyttes må de resterende bit fylles med 0.

I RFC 791 brukes de neste 8 bit til Type of Service (ToS) feltet. Dette feltet har blitt gjenbrukt til Diffserv og Explicit Congestion Notification. Tanken med ToS feltet var opprinnelig at avsender av pakka kunne spesifisere ønsker om hvordan pakka skulle håndteres gjennom nettverket. For eksempel kunne en avsender spesifisere et ønske om lav forsinkelse i ToS feltet, mens en annen avsender kunne spesifisere et ønske om høy grad av pålitlighet. I praksis så har ikke ToS feltet blitt tatt i bruk i vesentlig grad.

I Total Length feltet som omfatter de neste 16-bit lagres størrelsen til hele pakka inkludert hodet og nyttelasta i 8-bit tegn. Minimum lengde på pakka er 20 tegn (kun hodet), mens maksimum er 65535. Den maksimale størrelsen en vert er påkrevd å kunne håndtere er 576 tegn, men de aller fleste moderne verter kan håndtere mye større pakker. Noen ganger kan underliggende nettverksteknologi begrense pakkestørrelsen, noe som fører til at pakka må deles opp i mindre biter, fragmenteres. I IPv4 blir fragmentering enten håndtert av verten eller av en ruter.

Det neste 16-bit feltet, Identification brukes til å identifisere hvert enkelt fragment av ei IP-pakke. Det har også vært foreslått å bruke Identification-feltet til andre bruksområder, som å legge til sporingsinformasjon i IP-pakker for assistere sporing av IP-pakker med forfalska avsenderadresser.

Videre følger et 3-bit felt, Flags som brukes til å kontrollere og identifisere fragmenter. Hver bit har et bruksområde som i rekkefølge fra venstre mot høyre i figuren brukes til følgende:

• Reservert, må være satt til 0
• Ikke fragmenter (hvis satt)
• Flere fragmenter.

Fragment Offset feltet er på 13-bit og tillater en mottaker å avgjøre plasseringa av et enkeltfragment i den orginale IP-pakka og måles i enheter av 8-tegn store blokker.

Deretter har vi et 8-bit felt, Time to Live (TTL) som brukes for å unngå at IP-pakker forblir i nettverket, for eksempel ved at det går i sirkel. Opprinnelig var TTL feltet tenkt å begrense tida ei IP-pakke kunne oppholde seg i nettverket i antall sekunder, men det har endt opp med å bli en hoppteller. Hver ruter i nettverket reduserer TTL feltet med 1. Når TTL feltet når 0 så vil ikke pakka bli sendt videre, og den vil bli sletta.

Videre kommer Protocol feltet der transportlagsprotokollen spesifiseres. Internet Assigned Numbers Authority administrerer ei liste over protokollnummer. Noen eksempler på vanlige protokoller og tilhørende desimale protokollnummer er: ICMP (1), TCP (6) og UDP (17).

Så kommer et 16-bit felt, Header Checksum som er en sjekksum for IPv4 hodet. Noen felt (TTL) i IPv4 hodet endres for hver ruter som passers, så denne sjekksummen må oppdateres på vei gjennom nettverket.

Etter sjekksummen følger Source Address og Destination Address som begge er på 32-bit og inneholder IP-adressene til kilde og mål-vert for IP-Pakka.

Deretter kommer et valgfritt felt, Options som også kan ha variabel lengde.

[rediger] Fragmentering og sammensetting

IPv4 støtter bruken av nettverksforbindelser med små pakkestrørrelser. Dette kan føre til at vi kommer i den situasjonen at en ruter får ei pakke som er større enn nettverksforbindelsen pakka skal sendes på tillater. En mulig løsning er å fragmentere og sette sammen igjen IP-pakker for hver enkelt punkt til punkt forbindelse der fragmentering er påkrevd. En slik løsning ville føre til at ruteren knytta til den andre enden av forbindelsen som krevde fragmentering måtte sette sammen igjen IP-pakka. Dette er en komplisert operasjon, spesielt i tilfeller der enkeltfragmenter forsvinner som følge av feil på forbindelsen. Løsningen i IPv4 er derfor at den første ruteren som kommer i den situasjonen at IP-pakka er større enn det underliggende nettverket støtter fragmenterer IP-pakka. Pakka forblir fragmentert resten av veien gjennom nettverket og det er opp til mottaker å sette den sammen igjen til ei komplett pakke.

Når ei stor IPv4 pakke blir delt opp i mindre fragmenter, får hvert enkeltfragment et eget IP-hode og oppfører seg som ei vanlig IP-pakke. Nyttelasta til den opprinnelige IP-pakka som førte til fragmentering blir delt opp i biter som er små nok (sammen med IP hodet) til å kunne overføres over det underliggende nettverket. En bit av den orginale IP-pakka er plassert i hvert fragment. Nesten alle felta i IP-hodet til fragmentet er identisk med tilhørende felt i den orginale IP-pakka. Spesielt gjelder dette identifikasjons-feltet som må være likt for alle fragmentene. Forskjellene mellom enkeltfragmentene er:

• Total Length feltet vil bli satt til å stemme med størrelsen på hvert fragment
• More Fragments flagget vil bli satt til 1 for alle fragmenter unntatt det siste
• Fragment Offset feltet vil være forskjellig fra 0 i alle unntatt det første fragmentet

Merk at hos mottaker vil pakker der enten:

• More Fragments flagget er satt til 1, eller
• Fragment Offset flagget er forskjellig fra 0

bli oppfatta som et fragment.

Mottaker ser på identifikasjonsfeltet til enkeltfragmenter for å kunne sette de sammen igjen til ei komplett pakke. Fragmenter med lik identifikasjon hører alle til den samme opprinnelige IP-pakka. Offset og Total Length felta avgjør hvor hvert enkelt fragment skal plasseres inad i ei komplett pakke og hvor stor del av pakka fragmentet ugjør. Den totale pakkestørrelsen kan hentes ut av Total Length feltet i fragmentet der More Fragments ikke er satt. Verdien av Total Length feltet i den pakka og verdien av Offset feltet (multiplisert med den 8-tegn store blokkstørrelsen for fragmentene) utgjør den totale lengda av den opprinnelige pakka.

Merk at en ruter kan gjenta fragmenteringsprosessen selv om den kun har et enkelt fragment. Hvis dette skjer så tar ruteren fragmentet og deler det opp på samme måte som beskrevet tidligere, og lager to eller flere nye fragmenter. Offset og Total Length feltene blir justert til å passe. En kompliserende faktor er hvis More Fragments flagget var 0, isåfall må det settes til 1 for alle unntatt det siste av de nye fragmentene.

[rediger] Referanser

TCP/IP Illustrated, Volume 1
The Protocols
W. Richard Stevens
ISBN: 0-201-63346-9

[rediger] Eksterne lenker

• RFC791 (Spesifikasjonen)