Redigerer IPv4 (avsnitt)

== IPv4-hodeformat ==
[[Fil:IPv4_header (1).png|400px|right|Oversikt over de ulike felta i IPv4 hodet]]

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 [[Differentiated services|Diffserv]] og [[ECN|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.