IP og adressering
IP-datagrammer, CIDR, DHCP, NAT, IPv6 og Internetts arkitekturprinsipper — alt om hvordan adresser og pakker fungerer.
Formatet som bærer alt
Alt vi har sett så langt er generisk. Nå møter vi det konkrete: hva en faktisk IPv4-pakke ser ut som, og hvorfor hvert felt er der det er.
| Felt | Hva det gjør |
|---|---|
| Version | 4 for IPv4, 6 for IPv6. To helt forskjellige formater. |
| HLen | Header-lengde i 32-bits ord. Oftest 5 (= 20 bytes, ingen options). |
| Type of Service | Differensierte tjenester (Diffserv bits 0–5) og congestion-notifikasjon (ECN bits 6–7). |
| Total Length | Hele datagrammet inkludert payload. Maks 65 535 bytes, typisk ≤ 1500. |
| TTL | Dekrementeres med 1 i hver router. Ved 0: pakken droppes + ICMP-feil. Forhindrer evige løkker. Brukes av traceroute. |
| Protocol | Hva ligger i payloaden? 6 = TCP, 17 = UDP, 1 = ICMP. |
| Header Checksum | Beskytter bare headeren (ikke data). Må reberegnes i hver router fordi TTL endres. Droppet i IPv6. |
IP-fragmentering
Et datagram kan være opptil 65 535 bytes, men hver lenke har en MTU (Maximum Transmission Unit) — den største rammen den kan bære. Ethernet har typisk MTU = 1500 bytes. Hvis et datagram er større enn MTU-en på neste lenke, må routeren fragmentere det i mindre biter.
Tre felt i IPv4-headeren styrer fragmenteringen:
- 16-bit Identifier — alle fragmenter fra samme originale datagram får samme verdi, slik at mottakeren kan gruppere dem.
- Flags — MF-biten (More Fragments) er satt i alle fragmenter unntatt det siste. DF-biten (Don’t Fragment) forbyr fragmentering; routeren dropper heller pakken og sender ICMP-feilmelding.
- Fragment Offset — angir hvor i det originale datagrammet dette fragmentet hører hjemme, målt i enheter av 8 bytes.
Eksempel: 4000-byte datagram over MTU = 1500
Et datagram på 4000 bytes (20 header + 3980 payload) må deles opp. Hvert fragment får sin egen 20-byte IP-header, så nyttelast per fragment er 1500 − 20 = 1480 bytes:
| Fragment | Payload | Offset | MF | Total |
|---|---|---|---|---|
| #1 | 1480 bytes | 0 | 1 | 1500 |
| #2 | 1480 bytes | 185 | 1 | 1500 |
| #3 | 1020 bytes | 370 | 0 | 1040 |
Offset-verdiene er 1480/8 = 185 og 2960/8 = 370. Totalt: 1480 + 1480 + 1020 = 3980 bytes payload, som tilsvarer originalen.
Routere underveis setter ikke fragmenter sammen igjen — det er endesystemets jobb. Grunnen er enkel: fragmentene kan ta forskjellige ruter gjennom nettverket, så bare destinasjonen er garantert å se alle. Hvis ett fragment går tapt, forkaster mottakeren de øvrige og TCP/applikasjonen sørger for retransmisjon.
Adresser er bundet til grensesnitt
En IP-adresse identifiserer ikke en maskin — den identifiserer et grensesnitt. En router med åtte porter har åtte adresser.
En IP-adresse er 32 bit, skrevet som fire desimaltall atskilt med punktum (dotted decimal). Men den er bundet til et grensesnitt (interface), ikke en maskin. Din bærbare har to grensesnitt (Ethernet + WiFi) og får to forskjellige IP-adresser.
Subnett: «samme nabolag»
Et subnett er et sett med grensesnitt som kan nå hverandre direkte uten å passere gjennom en router. Alle maskiner på samme Ethernet-svitsj eller WiFi er på samme subnett.
Oppskriften for å identifisere subnett: ta av alle grensesnitt fra routere og verter. De sammenhengende «øyene» som er igjen er subnettene.
Adressene på et subnett deler en felles nettverksdel (høyordensbit) og varierer bare i vertsdelen (lavordensbit). For eksempel: 223.1.1.0/24 har 24 bits nettverksdel og 8 bits vertsdel (256 adresser).
Klasseløs adressering
De gamle klassene (/8, /16, /24) kastet bort enorme mengder adresser. CIDR lar nettverksdelen være et hvilket som helst tall mellom 0 og 32.
CIDR — Classless Inter-Domain Routing — dropper de faste klassene og lar prefikslengden være vilkårlig. 200.23.16.0/23 betyr «de første 23 bitene er nettverksdelen, de siste 9 er vertsdelen», som gir 2⁹ = 512 adresser.
Rute-aggregering
CIDR muliggjør hierarkisk adressering. En ISP som eier 200.23.16.0/20 kan annonsere den ene ruten til resten av Internett, selv om den internt deler rommet i åtte /23-blokker for åtte kundeorganisasjoner. Resten av Internett trenger ikke vite om underoppdelingen — bare at «alt som begynner med 200.23.16.0/20 sendes til denne ISP-en.»
Når en organisasjon bytter ISP, annonserer den nye ISP-en en mer spesifikk rute (lengre prefiks), og takket være LPM finner trafikken fram riktig. Systemet fungerer selvrepererende.
Hvem deler ut adresser?
ICANN (Internet Corporation for Assigned Names and Numbers) allokerer IP-adresseblokker gjennom fem regionale registre (RIR-er). ICANN tildelte den siste IPv4-blokken til et RIR i 2011 — den globale poolen er tom.
Få en adresse automatisk
DHCP — Dynamic Host Configuration Protocol — lar en maskin be om og motta en IP-adresse når den kobler seg på nettverket.
Manuell konfigurering fungerer for servere, men er umulig for bærbare som stadig bytter nettverk. DHCP løser dette med en dans i fire trinn — alle sendt som broadcast, fordi klienten i starten ikke engang kjenner sin egen adresse.
Fire meldinger, alle broadcast
DHCP leverer mer enn bare en IP-adresse. Svaret inneholder vanligvis også: adresse til første-hop-router (default gateway), adresse til DNS-server, og subnet-maske.
Hvorfor sendes DHCP request som broadcast, selv når klienten kjenner serveradressen?
Hvorfor hele hjemmet deler én IP
Network Address Translation lar et helt privat nettverk dele én offentlig IP-adresse. Det reddet IPv4 — men bryter end-to-end-prinsippet.
IPv4 har 2³² ≈ 4,3 milliarder adresser. Det er ikke nok for alle verdens enheter. NAT løser dette ved at alle maskiner på et privat nettverk (typisk 10.0.0.0/8 eller 192.168.0.0/16) deler én offentlig adresse utad.
Trikset ligger i portnumrene. Når maskinen din sender en pakke ut, omskriver NAT-routeren kildeadressen til sin offentlige IP og endrer kildeporten til et unikt nummer som den lagrer i en NAT-tabell. Når svaret kommer tilbake, slår den opp i tabellen og sender pakken til riktig intern maskin.
NAT bryter end-to-end-prinsippet: en maskin bak NAT kan ikke uten videre ta imot innkommende forbindelser. Det krever «port forwarding» for å kjøre en server hjemme, og peer-to-peer-protokoller må bruke «hole punching.» Routere «bør» bare prosessere opp til lag 3, men NAT manipulerer portnumre (lag 4). Likevel: NAT er her for å bli, bredt brukt i hjemmenett, bedrifter og 4G/5G-nett.
128-bit adresser og en enklere header
IPv6 ble spesifisert i 1998. Motivasjonen: 32-bit adresser ville gå tomt. Løsningen: 128-bit adresser — nok til å gi hvert sandkorn på jorden sin egen adresse flere tusen milliarder ganger.
IPv6 har to fordeler utover det større adresserommet. Først: en fast 40-byte header uten options eller variable felt, som gjør forwarding raskere. Deretter: støtte for flow labels som lar routere behandle flows forskjellig.
Hva er fjernet fra IPv4?
- Ingen header checksum — sparer tid i routere (transportlaget har sin egen).
- Ingen fragmentering i routere — hvis pakken er for stor, sender routeren ICMP «Packet Too Big» tilbake. Senderen må fragmentere selv.
- Ingen options — erstattet av extension headers som kjøres som «next header»-kjeder.
Overgang: tunneling og dual stack
IPv6 og IPv4 er ikke bakoverkompatible. Overgangen krever dual stack (kjøre begge samtidig) og tunneling (pakke IPv6-datagrammer inn i IPv4-payloads for å krysse IPv4-nettverk).
I 2026 er vi rundt 45–47% IPv6-trafikk globalt — etter over 25 år med gradvis migrasjon. NAT holdt IPv4 på livstøtte, og fjernet presset for en rask overgang.
Enkelt med vilje
Hvis det er én ting å ta med seg fra dette kapittelet: Internetts nettverkslag er enkelt med vilje. Hver designbeslutning — best-effort, dumme routere, hierarkisk adressering, destinasjonsbasert forwarding — er et valg mot kompleksitet.
Kompleksiteten er ikke borte — den har bare flyttet seg:
- Til endesystemene: TCP sørger for pålitelighet, QUIC for lav latens.
- Til control plane: BGP er et av de mest komplekse systemene mennesker har bygd.
- Til NAT og adressering i praksis (se over): nødvendig for IPv4 i stor skala, men i konflikt med streng end-to-end- og lagdelingsmodell slik læreboka beskriver det.
Data plane har holdt seg relativt enkelt — og derfor har det kunnet fly. Når vi neste gang åpner control plane-delen, ser vi hvordan forwarding-tabellene faktisk fylles ut: rutingalgoritmer, OSPF, BGP, og ICMP.