Kannattaa testata PING ensimmäiseksi IP:llä, eikä DNS:n kanssa, koska silloin jää epäselväksi kummassa vika on. Nyt PING tulos kertoo vain ja ainoastaan sen, että DNS resolve epäonnistui. Eikä sitä, että kulkeeko liikenne IPv6:lla ulos vai ei.

mm. Teredeoa (yuk) Windowssilla käytettäessä homma toimii juuri noin. Eli IPv6 AAAA recordien DNS ei ole käytössä vaikka se toimisikin nslookupilla, mutta jos käyttää IP-osoitetta, niin pingi kyllä kulkee.

Väärät menetelmtä ongelmatilanteen selvittelyssä johtavat usein sekaannukseen ja silloin on todella hankalaa tietää mikä on oikeasti se ongelman ydin.

Itselläni on palvelin myös palvelinsalissa, mutta olen toteuttanut 6to4 tunnelilla ulos. Yhteys on myös Soneran.

Käytän bash scriptiä:

/sbin/ip tunnel add tun6to4 mode sit ttl 64 remote any local XX.XX.XX.XX


 ip link set dev tun6to4 up


 ip -6 addr add 2002:XXXX:XXXX::/16 dev tun6to4


 ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1


ifconfig eth0 add 2002:XXXX:XXXX::1/64

ja tietenkin /etc/network/interfaces tiedostoon:

post-up sh ufile.sh]

@olkituItse haluaisin välttää 6to4 käyttöä.

Itse haluaisin välttää täysin IPv6 tunnelit, natiivina haluaisin kaiken...

---

@olkitu kirjoitti:

Itse haluaisin välttää täysin IPv6 tunnelit, natiivina haluaisin kaiken...

---

Toi on kyllä totta, mutta valitettavasti ei vielä mahdollista. :(

Palvelintarjoajani ei ole vielä tilannut Soneralta natiivista IPv6, kun siinä on kytkemismaksu... IPv6 on ilmainen mutta kytkeminen maksaa ja kun sitä ei niin paljon kaivata vielä. 

Saitko pingattua Googlen IPv6 osoitteeseen. Kokeilitko traceroute6?

---

@olkitu kirjoitti:

Palvelintarjoajani ei ole vielä tilannut Soneralta natiivista IPv6, kun siinä on kytkemismaksu... IPv6 on ilmainen mutta kytkeminen maksaa ja kun sitä ei niin paljon kaivata vielä. 

 

Saitko pingattua Googlen IPv6 osoitteeseen. Kokeilitko traceroute6?

---

Olin eilen niin turhautunut niin sain sen hoidettua HE-Net:in tunnelilla.

sm@localhost:~$ traceroute6 google.fi


traceroute to google.fi (2a00:1450:400f:804::2003) from 2001:470:28:a37::1:1, 30 hops max, 24 byte packets


 1  samip-2.tunnel.tserv24.sto1.ipv6.he.net (2001:470:27:a37::1)  14.421 ms  16.239 ms  14.672 ms


 2  ge2-20.core1.sto1.he.net (2001:470:0:11e::1)  11.705 ms  15.245 ms  11.982 ms


 3  2001:7f8:d:fe::115 (2001:7f8:d:fe::115)  11.744 ms  11.897 ms  13.893 ms


 4  2001:4860::1:0:26ec (2001:4860::1:0:26ec)  30.563 ms  27.96 ms  33.682 ms


 5  2001:4860:0:1::e5 (2001:4860:0:1::e5)  28.209 ms  28.187 ms  31.478 ms


 6  arn09s05-in-x03.1e100.net (2a00:1450:400f:804::2003)  27.685 ms  28.028 ms  27.748 ms

(HE-NET tunnelilla)

No hyvä että toimii jollakin tavalla jos IPv6 on välttämätön... Olisihan se hyvä että palvelimet vastaisi molemmilla IPv4 + IPv6... sitten vasta kuluttajalaitteet... 

Saas nähdä missä vaiheessa se tipping point tulee. Olen ihan varma että verkkojen ylläpitäjät on sitä mieltä että kuka nyt viitsii edes konfiguroida koko IPv4:sta, kun siitä on pelkkää haittaa. Mennään IPv6 only verkoilla niin kaikki on paljon selkeämpää. Puhumattakaan kaikeasta NAT hole punching roskasta ja CG-NAT:eista, joiden taakse vielä tupla nattina kuluttajien oman purkin NAT ja muista ongelmista käyttäjien ja rate-limittien kanssa, sekä jostain port forwardingeista. Ihan hirveetä ja turhaa säätämistä. Ihan sama kuvio on nähty uudelleen ja uudelleen, 64 bittisten käyttisten suhteen, Windows versioiden suhteen jne. Siis mitä, julkaisiko joku uuden pelin joka ei toimi täysin 32 bittisellä XP:llä, miksi joku tekee niin roskaa softaa.Eihän kukaan halua käyttää 64 bittisiä systeemeitä, kun niistä on kuulemma niin paljon ongelmia ja vaivaa.

Tämä on tietysti tulevaisuuden juttu joka jää nähtäväksi, jälkeenpäin katsoen kaikki näyttää niin ilmiselvältä ja siinä vaiheessa kun murros tapahtuu niin noista asioista puhuminen vaan jotenkin mystisesti loppuu ja katoaa. Kuten tämäkin keskustelu siirtyy historian arkistoihin.

Englanti on muuten aloittanut IPv4 osoitteiden myymisen: ne kun on kerran täysin arvottomia, jos et niitä ajoissa myy. Ihan kuten Bitcoinit.

Edit: Tässä hyvää IPv6 tilastoa RIPE:ltä Suomi valkoisella. Googlen IPv6 tilastot taas kuvaavat paremmin käytäntöä, eli kuinka hyvin loppukäyttäjät saavat IPv6 osoitteita.

Tässä edes odotetaan että operaattoreidenkin omat verkkosivut toimisivat IPv6:lla... Tai muutenkin verkkosivut voisivat toimia IPv6:lla... Ennen kuluttajan ei kannata oikein siirtyä IPv6 käyttämään jos palvelimet eivät käytä IPv6. 

Ja ei IPv6 Only verkkoja varmaan voida laittaa kymmeniin vuosiin mutta edes rinnakkain ajettaisiin... Monet DSLAMit ei varmana tue IPv6:sta.

Konesali jossa palvelimeni on ei ole natiivia IPv6 koska avausmaksut niin korkeat siihen nähden mitä hyötyä siitä olisi. Operaattorin laite ei tue IPv6 joten sekin joutuisi vaihtoon... (Joku Juniperin 1Gbps runkokytkin). 

6to4 taas tuo pingiä lisää kun menee Ficixin kautta... joten vaikka on IPv6 osoite palvelimella niin menee aina IPv4:lla. 

Tälläisen conffiksen tein Debian-reitittimelleni:

https://sintonen.fi/debian-6rd/

Tuo siis toimii dynaamisesti eikä sisällä kiinteitä IP-osoitteita.

Täysin tyytyväinen en ole siihen että tuo tekee turhia radvd-conffiksen kirjoituksia joka RENEW-tilanteessa ym.

Tein "option-6rd" scriptiin pienen parannuksen:

- Nyt operaatioita ei suoriteta kuin tilanteessa jossa 6RD-configuraatio ja/tai IPv4 -osoite muuttuu

Hei

Tässä on minun versioni, tehty debianille mutta toiminee ubuntullakin:

#!/bin/sh
#
# hae ipv4 osoite eth0 kortilta
#


extipv4="$(/sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}')"



# laske 6rd ipv6 osoite ipv4 osoittesta
#
extipv6="$(ipv6calc -I ipv4 $extipv4 --action 6rd_local_prefix --6rd_prefix 2001:2003::/32 --6rd_relay_prefix 80.221.111.254/0 -O ipv6addr | cut -d/ -f1 | awk '{ print $1 1}')"





case "$1" in


    start)





        echo "Asetan sonera-ipv6 tunnelin julkisesta osoitteesta " $extipv4 " kayttamaan " $extipv6





        ip tunnel add sonera-ipv6 mode sit remote 80.221.111.254 local $extipv4 ttl 255


        ip link set sonera-ipv6 up


        ip addr add $extipv6/64 dev sonera-ipv6


        ip route add ::/0 dev sonera-ipv6





        exit 1


        ;;


    stop)


        echo "Poistan sonera-ipv6 tunnelin.."





        ip -6 route del default


        ip link set sonera-ipv6 down


        ip tunnel del sonera-ipv6





        exit 1


        ;;


    *)


        echo "Aja $0 parametrilla start tai stop"





        exit 1


        ;;


esac

ja pastee samasta jos näyttää oudolta/puuttuu jotain: sonerav6.tunnel.sh

Skripti olettaa että ulkoverkkoon päin oleva kortti on eth0, asetetaan extipv4= alkuisella rivillä.

Tallenna siis tuo esim nimellä sonerav6.tunnel.sh

Anna sille ajo-oikeudet: chmod 700 sonerav6.tunnel.sh

Aja skripti roottina: sudo ./sonerav6.tunnel.sh start

Jos kaikki meni kuten strömsössä voit nyt testata yhteyden esim. traceroute6 ipv6nyt.fi:

$ traceroute6 ipv6nyt.fi


traceroute to ipv6nyt.fi (2a00:13f0:0:1005::11), 30 hops max, 80 byte packets


 1  2001:2003:50dd:6ffe::2 (2001:2003:50dd:6ffe::2)  22.348 ms  22.520 ms  22.485 ms


 2  * * *


 3  2001:2000:600a:4ff:3:0:2016:1 (2001:2000:600a:4ff:3:0:2016:1)  23.544 ms  23.770 ms  23.973 ms


 4  * * *


 5  ipv6nyt.fi (2a00:13f0:0:1005::11)  24.025 ms  24.228 ms  24.194 ms

Testasin scriptiäsi Debianissa ja hyvin toimii kunhan asentaa ipv6calc paketin pakettihallinnasta...

aptitude install ipv6calc

Itselläni siis Debian reititin mutta en saanut 6rd reititetty. 6to4 onnistuin kyllä. Tämä 6rd on paljon vieraampi kun tuo 6to4... Tartteeko tämä jotakin muuta kuin 6to4?

Huomasin lisäksi että 6to4 ei reitity esim omalle palvelimelle mutta www.google.com toimii ihan hyvin.

Taisin ratkaista 6rd ongelman... 

6rd:llä ainakin yhteydet toimii paremmin... sehän on suoraan Soneran verkossa tämä Soneran oma... 6to4 ei reititä kaikkialle, esim omalle palvelimelle ei pääse 6to4:lla mutta 6rd:llä ja natiivisesti pääsee. 

Maltion sitten tunkata tuon 6rd tunneloinnin päälle Ubuntun kanssa ja tein tölkistä samalla reitittimen, joka hoitaa liikennöinnin reitityksen koko sisäverkkoon. Hienosti toimii, myös DDNS nimet päivittyvät automaattisesti ja tunnelin osoitepäivittyy täysin automaattisesti jne. Yhteysnopeudt on mainiot Telia:n 6rd:llä.

Kuitenkin jäi yksi ongelma, josta ehkä tietäjät tietää. En ymmärrä miksi WiFissä oleva puhelin on täysin jumissa IPv6:n osalta, vaikka muilla koneilla (Linux) verkossa IPv6 toimii aivan mahtavasti. Jos joku tietää mistä on kyse, niin saa antaa pro-tipsin.

Edit, kappalejako kuntoon. Ilman javascriptiä tämä näköjään hukkaa kappaleet.

IPv6 DNS olisiko? Vai myös suorat IPv6-yhteyksissäkin ongelmia?

Testasin lisää tuota ja ei tuolla taida olla mitään tekemistä Linuxin, tai 6rd:n kanssa. Vaan jotain todella hämärää taitaa olla tuon reittittimen toiminnassa. Tuntuu että kaikki IPv6 liikenne on täysin jojossa WLAN:sta, kun kerran Ubuntu reititin on kiinni LAN:ssa.

Pitää debugata ja katsoa jos keksisin mistä johtuu. Mutta packet loss on järjetöntä, ja todellakin TCP:llä siirtonopeudet ovat enemmänkin kilotavuja sekunnissa, kuin megatavuja. Eikä edes ole vitsi. Just nyt siirtyy 680 bytes/second wgetillä. LANista tulee niin kovaa kun Telian kaistajarru antaa tulla tällä (rajoitetulla) liittymällä.

Eli omassa verkossa / reitittimessä (?) on jotain omituista vikaa (?). Vika ei ole Ubuntussa, koska sitä tuskin kiinnostaa onko WLANista vai LANsta tuo IPv6 liikenne peräsin, kun sen kannalta molemmat on samassa interfacessa. Reitittimen IPv6 mode on link local only, joten sen ei pitäisi tähän liikenteeseen sotkeutua. ip -6 route, on sama molemmissa koneissa, jne.

Tuleepahan yksi hyvä vianetsintä / debug harjoitus lisää. (Yay, ihan kun näitä ei muutenkin riittäisi tarpeeksi.)

Edit ja jatkot: Pienen säätämisen jälkeen vahvistettu. Sama läppäri, eetteri kaapelilla, IPv6 toimii täydelisesti. Vika siis ei ole läppärin IPv6 konfigissa, eikä myöskään Ubuntu reitittimen konfigeissa, eikä Telia:n 6rd:ssä. Vaan nyt liittyy vahvasti tuohon Telian toimittamaan ZyXELin reitittimeen, miten se voi sabotoida IPv6 liikennettä. Tuo jää selvitettäväksi. Mutta nyt on vikaa rajattu aikalailla.

Jatkot, koska on kind of off-topic, niin forkkasin tänne:

https://yhteiso.telia.fi/t5/Kiinteat-nettiyhteydet-ja/ZyXEL-NBG6515-IPv6-WLAN/m-p/177979#M10440

Lisädebuggauksen jälkeen lopputulos on tämä:

WLAN liikenne joka reitittyy eteenpäin Internettiin on se joka jumittaa.

Testasin myös, että WLAN IPv6 ei sinänsä ole ongelma, eli jos otan yhteyden paikallisen palvelimen link local tai public IPv6 osoitteeseen, toimii yhteys hyvin. Mutta vain kun liikenne reitittyy WLANsta (link localin / reitittimen kautta) eteenpäin, se alkaa katoamaan ja WLAN yhteyden kohdalla, koska paketit tulevat Internetistä kyllä reitittimelle asti ongelmitta.

Tämä on varmasti sellainen juttu, jonka tietäjät tietää ja osaa sanoa kuin apteekinhyllyltä mitä on sössitty. MTU on jo laitettu radvissa 1280 tavuun.

Tulee ihan mieleen klassikot kuten duplex issuet ethernetissä aikanaan. Toi on just niin paha, mutta miksi? Sitä tiedä en.