Defaults.Exposed › Åtgärder › IPv6-stöd
Hur du fixar IPv6-stöd
IPv6 är den nyare, mycket större versionen av internets adresseringssystem, framtagen för att det gamla (IPv4) tagit slut på utrymme. Att lägga till IPv6-stöd innebär att din webbplats och e-post kan nås via det moderna nätverket såväl som det gamla. I vår betygsättning är det informativt — att inte ha det sänker inte ditt betyg — men det är ett verkligt räckviddsproblem: en växande andel av mobila och utländska kunder ansluter via IPv6-only-nätverk, och de når dig smidigt bara om du stödjer det. Åtgärden är gratis och lever i din DNS- och hostinginstallation.
Slutsats för ditt företag: En ökande andel internetanvändare — speciellt på mobiloperatörer och i snabbväxande marknader — ansluter nu via IPv6. Om din webbplats bara har IPv4 kommer dessa besökare i regel igenom ändå (deras operatör översätter anslutningen åt dem), men den översättningen lägger till ett hopp, kan vara marginellt långsammare och är ytterligare en sak som kan misslyckas eller begränsas under rusningstid. Att stödja IPv6 innebär en renare, mer direkt anslutning för moderna kunder, en liten framtidssäkringsvinst och en snygg signal till tekniska köpare om att din infrastruktur är aktuell. Det ändrar ingenting om ditt betyg — behandla det som framtidsinriktad polering, inte en nödsituation — men det är gratis att lägga till och placerar dig i linje med vart internet är på väg.
Vad detta kan kosta dig
- En kund på en mobiloperatör som kör IPv6-only måste nå din IPv4-webbplats via operatörens översättningslager. Det fungerar nästan alltid — men det lägger till latens och är ytterligare ett beroende som kan hacka till vid topptider, vilket gör din webbplats marginellt långsammare än en konkurrent som är direkt nåbar.
- En teknisk köpares eller partners säkerhets-/infrastrukturteam kör en snabb skanning innan de skriver på och noterar att du bara har IPv4. Det underkänner dig inte, men en konkurrent som visar dual-stack (IPv4 + IPv6) hamnar i 'modern, välskött'-kolumnen medan du sitter i 'bra, lite bakom'.
- Du expanderar till en marknad — delar av Asien, Indien, vissa europeiska mobilnätverk — där IPv6 redan dominerar. Att vara direkt nåbar där, snarare än alltid via översättning, tar bort en liten men verklig källa till långsamma eller hackiga anslutningar för dina nyaste kunder.
- Din hosting eller CDN stödjer redan IPv6 gratis, men ingen slog någonsin på det, så du missar en enkel, nollkostnadsförbättring som dina konkurrenter hämtade som standard.
- En offentlig upphandlings- eller företagschecklista frågar om dina tjänster är IPv6-klara (många offentliga sektorsmandat gör det nu). 'Nej' är en besvärlig rad att förklara när åtgärden var gratis hela tiden.
Varför det spelar roll. I vår metodik är IPv6-stöd informativt — kontrollen är registrerad med noll poäng och rör aldrig ditt betyg. Vi rapporterar det för att det är en genuin, framtidsinriktad räckvidds- och modernitetssignal: internet tog slut på gammelstils (IPv4)-adresser för år sedan, och andelen användare som ansluter via IPv6-only-nätverk fortsätter klättra, speciellt på mobila och i IPv6-dominanta regioner. Att stödja IPv6 ger dessa användare en renare, mer direkt väg till din webbplats och e-post och signalerar aktuell infrastruktur till alla som kontrollerar. Det är gratis att lägga till och bryter sällan något — vilket är exakt varför det är värt att göra även om det inte påverkar ditt betyg.
IPv6-stöd, i klartext
Internet identifierar varje server med en numerisk adress. Det ursprungliga systemet, IPv4, har en fast, ganska liten pool av adresser — och världen tog slut på nya sådana för år sedan. Dess ersättare, IPv6, har en praktiskt taget obegränsad pool, och internet har tyst migrerat till det allt sedan dess.
IPv6-stöd innebär att din webbplats (och e-post) kan nås via det nyare nätverket såväl som det gamla. I praktiken kokar det ned till en sak i din DNS: bredvid den post som listar din gammeldagsadress (en A-post) publicerar du också en post som listar din IPv6-adress (en AAAA-post — fyra A:n). Att köra båda sida vid sida kallas dual-stack, och det är det normala, säkra sättet att göra det.
Den här kontrollen är informativ. Den ändrar inte ditt betyg. Vi slår upp om din domän publicerar AAAA-poster och rapporterar helt enkelt vad vi hittar — finns, eller saknas. Vi flaggar det för att det är en verklig räckvidds- och modernitetssignal som är gratis att åtgärda, inte för att det är ett misslyckande.
Vad det här kan kosta dig
Det orsakar sällan ett hårt avbrott — det är exakt varför det är informativt snarare än betygsatt. Men “osynlig kostnad” är fortfarande kostnad. Här är realistiska sätt en IPv4-only-inställning tyst arbetar mot dig:
-
En marginellt långsammare upplevelse för mobilkunder. Många mobiloperatörer kör nu bara IPv6 internt. En kund på ett sådant nätverk som når din IPv4-only-webbplats passerar genom deras operatörs översättningslager — ett extra hopp som lägger till latens och kan trängsel vid topptider. Din konkurrent med IPv6 ger samma kund en direkt, renare anslutning. På en kassasida adderar små långsamheter till övergiva varukorgar.
-
Ett svagare intryck hos tekniska köpare. Innan ett kontrakt skrivs på kör en köpares IT- eller säkerhetsteam ofta en snabb infrastrukturskanning. IPv4-only underkänner dig inte — men dual-stack läses som “modern och välskött,” och dess frånvaro läses som “lite bakom.” När du är nära på allt annat tippar dessa små signaler beslut.
-
Friktion på IPv6-dominanta marknader. Om du expanderar till regioner där IPv6 redan är normen — delar av Asien, Indien, flera europeiska mobilnätverk — tar det att vara direkt nåbar bort en verklig källa till långsamma eller hackiga anslutningar för dina nyaste, hårdast vunna kunder.
-
En missad upphandlingsruta. Ett växande antal offentliga och företags upphandlingsprocesser frågar nu uttryckligen om dina tjänster är IPv6-klara. “Nej” är ett besvärligt svar att ge när åtgärden var gratis.
-
Lämna gratis förbättring på bordet. Mycket ofta stödjer din värd eller CDN redan IPv6 utan extra kostnad — det slogs helt enkelt aldrig på. Det är en enkel, nollkostnadsvinst dina konkurrenter hämtade som standard och du inte hämtade.
Vad det faktiskt är
Varje enhet på internet behöver en adress. IPv4-adresser ser ut som 203.0.113.10 — fyra siffror, en pool av ungefär 4,3 miljarder, sedan länge uppbukad. IPv6-adresser ser ut som 2001:db8::1 — längre, hexadecimalt, med en pool så enorm att den är praktiskt taget obegränsad.
I din DNS — internets adressbok — lever dessa som två posttyper:
- A-post → din IPv4-adress (det gamla nätverket).
- AAAA-post → din IPv6-adress (det nya nätverket).
Vår kontroll gör ekvivalenten med att köra dig AAAA dindomän.com och rapporterar om AAAA-poster returneras.
Vad “bra” ser ut som: en dual-stack-inställning — dina befintliga A-poster orörda, med AAAA-poster publicerade bredvid dem, båda pekar på en server (eller lastbalanserare, eller CDN) som genuint svarar på båda nätverken och serverar samma webbplats. IPv4-användare fortsätter exakt som förut; IPv6-användare får en direkt väg. Du tappar inte IPv4 — du lägger till IPv6 bredvid det.
Vad “frånvaro” innebär: inga AAAA-poster. IPv6-only-användare kan i regel fortfarande nå dig via deras operatörs översättning, men aldrig direkt. Det är inte trasigt — det är bara en missad modernisering, vilket är varför det inte kostar dig poäng.
Så här åtgärdar du det (gratis, ~15–30 minuter)
Lämna det här till din IT-person eller den som hanterar din webbplats — åtgärden är gratis. Det är en DNS- och hostingändring, inte ett köp. Den gyllene regeln: lägg till IPv6 bredvid IPv4, aldrig istället för det (dual-stack), och bekräfta att målet faktiskt svarar på IPv6 innan du publicerar.
1. Ta reda på om din hosting/CDN stödjer IPv6 alls. Det är grindvakten. Om din värd inte har en IPv6-adress att erbjuda finns det inget mer att göra och ingen avgift för det. De flesta moderna plattformar och CDN:er stödjer det — ofta redan på.
2. Tillämpa det på din plattform:
-
Cloudflare: IPv6 är typiskt på som standard. När din webbplats är proxierad via Cloudflare (orange moln) svarar Cloudflare på IPv6 åt dig automatiskt — du lägger vanligtvis inte till AAAA-poster själv alls. Kontrollera att Nätverk → IPv6-kompatibilitet är aktiverat. Det här är den enklaste vägen med god marginal.
-
Google Workspace / Microsoft 365 (e-postsidan): e-postmottagningssidan är generellt redan IPv6-kapabel på leverantörens infrastruktur — du hanterar inte det. Den här sidans webbplats AAAA-poster handlar om din webbplats, inte deras e-postservrar; ingen åtgärd krävs för inkorgsleverantören i sig.
-
AWS: aktivera dual-stack på din lastbalanserare (ALB/NLB) eller instans, lägg sedan till en AAAA alias-post i Route 53 som pekar på den. För CloudFront är IPv6 en kryssruta i distributionsinställningarna.
-
Google Cloud / Azure: aktivera IPv6 (dual-stack) på lastbalanseraren eller instansen, skaffa IPv6-adressen och publicera AAAA-posten i din DNS.
-
Egenhostade / hanterade VPS: be din leverantör om en IPv6-adress, konfigurera din webbserver för att lyssna på IPv6 (och bekräfta att den serverar samma webbplats där), lägg sedan till DNS-posten:
dindomän.com. AAAA 2001:db8::1 www.dindomän.com. AAAA 2001:db8::1(Ersätt med din riktiga IPv6-adress. Behåll dina befintliga A-poster precis som de är.)
3. Testa innan du litar på det. Efter publicering, verifiera från ett IPv6-medvetet verktyg att AAAA-posten löses upp och webbplatsen faktiskt laddar över IPv6 (ett online “IPv6-test” eller curl -6 https://dindomän.com från en IPv6-kapabel maskin). En publicerad AAAA-post som pekar ingenstans är värre än ingen.
4. Skanna om. När AAAA-poster är live och svarar rapporterar den här kontrollen IPv6 som aktiverat. (Det ändrar inte ditt betyg — det var informativt hela tiden — men du har stängt gapet.)
Vanliga misstag
-
Publicera en AAAA-post som pekar på en server som inte lyssnar på IPv6. Det här är det klassiska självförsaktade problemet: IPv6-användare skickas till en död adress och din webbplats verkar trasig för dem bara — svårt att märka, eftersom det fungerar bra för dig på IPv4. Bekräfta alltid att målet svarar på IPv6 innan du publicerar.
-
Ersätta IPv4 istället för att lägga till IPv6. Du tar aldrig bort dina A-poster. Dual-stack behåller båda; att ta bort IPv4 skulle kapa majoriteten av användare över natten.
-
Lägga till apex-domänen men glömma
www(eller tvärtom), eller täcka webbplatsen men inte e-post/underdomänerna du bryr dig om. Var konsekvent över de värdnamn som spelar roll. -
Anta att det är klart för att värden “stödjer” IPv6. Stöd och aktiverat är olika. På Cloudflare är det vanligtvis automatiskt; på en råa VPS måste du konfigurera och publicera det själv.
-
Behandla det som brådskande. Det är det inte. Det är informativt. Gör dina betygsatta säkerhetskontroller (HTTPS, DMARC, DNSSEC, säkerhetshuvuden) först; lägg till IPv6 som framtidsinriktad polering när det passar.
Vanliga frågor
Om min IPv4-only-webbplats fortfarande laddar för alla, varför spelar IPv6 roll alls?
För att 'laddar fortfarande' gör mycket jobbet. Användare på IPv6-only-nätverk — vanligt på mobiloperatörer och i allt högre grad på andra ställen — når en IPv4-only-webbplats via deras operatörs översättningslager (NAT64/464XLAT). Det fungerar vanligtvis, men det är ett extra hopp som lägger till lite latens och är ytterligare en delad infrastruktur som kan vara långsam eller trång vid topptider. Att stödja IPv6 ger dessa användare en direkt anslutning istället. Det är en jämnhets- och framtidssäkringsförbättring, inte en 'trasig kontra fungerande'-strömbrytare — vilket är varför det är informativt och inte betygsätts.
Det här påverkar inte mitt betyg — ska jag bry mig?
Det är genuint valfritt, men det är också gratis och lågriskartat, så det är värt att göra när din IT-person nästa gång är i DNS- eller hostingkonsolen. Många leverantörer (Cloudflare, de stora molnplattformarna, massor av värdar) stödjer IPv6 från lådan — ibland är det bara en kryssruta. Om din leverantör inte stödjer det alls är det ett bra skäl att lämna det för nu; ingenting dåligt händer med ditt betyg åt något håll. Behandla det som en städning, inte en brandkår.
Jag är inte teknisk — vad gör jag faktiskt?
Lämna avsnittet 'Så här åtgärdar du det' till den som driver din webbplats eller DNS och fråga: 'Kan vi lägga till IPv6 (AAAA-poster) för vår webbplats? Det är gratis och bör inte bryta något.' Om du är på Cloudflare är det vanligtvis redan på. Om du är på en hanterad värd eller en stor molnplattform är det ofta en enda inställning. Om din värd inte stödjer IPv6 alls finns det ingenting att göra — och ingen avgift för det.
Vad är en AAAA-post, i klarspråk?
Din DNS är internets adressbok. En 'A-post' listar din webbplats gammeldagsadress (IPv4); en 'AAAA-post' (fyra A:n) listar dess nyare IPv6-adress. Att lägga till IPv6-stöd innebär att publicera AAAA-poster bredvid dina befintliga A-poster, så att enheter på det nya nätverket kan hitta dig direkt. Vår kontroll slår helt enkelt upp dina AAAA-poster (det tekniska ekvivalenta med att köra 'dig AAAA dindomän.com') och rapporterar om några finns.
Kan att lägga till IPv6 bryta min webbplats eller e-post?
Det är lågriskartat när det görs rätt, men inte nollrisk, vilket är varför du testar. Det säkra mönstret är 'dual-stack' — du behåller alla dina befintliga IPv4 (A)-poster precis som de är och lägger till IPv6 (AAAA)-poster bredvid dem. IPv4-användare fortsätter oförändrade; IPv6-användare får en ny direkt väg. Det att verifiera är att vad AAAA-posten pekar på (din server eller lastbalanserare) faktiskt lyssnar på IPv6 och serverar samma webbplats — en gammal eller fel AAAA-post kan skicka IPv6-användare till en död adress. På hanterade plattformar och CDN:er hanteras det åt dig; på egenhostade inställningar, bekräfta att servern svarar på IPv6 innan du publicerar.
Gör IPv6 min webbplats säkrare?
Inte i sig — det är primärt en räckvidds- och modernitetssförbättring, inte en säkerhetskontroll, vilket är en del av varför det inte betygsätts. Det refereras i bredare riskhanteringsramverk (till exempel NIS2:s allmänna cybersäkerhetsriskhanteringsskyldigheter) som en del av att köra aktuell, resilient infrastruktur, men att lägga till en AAAA-post härdar dig inte på det sätt HTTPS, DMARC eller DNSSEC gör. Gör de betygsatta säkerhetskontrollerna först; behandla IPv6 som framtidsinriktad infrastrukturhygien ovanpå.