IPv4
| Applikasjonslaget |
|---|
| Transportlaget |
| Nettverkslaget |
| Datalink-laget |
IPv4 (Internet Protocol version 4) er versjon 4 av Internett-protokollen og var den første versjonen som oppnådde vidstrakt bruk.[trenger referanse] IPv4 opererer på nettverkslaget i OSI-modellen for datanett og er en forbindelsesløs og upålitelig 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 formål[trenger referanse] 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.
Adressering
[rediger | rediger kilde]IPv4-adresserepresentasjoner
[rediger | rediger kilde]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 |
Allokering
[rediger | rediger kilde]Opprinnelig var IP-adressene delt inn i to deler:
- Nettverks-id – første oktett
- Host-id – siste tre oktetter.
Dette ga en øvre grense på 256 nettverk og førte til opprettelsen av nettklasser. Med klasseinndelinger opprettet man fem klasser (A, B, C, D og E) hvor tre ble opprettet med forskjellige inndelinger av antallet nettverk og hoster; få nettverk med mange adresser til mange nettverk med få host-adresser. Klasse D var for multicast og klasse E er reservert.
Rundt 1993 ble nettklassene erstattet av Classless Inter-Domain Routing (CIDR). CIDR sin fordel var kunne dele opp nettverk slik at en organisasjon kunne dele ut IP-adressene videre (for eksempel en internettleverandør kan dele ut IP-adresser videre til en kunde).
Den faktiske tildelingen av en adresse er ikke tilfeldig. Det grunnleggende prinsippet bak ruting er at en adresse innehar en koding av en enhets posisjon innenfor et nettverk. Dette innebærer at en adresse som er tildelt en del av et nettverk ikke vil fungere i en annen del av nettverket. En hierarkisk struktur, laget med grunnlag i CIDR og styrt av Internet Assigned Numbers Authority (IANA) og dets regionale internettregistere (RIR) administrerer tildelingen av internett-adresser over hele verden. Hver RIR har en offentlig tilgjengelig søkbar WHOIS database som gir ut informasjon om en IP-adresse sin tildeling. Informasjon fra disse databasene blir hele tiden benyttet av forskjellige verktøy for kunne finne ut hvor IP-adresser tilhører geografisk.
| CIDR adresseblokk | Beskrivelse | Referanse |
|---|---|---|
| 0.0.0.0/8 | Lokalt nettverk (kun gyldig som kildeadresse) | RFC 1700 |
| 10.0.0.0/8 | Privat nettverk | RFC 1918 |
| 14.0.0.0/8 | Offentlig datanettverk | RFC 1700 |
| 39.0.0.0/8 | Reservert | RFC 1797 |
| 127.0.0.0/8 | Lokalt nettverk | RFC 3330 |
| 128.0.0.0/16 | Reservert (IANA) | RFC 3330 |
| 169.254.0.0/16 | Uten konfigurasjon | RFC 3927 |
| 172.16.0.0/12 | Privat nettverk | RFC 1918 |
| 191.255.0.0/16 | Reservert (IANA) | RFC 3330 |
| 192.0.0.0/24 | ||
| 192.0.2.0/24 | Dokumentasjon og eksempelkode | RFC 3330 |
| 192.88.99.0/24 | IPv6 til IPv4 omlegging | RFC 3068 |
| 192.168.0.0/16 | Privat nettverk | RFC 1918 |
| 198.18.0.0/15 | Ytelsestesting av nettverk | RFC 2544 |
| 223.255.255.0/24 | Reservert | RFC 3330 |
| 224.0.0.0/4 | Multicast (tidligere Klasse D nettverket) | RFC 3171 |
| 240.0.0.0/4 | Reservert (tidligere Klasse E nettverket) | RFC 1700 |
| 255.255.255.255 | Lokal kringkasting (broadcast) |
Private nettverk
[rediger | rediger kilde]Av over 4 milliarder adresser som er tillatt i IPv4 er det reservert fire områder for bruk kun i private nettverk. Disse områdene er ikke rutbare utenfor de private nettverkene og private maskiner kan derfor ikke kommunisere direkte med offentlige nettverk. Ved hjelp av adresseoversetting kan de derimot få tilgang.
Følgende fire områder er reservert for private nettverk
| Navn | IP-adresse område | antall IP-er | klasse-beskrivelse | største CIDR blokk |
|---|---|---|---|---|
| 24-bits blokk | 10.0.0.0 – 10.255.255.255 | 16 777 216 | enkel A-klasse | 10.0.0.0/8 |
| 20-bits blokk | 172.16.0.0 – 172.31.255.255 | 1 048 576 | 16 sammenhengende B-klasser | 172.16.0.0/12 |
| 16-bits blokk | 192.168.0.0 – 192.168.255.255 | 65 536 | 256 sammenhengende C-klasser | 192.168.0.0/16 |
| 16-bits blokk | 169.254.0.0 – 169.254.255.255 | 65 536 | 256 sammenhengende C-klasser | 169.254.0.0/16 |
IPv4-hodeformat
[rediger | rediger kilde]
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å minimumsverdien 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 originale 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 passeres, 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 som inneholder IP-adressene til kilde og mål-vert for IP-pakka.
Deretter kommer et valgfritt felt, Options, som også kan ha variabel lengde.
Fragmentering og sammensetting
[rediger | rediger kilde]IPv4 støtter bruken av nettverksforbindelser med små pakkestø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 originale IP-pakka er plassert i hvert fragment. Nesten alle felta i IP-hodet til fragmentet er identisk med tilhørende felt i den originale 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, i så fall må det settes til 1 for alle unntatt det siste av de nye fragmentene.
Litteratur
[rediger | rediger kilde]- W. Richard Stevens, TCP/IP Illustrated, Volume 1 : The Protocols, ISBN 0-201-63346-9
Eksterne lenker
[rediger | rediger kilde]- RFC791 (Spesifikasjonen)