Näkymät
Sisällysluettelo |
IPv6
Internetin suosio on noussut valtaviin mittasuhteisiin muutaman vuoden aikana. Suosion kasvu näkyy niin käyttäjien kuin palveluiden määrässä. Internetin käyttämä tekniikka pohjautuu tietotekniikan aikajanalla mitattuna erittäin vanhaan standardiin. Vuodelta 1981 oleva standardi pohjautuu legendaariseen ARPANET-ympäristöön, joka tunnetaan koko Internetin perustana. Vaikka standardi on vanha, on hämmästyttävää, että siihen pohjautuva tekniikka pystyy vielä tänäkin päivänä toimimaan, vaikka alunperin tuskin kukaan pystyi ennustamaan tällaisia käyttäjämääriä.
Vanhalle standardille on saatu jatkoaikaa lukemattomilla parannuksilla, mutta silti standardissa on paljon asioita, joita ei pystytä korjaamaan ilman radikaaleja muutoksia. Niinpä vuonna 1995 julkaistiin ensimmäinen standardi, joka tunnetaan IPv6-tekniikan lähtöpaaluna. Uudistuksessa otettiin huomioon juuri niitä asioita, jotka olivat edellisessä ongelmallisia. Nykyään nämä tekniikat tunnetaan lyhentein IPv4 ja IPv6.
IPv4-tekniikan suurimmat ongelmat * 32-bittinen osoitteistus * IP-osoitteiden määrä * Verkkojen koko * Verkon arkkitehtuuri * Reititys * Osoitteiden muutokset (NAT) * Verkkoliityntä oletuksena vain yhdessä verkossa * Siirtyminen verkkojen välillä * Osoitteiden hallinta * Broadcast ja ARP * Tietoturva * Toimintojen päällekkäisyys (Tarkistesummat) * Historian painolastit verkkotekniikoista (MTU) * .....
IPv6-tekniikan tarkoitus on parantaa edellä listattuja asioita. Muutokset ovat todella merkittäviä, ja on päivänselvää, ettei näin suuria muutoksia oteta käyttöön päivässä eikä kahdessa. Päivänselvää on myös se, että IPv4-tekniikan ongelmien vuoksi, IPv6 tulee varmuudella käyttöön.
Enää ei kannata tuhlata aikaa spekulointiin, että tuleeko IPv6 vai ei! Kannattaa keskittyä siihen, että milloin IPv6 otetaan käyttöön!
IPv6-tekniikan käyttöönotto on vielä alan lehtien ja julkaisujen mukaan lapsenkengissä. Tämä on osakseen totta, jos katsotaan asiaa yleisesti saatavilla olevien liittymien kannalta. Tekniikan käyttöönotossa suurin pullonkaula on tällä hetkellä operaattorit. Sillä suurin osa sovelluksista ja käyttöjärjestelmistä tukee jo kyseistä tekniikka, eli organisaatioiden sisällä on jo lähes täysi valmius käyttöönotolle.
Käsitteet
IPv6-tekniikkaan liittyvät standardit ovat uudistuneet ja täydentyneet useita kertoja. Esimerkiksi RFC 1883 on uudistunut versioon RFC 2460, mutta perusasiat ovat pysyneet alusta alkaen samoina. Ison muutoksen on käynyt läpi myös esimerkiksi osoitteistuksen määrittelevä standardi, joka oli aluksi RFC 1884, sitä seurasi RFC 2373, ja taas RFC 3513, ja lopuksi RFC 4291. Standardin päivittyminen muutaman vuoden välein on johtanut tilanteeseen, jossa odotetaan sitä lopullista. Tilanne on mielenkiintoinen, sillä esimerkiksi verkon päätelaitteet päivittyvät jatkuvasti. Käyttöjärjestelmiin tulee muutoksia päivityksien ja uudistuksien myötä lähes päivittäin. On hienoa, että standardi pystyy mukautua vallalla olevaan tilanteeseen, ja näin parantaa verkkojen toimintaa.
Standardi muuttuu, mutta perusasiat pysyvät lähes muuttumattomina!
Standardi RFC 2460 määrittelee seuraavat käsitteet
* node - laite, joka tukee IPv6-tekniikkaa * router - verkon laite, joka välittää IPv6-liikennettä * host - verkon laite, joka ei välitä IPv6-liikennettä * upper layer - OSI-mallissa verkkokerroksen päällä olevat kerrokset * link - laitteiden välinen yhteys eli linkki * neighbors - samassa linkissä olevat laitteet * interface - liityntä linkkiin eli verkkoliityntä * address - laitteilla oleva osoite eli IP-osoite * packet - IPv6-verkossa laitteiden välillä liikkuva paketti * link MTU - Samassa linkissä olevien laitteiden välillä liikkuvan paketin maksimipituus * path MTU - Missä tahansa verkossa olevien laitteiden välillä liikkuvan paketin minimipituus.
Käsitteillä on yksinkertaistettu verkkoa ja sen osapuolten toimintaa. Esimerkiksi verkossa on vain kahdessa roolissa olevia laitteita eli router ja host. Iso osa käsitteistä on tuttuja jo IPv4-tekniikasta, joten siirtymä näiden osalta on suhteellisen pieni. Toki käsitteiden arvot ovat muuttuneet lähes alusta loppuun, sillä esimerkiksi link MTU ja path MTU ovat aivan jotain muuta kuin aikaisemmin.
Valmius
IPv6 on OSI-mallin verkkokerrokseen vaikuttava tekniikka. Tällä kerroksessa toimiva laitteita ovat node-tyyppiset laitteet. Lähes jokaiselle laitteet on yhteistä se, että niissä on käyttöjärjestelmä. Käyttöjärjestelmävaihtoehtoja on lukematon määrä, joista yleisimmissä on täysi tuki IPv6-tekniikalle. Käyttöjärjestelmissä on sovelluksia, jotka tarjoavat verkkoihin palveluita. Näitä palvelinohjelmiksi kutsutuissa sovelluksissa on valtaosassa IPv6-valmius. Palvelinohjelmistoja käytetään käyttöjärjestelmiin asennettavilla sovellusohjelmistoilla, joissa lähes jokaisessa on myös IPv6-tuki.
http://www.ipv6.org/ http://www.ipv6ready.org/ http://www.ipv6forum.com/ http://www.go6.net/ http://www.ipv6-to-standard.org/
Miksi IPv6-tekniikan käyttöönotto ei sitten etene niin nopeasti kuin pitäisi? Mikä ratkaisuksi, sillä fakta on se, että esimerkiksi julkiset IPv4-osoitteet loppuvat lähivuosien aikana kesken?
Kysymyksiä, joita lähes jokainen kysyy! Vastauksia ja selityksiä löytyy joka paikasta! Entä konkreettisia toimia?!
IPv6-osoitteet
Näkyvin ja suurin muutos IPv6-tekniikassa on osoitteen täydellinen muuttuminen. Perinteisessä IPv4-tekniikassa osoitteen pituus on 32 bittiä. Tämä tarkoittaa, että teoriassa käytettävissä olevia osoitteita on reilu neljä miljoona. Luku kuulostaa suurelta, mutta käytännössä käytettävien osoitteiden määrä on huomattavasti pienempi, ja ennen pitkää riittämätön. Elektroniikkateollisuus kehittää yhä pienempiä ja monipuolisempia laitteita, joiden tarkoitus on olla osana Internettiä. Niillä voidaan esimerkiksi surffata, käyttää sähköpostia ja kuunnella musiikkia, mutta yhteistä niille on se, että ne tarvitsevat aina osoitteen. Tästä näkökulmasta katsottuna IPv4-tekniikan osoitteiden määrä ei riitä mihinkään.
Alla on perinteisen IPv4:n otsikon rakenne. Tämä on käytössä siis jokaisessa datapaketissa, joka Internet-verkossa liikennöi. Jos esimerkiksi ladataan yhden megatavun tiedosto, näitä alla olevaan otsikkoon perustuvia paketteja siirretään kaikkiaan noin tuhannen kappaletta. Kyse on todella merkittävästä, koko Internetin toimintaan liittyvästä asiasta. Otsikosta voidaan todeta, että se sisältää paljon muutakin kuin pelkät osoitteet.
| + | Bitit 0–3 | 4–7 | 8–15 | 16–18 | 19–31 | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Versio | Otsikon pituus | Palvelun tyyppi | Kehyksen pituus | |||||||||||||||||||||||||||||||||||||||||||||
| 32 | Yksilötunnus | Liput | Lohkon sijainti | ||||||||||||||||||||||||||||||||||||||||||||||
| 64 | Elinikä | Protokolla | Otsikon tarkistesumma | ||||||||||||||||||||||||||||||||||||||||||||||
| 96 | Lähdeosoite (32 bittiä) | ||||||||||||||||||||||||||||||||||||||||||||||||
| 128 | Kohdeosoite (32 bittiä) | ||||||||||||||||||||||||||||||||||||||||||||||||
| 160 | Optiot+täyte | ||||||||||||||||||||||||||||||||||||||||||||||||
| 160 tai 192+ | Data | ||||||||||||||||||||||||||||||||||||||||||||||||
IPv6-tekniikassa on haluttu tehostaa ja selkeyttää koko OSI-mallia ja erityisesti sen verkkokerroksen toimintaa. Otsikosta on karsittu IPv4:n toiminnallisuuksia, joista yhtenä esimerkkinä voisi mainita jokaiselle paketille laskettavan tarkistesumman. Tarkistesumman laskeminen on lähes aina tässä kerroksessa turhaa, sillä se tehdään aina linkkikerroksella ja lähes aina sovelluskerroksilla. Näin vähennetään prosessorin laskentakuormaa ja nopeutetaan verkon toimintaa. Otsikko sisältää luonnollisesti myös osoitetiedot.
| + | Bitit 0–3 | 4–11 | 12-15 | 16–23 | 24–31 | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Versio | Luokkakenttä | Vuon tunniste | ||||||||||||||||||||||||||||||||||||||||||||||
| 32 | Kuorman pituus | Seuraava otsikko | Elinikä | ||||||||||||||||||||||||||||||||||||||||||||||
| 64 | Lähdeosoite (128 bittiä) | ||||||||||||||||||||||||||||||||||||||||||||||||
| 96 | |||||||||||||||||||||||||||||||||||||||||||||||||
| 128 | |||||||||||||||||||||||||||||||||||||||||||||||||
| 160 | |||||||||||||||||||||||||||||||||||||||||||||||||
| 192 | Kohdeosoite (128 bittiä) | ||||||||||||||||||||||||||||||||||||||||||||||||
| 224 | |||||||||||||||||||||||||||||||||||||||||||||||||
| 256 | |||||||||||||||||||||||||||||||||||||||||||||||||
| 288 | |||||||||||||||||||||||||||||||||||||||||||||||||
| 320+ | Data | ||||||||||||||||||||||||||||||||||||||||||||||||
IPv6 tarjoaa teoriassa 128 bitillä niin valtavan määrän osoitteita, ettei niitä saada käytännössäkään loppumaan koskaan. Tämä luo aivan uuden mahdollisuuden koko Internettiä ajatellen, sillä jokaiselle Internetissä olevalle laitteelle voidaan antaa vähintään yksi niin sanottu julkinen osoite. Tämä tarkoittaa sitä, että jokainen laite voi keskustella toistensa kanssa ilman keinotekoisia yhteyden välittäjiä. Esimerkiksi Internet-yhteyden kautta saadaan suora yhteys valvontakameraan, ilman lisäkustannuksia ja välityslaitteita.
Osoitteiden muodot
Verkossa liikennöidessään paketti on aina verkkokerroksen tekniikasta välittämättä bittimuodossa. Bitit voidaan esittää isompana kokonaisuutena eli tavuna. Bitit ja tavut muutetaan yleensä ihmiselle sopivampaan lukujärjestelmään, jotta laskutoimituksien tekeminen ja arvojen tulkitseminen olisi ihmisen kannalta helpompaa.
IPv4-tekniikassa osoitteen esitetään yleensä kymmenkantamuodossa eli kaikki esitetään numeroina, jotka ovat välillä 0-9. Kaikki osoitteet ovat välillä 0.0.0.0 ja 255.255.255.255. IPv4:n tyypillinen osoite on siis muotoa 192.168.11.17, joka bittiesityksenä näyttää seuraavalta.
192.168.11.17 => 11000000.10101000.00001011.00010001 32-bittinen konekielinen osoite => 11000000101010000000101100010001
Bittiesitysmuotoa käyttävät kaikki verkkokerroksella olevat laitteet. Niinpä tätä asiaa on lähdetty kehittämään tästä suunnasta. Päämääränä on siis ollut kehittää muoto, joka on ihmisen näkökulmasta yksinkertainen. IPv4-tekniikassa päädyttiin siis yllämainittuun.
IPv6-osoitteen 128 bitin pituus sulki pois numeroesitysmuodon, sillä näin perusajatus olisi kadonnut. Jos bittiesitysmuoto on se, jota laitteet käyttävät, oli keksittävä ihmisille uusi esitystapa. Näkyvin muutos on kymmenkantamuodon muuttaminen heksadesimaalimuotoon, jolloin numeroiden lisäksi on käytössä kirjaimet a-f. Tämän etu on esitetty alla
255.255.255.255 => 11111111.11111111.11111111.11111111 => ff.ff.ff.ff
=> 11111111111111111111111111111111 => ffffffff
255.255.255.255 vs ff.ff.ff.ff => Kaikki merkit samoja, ja neljä merkkiä vähemmän!
Heksadesimaalimuodolla säästetään merkkejä. Tämä säästö hyödynnetäänn myös niin, että pisteiden käyttöä vähennetään. Selvyyden vuoksi pisteet korvataan kaksoispisteillä, josta päästäänkin osoitteen lopulliseen muotoon, joka esitetty alla
128-bittinen konekielinen osoite => 11111111111111111111111111111111111111111111111111111111111...... IPv6-osoite => ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Kaikki IPv6-osoitteet => 0000:0000:0000:0000:0000:0000:0000:0000 - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Osoite muodostuu kahdeksasta 16-bitin ryhmästä, jotka on esitetty heksadesimaalein. Jokaisen ryhmän lukuarvo voi olla välillä 0-65535. Osoitteen esitystapaa on hiottu vielä niin, että 0-merkillä on omat esittämissääntönsä. Näitä sääntöjä on lueteltu alla
Jos yhden ryhmän lukuarvo on esimerkiksi 600 eli heksaluku 258, ei eteen tarvitse laittaa nollaa 600 => heksaluku 258 => normaalisti ..:0258:.. => voidaan poistaa etunolla! => eli ..:258:.. Osoitteesta voidaan yksi pitkä nollaryhmä korvata kahdella kaksoipisteellä fe80:0000:0000:0000:0000:0000:a462:0000 => Korvataan yksi nollaryhmä! => fe80::a462:0000
Edellä mainittujen sääntöjen käyttäminen on arkipäivää. Seuraavassa yhteenvetona vasemmalla olevat koneiden näyttämät osoitteet, jotka on muunnettu niin sanottuun todelliseen muotoon.
fe80::a00:27ff:fec1:a462 => fe80:0000:0000:0000:0a00:27ff:fec1:a462 fc00::230:1bff:fe47:ce03 => fc00:0000:0000:0000:0230:1bff:fe47:ce03 2001::1 => 2001:0000:0000:0000:0000:0000:0000:0001
Osoiteluokitukset
Vuosien varrella IPv4-tekniikkaan on tullut parannuksia, joilla on pyritty samaan tekniikalle lisäaikaa. Yksi tällaisista on niin sanotut Privaatit verkot, joita käytetään nykyisin esimerkiksi lähes jokaisessa organisaatiossa. Standardi määrittelee kolme aluetta, jotka on esitelty alla. IP-osoitteet ovat täysin normaaleja osoitteita, jotka eivät ole osana koko Internettiä. Näiden osoitteiden tarkoitus on tuoda esimerkiksi organisaatioiden sisäiseen käyttöön oma verkko, johon ei ole yhteyttä Internetistä.
Privaatit osoitealueet 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255
Privaatista verkosta liikennöidään Internettiin käyttäen NAT-tekniikka. Näin ollaan säästetty valtava määrä IANAn hallinnoimia julkisia IP-osoitteita, mutta ollaan menetetty iso osa Internetin tarjoamista mahdollisuuksista. Ollaan menetetty laitteelta-laiteelle -tyyppiset yhteydet lähes täysin. IPv6-tekniikan yhtenä tarkoituksena on poistaa NAT-tekniikan mukaan tuomat ongelmat.
Ensimmäinen iso uudistus IPv4-tekniikkaan verrattuna on se, että jokaisella verkkoliitynnällä (esim. verkkokortilla) voi olla lukematon määrä osoitteita. Näistä osoitteista vähintään yksi on tyyppiä Link local, jonka avulla jokainen verkon laite voi kommunikoida samassa verkossa olevien laitteiden kanssa. Tämä osoite ei näy Internetiin, joten se on tarkoitettu verkkokohtaiseen kommunikointiin. Vastaa siis melkein edellisessä esiteltyä NAT-tekniikkaa. Link local-osoite muodustuu automaattisesti käyttäen EUI-64-menetelmää. Osoite on siis aina sidottu verkkoliitynnän MAC-osoitteeseen. Tästä esimerkki alla
Verkkokortin MAC-osoite 00:30:1b:47:ce:03 => Link Local -osoite fe80::230:1bff:fe47:ce03
00:0d:0b:87:7c:5c => fe80::20d:bff:fe87:7c5c
Link local -osoite on siis jokaisella verkkoliitynnällä, ja on aivan normaali osoite, jota käyttäen voidaan kommunikoida. Liikenne rajoittuu kuitenkin aina yhteen verkkoalueeseen, jolloin verkkoalueita yhdistäessä tarvitaan uusi osoite. Näitä osoitteita kutsutaan julkisiksi osoitteiksi. Julkisista osoitteista on lohkottu yleiseen käyttöön ja niin sanottuun sisäiseen käyttöön osoitealueet. Julkiset osoitteet ovat esimerkiksi muotoa 2000::1, ja ne on tarkoitettu nimensä mukaisesti Internetissä liikennöintiin. Julkiset, mutta sisäiset osoitteet, ovat muotoa fc00::1. Näiden osoitteiden tarkoitus on esimerkiksi yhdistää organisaatioiden verkkoalueet yhteen.
Yhdellä verkkoliitynnällä voi olla samanaikaisesti käytössä seuraavat osoitteet
fe80::230:1bff:fe47:ce03 => Link Local eli verkkoalueen sisällä fc00::230:1bff:fe47:ce03 => Unique Local eli paikallisten verkkoalueiden osoite 2001:0998::230:1bff:fe47:ce03 => Global Unicast eli Internetissä käytetty julkinen osoite
Verrattaessa tilanne IPV4-tekniikkaan, niin huomaa erittäin suuren muutoksen. IPv4-osoitteita jaetaan laitteille tyypillisesti yksi kappale, ja tätä osoitetta laite käyttää liikennöintiin. Verkossa kaikki perustuu tuohon yhteen osoitteeseen, jonka perusteella tehdään esimerkiksi muunnoksia (NAT), reititystä ja palomuurisääntöjä. IPv6 antaa mahdollisuuden verkkoalueiden sekä verkkojen yksinkertaistamiseen ja selkeyttämiseen.
IPv6 ja verkottaminen
Jokainen laite Internetissä kuuluu tiettyyn verkkoalueseen. IPv6-verkossa laitteesta käytetään nimitystä node, joka on joko host tai router. Host on laite, joka kommunikoi toisen host-laitteen kanssa. Router on laite, joka huolehtii verkkoalueiden yhdistämisestä eli tunnetaan yleisesti nimellä reititin. Host voi olla matkapuhelin, kannettava tietokone, palvelin, valvontakamera tai vaikkapa ilmankosteutta mittaava anturi. Verkottaminen on näiden laitteiden yhdistämistä.
Aliverkot
Jokainen laite, jolla on IP-osoite, on osa aliverkkoa. Näin ollen IP-osoite ja aliverkon määrittelevä peite kulkevat aina käsi kädessä. Tämä näkyy esimerkiksi IPv4-tekniikassa seuraavasti
Laitteen IP-osoite on 192.168.11.17 ja määritelty aliverkon peite on 255.255.255.0 Osoite => 11000000101010000000101100010001 => 192.168.11.17 Peite => 11111111111111111111111100000000 => /24 Verkko-osoite => 11000000101010000000101100000000 => 192.168.11.0 Yleislähetys => 11000000101010000000101111111111 => 192.168.11.255 Samassa verkossa olevien laitteiden IP-osoitteet Pienin osoite => 11000000101010000000101100000001 => 192.168.11.1 Suurin osoite => 11000000101010000000101111111110 => 192.168.11.254 Verkkoalueen 192.168.11.0/24 käytettävissä olevat osoitteet ovat välillä 192.168.11.1 - 192.168.11.254
Kaikki laitteet, joilla on määriteltynä IP-osoite edelliseltä väliltä sekä aliverkon peitteeksi mainittu, kuuluvat samaan aliverkkoon. Aliverkko on siis alue, johon kuuluu tietty määrä laitteita. Jokaisella laitteella on eri IP-osoite, mutta sama aliverkon peite. Saman aliverkossa olevat laitteet pystyvät kommunikoimaan keskenään käyttäen niille määriteltyjä IP-osoitteita.
IPv6-tekniikassa on aliverkottaminen tapahtuu täysin saman periaatteen mukaan kuin IPv4-tekniikassa. Poikkeuksena on se, että aliverkon peitteen pituus on moninkertainen ja merkintään käytetään /-muotoa. Seuraavassa esimerkki
osoite => fc00:0000:0000:0000:0212:f0ff:feb2:0e40 => fc00::212:f0ff:feb2:e40 Peite => ffff:ffff:ffff:ffff:0000:0000:0000:0000 => /64 Verkko-osoite => fc00:0000:0000:0000:0000:0000:0000:0000 => fc00:: Samassa verkossa olevien laitteiden IP-osoitteet Pienin osoite => fc00:0000:0000:0000:0000:0000:0000:0001 => fc00::1 Suurin osoite => fc00:0000:0000:0000:ffff:ffff:ffff:ffff => fc00::ffff:ffff:ffff:ffff Verkkoalueen fc00::/64 käytettävissä olevat osoitteet ovat välillä fc00::1 - fc00::ffff:ffff:ffff:ffff
Edellä mainittu aliverkon peite on paljon käytetty. Kyseistä peitettä käyttäessä aliverkkoon mahtuu niin paljon laitteita, etteivät osoitteet tule varmuudella loppumaan kesken.
Aliverkkojen pyörittämiseen ja laskemiseen on olemassa paljon hyviä ohjelmia. Esimerkiksi Linuxiin saatavat Ipcalc ja Sipcalc-ohjelmat ovat erittäin käteviä näissä asioissa. Esimerkki alla
ville@ville-ibm:~# sipcalc 192.168.11.17/24 -[ipv4 : 192.168.11.17/24] - 0 [CIDR] Host address - 192.168.11.17 Host address (decimal) - 3232238353 Host address (hex) - C0A80B11 Network address - 192.168.11.0 Network mask - 255.255.255.0 Network mask (bits) - 24 Network mask (hex) - FFFFFF00 Broadcast address - 192.168.11.255 Cisco wildcard - 0.0.0.255 Addresses in network - 256 Network range - 192.168.11.0 - 192.168.11.255 Usable range - 192.168.11.1 - 192.168.11.254 - ville@ville-ibm:~# sipcalc fc00::212:f0ff:feb2:e40/64 -[ipv6 : fc00::212:f0ff:feb2:e40/64] - 0 [IPV6 INFO] Expanded Address - fc00:0000:0000:0000:0212:f0ff:feb2:0e40 Compressed address - fc00::212:f0ff:feb2:e40 Subnet prefix (masked) - fc00:0:0:0:0:0:0:0/64 Address ID (masked) - 0:0:0:0:212:f0ff:feb2:e40/64 Prefix address - ffff:ffff:ffff:ffff:0:0:0:0 Prefix length - 64 Address type - Unassigned Network range - fc00:0000:0000:0000:0000:0000:0000:0000 - fc00:0000:0000:0000:ffff:ffff:ffff:ffff -
Alla olevassa kuvassa on hahmoteltu yllä olevaa tilannetta
Reitittäminen
Jokainen laite, jolla on IP-osoite, tarvitsee myös aliverkon peitteen. Näin laite on osa aliverkkoa. Jos laite haluaa kommunikoida muissa aliverkoissa olevien laitteiden kanssa, täytyy samaan aliverkkoon lisätä uusi laite. Tämä laite tunnetaan nimellä reititin eli router.
Reititin on kuin mikä tahansa verkon laite. Siihen on määritelty IP-osoite ja aliverkon peite. Tästä syystä IPv6-tekniikassa on jokaisella laitteella käytössä yleisnimi node. Poikkeuksena host-tyyppisiin laitteisiin reititin osaa välittää liikenteen eteenpäin. Reitittimessä on useampia verkkoliityntöjä, jotka ovat toteutettu joko verkkokorteilla tai vaihtoehtoisesti tiettyjä tunnelointiprotokollia käyttäen.
Reititin on samanaikaisesti monen aliverkon laite!
Reititys perustuu konekieliseen binäärilaskentaan. Reitittimeen tulee paketti, joka sen pitää ohjata oikeaan paikkaan. Reititin tutkii IP-otsikon kohdeosoitetta Avataan hieman edellä olevan kuvan reitittimen toimintaa
Reitittimen reititystaulu
Liityntä eth0 => Verkko => 11000000101010000000110000000000
Aliverkko => 11111111111111111111111100000000
Liityntä eth1 => Verkko => 11000000101010000000101100000000
Aliverkko => 11111111111111111111111100000000
Saapuva paketti osoitteeseen 192.168.13.88
Osoite => 110000001010100000001101 01011000
Liityntä eth0 => 110000001010100000001100 00000000
000000000000000000000001 => Ei täsmää!
Osoite => 110000001010100000001101 01011000
Liityntä eth1 => 110000001010100000001011 00000000
0000000000000000000001 => Ei täsmää!
Saapuva paketti osoitteeseen 192.168.11.188
Osoite => 110000001010100000001011 10111100
Liityntä eth0 => 110000001010100000001100 00000000
0000000000000000000001 => Ei täsmää!
Osoite => 110000001010100000001011 10111100
Liityntä eth1 => 110000001010100000001011 00000000
000000000000000000000000 => Täsmää! Välitetään paketti tähän verkkoon!
Edellä on esitelty mahdollisimman yksinkertainen reitityslaskenta. Reitittimen reititystaulussa on kaksi aliverkkoa ja tulevaa liikennettä verrataan siihen. Kun liikenteen osoitetieto täsmää, se välitetään oikealle laitteelle.
Reititin välittää aliverkkojen välisen liikenteen!
Reitittimen reititystaulun hallintaan on olemassa kaksi tapaa. Yksinkertaisin on niin sanottu staattinen reititys, jossa reitittimelle käydään manuaalisesti lisäämässä jokainen aliverkko, johon reitittimen halutaan liikennettä välittävän. Verkkojen kasvaessa ja laitteiden lisääntyessä reititys on monimutkaistunut niin paljon, että pelkästään staattiseen reititykseen perustuva verkko on ylläpidon kannalta haastava. Tällaista tilannetta on hahmoteltu seuraavassa kuvassa, jossa pienikin muutos verkko-osoitteistuksessa aiheuttaa molempiin reitittimeen muutoksia.
Staattista reititystä täydentämään on tullut protokollapohjainen reititys. Tässä reitityksessä verkon reitittimet käyttävät samaa protokollaa, jolla he informoivat toisiaan tapahtuneista muutoksista. Tällaisia protokollia on paljon, ja jokaisella on omat vahvuudet ja heikkoudet. Alla lueteltu muutama
* RIP * OSPF * BGP
Kaikkien protokollien tarkoitus on vain ylläpitää reitittimien reititystaulua niin, että se muuttuu verkon sen hetkisen tilanteen mukaisesti. Jos joku verkko poistuu esimerkiksi kaapelirikon vuoksi, muuttuu kaikkien reitittimien reititystaulu sellaiseksi, ettei kyseiseen verkkoon menevää liikennettä enää reititetä. Protokollat lisäävät verkon toimintavarmuutta ja helpottavat ylläpitoa.
IPv6-tekniikassa reititys toimii täysin samojen periaatteiden mukaisesti kuin edellä. Ero on vain osoitteiden ja aliverkon peitteiden pituudet. Edellä käsiteltiin reititystä 32-bittisiä osoitteita käyttäen, kun vastaavasti IPv6-osoitteiden pituus on 128-bittiä. IPv6-tekniikassa aliverkkojen koot ovat huomattavasti suurempia, joka helpottaa reitittimien tekemää laskenta- eli reititystyötä. IPv6:n staattiset reitit määritellään samoin periaattein kuin IPv4:ssä, ja protokollatkin ovat pitkälti samoja.
* RIPng * OSPF
IPv6-tekniikan etu ei olekaan itse reitityksessä vaan verkon ja liikenteen yksinkertaistumisessa. Reitittimiltä on esimerkiksi otettu jokaiseen IPv4-pakettiin liittyvä Otsikon tarkistesumman laskenta pois. Tällä toimenpiteellä tehostetaan reitittimien toimintaa.
IPv6 ja verkon toiminta
Osoitteiden esitysmuoto on yksi näkyvimmistä muutoksista, joka IPv6-tekniikassa on tapahtunut. Tarkemmin ottaen tämä on näkyvin muutos ihmisen näkökulmasta, mutta erittäin suuri muutos on tapahtunut myös verkon yleisessä toiminnassa. Muutos koskee lähes jokaista verkon toimintaa ja sen osaa, lähtien aina osoitteiden jakamisesta itse kommunikointiin. Muutoksilla on selkeytetty OSI-mallin kerroksien roolia, jolloin esimerkiksi verkon toiminta paranee ja verkot yksinkertaistuvat.
Multicast
Lähes kaikki IPv6-verkon yleiseen toimintaan liittyvä kommunikointi tapahtuu käyttäen Multicast-tekniikkaa. Multicast-osoite on kuin mikä tahansa IP-osoite. Se on muodoltaan täysin samanlainen, vaikkakin IPv6-tekniikassa osoite alkaa aina merkeillä ff. Multicast-osoitteen vahvuus piilee siinä, että se voi olla käytössä samassa verkossa usealla eri koneella. Yhteydenotto Multicast-osoitteeseen voi avata yhteyden useaan eri laitteeseen.
Multicast-tekniikan käyttötarkoitus on aivan vastaava kuin IPv4-tekniikasta tuttu Broadcast. IPv4-tekniikassa jokaisessa aliverkossa on varattu yksi osoite Broadcastille, ja tätä osoitetta käyttäen verkossa tapahtuu esimerkiksi kommunikointiin liittyviä toimenpiteitä.
ville@ville-ibm:~$ ipcalc 213.250.105.78/25 Address: 213.250.105.78 11010101.11111010.01101001.0 1001110 Netmask: 255.255.255.128 = 25 11111111.11111111.11111111.1 0000000 Wildcard: 0.0.0.127 00000000.00000000.00000000.0 1111111 => Network: 213.250.105.0/25 11010101.11111010.01101001.0 0000000 HostMin: 213.250.105.1 11010101.11111010.01101001.0 0000001 HostMax: 213.250.105.126 11010101.11111010.01101001.0 1111110 Broadcast: 213.250.105.127 11010101.11111010.01101001.0 1111111 Hosts/Net: 126 Class C
Broadcast-osoitteen tarjoama etu on siinä, että osoitteeseen lähetetty paketti menee välittömästä kaikille verkon osapuolille, eli toiminta on täysin sama kuin Multicastissa. Ongelmallisinta Broadcast-osoitteen käytössä on se, että jokainen lähetetty paketti aiheuttaa jokaiseen verkon laitteeseen keskeytyksen. Tällainen keskeytys aiheuttaa aina laitteeseen tiettyjä toimenpiteitä, joilla on vaikutusta jokaiseen meneillään olevaan ohjelmaan.
Verkossa oleva laite voi vaikuttaa kaikkien muiden verkossa olevien laitteiden toimintaan!
Käytännössä edellä kerrottu muuttuu ongelmaksi isoissa aliverkoissa, joissa on paljon laitteita. Ongelma näkyy verkon hitautena ja yleisenä tökkimisenä. Alla on esimerkki tyypillisestä verkkoympäristöstä, jota on monitoroitu Linuxiin asennetulla protokolla-analysaattorilla.
ville@ville-ibm:~$ sudo tcpdump -ni eth0 broadcast [sudo] password for ville: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 12:31:07.197723 arp who-has 213.250.105.83 tell 213.250.105.4 12:31:07.198035 IP 213.250.105.83.137 > 213.250.105.127.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:31:07.410480 arp who-has 213.250.105.4 tell 213.250.105.52 12:31:07.425643 arp who-has 213.250.105.52 tell 213.250.105.4 12:31:07.946882 IP 213.250.105.83.137 > 213.250.105.127.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:31:08.696890 IP 213.250.105.83.137 > 213.250.105.127.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:31:08.968889 arp who-has 213.250.105.3 tell 213.250.105.72 12:31:10.451063 arp who-has 213.250.105.13 tell 213.250.105.58 12:31:11.265880 arp who-has 213.250.105.13 tell 213.250.105.58 12:31:11.654739 arp who-has 213.250.105.13 tell 213.250.105.67 12:31:12.265938 arp who-has 213.250.105.13 tell 213.250.105.58 12:31:12.519588 arp who-has 213.250.105.17 tell 213.250.105.59 12:31:12.561551 arp who-has 213.250.105.13 tell 213.250.105.67 12:31:13.561547 arp who-has 213.250.105.13 tell 213.250.105.67 12:31:16.962506 arp who-has 213.250.105.63 tell 213.250.105.11 12:31:17.061668 arp who-has 213.250.105.58 tell 213.250.105.4 12:31:17.063171 arp who-has 213.250.105.4 tell 213.250.105.58 12:31:17.613523 arp who-has 213.250.105.63 tell 213.250.105.11 12:31:18.615450 arp who-has 213.250.105.63 tell 213.250.105.11 12:31:21.175505 arp who-has 213.250.105.13 tell 213.250.105.58 12:31:21.766326 arp who-has 213.250.105.13 tell 213.250.105.58 12:31:22.428320 arp who-has 213.250.105.13 tell 213.250.105.67 12:31:22.766391 arp who-has 213.250.105.13 tell 213.250.105.58 12:31:22.843850 IP 213.250.105.97.138 > 213.250.105.127.138: NBT UDP PACKET(138) 12:31:23.061207 arp who-has 213.250.105.13 tell 213.250.105.67 12:31:24.061182 arp who-has 213.250.105.13 tell 213.250.105.67 12:31:27.639996 arp who-has 213.250.105.63 tell 213.250.105.11 12:31:28.163597 (NOV-ETHII) IPX 00000000.00:c0:ee:18:09:1b.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:28.163693 (NOV-ETHII) IPX 00000000.00:c0:ee:12:d6:ca.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:28.628225 arp who-has 213.250.105.63 tell 213.250.105.11 12:31:28.972700 (NOV-ETHII) IPX 00000000.00:c0:ee:15:03:cf.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:28.972900 (NOV-ETHII) IPX 00000000.00:c0:ee:13:c8:e5.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:29.150863 (NOV-ETHII) IPX 00000000.00:c0:ee:12:d6:ca.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-req 0004 12:31:29.165854 (NOV-ETHII) IPX 00000000.00:c0:ee:18:09:1b.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-req 0004 12:31:29.405164 arp who-has 213.250.105.107 tell 213.250.105.4 12:31:29.631131 arp who-has 213.250.105.63 tell 213.250.105.11 12:31:29.742500 IP 213.250.105.58.138 > 213.250.105.127.138: NBT UDP PACKET(138) 12:31:29.960599 (NOV-ETHII) IPX 00000000.00:c0:ee:13:c8:e5.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-req 0004 12:31:29.975161 (NOV-ETHII) IPX 00000000.00:c0:ee:15:03:cf.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-req 0004 12:31:30.153318 IPX 00000000.00:c0:ee:12:d6:ca.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:30.168316 IPX 00000000.00:c0:ee:18:09:1b.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:30.963094 IPX 00000000.00:c0:ee:13:c8:e5.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:30.977684 IPX 00000000.00:c0:ee:15:03:cf.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-nearest-req 0004 12:31:31.155715 IPX 00000000.00:c0:ee:12:d6:ca.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-req 0004 12:31:31.170720 IPX 00000000.00:c0:ee:18:09:1b.4006 > 00000000.ff:ff:ff:ff:ff:ff.0452: ipx-sap-req 0004 12:31:31.175822 arp who-has 213.250.105.13 tell 213.250.105.58
Multicastin etu verrattuna Broadcastiin on se, että se on puhtaasti IP-pohjaista liikennettä, jota käsitellään jokaisessa laitteessa normaalina liikenteenä. Multicast ei aiheuta keskeytyksiä, joten yksittäiset paketit eivät aiheuta laitteiston toimintaan muutoksia.
Multicast toimi puhtaasti OSI-mallin verkkokerroksella!
Neighbor Discovery
Aliverkoissa tapahtuva kommunikaatio perustuu siirtokerroksen MAC-osoitteisiin. Ennen yhteydenottoa laitteen on saatava selville kohdelaitteen MAC-osoite. Tämä tapahtuu IPv4-tekniikassa ARP-protokollalla, jonka edellä olleesta liikennekaappauksestakin voi huomata olevan Broadcast-liikennettä. ARP on sekoitus molempia eli siirto- ja verkkokerrosta, ja lopputuloksena on edellä kerrotut keskeytyksiin liittyvät ongelmat.
IPv6-tekniikassa tähän tarkoitukseen on luotu oma protokolla nimeltä Neighbor Discovery (ND). Tämä protokolla toimii täysin verkkokerroksella eli käyttää toiminnassaan IP-osoitteita. ND perustuu multicast-osoitteisiin, joita jokainen verkossa oleva laite kuuntelee. Seuraavassa esimerkki Linux-pohjaisesta laitteesta. Ensimmäisenä on listattu siirtokerroksen tiedot, joista löytyy jokaisen liitynnän MAC-osoitteet. Esimerkkinä liitynnän (verkkokortti) eth0 osoite 00:0a:e4:c0:ba:d1. Toisena on laitteen IP-osoitetiedot. eth0 on kytketty verkkoon, jossa laite tunnetaan Link Local-osoitteella fe80::20a:e4ff:fec0:bad1. Samassa liitynnässä on voimassa kaksi muutakin osoitetta, jotka ovat fc00::20a:e4ff:fec0:bad1 ja 2001:5c0:1502:7000:20a:e4ff:fec0:bad1. Näiden osoitteiden kautta saadaan yhteys muihin verkkoihin.
ville@ville-ibm:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0a:e4:c0:ba:d1 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT qlen 1000
link/ether 00:12:f0:b2:0e:40 brd ff:ff:ff:ff:ff:ff
4: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:76:62:6e:65:74 brd ff:ff:ff:ff:ff:ff
ville@ville-ibm:~$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:5c0:1502:7000:20a:e4ff:fec0:bad1/64 scope global dynamic
valid_lft 23sec preferred_lft 13sec
inet6 fc00::20a:e4ff:fec0:bad1/64 scope global dynamic
valid_lft 593sec preferred_lft 113sec
inet6 fe80::20a:e4ff:fec0:bad1/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::212:f0ff:feb2:e40/64 scope link
valid_lft forever preferred_lft forever
Laite kuuntelee oletuksena seuraavia Multicast-osoitteita. osoite ff02::1 on jokaiselle verkossa olevalle laitteelle yhteinen. ff02::1:ffc0:bad1 on Solicited-Node-osoite , joka on sekoitus Link Local ja ff02::1-osoitteesta.
ville@ville-ibm:~$ ip -6 maddr show 1: lo inet6 ff02::1 2: eth0 inet6 ff02::1:ffc0:bad1 users 4 inet6 ff02::1 3: eth1 inet6 ff02::1:ffb2:e40 inet6 ff02::1 4: vboxnet0 inet6 ff02::1
Yhteyden muodostaminen alkaa sillä, että laite lähettää Multicast-osoitteeseen Neighbor Solicitation-viestin. Kohdelaite vastaa edelliseen Neighbor Advertisement-viestillä, josta laite saa MAC-osoitteen ja laittaa sen laitteesta riippuen muutamaksi kymmeneksi sekunniksi muistiin. Seuraavassa on yritetty havainnollistaa toimintaa:
Alussa on näytetty laitteen muistista löytyvät, samassa verkossa olevien laitteiden MAC-osoitteet. Laite tuntee ainoastaan yhden reitittimen.
ville@ville-ibm:~$ ip -6 neigh show fe80::207:95ff:feb4:8859 dev eth0 lladdr 00:07:95:b4:88:59 router STALE
Tiedossa on, että osoite fc00::200:5aff:fe75:21e9 on olemassa samassa verkossa olevalla koneella. Yritetään ottaa yhteys laitteeseen ping-komennolla, joka lähettää yhden ICMP-kyselyn IP-osoitteeseen.
ville@ville-ibm:~$ ping6 fc00::200:5aff:fe75:21e9 -c1 PING fc00::200:5aff:fe75:21e9(fc00::200:5aff:fe75:21e9) 56 data bytes 64 bytes from fc00::200:5aff:fe75:21e9: icmp_seq=1 ttl=63 time=2.61 ms --- fc00::200:5aff:fe75:21e9 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.610/2.610/2.610/0.000 ms
Samanaikaisesti on monitoroitu verkon toimintaa. Kaappauksesta käy ilmi, että ensimmäisenä ollaan selvitetty Neighbor Discovery-protokollalla MAC-osoite. Tämän jälkeen ollaan aloitettu kommunikointi haluttuun osoitteeseen.
ville@ville-ibm:~$ sudo tcpdump -ni eth0 ip6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes ---- 15:01:47.687904 IP6 fc00::20a:e4ff:fec0:bad1 > ff02::1:ff75:21e9: ICMP6, neighbor solicitation, who has fc00::200:5aff:fe75:21e9, length 32 15:01:47.688083 IP6 fc00::200:5aff:fe75:21e9 > fc00::20a:e4ff:fec0:bad1: ICMP6, neighbor advertisement, tgt is fc00::200:5aff:fe75:21e9, length 32 ---- 15:01:47.688105 IP6 fc00::20a:e4ff:fec0:bad1 > fc00::200:5aff:fe75:21e9: ICMP6, echo request, seq 1, length 64 15:01:47.689560 IP6 fc00::200:5aff:fe75:21e9 > fc00::20a:e4ff:fec0:bad1: ICMP6, echo reply, seq 1, length 64
MAC-osoite tallennetaan muistiin, joka näyttää operaation jälkeen seuraavalta. Muisti tyhjenee noin minuutin kuluttua edellä olleen kaltaiseksi.
ville@ville-ibm:~$ ip -6 neigh show fe80::200:5aff:fe75:21e9 dev eth0 lladdr 00:00:5a:75:21:e9 REACHABLE fc00::200:5aff:fe75:21e9 dev eth0 lladdr 00:00:5a:75:21:e9 REACHABLE fe80::207:95ff:feb4:8859 dev eth0 lladdr 00:07:95:b4:88:59 router REACHABLE
Kaikki liikenne on puhtaasti verkkokerroksella tapahtuvaa, mikä käy ilmi edellisestä kaappauksesta. Neighbor Discovery-protokolla on keskeinen osa IPv6-verkkojen toimintaa, joten sen toimintaperiaatteen ymmärtäminen tärkeää.
ND huolehtii verkkojen sisällä tapahtuvasta kommunikaatiosta!
Router Discovery
Neighbor Discovery on huomattavasti edistyksellisempi protokolla kuin vastaavan tehtävän IPv4-tekniikassa hoitava ARP. ND on puhdasta verkkokerroksella tapahtuvaa kommunikointia, jolla saavutetaan koko verkon kannalta jouhevampaa toimintaa. Tämä on yksi osa IPv6-tekniikan tavoitetta eli parantaa verkkojen ylläpitoa, hallintaa ja yleistä toimintaa.
Router Discovery on eräs niistä suurista muutoksista, jonka siirtymä IPv4-tekniikasta aiheuttaa. Tämän ominaisuuden pystyy kyllä lähes vastaavalla tavalla toteuttamaan, mutta yleisesti se ei ole levinnyt käyttöön. IPv6-tekniikassa tämä RD on ominaisuus, jonka käyttö on erittäin suositeltavaa. Se ei pakollista, mutta verkon sujuvan toiminnan kannalta suositeltavaa.
RD on yksi niistä loistavista asioista, jonka IPv6 mahdollistaa!
RD on osa Neighbor Discovery-protokollaa, josta edellisessä kappaleessa esiteltiin yksi osa-alue. RD perustuu kahteen viestiin, jotka ovat Router Solicitation ja Router Advertisement. Router Solicitation on viesti, jonka verkossa olevat host-laitteet lähettävät verkkoon. Viesti lähetetään reitittimien yhteiseen Multicast-osoitteeseen ff02::2, ja reitittimet vastaavaat Router Advertisement-viestillä. Router Advertisement on siis reitittimien tapa tiedottaa itsestään verkkoon. Tätä viestiä reitittimet lähettävät myös säännöllisin väliajoin, huolimatta siitä, että tulee kyselyä tai ei. Esimerkin valossa asiaa näyttää seuraavalta.
ville@ubuntu-home:~$ sudo tcpdump -ni eth0 ip6 and not port 22 -vvs 1000
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1000 bytes
12:37:34.822979 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8) fe80::230:1bff:fe47:ce03 > ff02::2: [icmp6 sum ok]
ICMP6, router solicitation, length 8
----
12:37:35.262484 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::a00:27ff:feec:f1a5' > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref high, router lifetime 960s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 08:00:27:ec:f1:a5
0x0000: 0800 27ec f1a5
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
prefix info option (3), length 32 (4): fc00:0:0:2000::/64, Flags [onlink, auto], valid time 480s, pref. time 240s
0x0000: 40c0 0000 01e0 0000 00f0 0000 0000 fc00
0x0010: 0000 0000 2000 0000 0000 0000 0000
----
12:37:35.312823 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::a00:27ff:fe35:29f3 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref low, router lifetime 960s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 08:00:27:35:29:f3
0x0000: 0800 2735 29f3
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
prefix info option (3), length 32 (4): fc00:0:0:2000::/64, Flags [onlink, auto], valid time 480s, pref. time 240s
0x0000: 40c0 0000 01e0 0000 00f0 0000 0000 fc00
0x0010: 0000 0000 2000 0000 0000 0000 0000
Verkossa oleva host-laite, jonka Link Local -osoite on fe80::230:1bff:fe47:ce03 lähettää reitittimien Multicast-osoitteeseen ff02::2 viestin. Kyselyyn vastaa kaksi reitintä, jotka molemmat ovat samassa aliverkossa fc00:0:0:2000::/64. Ensimmäisen reitittimen Link Local -osoite on fe80::a00:27ff:feec:f1a5 ja toisen fe80::a00:27ff:fe35:29f3. Näistä vastauksista laite saa oikeat reittimet, jotka se lisää omaan, sisäiseen reititystauluunsa seuraavasti:
ville@ubuntu-home:~$ ip -6 route show fc00:0:0:2000::/64 dev eth0 proto kernel metric 256 expires 464sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 21316762sec mtu 1500 advmss 1440 hoplimit 4294967295 ff00::/8 dev eth0 metric 256 expires 21316762sec mtu 1500 advmss 1440 hoplimit 4294967295 default via fe80::a00:27ff:feec:f1a5 dev eth0 proto kernel metric 1024 expires 910sec mtu 1500 advmss 1440 hoplimit 64 default via fe80::a00:27ff:fe35:29f3 dev eth0 proto kernel metric 1024 expires 944sec mtu 1500 advmss 1440 hoplimit 64
Edellisessä reitittimet vastasivat tulevaan kyselyyn. Tämän lisäksi reitittimet tiedot itsestään seuraavan esimerkin mukaisesti.
ville@ubuntu-home:~$ sudo tcpdump -ni eth0 ip6 and not port 22 -vvs 1000
[sudo] password for ville:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1000 bytes
12:57:29.551154 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::a00:27ff:fe35:29f3 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref low, router lifetime 960s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 08:00:27:35:29:f3
0x0000: 0800 2735 29f3
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
prefix info option (3), length 32 (4): fc00:0:0:2000::/64, Flags [onlink, auto], valid time 480s, pref. time 240s
0x0000: 40c0 0000 01e0 0000 00f0 0000 0000 fc00
0x0010: 0000 0000 2000 0000 0000 0000 0000
----
12:57:58.522520 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::a00:27ff:feec:f1a5 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref high, router lifetime 960s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 08:00:27:ec:f1:a5
0x0000: 0800 27ec f1a5
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
prefix info option (3), length 32 (4): fc00:0:0:2000::/64, Flags [onlink, auto], valid time 480s, pref. time 240s
0x0000: 40c0 0000 01e0 0000 00f0 0000 0000 fc00
0x0010: 0000 0000 2000 0000 0000 0000 0000
---
12:58:47.525152 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::a00:27ff:feec:f1a5 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref high, router lifetime 960s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 08:00:27:ec:f1:a5
0x0000: 0800 27ec f1a5
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
prefix info option (3), length 32 (4): fc00:0:0:2000::/64, Flags [onlink, auto], valid time 480s, pref. time 240s
0x0000: 40c0 0000 01e0 0000 00f0 0000 0000 fc00
0x0010: 0000 0000 2000 0000 0000 0000 0000
----
12:59:04.602281 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::a00:27ff:fe35:29f3 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref low, router lifetime 960s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 08:00:27:35:29:f3
0x0000: 0800 2735 29f3
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
prefix info option (3), length 32 (4): fc00:0:0:2000::/64, Flags [onlink, auto], valid time 480s, pref. time 240s
0x0000: 40c0 0000 01e0 0000 00f0 0000 0000 fc00
0x0010: 0000 0000 2000 0000 0000 0000 0000
RD on siis tapa, jolla huolehditaan host-laitteiden sen hetkisistä verkkoa koskevista reititystiedoista. Jos jokin reititin muuttuu, reitti katoaa, reititin hajoaa tai mitä ikinä, verkko pysyy aina toimintakunnossa. Host-laitteet pääsevät aina parasta mahdollista reittiä pitkin muihin verkkoihin. IPv4-tekniikassa näiden asioiden hallinta on huomattavasti vaikeampaa.
RD huolehtii verkkojen välisestä toiminnasta!
IPv6 ja Node
IPv6-verkossa jokainen laite tunnetaan nimellä node. Jokaiselle nodelle on yhteistä se, että niillä on osoite. Jokainen node on siis aina osa verkkoa, jossa voi olla myös muita nodeja. Node-laitteet jaotellaan toimintansa puolesta kahteen osaan eli Host- ja Router-laitteisiin. Router reitittää verkkojen välisen liikenteen, joka kulkee vähintään kahden Host-laitteen välillä. Toinen Host-laitteista on asiakas ja toinen palvelin.
Host ja Router ovat Nodeja IPv6-verkossa!
Osoitteen määrittely
IPv4-tekniikassa osoitteiden määrittelyyn on olemassa kolme eri tekniikka. Ensimmäinen ja yksinkertaisin on osoitteiden määrittäminen kiinteäksi. Jokaiselle laitteelle käydään asettamassa omat osoitetiedot eli IP-osoite, aliverkon peite ja tarvittaessa reitittimen IP-osoite. Toimintavarma, mutta vaikeasti ylläpidettävä tapa. Verkkojen kasvaessa ja tilanteiden muuttuessa oli pakollista kehittää vaihtoehtoinen tapa.
Kiinteästi asetteva osoite on toimintavarma, mutta ylläpidollisesti hankala ratkaisu!
Ratkaisuksi kiinteän osoitteistuksen ongelmiin muodostui DHCP. DHCP-protokollan tarkoitus on hallita verkossa olevien laitteiden osoitetietoja. Keskeiset osapuolet ovat verkon laitteeseen tai laitteisiin asennettava palvelinohjelma sekä muissa laitteista olevat asiakasohjelmat. Asiakasohjelma suorittaa verkkoon kyselyn, johon palvelinohjelma vastaa antamalla osoitteen sekä muuhun toimintaan liittyviä tietoja. Verkossa olevien laitteiden osoitteita ja muita tietoja voidaan hallita siis laitteesta, jossa palvelinohjelma on käynnissä. Tässä on myös DHCP:n yksi suurimmista ongelmista. Verkon laitteet ovat aina riippuvaisia palvelinohjelmasta ja sen toiminnasta. Jos samassa verkossa halutaan ottaa käyttöön useita palvelinohjelmia, vaatii se erikoistoimenpiteitä. Yksi ongelmien lähde on Broadcast-liikenne, jota DHCP käyttää toimintaansa.
DHCP on ylläpidollisesti hyvä ratkaisu, mutta ongelmaksi muodostuu toimintavarmuus!
Viimeinen, ja samalla vähäisimmän suosion IPv4-tekniikassa saavuttanut tapa, joka tunnetaan ehkä parhaiten Microsoftin markkinoimalla APIPA-nimellä. Tämän tekniikan tarkoitus on asettaa jokaiselle laitteelle osoite automaattisesti. Näiden osoitteiden avulle laitteet voivat kommunikoida verkon sisällä, mutta eivät verkon ulkopuolelle. Osoite määräytyy automaattisesti ja satunnaisesti, eli verkon kautta ei voi päätellä, millä laitteella on mikäkin osoite. Lisäksi toimintaa haittaa se, että osoite on voimassa vain silloin, kun kumpikaan edellä mainituista osoitteen määrittelytavoista ei ole käytössä. IPv4-tekniikassahan useiden, samanaikaisesti käytössä olevien osoitteiden käyttäminen on hankalaa.
Automaattisuus ja satunnaisuus tekevät tästä tavasta lähes käyttökelvottoman!
IPv6-tekniikassa osoitteiden määrittelyyn on olemassa täsmälleen samat tavat kuin edellä mainittiin. IPv6-osoite voidaan määritellä kiinteästi, jolloin sillä on täysin samat ominaisuudet kuin edellä kerrottiin. Se, miten osoite Nodelle annetaan, on järjestelmästä riippuvainen. Linuxissa asiat hoidetaan luonnollisesti toisella tavalla kuin esimerkiksi Windowssissa. Alla esimerkki Debian/Ubuntu-järjestelmästä, johon on asettettu kiinteästi osoite fc00:0:0:3000::10.
lighty:~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp auto eth0 iface eth0 inet6 static address fc00:0:0:3000::10 netmask 64 gateway fc00:0:0:3000::1
IPv6-tekniikassa on vastaavasti käytössä DHCP, joka määritellä omassa standardissaan. DHCP:n toiminta on lähes vastaava kuin IPv4-tekniikassa. DHCP:llä saavutetaan samat edut kuin edellä, ja vastaavasti kohdataan lähes samat ongelmat. Multicast-osoitteiden hyödyntämisellä on vaikutusta verkon toimintaan, mutta silti ongelmana on, että palvelinohjelman pitää olla jatkuvasti päällä.
Suurin muutos IPv4-tekniikan osoitteiden hallintaan on asia nimeltään IPv6 Stateless Address Autoconfiguration. Tämä tekniikka tarjoaa vastaavan toiminnallisuuden kuin APIPA, mutta toimivampana versiona. Tässä tavassa jokainen node päättelee verkossa esiintyvästä Router advertisement-viestistä osoitteensa. Tätä viestihän lähettää verkkoon yleensä reititin, joka samalla esittelee itsensä ja antaa muiden laitteiden ottaa osoitteen halutessaan käyttöön. Seuraavassa esimerkki.
lighty:~# ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fc00:0:0:3000::10/64 scope global
valid_lft forever preferred_lft forever
inet6 fc00::2000:a00:27ff:fec1:a462/64 scope global dynamic
valid_lft 450sec preferred_lft 210sec
inet6 fe80::a00:27ff:fec1:a462/64 scope link
valid_lft forever preferred_lft forever
---
lighty:~# tcpdump -ni eth0 ip6 -vvs 1000
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1000 bytes
15:31:40.501899 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::a00:27ff:fe35:29f3 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref low, router lifetime 960s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 08:00:27:35:29:f3
0x0000: 0800 2735 29f3
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
prefix info option (3), length 32 (4): fc00:0:0:2000::/64, Flags [onlink, auto], valid time 480s, pref. time 240s
0x0000: 40c0 0000 01e0 0000 00f0 0000 0000 fc00
0x0010: 0000 0000 2000 0000 0000 0000 0000
^C
1 packets captured
1 packets received by filter
0 packets dropped by kernel
lighty:~#
Linux-palvelimella on verkkoliittymä (verkkokortti), joka tunnetaan nimellä eth0. Verkkokortilla on voimassa kolme eri osoitetta, eli siihen voidaan ottaa yhteys, käyttämällä jotain noista osoitteista. Osoite fc00:0:0:3000::10 on määritelty kiinteäksi eli on voimassa ikuisesti (valid_lft forever). Link-Local -osoite on jokaiselle liitynnälle MAC-osoitteesta johdettu, ja on tässä fe80::a00:27ff:fec1:a462. Link-Local -osoitekkin on voimassa ikuisesti. Reitittimen viestistä päätelty osoite on fc00::2000:a00:27ff:fec1:a462, ja on voimassa maksimissaan 480 sekuntia (valid time 480s => valid_lft 450sec). Osoite on johdettu myös MAC-osoitteesta, mikä näkyy vertailtaessa Link-Local -osoitteseen.
IPv6-tekniikka tarjoaa huomattavasti joustavammat tavat osoitteiden hallintaan kuin IPv4!
Liikenteen ohjaus
IPv6-tekniikassa liikenteen reitityksen periaatteet eivät juurikaan poikkea IPv4-tekniikasta. Host-laitteiden täytyy olla tietoisia Router-laitteesta, jotta aliverkkojen välinen liikenne voi onnistua. Käytännössä Host-laitteilla täytyy tietää Router-laitteen IP-osoite. Router-laitteilla pitää olla vastaavasti tieto muiden aliverkkojen Router-laitteista, jotta se voi reitittää liikenteen oikeaan aliverkkoon. Router-laitteen pitää siis pystyä yhdistämään aliverkko ja IP-osoite.
Keskeinen osa reititystä eli liikenteen ohjausta on jokaisella verkon laitteella oleva reititystaulu. Jokainen laite, oli se sitten Host tai Router, omistaa reititystaulun, jonka perusteella se reitittää liikenteen eteenpäin. Seuraavaksi esimerkki tavallisesta Linux-työasemasta, jonka IPv4-reititystaulu näyttää seuraavalta. Reititystaulu on tulostettu esimerkin vuoksi kahdella eri komennolla
ville@ville-ibm:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 213.250.105.0 0.0.0.0 255.255.255.128 U 1 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 213.250.105.126 0.0.0.0 UG 0 0 0 eth0 ville@ville-ibm:~$ ip route show 213.250.105.0/25 dev eth0 proto kernel scope link src 213.250.105.61 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default via 213.250.105.126 dev eth0 proto static ville@ville-ibm:~$
Aliverkon ulkopuolelle lähtevä liikenne, eli tätähän liikennettä lähes kaikki on, ohjataan aina osoitteeseen 213.250.105.126, joka on oletusyhdyskäytävä. Oletusyhdyskäytävä, eli reititin, ohjaa liikennettä eteenpäin. Jos koko reititysketju on kunnossa, yhteydenotto muussa aliverkossa olevaan laitteeseen (esimerkiksi www.yle.fi) onnistuu.
Reititys on läsnä lähes jokaisessa yhteydessä!
Seuraavassa on esimerkin mukaisesti havainnollistettu asiaa IPv6-tekniikkaa käyttäen. Esimerkissä on toteutettu alla olevan kuvan mukainen verkko, jossa kaksi reititintä yhdistää kahden eri aliverkon liikenteen.
Aliverkossa fc00:2::/64 on WWW-palvelin, jossa on käyttöjärjestelmänä Debian. fc00::/64 on reititykseen käytetty aliverkko, jossa on kaksi reititintä. Reitittimet on toteutettu OpenBSD-käyttöjärjestelmillä allekirjoittaneen katu-uskottavuuden lisäämiseksi. Aliverkossa fc00:1::/64 on työasema, jossa käyttöjärjestelmänä on Ubuntu.
Verkon rakentaminen aloitetaan reitittimestä, joka on yhteydessä työasemaan ja verkkoon fc00::/64. Reitittimen pitää ilmoittaa olemassa olostaan työasemalle. Tämä tapahtuu radvd-ohjelmalla, joka lähettää verkkoon Router Advertisement-viestiä. Tästä työasema päättelee oman osoitteensa ja reitittimensä, jonka jälkeen homma näyttää työasemalla seuraavalta
Työaseman reitittimeltä päätelty osoite on fc00:1::230:1bff:fe47:ce03. Tämä on siis julkinen osoite, johon voidaan ottaa yhteyttä muista aliverkoista. Toinen osoitehan, eli fe80::230:1bff:fe47:ce03, on Link Local, jota käytetään siis vain aliverkon sisällä.
ville@ubuntu-home:~$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fc00:1::230:1bff:fe47:ce03/64 scope global dynamic
valid_lft 420sec preferred_lft 180sec
inet6 fe80::230:1bff:fe47:ce03/64 scope link
valid_lft forever preferred_lft forever
Työseman päättelemä oletusreittimen osoite on fe80::a00:27ff:fe35:29f3, johon siis lähetetään muihin aliverkkoihin menevä liikenne. Tämä on siis työaseman reititystaulu.
ville@ubuntu-home:~$ ip -6 route show fc00:1::/64 dev eth0 proto kernel metric 256 expires 417sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 21323260sec mtu 1500 advmss 1440 hoplimit 4294967295 ff00::/8 dev eth0 metric 256 expires 21323260sec mtu 1500 advmss 1440 hoplimit 4294967295 default via fe80::a00:27ff:fe35:29f3 dev eth0 proto kernel metric 1024 expires 897sec mtu 1500 advmss 1440 hoplimit 64
Työaseman oletusreitittimen MAC-osoite on 08:00:27:35:29:f3 ja reititin tunnetaan myös osoitteella fc00:1::1. Reitittimestä tiedetään siis kaksi osoitetta.
ville@ubuntu-home:~$ ip -6 neigh show fc00:1::1 dev eth0 lladdr 08:00:27:35:29:f3 router STALE fe80::a00:27ff:fe35:29f3 dev eth0 lladdr 08:00:27:35:29:f3 router STALE ville@ubuntu-home:~$
Seuraavaksi on tarkistettu, että yhteys reittimeen onnistuu.
ville@ubuntu-home:~$ ping6 -c1 fc00:1::1 PING fc00:1::1(fc00:1::1) 56 data bytes 64 bytes from fc00:1::1: icmp_seq=1 ttl=64 time=1.14 ms --- fc00:1::1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.147/1.147/1.147/0.000 ms ville@ubuntu-home:~$ ping6 -c1 fe80::a00:27ff:fe35:29f3%eth0 PING fe80::a00:27ff:fe35:29f3%eth0(fe80::a00:27ff:fe35:29f3) 56 data bytes 64 bytes from fe80::a00:27ff:fe35:29f3: icmp_seq=1 ttl=64 time=1.12 ms --- fe80::a00:27ff:fe35:29f3%eth0 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.121/1.121/1.121/0.000 ms ville@ubuntu-home:~$
Viimeisenä on yritetty yhteyttä ennalta tiedossa olevan WWW-palvelimen osoitteeseen fc00:2::a00:27ff:fe1d:ed97. Huomataan, että reitti ei ole kunnossa ja yhteyden luonti ei onnistu.
ville@ubuntu-home:~$ ping6 -c1 fc00:2::a00:27ff:fe1d:ed97 PING fc00:2::a00:27ff:fe1d:ed97(fc00:2::a00:27ff:fe1d:ed97) 56 data bytes From fc00:1::1 icmp_seq=1 Destination unreachable: No route --- fc00:2::a00:27ff:fe1d:ed97 ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms ville@ubuntu-home:~$
Siirrytään ensimmäiselle reitittimelle eli osoitteen fc00:1::1 koneelle. Reitittimellä on siis kaksi verkkoliityntää, käytännössä verkkokorttia, joista toinen on työaseman kanssa samassa verkossa osoitteella fc00:1::1, ja toinen toisen reitittimen kanssa samassa verkossa osoitteella fc00::1. Ensimmäinen reititin tietää, että toisen reitittimen osoite on fc00::2, johon yritetään ensimmäisenä yhteyttä. Tosin ensimmäisellä komennolla on näytetty, että reitittimen osoite on todellakin fc00::1.
# ifconfig pcn1
pcn1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 08:00:27:94:c6:cb
priority: 0
media: Ethernet none
status: active
inet6 fc00::1 prefixlen 64
inet6 fe80::a00:27ff:fe94:c6cb%pcn1 prefixlen 64 scopeid 0x2
# ping6 -c1 fc00::2
PING6(56=40+8+8 bytes) fc00::1 --> fc00::2
16 bytes from fc00::2, icmp_seq=0 hlim=64 time=3.154 ms
--- fc00::2 ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 3.154/3.154/3.154/0.000 ms
#
Huomataan, että yhteys onnistuu mainiosti. Seuraavaksi yritetään yhteyttä WWW-palvelimen osoitteeseen fc00:2::a00:27ff:fe1d:ed97 ja havainnollistamiseksi työaseman osoitteeseen fc00:1::230:1bff:fe47:ce03.
# ping6 -c1 fc00:2::a00:27ff:fe1d:ed97 ping6: UDP connect: No route to host # ping6 -c1 fc00:1::230:1bff:fe47:ce03 PING6(56=40+8+8 bytes) fc00:1::1 --> fc00:1::230:1bff:fe47:ce03 16 bytes from fc00:1::230:1bff:fe47:ce03, icmp_seq=0 hlim=64 time=1.079 ms --- fc00:1::230:1bff:fe47:ce03 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.079/1.079/1.079/0.000 ms #
Työasemaan saadaan yhteys, koska se on reittimen kanssa samassa aliverkossa. WWW-palvelimella taas vastaavasti ei. Tämä siksi, että ensimmäisellä reittimellä ei ole hajuakaan missä verkko fc00:2::/64 on. Tämä nähdään reititystaulusta, joka on esitetty ensimmäiseksi alla olevassa. Tämän jälkeen asia on korjattu,
# route -n show -inet6 Routing tables Internet6: Destination Gateway Flags Refs Use Mtu Prio Iface ---- fc00::/64 link#2 UC 1 0 - 4 pcn1 fc00::1 08:00:27:94:c6:cb UHL 0 2 - 4 lo0 fc00::2 08:00:27:a6:70:47 UHLc 0 11 - 4 pcn1 fc00:1::/64 link#1 UC 1 0 - 4 pcn0 fc00:1::1 08:00:27:35:29:f3 UHL 1 0 - 4 lo0 fc00:1::230:1bff:fe47:ce03 00:30:1b:47:ce:03 UHLc 1 1141 - 4 pcn0 ---- # route -n add -inet6 fc00:2:: -prefixlen 64 fc00::2 add net fc00:2::: gateway fc00::2 # route -n show -inet6 Routing tables Internet6: Destination Gateway Flags Refs Use Mtu Prio Iface ---- fc00::/64 link#2 UC 1 0 - 4 pcn1 fc00::1 08:00:27:94:c6:cb UHL 0 2 - 4 lo0 fc00::2 08:00:27:a6:70:47 UHLc 1 11 - 4 pcn1 fc00:1::/64 link#1 UC 1 0 - 4 pcn0 fc00:1::1 08:00:27:35:29:f3 UHL 1 0 - 4 lo0 fc00:1::230:1bff:fe47:ce03 00:30:1b:47:ce:03 UHLc 1 1160 - 4 pcn0 fc00:2::/64 fc00::2 UGS 0 0 - 8 pcn1 ---- #
Testataan vielä yhteys WWW-palvelimelle ja Työasemalle. Alla olevasta huomataan, että molemmat yhteydet toimivat loistavasti.
# ping6 -c1 fc00:2::a00:27ff:fe1d:ed97 PING6(56=40+8+8 bytes) fc00::1 --> fc00:2::a00:27ff:fe1d:ed97 16 bytes from fc00:2::a00:27ff:fe1d:ed97, icmp_seq=0 hlim=63 time=4.917 ms --- fc00:2::a00:27ff:fe1d:ed97 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 4.917/4.917/4.917/0.000 ms # ping6 -c1 fc00:1::230:1bff:fe47:ce03 PING6(56=40+8+8 bytes) fc00:1::1 --> fc00:1::230:1bff:fe47:ce03 16 bytes from fc00:1::230:1bff:fe47:ce03, icmp_seq=0 hlim=64 time=1.72 ms --- fc00:1::230:1bff:fe47:ce03 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.720/1.720/1.720/0.000 ms
Luulisi, että asia on kunnossa, mutta ei! Työasemalta ei saa WWW-palvelimelle yhteyttä vieläkään, koska toinen reititin ei tiedä missä verkko työaseman aliverkko on!
Siirrytään korjaamaan asia toiselle reitittimelle, jossa on niin ikään kaksi verkkokorttia, toinen verkossa fc00::/64 ja toinen fc00:22::/64'. Reititin tunnetaan ensin mainitussa verkossa osoitteella fc00::2 ja toisessa verkossa osoitteella fc00:2::1. Ongelma on siis toisen reitittimen reititystaulussa, joka on tulostettu alla olevassa viimeisenä. Ennen reititystaulua on näytetty osoitteet.
# ifconfig pcn0
pcn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 08:00:27:ec:f1:a5
priority: 0
media: Ethernet none
status: active
inet6 fc00:2::1 prefixlen 64
inet6 fe80::a00:27ff:feec:f1a5%pcn0 prefixlen 64 scopeid 0x1
# ifconfig pcn1
pcn1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 08:00:27:a6:70:47
priority: 0
media: Ethernet none
status: active
inet6 fc00::2 prefixlen 64
inet6 fe80::a00:27ff:fea6:7047%pcn1 prefixlen 64 scopeid 0x2
# route -n show -inet6
Routing tables
Internet6:
Destination Gateway Flags Refs Use Mtu Prio Iface
----
fc00::/64 link#2 UC 1 0 - 4 pcn1
fc00::1 08:00:27:94:c6:cb UHLc 1 127 - 4 pcn1
fc00::2 08:00:27:a6:70:47 UHL 1 4 - 4 lo0
fc00:2::/64 link#1 UC 1 0 - 4 pcn0
fc00:2::1 08:00:27:ec:f1:a5 UHL 0 0 - 4 lo0
fc00:2::a00:27ff:fe1d:ed97 08:00:27:1d:ed:97 UHLc 0 2 - 4 pcn0
----
Reititystaulusta huomataan, ettei reitittimellä ole mitään tietoa verkosta fc00:1::/64. Verkosta tuleva tai verkkoon menevä liikenne ei ohjaudu tältä reitittimeltä koskaan mihinkään. 'Reititysketju ei ole siis kunnossa. Seuraavaksi on korjattu asia, jonka jälkeen verkko toimi kokonaisuudessaan loistavasti.
# route -n add -inet6 fc00:1:: -prefixlen 64 fc00::1 add net fc00:1::: gateway fc00::1 # route -n show -inet6 Routing tables Internet6: Destination Gateway Flags Refs Use Mtu Prio Iface ---- fc00::/64 link#2 UC 1 0 - 4 pcn1 fc00::1 08:00:27:94:c6:cb UHLc 2 203 - 4 pcn1 fc00::2 08:00:27:a6:70:47 UHL 1 4 - 4 lo0 fc00:1::/64 fc00::1 UGS 0 0 - 8 pcn1 fc00:2::/64 link#1 UC 1 0 - 4 pcn0 fc00:2::1 08:00:27:ec:f1:a5 UHL 0 0 - 4 lo0 fc00:2::a00:27ff:fe1d:ed97 08:00:27:1d:ed:97 UHLc 0 2 - 4 pcn0 ---- #
Siirrytään viimeiseen vaiheeseen, eli työasemalle testaamaan verkon toimintaa ensiksi ping-komennolla.
ville@ubuntu-home:~$ ping6 -c1 fc00:2::a00:27ff:fe1d:ed97 PING fc00:2::a00:27ff:fe1d:ed97(fc00:2::a00:27ff:fe1d:ed97) 56 data bytes 64 bytes from fc00:2::a00:27ff:fe1d:ed97: icmp_seq=1 ttl=62 time=4.20 ms --- fc00:2::a00:27ff:fe1d:ed97 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.208/4.208/4.208/0.000 ms ville@ubuntu-home:~$
Ja lopuksi selaimella
Verkon liikenne ohjataan oikein, eli reititys pelaa! Kuten huomataan reititys on monimutkainen prosessi, mutta ei eroa periaatteeltaan IPv4-tekniikasta yhtään!
Liikenteen suodatus
IPv6-tekniikan yksi parhaimmista uudistuksista on, että jokainen laite saa julkisen IP-osoitteen. Näin laitteeseen saadaan yhteys jokaisesta maailman kolkasta, jossa IPv6-verkko on saatavilla. Julkinen IP-osoite tulee Internet-liittymän mukana, eikä siitä tarvitse maksaa erillistä korvausta, kuten IPv4-tekniikka suosivilla operaattoreilla on tapana ollut. Lähtökohtaisesti jokainen verkossa oleva laite voi ottaa toisiinsa yhteyden.
IPv6-tekniikka nostaa turvallisuusnäkökulman IPv4-tekniikkaan verrattuna aivan uudelle tasolle!
Jokainen laite on siis alttiina muiden käyttäjien hyvän- tai pahantahtoisille tahallisille tai tahattomille yhteysyrityksille. Kuten IPv4-tekniikassakaan IPv6 ei ota kantaa OSI-mallin ylempien kerroksien palveluille, vaan tarjoaa ainoastaan yhteyden eri laitteiden ja verkkojen välille. Jos laitteessa olevassa sovelluksessa on turvallisuushaavoittuvuus, jota käyttämällä pahantahtoinen käyttäjä saa esimerkiksi laitteen haltuunsa, on se sovelluksen vika ei IPv6-tekniikan.
Totuus on, että ilmeisesti tässä maailmassa ei virheetöntä ja täysin turvallista sovellusta ole olemassakaan. Tästä syystä on pakko käyttää liikenteen suodattamista eli yleisesti tunnettua Palomuuria. Palomuuri on laite, joka tutkii siihen tulevaa ja siitä lähtevää liikennettä. Se joko sallii tai estää liikenteen, siihen luodun säännöstön mukaisesti. Sillä voidaan esimerkiksi sallia edellisen kappaleen WWW-palvelimelle menevä liikenne, mutta estää laitteelle kohdistuvat muut yhteydenottoyritykset.
Seuraavassa esimerkissä on toteutettu juuri tämä edellä mainittu suodatustoimenpide. Vaihtoehtoja suodatukseen toteuttamiseen on lukematon määrä, joista seuraavassa on valittu yksinkertaisin. Suodattimen tehdään itse WWW-palvelimella, eli käyttöjärjestelmän tarjoama palomuuri on otettu käyttöön. Debianissa, lähes jokaisen Linuxin tavoin, on siinä valmiina sisäänrakennettuna IPtables nimeä kantava palomuuri. Hämäävästi palomuuri on jatkuvasti päällä, mutta se ei ota kantaa mihinkään liikenteeseen, koska siihen ei ole määritelty säännöstöä. Tämä on havainnollistettu alla oleva tulostuksella.
apache:~# ip6tables --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Palomuurilla voidaan suodattaa koneelle tulevia yhteyksiä (INPUT), koneelta lähteviä (OUTPUT) ja verkkoliittymien välillä kulkevaa (FORWARD) liikennettä. Viimeinen vaihtoehto on tarpeellinen, jos kone toimii reitittimenä. Näinhän ei tässä tapauksessa ole, vaan kone toimii ainoastaan palvelimena. Palomuurisäännöstön tekeminen on vaativaa ja aikaa vievää, joka kannattaa tehdä todella huolella. Meidän tapauksessa säännöstö näyttää seuraavalta, eli alla oleva komennot annetaan palvelimen komentoriville.
Sisäinen liikenne on sallitava aina ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT Sallitaan palvelimelta uloslähtevät yhteydet ip6tables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A OUTPUT -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT Sallitaan ulkoverkosta porttiin 80 tulevat yhteydet ip6tables -A INPUT -i eth0 -p tcp --destination-port 80 -j ACCEPT Estetään ulkoverkosta PING-yhteydet, mutta sallitaan muu ICMP-liikenne ip6tables -A INPUT -i eth0 -p ipv6-icmp --icmpv6-type 128 -j DROP ip6tables -A INPUT -i eth0 -p ipv6-icmp -j ACCEPT ip6tables -A OUTPUT -o eth0 -p ipv6-icmp -j ACCEPT Kaikki muut yhteydet, joita yllä ei ole listattu estetään ip6tables -P INPUT DROP ip6tables -P OUTPUT DROP ip6tables -P FORWARD DROP
Alla säännöstö on määritelty koneeseen, jonka jälkeen liikenteen suodattaminen alkaa. Viimeisellä komennolla on listattu säännöstö uudestaan, ja näin huomataan mitä on muuttunut. Verkon muille laitteille muutos näkyy niin, että laite ei vastaa Ping-komentoon, mutta selainyhteys aukeaa edelleen.
apache:~# ip6tables -A INPUT -i lo -j ACCEPT apache:~# ip6tables -A OUTPUT -o lo -j ACCEPT apache:~# ip6tables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT apache:~# ip6tables -A OUTPUT -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT apache:~# ip6tables -A INPUT -i eth0 -p tcp --destination-port 80 -j ACCEPT apache:~# ip6tables -A INPUT -i eth0 -p ipv6-icmp --icmpv6-type 128 -j DROP apache:~# ip6tables -A INPUT -i eth0 -p ipv6-icmp -j ACCEPT apache:~# ip6tables -A OUTPUT -o eth0 -p ipv6-icmp -j ACCEPT apache:~# ip6tables -P INPUT DROP apache:~# ip6tables -P OUTPUT DROP apache:~# ip6tables -P FORWARD DROP apache:~# ip6tables --list Chain INPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere ACCEPT all anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp anywhere anywhere tcp dpt:www DROP ipv6-icmp anywhere anywhere ipv6-icmp echo-request ACCEPT ipv6-icmp anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere ACCEPT all anywhere anywhere state NEW,RELATED,ESTABLISHED ACCEPT ipv6-icmp anywhere anywhere apache:~#
Vastaava suodatus voi tehdä reitittimellä tai nykyisin lähes missä tahansa verkon laitteessa.
Suodattimen on periaatteiltaan aivan samanlaista kuin IPv4-tekniikassa! IPv6-verkon laitteet ovat oletuksena alttiina aivan toisenlaisille uhkille kuin IPv4-verkossa!