Eftersom många nätverk använder både IPv4 och IPv6, behövs det ett sätt att använda NAT även med IPv6. Detta avsnitt förklarar hur IPv6 kan integreras med NAT.
IPv6 använder 128‑bitars adresser och erbjuder ungefär 3,4 × 10³⁸ unika adresser. Adressbrist, som i IPv4 ledde till utbredd användning av NAT, är därför inte ett problem. Den långsiktiga målbilden är ett nativt IPv6‑nät där alla noder kommunicerar med globalt unika adresser, utan adressöversättning mellan privata och publika adresser.
Varför finns NAT i en IPv6‑värld?
Behovet av adressöversättning i IPv6 handlar inte om adress besparing utan om interoperabilitet under övergången från IPv4. När IPv6‑klienter behöver nå IPv4‑resurser används översättningstekniker. Den centrala mekanismen är NAT64 (med DNS64), medan NAT66 i princip bara förekommer i snäva specialfall.
Unique Local Addresses (ULA)
IPv6 definierar ett lokalt adressområde kallat Unique Local Addresses (ULA) enligt RFC 4193. ULA är avsedd för intern kommunikation, testmiljöer och nät utan internetanslutning. Prefixet är fd00::/8, till exempel fd12:3456:789a::1. Tanken är inte att ULA ska NAT:as till globala adresser; i ett korrekt utformat IPv6‑nät används i stället globala prefix för trafik som måste vara åtkomlig externt.
NAT64 – översättning mellan IPv6 och IPv4
NAT64 (RFC 6146) låter en IPv6‑klient kommunicera med en IPv4‑server. DNS64 skapar en syntetisk IPv6‑adress från serverns IPv4‑adress. Klienten skickar IPv6‑paket till den syntetiska adressen, en NAT64‑nod översätter paketet till IPv4 mot servern, och svaren översätts tillbaka till IPv6. Lösningen kräver en NAT64‑router och en DNS64‑server och är avsedd som övergångsteknik.
Här är en steg-för-steg-förklaring av ett exempel, så att det blir tydligt vad som händer i kommunikationen mellan en IPv6-endast klient och en IPv4-endast server med hjälp av DNS64 och NAT64:
- En IPv6-endast klient skickar en DNS-förfrågan till DNS64-servern och frågar efter en AAAA-post för www.domain.test.
- DNS64-servern vidarebefordrar frågan om AAAA-post till en DNS-server i IPv4-nätet (till exempel den auktoritativa servern för domänen).
- DNS-servern i IPv4-nätet svarar att det inte finns någon AAAA-post för domänen.
- DNS64-servern skickar nu istället en fråga efter en A-post (IPv4-adress) för www.domain.test till samma DNS-server i IPv4-nätet.
- DNS-servern svarar med A-posten: 203.0.113.10.
- DNS64-servern skapar (syntetiserar) en IPv6-adress genom att använda det speciella prefixet 64:FF9B::/96 och lägga till IPv4-adressen i slutet, vilket ger 64:FF9B::203.0.113.10.
- DNS64-servern skickar tillbaka svaret till klienten, som nu får en IPv6-adress för www.domain.test: 64:FF9B::203.0.113.10.
- Klienten skickar ett TCP- eller UDP-paket med source-adress 2001:DB8:1::100 och destinationsadress 64:FF9B::203.0.113.10.
- NAT64-gatewayen tar emot paketet och översätter det från IPv6 till IPv4.
- Det översatta paketet får source-adress 198.51.100.1 (gatewayens IPv4-adress) och destinationsadress 203.0.113.10 (serverns IPv4-adress) och skickas sedan vidare till servern.
Jämförelse: NAT i IPv4 kontra NAT64
| Egenskap | NAT i IPv4 | NAT i IPv6 (NAT64) |
|---|---|---|
| Primärt syfte | Adressbesparing, maskering av interna nät | Övergång mellan IPv6‑klienter och IPv4‑tjänster |
| Typisk riktning | Privat → Publik IPv4 | IPv6‑klient → IPv4‑server |
| Adress domäner | IPv4 ↔ IPv4 | IPv6 ↔ IPv4 |
| DNS‑beroende | Nej | Ja (DNS64) |
| End‑to‑end | Bryts | Bryts |
NAT66 – när används det?
NAT66 är en en‑till‑en‑översättning mellan två IPv6‑adresser. Den kan minska omnumrering vid t.ex. ISP‑byte, men bryter end‑to‑end‑principen, försvårar felsökning och ger begränsad nytta i välplanerade nät. Därför rekommenderas den sällan och bör ses som undantag snarare än regel.
Övergångs strategier i praktiken
Under migreringen till IPv6 kombineras ofta flera metoder.
- Dual Stack låter noder köra både IPv4 och IPv6 parallellt tills alla beroenden av IPv4 är borta.
- Tunnling möjliggör IPv6‑transport över befintliga IPv4‑domäner genom inkapsling.
- Översättning kopplar ihop separata protokollvärldar, typiskt via NAT64/DNS64 när IPv6‑klienter måste nå IPv4‑tjänster.
Tunnling – princip och funktion
Tunnling kapslar in ett IPv6‑paket i ett IPv4‑paket, transporterar det över ett IPv4‑nät och plockar sedan ut IPv6‑innehållet vid tunnelns slutpunkt. Metoden är praktisk där native IPv6 saknas längs vägen, men den tillför overhead och måste hanteras med tydliga policys i brandväggar och säkerhetskontroller.
Vanliga tunnlingstyper
Notera att flera äldre varianter inte längre rekommenderas i produktion, men förekommer i dokumentation och äldre miljöer.
| Tunnlingstyp | Användning | Protokoll | Status |
|---|---|---|---|
| Manual tunneling (6in4) | Punkt‑till‑punkt över IPv4 | IPv4 protokoll 41 | Rekommenderad där kontroll önskas |
| Teredo | IPv6 över NAT:ade IPv4‑nät | UDP | Tillfällig lösning |
| 6to4 | Automatisk tunnling, kräver publik IPv4 | IPv4 protokoll 41 | Föråldrad |
| ISATAP | IPv6 över internt IPv4‑länklager | IPv4 | Föråldrad |
Säkerhetsaspekter
Varken tunnlar eller översättning är säkra per automatik. Kryptering och autentisering måste tillämpas där krav finns, exempelvis via IPsec eller VPN. Brandväggar bör uttryckligen hantera tunneltrafik och förhindra obefogad IPv6‑passage genom inkapsling. Dokumentera topologi, översättningsregler och felvägar för att underlätta felsökning.
Slutsats
NAT i IPv6 är ett övergångs verktyg – inte ett sätt att spara adresser. NAT64 möjliggör kommunikation mellan IPv6‑klienter och IPv4‑tjänster när sådana behövs. NAT66 bör undvikas i normal drift. Den långsiktigt hållbara vägen är native IPv6 med väl definierade brandväggs policys och tydlig avveckling av beroenden till IPv4.