Nettverkslaget

Svar: Forwarding er den lokale, per-pakke-operasjonen i én ruter — slå opp destinasjonsadressen i forwarding-tabellen og send pakken ut riktig utport, på nanosekunder. Routing er den nettverksglobale prosessen som bestemmer hvilke ruter som finnes og fyller forwarding-tabellen, på millisekunder–sekunder.

Hvorfor skillet er viktig: De to oppgavene har helt ulike tidsskalaer og krav. Forwarding må gå så fort at det implementeres i dedikerte ASIC-er (data plane), mens routing er kompleks logikk som kjører i programvare (control plane). Dette skillet er hele organiseringsprinsippet for kapittel 4 og for moderne ruterdesign. Analogi: forwarding = ta høyre i veikrysset; routing = planlegge hele turen fra Trondheim til Roma før du setter deg i bilen.

Svar: Data plane er maskinvaren som faktisk flytter pakker fra innport til utport (forwarding-tabell, switching fabric, ASIC-er — nanosekunder). Control plane er programvaren som beregner ruter og skriver inn i forwarding-tabellen (typisk rutingprotokoller som OSPF og BGP — millisekunder til sekunder).

Hvorfor skille: Hver pakke gjennom en 100 Gbps-lenke har bare ~5 ns til disposisjon — det går ikke å kjøre rutingalgoritmer i den løkka. Ved å skille bort den langsomme planleggingen til control plane og la data plane bare slå opp og videresende, klarer ruteren tempoet. I TTM4100-pensum for kapittel 4 er det den tradisjonelle modellen som gjelder: hver ruter kjører kontrollplanet lokalt og fyller sin egen forwarding-tabell.

Svar: Best-effort betyr at IP ikke gir noen garantier — verken for at pakken kommer fram, hvilken rekkefølge den ankommer i, hvilken båndbredde du får, eller hvor lang forsinkelsen blir. Pakken sendes så godt nettverket klarer det, og resten er endepunktets ansvar.

Hvorfor det fungerer: (1) Enkelhet skalerer — en ruter som bare slår opp én destinasjon og sender videre kan bygges billig av hvem som helst; ATM krevde per-flow-tilstand i hver eneste ruter. (2) Overprovisjonering — båndbredde har blitt billig nok til at video og tale fungerer godt nok, mesteparten av tiden. (3) CDN-er + congestion control — innhold replikeres nær brukerne, og TCP hindrer kollaps. Internett valgte enkelhet i nettverket og intelligens i kantene — og det er grunnen til at IP, ikke ATM, vant.

Svar: (1) Innporter — linjeavslutning, lenkelagsdekoding og tabelloppslag for å bestemme utport. (2) Switching fabric — flytter pakken fra innport til riktig utport. (3) Utporter — kø, scheduling, lenkelagsenkoding og transmisjon. (4) Routing-prosessor — kjører rutingprotokoller og fyller forwarding-tabellen. De tre første er data plane; den siste er control plane.

Hvorfor designet er slik: Tabelloppslaget gjøres lokalt i hver innport uten å involvere CPU-en, slik at alle porter jobber parallelt. Det er et raskt prefiks-/destinasjonsoppslag: les typisk destinasjons-IP, finn lengste matchende prefiks i forwarding-tabellen, og send pakken ut på angitt utport. Det er kjernen i tradisjonell destinasjonsbasert IP-forwarding i dataplanet (jfr. pensum utenfor generalisert videresending i lærebok 4.4).

Svar: Forwarding-tabellen inneholder prefikser (f.eks. 10.0.0.0/8, 10.1.0.0/16), ikke hele adresser. Når en destinasjonsadresse matcher flere oppføringer, velger ruteren den med lengst prefiks fordi det er den mest spesifikke ruten. Eksempel: pakken til 10.1.5.3 matcher både /8 og /16, men /16-ruten vinner.

Hvorfor det er nødvendig: Hierarkisk adressering og rute-aggregering gjør at det ofte finnes overlappende oppføringer — en ISP annonserer et stort blokk-prefiks, mens en enkeltkunde innenfor blokken har en mer spesifikk rute via en annen lenke. Uten LPM ville disse vært tvetydige. Lengre prefiks = mer spesifikk = nærmere sluttdestinasjon, så LPM er det riktige valget.

Svar: En 100 Gbps-lenke leverer en 64-byte-pakke omtrent hvert 5. nanosekund. Programvare på en generell CPU klarer ikke å gjøre et tabelloppslag så raskt — særlig ikke med en kvart million prefikser i tabellen.

Hvorfor TCAM: Ternary Content-Addressable Memory sammenligner alle oppføringer parallelt på én klokkesyklus, uavhengig av tabellstørrelsen. "Ternary" betyr at den i tillegg kan ha "wildcard"-bits, perfekt for prefiksmatching. ASIC-er er kretser hardkodet til denne ene jobben. Uten denne maskinvareakselerasjonen ville ruterne blitt selve flaskehalsen i Internett — Cisco Catalyst-svitsjer har ~1 million oppføringer i TCAM.

Svar:

1. Via minne — pakke kopieres innport → systemminne → utport via CPU-en. To busskrysninger; begrenses av minnebåndbredden.
2. Via buss — direkte innport-til-utport over delt buss, uten CPU. Men bare én pakke om gangen pga. bus contention (Cisco 5600: 32 Gbps).
3. Sammenkoblingsnettverk (crossbar) — flere pakker krysser parallelt så lenge de skal til ulike utporter. Moderne rutere bruker flere parallelle fabric planes (Cisco CRS: 8 planes, hundrevis av Tbps).

Hvorfor evolusjonen: Hver generasjon fjerner én flaskehals — først CPU-en, så bussen, til slutt sekvensiell prosessering — og åpner for stadig høyere ruterkapasitet.

Svar: Hvis switching fabric er tregere enn summen av innportene, bygger det seg opp køer ved innportene. HOL-blokkering oppstår når pakken først i innport-køen venter på en opptatt utport, og dermed blokkerer pakkene bak seg — selv om deres utporter er ledige.

Hvorfor det er ille: Du sløser kapasitet: ledige utporter står ubrukte mens trafikk hoper seg opp lokalt. Moderne rutere unngår problemet ved å bruke virtual output queues (én kø per utport per innport) eller ved å gjøre fabric-en raskere enn summen av innportene, slik at kun output-køer (som ikke har samme problem) bygger seg opp.

Svar: Bufferbloat oppstår når routerbuffere er for store. Tap-raten ser bra ut (få pakker droppes), men pakkene står lenge i kø før de sendes videre. Resultatet er høy og variabel latens som ødelegger interaktive applikasjoner: VoIP, spill, videosamtaler.

Hvorfor det er kontraintuitivt: TCP regulerer ned vinduet sitt først når det ser tap; med ekstra store buffere blir tapet utsatt, så TCP holder køene fulle lenger. Den gamle tommelfingerregelen RTT·C (250 ms × 10 Gbps = 2,5 Gbit) er erstattet av RTT·C/√N for N flows — fordi statistisk multipleksing reduserer behovet. Aktive køstyringer som RED (drop tilfeldige pakker før køen er full) kan signalisere metning tidligere uten å fylle buffere helt.

Svar:

FCFS / FIFO: sender i ankomstrekkefølge — enkel og "nøytral", men en stor nedlasting kan gjøre en VoIP-samtale ubrukelig.
Priority scheduling: klassifiser pakker, server alltid høyeste klasse med pakker først — gir lav latens til viktig trafikk, men kan sulte ut lavprioriterte flows.
Round Robin / WFQ: hver klasse får sin tur. WFQ gir vekt w_i til klasse i, slik at klassen får andelen w_i/Σw_j av lenkekapasiteten. Slik kan man garantere minimum båndbredde uten å sulte de andre.

Hvorfor det er politisk ladet: Scheduling- og buffer-regler er mekanismene der nettnøytralitet får teknisk innhold. FCFS er strengt nøytralt; priority-scheduling basert på betalende kunder er "paid prioritization" — det 2015 FCC-regelverket forbød.

Svar: TTL (Time To Live) er et 8-bits felt som dekrementeres med 1 i hver eneste ruter. Når TTL når 0, dropper ruteren pakken og sender en ICMP "Time Exceeded" tilbake til avsenderen.

Hvorfor det finnes: Først og fremst for å hindre evige løkker: ved en feilkonfigurasjon i ruting kunne pakker sirkulert uendelig og spist opp båndbredde. TTL gir en garantert øvre grense på antall hopp. Sekundærbruk: traceroute utnytter mekanismen aktivt — ved å sende pakker med TTL = 1, 2, 3, … får man én ICMP-feilmelding per ruter på ruta og kan kartlegge hopp-for-hopp-forsinkelse.

Svar: Checksummen dekker bare headeren (ikke payloaden). Siden TTL-feltet endres ved hvert hopp (dekrementeres), endres checksummen tilsvarende — og hver ruter må regne den ut på nytt for å bevare integriteten på den nye headeren.

Hvorfor IPv6 dropper det: Beregningen er en kostnad som gjentas på millioner av pakker per sekund i en travel ruter, og dupliserer arbeid som allerede gjøres på andre lag — TCP og UDP har egne ende-til-ende-checksums som dekker både header og data, og lenkelaget (Ethernet FCS) fanger bitfeil per hopp. IPv6-designerne konkluderte med at en hop-by-hop checksum på nettverkslaget var bortkastet prosessering, og fjernet den for raskere forwarding.

Svar: Hvis et datagram er større enn neste lenkes MTU (typisk 1500 bytes på Ethernet), må ruteren fragmentere det i mindre biter. Identifier er lik for alle fragmenter fra samme originale datagram (slik at mottakeren kan gruppere dem). MF (More Fragments) = 1 i alle fragmenter unntatt det siste. DF (Don't Fragment) = 1 forbyr fragmentering — for store pakker droppes da, og avsender får ICMP-feil. Fragment Offset angir plasseringen i originalen, målt i 8-byte-enheter.

Hvor reassembleres: Kun i destinasjonsverten, ikke i mellomliggende rutere. Fragmenter kan ta forskjellige ruter, så bare destinasjonen er garantert å se alle. Hvis ett fragment går tapt, forkaster mottakeren resten — TCP eller applikasjonen sørger for retransmisjon. Eksempel: 4000-byte datagram over MTU=1500 deles i tre fragmenter med payload 1480/1480/1020 og offsets 0/185/370.

Svar: En 32-bits IPv4-adresse identifiserer ikke en maskin, men ett grensesnitt. En bærbar med både Ethernet og WiFi har to grensesnitt og dermed to forskjellige IP-adresser. En ruter med åtte porter har åtte adresser. Et subnett er et sett med grensesnitt som kan nå hverandre direkte uten å passere en ruter — de deler felles nettverksdel av adressen og varierer bare i vertsdelen.

Hvorfor det er viktig: Subnett-konseptet er fundamentet for forwarding. En ruter ser på destinasjonsadressens nettverksprefiks for å bestemme hvilket subnett pakken skal til, ikke hvilken individuell maskin. Oppskrift for å identifisere subnett: ta av alle grensesnitt fra rutere og verter, og de sammenhengende "øyene" som blir igjen er subnettene.

Svar: CIDR (Classless Inter-Domain Routing) dropper de gamle faste klassene (/8, /16, /24) og lar prefikslengden være vilkårlig fra 0 til 32. 200.23.16.0/23 betyr "de første 23 bitene er nettverksdelen", som gir 2⁹ = 512 adresser. Notasjonen kalles dotted-decimal/prefix.

Hvorfor rute-aggregering: En ISP som eier 200.23.16.0/20 kan annonsere én rute til resten av Internett, selv om den internt deler rommet i åtte /23-blokker for åtte kunder. Resten av Internett trenger ikke kjenne underoppdelingen, og forwarding-tabellene globalt holdes mye mindre. Når en kunde bytter ISP, annonserer den nye et mer spesifikt prefiks (lengre), og takket være LPM finner trafikken fram automatisk.

Svar: Discover (klient → broadcast: "noen som har en IP til meg?") → Offer (server → broadcast: "her er IP X, lease Y sek") → Request (klient → broadcast: "jeg velger denne") → ACK (server → broadcast: "bekreftet"). I tillegg til IP-adressen leverer DHCP også subnettmaske, default gateway og DNS-serveradresse.

Hvorfor broadcast hele veien: I steg 1–2 har klienten ingen IP, så unicast er umulig. I steg 3 (Request) kunne klienten teoretisk sendt unicast — men broadcasten har en viktig sidefunksjon: hvis flere DHCP-servere har sendt tilbud, ser de andre nå at klienten valgte en konkurrent og kan frigjøre sine reservasjoner. Det unngår at adresser blir liggende reservert unødig.

Svar: IPv4 har bare 2³² ≈ 4,3 milliarder adresser — for få for verdens enheter. NAT lar et helt privat nettverk (typisk 10.0.0.0/8 eller 192.168.0.0/16) dele én offentlig IP utad. Når en intern maskin sender en pakke ut, omskriver NAT-ruteren kildeadressen til sin egen offentlige IP og bytter kildeporten til et unikt nummer som lagres i en NAT-tabell. Når svaret kommer tilbake, slår ruteren opp i tabellen via destinasjonsporten og oversetter tilbake til riktig intern maskin og port.

Hvorfor port-trikset er nøkkelen: Én offentlig IP har 65 535 mulige portnumre, så samme adresse kan multiplekse mange tusen samtidige flows. Uten port-omskriving ville det ikke vært nok unikhet til å rute svarpakkene tilbake. NAT er bredt utrullet i hjemmenett, bedrifter og 4G/5G — og er en hovedgrunn til at IPv4 har overlevd så lenge.

Svar: NAT bryter end-to-end-prinsippet: en maskin bak NAT kan ikke uten videre ta imot innkommende forbindelser, fordi NAT-tabellen bare har oppføringer for flows som er initiert innenfra. Servere hjemme krever "port forwarding"; P2P-applikasjoner må bruke "hole punching"; IoT blir vanskelig.

Andre brudd: (1) NAT er en lag-3-enhet (ruter), men manipulerer portnumre, som er lag-4-informasjon — det bryter den rene lagdelingen. (2) Den må holde tilstand per flow (NAT-tabellen), som strider mot den tilstandsløse IP-modellen. Likevel er NAT her for å bli — den løste IPv4-knappheten godt nok til at presset for IPv6-overgang forsvant.

Svar: IPv6 har en fast 40-byte basisheader uten options. Tre ting er fjernet:

1. Header checksum — duplisert arbeid; transportlaget (TCP/UDP) har ende-til-ende-checksum og lenkelaget fanger bitfeil per hopp.
2. Fragmentering i rutere — hvis pakken er for stor, sender ruteren ICMPv6 "Packet Too Big" og avsenderen må fragmentere selv (eller gjøre Path MTU Discovery).
3. Inline options — erstattet av extension headers som linkes via Next Header-feltet.

Hvorfor: Alle tre var kostnader som ble betalt på hver pakke i hver ruter. Ved å flytte dem ut av forwarding-stien (eller til endesystemene) kan IPv6-rutere prosessere pakker raskere, til tross for at adressene er fire ganger lengre. 128-bits adresserommet gir 2¹²⁸ adresser — nok til å adressere hvert sandkorn på jorden mange ganger over.

Svar: IPv4 og IPv6 er ikke bakoverkompatible — en IPv4-bare ruter forstår ikke en IPv6-pakke og omvendt. To overgangsmekanismer brukes:

Dual stack: verter og rutere kjører begge protokollstabler samtidig og velger versjon basert på destinasjonens støtte (typisk via DNS-oppslag — AAAA for IPv6, A for IPv4).
Tunneling: en IPv6-pakke pakkes inn som payload i et IPv4-datagram for å krysse en IPv4-bare del av nettverket; IPv6 "pakkes ut" igjen i andre enden.

Hvorfor overgangen er treg: NAT holdt IPv4 på livstøtte ved å løse adresseknappheten godt nok, så det presserende behovet for IPv6 forsvant. I 2026 ligger global IPv6-trafikk på rundt 45–47 % etter over 25 år med gradvis migrasjon.

Svar: Internett har mange protokoller på applikasjons-, transport-, lenke- og fysisk lag — men bare én nettverkslagsprotokoll: IP. Denne "smale midjen" i timeglasset er det alle må implementere, og det som gjør interoperabilitet mulig: enhver enhet som snakker IP kan kommunisere med enhver annen.

End-to-end-argumentet (Saltzer, Reed, Clark, 1981): En funksjon kan kun implementeres fullstendig og korrekt med kunnskap fra applikasjonen i endepunktene. En ufullstendig versjon i nettverket kan være en ytelsesoptimalisering, men kan aldri erstatte endepunktimplementeringen. Konkret: pålitelig dataoverføring kan enten bygges hop-by-hop inn i nettverket (dyrt, komplekst) eller end-to-end via TCP. Internett valgte end-to-end — intelligens i kantene, dumt nett — og har skalert bedre enn alle alternativene. 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."

Svar: En default-rute er en oppføring med prefiks 0.0.0.0/0 som matcher alle destinasjoner. Den brukes når ingen mer spesifikk oppføring finnes i tabellen — siden /0 har lengde null, vinner den bare når alt annet feiler i LPM.

Hvorfor og når: Default-rute er ideell i små nett som har én oppstrøms-ISP — istedenfor å holde en kvart million prefikser i tabellen, sender hjemmeruteren bare alt ukjent til ISP-en, som har den fulle BGP-tabellen. Ditt hjemmenett trenger bare å vite hva som er lokalt; resten "drar på defaulten." I store ISP-er som peerer med flere andre er full tabell nødvendig fordi default ikke kan velge mellom flere oppstrøms-stier.

Svar: Subnettmasken skiller nettverksdelen fra vertsdelen i en IPv4-adresse. 255.255.255.0 er den dotted-decimal-formen — alle 1-ere i nettverksbitene, alle 0-ere i vertsbitene. /24 er CIDR-notasjon for samme ting (24 ledende 1-bit). De er to skrivemåter for nøyaktig samme informasjon.

Hvorfor det er viktig: Verten din bruker masken til å avgjøre om en destinasjons-IP ligger på samme subnett (send pakken direkte over lenken) eller utenfor (send til default gateway). Operasjonen er enkel: en bitvis AND mellom IP og maske gir nettverksprefikset; sammenlign med eget prefiks. /24 = 8 vertsbit = 256 adresser; /28 = 4 vertsbit = 16 adresser; /30 = bare 4 adresser (typisk for point-to-point-lenker mellom rutere).

Svar: Tre områder, definert i RFC 1918:

• 10.0.0.0/8 — ~16,7 millioner adresser
• 172.16.0.0/12 — ~1 million adresser
• 192.168.0.0/16 — 65 536 adresser

Hvorfor: Pakker med private adresser droppes av rutere på det offentlige Internett — disse blokkene er reservert for lokal bruk bak NAT. Det gjør at hjemmenett, bedrifter og 4G/5G-operatører kan tildele IP-adresser fritt internt uten å koordinere med ICANN. NAT oversetter den private adressen til en offentlig når trafikken forlater nettverket. 192.168.0.0/16 er det vanligste i hjemmerutere — derav adresser som 192.168.0.1 eller 192.168.1.1 for husets ruter.

Svar: Verten sjekker (via subnettmasken) om destinasjonsadressen er på samme subnett. Hvis ikke: pakken sendes ikke direkte til destinasjonen, men til default gateway — typisk førsteruteren på subnettet. Verten lager en lenkelagsramme der:

• destinasjons-IP = den endelige målets IP (uendret hele veien til endepunktet)
• destinasjons-MAC = gatewayens MAC-adresse (funnet via ARP)

Hvorfor: En vert kan bare snakke direkte med andre på samme lenke (samme subnett). For alt annet er det ruterens jobb å finne veien videre. Default gateway-adressen leveres som en del av DHCP-tilbudet sammen med IP, maske og DNS — det er derfor du må kjenne alle fire for å være "online". MAC-adressene endres ved hvert hopp, men IP-adressene forblir uendret hele veien.

Svar: På sendersiden mottar nettverkslaget et segment fra transportlaget (TCP/UDP), kapsler det inn i et datagram ved å legge til IP-header (kildeadresse, destinasjonsadresse, TTL, protokollfelt osv.), og leverer datagrammet til lenkelaget under. På mottakersiden gjøres motsatt: datagrammet kommer fra lenkelaget, segmentet trekkes ut og leveres opp til transportlaget.

Hva rutere gjør forskjellig: Rutere kjører nettverkslaget, men leverer ikke segmentet opp — de bruker IP-headerens destinasjonsadresse til å forwarde datagrammet videre på riktig utport. Dette er enkapsulerings-mønsteret som gjør lagdelingen mulig: hvert lag legger på sin egen header på vei ned, og fjerner den på vei opp. Endesystemer kjører hele stabelen; rutere stopper ved nettverkslaget.

Svar: Minimum 20 bytes. Utover 32-bit kilde- og destinasjons-IP (8 bytes til sammen):

• Version (4 for IPv4) + HLen (header-lengde i 32-bits ord, vanligvis 5 = 20 bytes)
• Type of Service — brukes blant annet til Diffserv (DSCP)
• Total Length — hele datagrammet inkl. payload, maks 65 535 bytes
• Identifier / Flags / Fragment Offset — fragmentering
• TTL — hopgrense
• Protocol — 6 = TCP, 17 = UDP, 1 = ICMP
• Header Checksum

Hvorfor det er nyttig å kjenne: Overhead summerer seg: 20 IP + 20 TCP = 40 bytes per pakke før noe payload. Protocol-feltet er nøkkelen til demultipleksing i mottakeren — det forteller hvilken transportprotokoll segmentet skal leveres til. Total Length er hva mottakeren bruker for å vite når payload slutter, siden lenkelagsrammen kan ha padding.

Svar: ICANN (Internet Corporation for Assigned Names and Numbers) allokerer IP-blokker globalt, gjennom fem regionale registre (RIR-er): ARIN (Nord-Amerika), RIPE (Europa), APNIC (Asia/Stillehavet), LACNIC (Latin-Amerika), AFRINIC (Afrika). RIR-ene tildeler videre til ISP-er og store organisasjoner. ICANN tildelte den siste IPv4-blokken til et RIR i 2011 — den globale poolen er tom.

Hvorfor det betyr noe: Dette er motivasjonen for IPv6 (128-bit adresser), og forklaringen på hvorfor NAT er nødvendig — uten port-omskriving ville knappe IPv4-adresser ikke rakt til milliarder av enheter. Adresser kan nå handles på et sekundærmarked: det er ikke uvanlig at /24-blokker selges for titusenvis av dollar mellom selskaper.

Svar: To muligheter:

• Input-køer — bygger seg opp ved innportene hvis switching fabric er tregere enn summen av innports kapasitet.
• Output-køer — bygger seg opp ved utportene når flere innporter sender til samme utport (ankomstrate > sendingsrate).

Output-køer dominerer i moderne rutere fordi fabric-en designes raskere enn N × innport-kapasitet, slik at HOL-blokkering ved input unngås.

Hvorfor output-køer er der "alt skjer": De reiser to klassiske spørsmål: (1) hva droppes når køen er full? (tail drop, RED), og (2) hvilken pakke sendes først? (FCFS, priority, WFQ). Det er her metningshåndtering og nettnøytralitet får teknisk innhold. Input-køer derimot lider av HOL-blokkering — derfor unngås de.

Svar:

• Tail drop: dropp pakken som nettopp ankom hvis køen er full. Enkelt, men signaliserer metning sent — først når køen allerede er full.
• RED: dropp pakker tilfeldig med økende sannsynlighet etter hvert som køen fyller seg, før den er full. TCP ser tap tidligere og reduserer sending før køen renner over.

Hvorfor det spiller rolle i pensum: Begge er klassiske ruter-kømekanismer i læreboka. Mer avansert ECN-basert metningsvarsling (lærebok 3.7.2) er ikke pensum i TTM4100 — her holder vi oss til drop-baserte strategier.

Svar: Avsenderen finner det minste MTU langs hele ruten ved å sende pakker med DF=1 (Don't Fragment). Hvis en ruter underveis har lavere MTU, dropper den pakken og sender ICMP "Fragmentation Needed" (IPv4) eller ICMPv6 "Packet Too Big" (IPv6) tilbake. Avsenderen reduserer pakkestørrelsen og prøver igjen, helt til alt går gjennom.

Hvorfor IPv6 krever det: IPv6-rutere fragmenterer ikke i det hele tatt — så avsenderen må kjenne path MTU. I IPv4 er det en optimalisering: alternativet er at hver ruter fragmenterer, men fragmenter koster ekstra header-overhead (hvert fragment har sin egen 20-byte IP-header) og setter mottakeren i fare for å miste hele datagrammet hvis ett fragment forsvinner. Bedre å fragmentere ved kilden — én gang, riktig størrelse.

Svar: 128 bits, skrevet som åtte 16-bits grupper i heksadesimal, atskilt med kolon: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. To komprimeringsregler:

• Ledende nuller i hver gruppe kan droppes: 0db8 → db8
• Sammenhengende grupper med null kan komprimeres med dobbel-kolon — men kun én gang per adresse: 2001:db8:85a3::8a2e:370:7334

Hvorfor det er praktisk: 2¹²⁸ adresser er astronomisk mye flere enn IPv4 (2³² ≈ 4,3 milliarder) — så hver enhet kan i prinsippet ha sin egen globalt rutbare adresse, og NAT er unødvendig. Komprimeringsreglene gjør at typiske adresser (mye nullpadding i praksis) blir korte nok til å være håndterlige, til tross for å være fire ganger så lange som IPv4.

Svar: ATM tilbød rike garantier:

• CBR (Constant Bit Rate): garantert fast båndbredde, ingen tap, rekkefølge og timing — virtuell krets.
• ABR (Available Bit Rate): minimum garantert båndbredde, men ingen tap-garanti.
• Intserv Guaranteed: per-flow ressursreservering på IP — full garanti.
• Diffserv: grov klasse-basert prioritering uten harde garantier.

Internetts best-effort gir ingen garantier.

Hvorfor best-effort vant: Garantier krever per-flow-tilstand og ressursreservering i hver eneste ruter. Det skalerer ikke til milliarder av samtidige flows. Best-effort holder rutere enkle og billige å bygge — kompleksiteten flyttes til endesystemene (TCP for pålitelighet, applikasjonen for ratebegrensning). Resultatet: Internett har skalert til milliarder av enheter; ATM har forsvunnet fra det offentlige nettet.