Yritysverkon suorituskykyä mitataan usein vain yhteysnopeuksilla: kuinka monta megabittiä tai gigabittiä sekunnissa yhteys tarjoaa. Silti todellinen käyttökokemus – viiveet, vasteajat ja sovellusten nopeus – riippuvat yhä vähemmän kaistan leveydestä ja yhä enemmän verkon rakenteesta ja protokollista. Yksi tällainen “rakenteellinen” ratkaisu on jo täällä, vaikka sen käyttöönotto monessa yrityksessä on kesken: IPv6. Sen avulla voit parantaa verkon suorituskykyä – nostamatta nopeuksia.
IPv6 nopeuttaa ilman lisäkaistaa
IPv6 ei ole vain “uusi osoiteavaruus”. Sen suurin käytännön hyöty tulee siitä, että se poistaa tarpeen osoitemuunnoksille (NAT , Network Address Translation), joita IPv4-verkoissa tarvitaan yhä monessa kohdassa – esimerkiksi reitittimissä, mobiiliverkoissa ja SD-WANin reunoilla.
Jokainen NAT-taso lisää pieniä viiveitä ja monimutkaistaa yhteyden muodostusta. IPv6:lla liikenne kulkee suoremmin, ilman osoitteenmuunnosta, ja usein myös suorempaa BGP-reittiä pitkin.
Tuloksena on pienempi RTT (round-trip time), vähemmän viiveen vaihtelua ja nopeampi yhteys SaaS-palveluihin esimerkkinä Microsoft 365, Teams tai Google Workspace. Käytännön mittauksissa IPv6-yhteydet ovat monilla alueilla 5–20 % nopeampia kuin vastaavat IPv4-yhteydet – vaikka fyysinen verkko olisi sama.
IPv6 on arkea mobiilissa – mutta ei vielä yrityksissä
APNICin ja Google Statisticsin mukaan 45–50 % maailman Internet-käyttäjistä tavoittaa verkon IPv6:n kautta.
Suomessa kuluttajaverkot ovat edelläkävijöitä:
- Mobiiliverkoissa IPv6 on käytössä lähes kaikilla operaattoreilla.
- Kotilaajakaistoissa dual-stack on jo normi.
Yritysverkoissa tilanne on toisenlainen.
Vaikka useimmat NGFW-, SD-WAN- ja SASE-ratkaisut tukevat IPv6:ta täysin, se ei ole oletusarvoisesti käytössä. Syitä ovat mm. konfiguroinnin monimutkaisuus, kahdennetut palomuuripolitiikat ja huoli hallittavuudesta. Käytännössä tämä tarkoittaa, että monet yritysverkot ja julkiset palvelut toimivat yhä IPv4-painotteisesti – vaikka valmiudet IPv6:lle olisivat olemassa.
Kokeilu: IPv6 näkyy jo kolmanneksessa Suomen suurimpien yritysten verkkosivuista
Testasimme Suomen 50 suurimman yrityksen verkkosivujen IPv6-tuen. Jokaista yritystä vastasi kaksi domainia (.fi ja .com), yhteensä 100 osoitetta. Testi tehtiin PowerShellin Test-NetConnection-komennolla, ja tarkastelun kohteena oli, avautuuko TCP-portti 443 (HTTPS) IPv6-osoitteeseen.
Tulokset: 32 % domaineista vastasi IPv6-osoitteella ja hyväksyi HTTPS-yhteyden. Toisin sanoen vain noin kolmannes Suomen suurimmista yrityksistä toimii natiivilla IPv6:lla. Yllättäen 2/3 Suomen suurista teleoperaattoreista ei tarjonnut IPv6-tukea sivuilleen.
Laajennettuna 200 suurimman yrityksen joukkoon tulos olisi todennäköisesti 30–40 %. Kansainvälisesti tämä on hyvä tulos – mutta kertoo myös, että enemmistö yrityksistä ei vielä tarjoa IPv6-palvelua edes verkkosivuillaan, puhumattakaan sisäverkoista tai pilviyhteyksistä.
Miksi tämä on tärkeää nyt?
Pilvipalvelut, CDN-verkot ja SaaS-tuotteet (Microsoft, Google, Cloudflare, Akamai) priorisoivat IPv6-reittejä.
Ne tarjoavat usein suoremman ja vähemmän kuormitetun reitityksen IPv6:lla.
Kun yhteys muodostetaan IPv6:lla:
- liikenne ohjautuu suoremmin lähimpään CDN-solmuun
- NAT-ketjut jäävät pois
- Happy Eyeballs v2 -algoritmi valitsee automaattisesti nopeamman protokollapinon (kaikki selaimet)
Käytännössä IPv6 parantaa yhteysnopeutta ja käyttäjäkokemusta – ilman, että kaistaa kasvatetaan.
NAT – näkymätön pullonkaula yritysverkoissa
NAT on ollut välttämätön osa IPv4-aikakauden verkkoja, mutta sen vaikutusta suorituskykyyn ja skaalautuvuuteen aliarvioidaan yhä usein. Kun liikenne kulkee useamman NAT-pisteen läpi – esimerkiksi asiakkaan palomuurin ja Clobal SASE-palvelun kautta – syntyy helposti piilossa oleva pullonkaula ja 2 x NAT, jota ei näe perinteisen kaistanleveyden mittareissa.
Miksi NAT rajoittaa suorituskykyä
- Jokainen NAT-yhteys vaatii osoite- ja porttimuunnoksen sekä tilaseurannan.
- Kuormitushuipuissa rajoittava tekijä on usein flows/s tai session-taulun koko, ei megabitit.
- Yhdellä julkisella IPv4-osoitteella on vain ~65 000 lähdeporttia – ne voivat täyttyä nopeasti suurissa SaaS-ympäristöissä (Teams, M365, QUIC).
- Tupla-NAT lisää viivettä, monimutkaisuutta ja diagnostiikan vaikeutta.
NAT-ongelmien tunnusmerkkejä
- Yhteydet muodostuvat hitaasti tai epäluotettavasti.
- Viiveet vaihtelevat ilman näkyvää syytä.
- Palomuuri ilmoittaa “no ports available” -virheitä.
- Sovellukset (erityisesti UDP/QUIC) käyttäytyvät epävakaasti.
Kuinka ongelmaa voi vähentää
- Vältä tupla-NATia – määritä reititys niin, että vain yksi laite tekee osoitteenmuunnoksen ennen pilvipalvelua.
- IPv6 ensisijaiseksi – poistaa NAT:n tarpeen kokonaan ja palauttaa end-to-end-läpinäkyvyyden.
- Skaalaa oikein – seuraa uusia yhteyksiä sekunnissa ja käytettyjen porttien määrää, ei vain kaistanleveyttä.
- Segmentoi liikenne – suuret SaaS-palvelut voivat hyötyä omasta egress-osoitteesta tai NAT-poolista.
- Hyödynnä SD-WAN-älyä – ohjaa liikenne optimaaliselle uloskäynnille ilman keskitettyä NAT-solmua.
NAT ei yksin kaada verkkoa, mutta se voi olla juuri se näkymätön tekijä, joka erottaa sujuvan pilvikokemuksen ja satunnaiset viivepiikit. IPv6 ja modernit SD-WAN-ratkaisut tarjoavat vihdoin tavan päästä eroon tästä vuosikymmeniä mukana kulkeneesta kompromissista.
5G SA, MVNO ja IPv6 – alkuperäinen tavoite on jäänyt puolitiehen
5G Stand Alone (SA) -verkon alkuperäinen suunnittelutavoite oli siirtyä IPv6-pohjaiseen, NAT-vapaaseen arkkitehtuuriin, jossa jokaisella laitteella on oma reititettävä IP-osoite ja datapolku kulkee suorinta mahdollista reittiä. Käytännössä suuri osa yritys- ja MVNO-liittymistä toimii yhä IPv4-only + CGNAT -mallissa, koska operaattorit eivät tarjoa IPv6:ta kaikille APN-profiileille. Tämä luo monikerroksisen NATin, porttirajoituksia ja epäsuoria reittejä, jotka heikentävät suorituskykyä ja rajoittavat skaalautuvuutta – erityisesti AI-agenttien ja massiivisten 5G-laitemäärien aikakaudella. IPv6 poistaisi nämä pullonkaulat, mutta sen käyttöönotto 5G SA -yritys- ja MVNO-palveluissa on edelleen kesken, mikä estää verkkoa saavuttamasta alkuperäistä tavoitettaan.
AI-agentit ja NAT – Pullonkaula enenkuin kasvu on edes alkanut
AI-agenttien nopea yleistyminen muuttaa yritysverkkojen kuormaprofiilin täysin. Yksi agentti avaa tyypillisesti useita samanaikaisia yhteyksiä, ja kun agentteja on tuhansia, NAT-taulut täyttyvät nopeasti. Yksi julkinen IPv4-osoite tukee vain noin 55 000–64 000 flow’ta, joten agenttiparvet voivat aiheuttaa pullonkauloja ilman, että kaistanleveyskasvu auttaa asiaa.
Lisäksi suurin osa agenteista toimii yksityisissä verkoissa tai 5G/CGNAT-ympäristöissä, joissa symmetrinen NAT estää agenttien väliset suorat yhteydet. Tämä tekee peer-to-peer -kommunikaatiosta lähes mahdotonta ja aiheuttaa viiveitä, porttien loppumista ja epäluotettavuutta, jotka ovat vaikeita diagnosoida.
Yksi ratkaisu on IPv6. Se poistaa NATin, antaa jokaiselle agentille oman osoitteen ja palauttaa aidon end-to-end -yhteyden. AI-agenttien aikakaudella IPv4 + NAT ei skaalaudu — IPv6 kyllä.
Yhteenveto
Suorituskykyä ei aina tarvitse ostaa lisää – sen voi vapauttaa olemassa olevasta verkosta poistamalla pullonkaulat ja ylimääräiset NAT-kerrokset. IPv6 on jo täällä: kolmannes Suomen suurimmista yrityksistä käyttää sitä julkisissa verkkopalveluissaan, ja operaattorit tarjoavat sen vakiona.
Suurimmat pilvitoimijat (Microsoft, Google, Cloudflare, Akamai) priorisoivat IPv6-liikennettä ja tarjoavat pienempää latenssia. Seuraava askel on ottaa se käyttöön myös yritysverkoissa, SD-WAN- ja SASE-yhteyksissä – ei huomenna, vaan nyt.
5Feet Networks Oy