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.
Internetts arkitekturprinsipper
IP er Internetts «smale midje» — det eneste som alle må implementere. Kompleksiteten lever i kantene. Dette er et bevisst designvalg.
Seksjon 4.5 (Middleboxes) i boken er ikke pensum. Timeglassmodellen og end-to-end-argumentet er likevel sentrale arkitekturprinsipper som refereres gjennom hele kurset. Denne seksjonen gir nyttig bakgrunn, men eksamensfokuset ligger på seksjonene 4.1–4.3.
IP-timeglasset
Internett har mange protokoller i applikasjons-, transport-, lenke- og fysisk lag — men bare én nettverkslagsprotokoll: IP. Denne «smale midjen» er det som gjør interoperabilitet mulig: enhver enhet som implementerer IP kan kommunisere med enhver annen.
I «middelalderen» har Internett fått «love handles»: mellombokser (firewalls, NAT, caches) som opererer inne i nettverket og bryter den rene timeglassmodellen.
Arkitekturprinsipper (RFC 1958)
«The goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.»
Tre hjørnesteiner: enkel konnektivitet, IP som den smale midjen, og intelligens i kantene.
End-to-end-argumentet
Saltzer, Reed og Clark (1981) formulerte det slik: en funksjon kan kun implementeres fullstendig og korrekt med kunnskap fra applikasjonen i endepunktene. Å bygge den inn i nettverket selv er ikke mulig. En ufullstendig versjon i nettverket kan være nyttig som ytelsesoptimalisering, men kan aldri erstatte endepunktimplementeringen.
Konkret: pålitelig dataoverføring kan enten implementeres hop-by-hop i nettverket (dyrt, komplekst) eller end-to-end i endesystemene (TCP). Internett valgte end-to-end — og det har skalert bedre enn alle alternativene.
Hva betyr end-to-end-argumentet i praksis for nettverksdesign?
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 mellombokser: NAT, brannmurer, load balancers, deep packet inspection.
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.