Kuusitunneli.fi - ilmainen suomalainen IPv6-tunnelipalvelu

Harmi tosiaan tuossa Netgearissa ei ole asetusta tuolle 6in4:lle. 6to4 toki voi kokeilla tai 6rd:tä mutta 6rd kai toimii vain Telian kiinteässä verkossa pelkästään. Sen gatewayn IP-osoite on muuten muuttunut. Lisätietoa: Vs: Sonera IPv6 - sivu 9 - Telia Yhteisö
Kävin Wiresharkilla kuulemassa tämän Telian uuden osoitteen; 6rd Border Relay IP: 84.251.255.254.

Aikaisempi osoite 80.221.111.254 onkin poistettu käytöstä tosiaan. Tämä avuksi niille joiden muovipurkit eivät tätä tietoa osaa DHCP Option 212:n takaa hakea, vaan se pitää itse määrittää tavalla tai toisella, esim. skriptillä kuten mulla Mikrotikin tapauksessa.

Tämä tulee siis Telian taloyhtiölaajakaistan takaa etsku/kuitu -liittymätekniikalla ilman mitään huoneistossa asuvia modeemipurkkeja.

PS. Kuusitunneli.fi toimii toki hienosti, mutta kuten aikaisemminkin todettua tässä ketjussa, on operin oma 6rd astetta parempi näin kun ei vieläkään sitä natiivia toteutusta ole...
 
Kävin Wiresharkilla kuulemassa tämän Telian uuden osoitteen; 6rd Border Relay IP: 84.251.255.254.
Enpä saanutkaan vielä tätä pelaamaan Mikrotikillä - liikennettä menee tunnelin suuntaan kyllä, mutta yhtään pakettia ei kuulu takaisin, joten ollaan takaisin Kuusitunnelissa. Tshoot jatkuu.

Lisätietoja;
  • 6rd Prefix Lenght: 38
  • 6rd Prefix: 2001:2003:f400::
...ja pahoittelut, alkaa kohta mennä topicin ulkopuolelle, mutta Kuusitunnelin kanssa samoissa transitiotekniikoissa pyöritään, ja 6rd ollut tässäkin ketjussa aikaisemmin esillä. Tehdään uusi ketju jos lähtee käsistä.
 
Viimeksi muokattu:
Enpä saanutkaan vielä tätä pelaamaan Mikrotikillä - liikennettä menee tunnelin suuntaan kyllä, mutta yhtään pakettia ei kuulu takaisin, joten ollaan takaisin Kuusitunnelissa. Tshoot jatkuu.

Lisätietoja;
  • 6rd Prefix Lenght: 38
  • 6rd Prefix: 2001:2003:f400::
...ja pahoittelut, alkaa kohta mennä topicin ulkopuolelle, mutta Kuusitunnelin kanssa samoissa transitiotekniikoissa pyöritään, ja 6rd ollut tässäkin ketjussa aikaisemmin esillä. Tehdään uusi ketju jos lähtee käsistä.

On hyvä jakaa myös tietoa tuosta 6rd:stä. Mikäli se onnistuu niin suosin sitä tietenkin koska operaattorilla on enemmän kapasiteettia kuin tunnelissani. Tosin hyvin se on kyllä toiminut ilman suurempia ongelmia jo kahden vuoden ajan. Toki pieniä katkoja ollut kun palvelimilta siirrelty.

Tietysti vaihtoehtona on myös 6to4, Tunnelbrokerin 6in4 (samanlainen kuin kuusitunneli.fi suurinpiirtein) ja sitten mm. Trexiltä Teredo -palvelu.
 
@olkitu Laittelin sulle Kuusitunneli.fi:n sivun kautta yhteydenottoa Reverseen liittyen, ja Telian 6RD toimii usein todella paljon huonommin kuin sun Kuusitunneli varsinkin kuin yrittää sitä käyttää eri IP osoitteilla.

Nimimerkillä, kaksi business ADSL yhteyttä sekä Talojakamoon asti valokuitu + sieltä coax, jonka johdossa on jotain häiriöitä.
 
@olkitu Laittelin sulle Kuusitunneli.fi:n sivun kautta yhteydenottoa Reverseen liittyen, ja Telian 6RD toimii usein todella paljon huonommin kuin sun Kuusitunneli varsinkin kuin yrittää sitä käyttää eri IP osoitteilla.

Nimimerkillä, kaksi business ADSL yhteyttä sekä Talojakamoon asti valokuitu + sieltä coax, jonka johdossa on jotain häiriöitä.

Kiinteän IPv6 osoitteesta on varmasti hyötyä kun ei muutu kokoajan - vaikka IPv4 muuttuu niin päivittää vain API:n kautta uuden osoitteen palvelimelle niin sitten taas toimii normaalisti.
 
upload_2019-12-1_21-58-24.png


Reilu vuodessa +5% enemmän IPv6 käyttäjiä Googlen (IPv6 – Google) mukaan ja kuusitunneli.fi palvelun kautta liikennne noin 2TB/kk tällä hetkellä.

RIPE:ltä loppui myös jaettavat IPv4-osoitteet joten uudet toimijat eivät tahdo osoitteita saada. Odotuslista on pitkä ja vain palautuvia osoitteita voidaan jakaa. Tosin osoitteita on oikeasti vapaana jos vain organisaatiot luopuvat käyttämättömistä osoitteista.
 
upload_2019-12-1_21-58-24.png


Reilu vuodessa +5% enemmän IPv6 käyttäjiä Googlen (IPv6 – Google) mukaan ja kuusitunneli.fi palvelun kautta liikennne noin 2TB/kk tällä hetkellä.

RIPE:ltä loppui myös jaettavat IPv4-osoitteet joten uudet toimijat eivät tahdo osoitteita saada. Odotuslista on pitkä ja vain palautuvia osoitteita voidaan jakaa. Tosin osoitteita on oikeasti vapaana jos vain organisaatiot luopuvat käyttämättömistä osoitteista.
Minusta yllättävää että IPV6 on Ruotsissa jopa Suomea matalammalla tasolla, olisin muistellut sen olevan korkeammalla kuin Suomessa.
 
Minusta yllättävää että IPV6 on Ruotsissa jopa Suomea matalammalla tasolla, olisin muistellut sen olevan korkeammalla kuin Suomessa.

Ainakin Ruotsissa on kiinteä laajakaista kovassa käytössä kun mobiili kallimpaa. Tästä voisi johtua...

Iso hyppy tuli meillä kun DNA ja Elisa alkoivat tarjoamaan mobiilissa. Saataisiin 10% lisää ainakin kun Telia ottaisi vielä käyttöön.
 
Kuusitunneli.fi palvelut näyttäisivät olevan sekaisin, mutta tilanne on varmaan tiedossa ja tulee korjautumaan lähiaikoina?
 
Kuusitunneli.fi palvelut näyttäisivät olevan sekaisin, mutta tilanne on varmaan tiedossa ja tulee korjautumaan lähiaikoina?

Ongelma on tiedossa ja se on palveluntarjoajan päässä. Odotan että palveluntarjoaja korjaa palvelimessa olevan ongelman mahdollisimman pian.
 
Kun tuossa tuli puheeksi toisella threadissä NAT64 ja DNS64 -palvelu niin nyt kuusitunneli.fi käyttäjille jos haluaa kokeilla miten IPv6 only toimisi pelkästään.

Kun asettaa IPv6-nimipalvelimeksi 2a01:4f9:c010:3e80::1 niin on käytössä. Voit kokeilla poistaa IPv4-osoite käytöstä kokonaan. Osa sovelluksista kuten Steam ja Spotify eivät tue ollenkaan IPv6 joten ne lakkaavat toimimasta.

Vastaava palvelu olisi Public NAT64 service .

Testailen mutta jos kiinnostaa saa myös kokeilla. Tämä toimii siis vain kuusitunneli.fi IPv6-osoitteilla ainakin alkuun. Pitää katsoa jos avaisi laajempaan käyttöön.

Ongelmia:

Jostain syystä osa sivuista ei toimi... Pitääpä miettiä mikäs tässä ongelmana.
 
Viimeksi muokattu:
Voisko johtua siitä että upotetut elementit (somet, YouTubet jne..) ei tule puhtaasti client dns pohjalta vaan ovat HTML tasolla IPv4 ohjattuja serverin päässä..
 
Jäin vaan miettimään...

240e:f7:4000::/36 (AS58461 China Telecom HangZhou IDC) - näyttäisi tekevän ICMPv6 + SYN scannin kaikille IPv6 osoitteille / porteille. Olen katsellut tuota muutaman päivän ja alkoi tympimään joten blokkasin reitityksen ja pistin mailin niille. Jäin vaan miettimään, tuleeko samaa tauhkaa myös kaikille muille kuusitunnelin käyttäjille.

No ainakin ne lajoittavat entropiaa satunnaislukuihin. Kun liikenne on blokattu, niin no route to host vastauksia ei lähetetä, mutta liikenne kyllä silti osallistuu vielä entropia-projektiin. - Kiitos siitä.

Lähettävät myös ihan valideja L2TP probeja. Onkohan toi ihan valtion tasolta tuo skannaus. ;)

Edit, off-topic. Mutta kysytään kun liittyy asiaan.

@olkitu - Eiks niin, että paremmissa reitittimissä tuo asia on hoidettu niin, että NDP kyselyitä ei lähetetä turhaan jatkuvasti saapuvan liikenteen mukaan. Vaan tehdään säännöllinen all nodes kysely, jonka perusteella pidetään lista muistissa. -> Turhan liikenteen voi sitten dropata suoraan, eikä tarvitse lähettää NDP paketteja jokaist satunnaista IP osoitetta varten LANissa. - Tuostahan on tupla hyöty, verkkolatenssit pysyy pienempänä ja turhaa multicast liikennettä ei jatkuvasti valu verkkoon kaikkien riesaksi. - Kuulostaisi kokonaisvaltaisesti järkevältä järjestelyltä. Olen nimittäin joskus huomannut, että jos noihin all nodes kyselyihin ei vastaa, niin sen jälkeen liikenne loppuu hetken päästä. Eikä osoite kohtaisia NDP probeja koskaan tule.
 
Viimeksi muokattu:
Jäin vaan miettimään, tuleeko samaa tauhkaa myös kaikille muille kuusitunnelin käyttäjille.
Kyllä noita tulee. Kiinasta ei tule mitään hyvää:
Koodi:
Action Time             Rule                                      Source                     Protocol
x      May 10 08:20:46  Default deny rule IPv6 (1000000105)       [240e:f7:4f01:c::2]:5498   TCP:S
 
Itsellä myös kiinalla banaania päällä samoista syistä. Toki liikenteestä päätellen, ovat tehneet backup probeja ulkomaisiin konesaleihin. Mutta ison siivun saa CH estolla jo pois. En ole sen tarkemmin validoinut omaa banaanin osuvuutta, kuin että kunhan blokkaa.
 
Jäin vaan miettimään...

240e:f7:4000::/36 (AS58461 China Telecom HangZhou IDC) - näyttäisi tekevän ICMPv6 + SYN scannin kaikille IPv6 osoitteille / porteille. Olen katsellut tuota muutaman päivän ja alkoi tympimään joten blokkasin reitityksen ja pistin mailin niille. Jäin vaan miettimään, tuleeko samaa tauhkaa myös kaikille muille kuusitunnelin käyttäjille.

No ainakin ne lajoittavat entropiaa satunnaislukuihin. Kun liikenne on blokattu, niin no route to host vastauksia ei lähetetä, mutta liikenne kyllä silti osallistuu vielä entropia-projektiin. - Kiitos siitä.

Lähettävät myös ihan valideja L2TP probeja. Onkohan toi ihan valtion tasolta tuo skannaus. ;)

Edit, off-topic. Mutta kysytään kun liittyy asiaan.

@olkitu - Eiks niin, että paremmissa reitittimissä tuo asia on hoidettu niin, että NDP kyselyitä ei lähetetä turhaan jatkuvasti saapuvan liikenteen mukaan. Vaan tehdään säännöllinen all nodes kysely, jonka perusteella pidetään lista muistissa. -> Turhan liikenteen voi sitten dropata suoraan, eikä tarvitse lähettää NDP paketteja jokaist satunnaista IP osoitetta varten LANissa. - Tuostahan on tupla hyöty, verkkolatenssit pysyy pienempänä ja turhaa multicast liikennettä ei jatkuvasti valu verkkoon kaikkien riesaksi. - Kuulostaisi kokonaisvaltaisesti järkevältä järjestelyltä. Olen nimittäin joskus huomannut, että jos noihin all nodes kyselyihin ei vastaa, niin sen jälkeen liikenne loppuu hetken päästä. Eikä osoite kohtaisia NDP probeja koskaan tule.

Voisi blokata tuon skannaavan IPv6-osoitteen 240e:f7:4f01:c::2 alkajaisiksi niin loppuu tältä osin. Toki se jatkuu jostakin uudestaan.

En osaa sanoa tuosta NDP:stä paljonkaan miten toteutettu reitittimissä.
 
Onkohan login ikkuna hajonnut? Onnistuinpa tietysti hukkamaan oman tunnelini numeron, niin ei pahemmin API:n kautta päivitellä.
 
Onkohan login ikkuna hajonnut? Onnistuinpa tietysti hukkamaan oman tunnelini numeron, niin ei pahemmin API:n kautta päivitellä.

Kukaan ei tainnut sitä mainita, mutta siis ainakin mun käsityksen mukaan tunnelin ID on ihan siinä IP-osoitteessa mukana, joten sitä ei tarvii metsästää käyttöliittymän kautta.

Tietysti saattaa olla että jossain tilanteissa tuo sääntö ei pidä, mutta ainakin mulla se näyttäisi olevan näin kaikkien tunnelien kohdalla.
 
Kukaan ei tainnut sitä mainita, mutta siis ainakin mun käsityksen mukaan tunnelin ID on ihan siinä IP-osoitteessa mukana, joten sitä ei tarvii metsästää käyttöliittymän kautta.

Tietysti saattaa olla että jossain tilanteissa tuo sääntö ei pidä, mutta ainakin mulla se näyttäisi olevan näin kaikkien tunnelien kohdalla.

Tunnelin ID tarvitaan, jotta tiedetään mihin tunneliin päivitetään uusi IP-osoite. IP-parametri on optional. Tässä on API dokumentaatio: API - Kuusitunneli.fi
 
Kukaan ei tainnut sitä mainita, mutta siis ainakin mun käsityksen mukaan tunnelin ID on ihan siinä IP-osoitteessa mukana, joten sitä ei tarvii metsästää käyttöliittymän kautta.

Näköjään, olipas hyvin ajateltu (ei tullut edes mieleen). Tuon voisi kieltämättä dokumentoida jos se ei ole vain vahinko niin kauan kunnes lähdetään kierrättämään tunneli-ID:tä.
 
Itsellä on parhaimmillaan mennyt yli 50% liikenteestä IPv6:lla DNS-pyyntöjen perusteella. En tiedä koska liikenne on blokkaantunut kokonaan, mutta mitään totaalista verkkostoppia en ole huomannut pienten viiveiden lisäksi. Happy eyeballs toimii siis aika hyvin.
Täytyykin nyt säätää, että Kuusituneliin ei mene mitään tarpeetonta liikennettä kuten videostriimeja.
 
Nyt on taas käynnissä normaaliin tapaan. Jospa näitä katkoja vaan ei tulisi useasti... Harmillisesti ei ole toista palveluntarjoajaa minkä kautta voisi varmentaa kahdennetusti ilman korkeita kustannuksia.

Pelkkään kuusitunneli.fi ei kannata liikennöidä eli IPv4 sitten jos IPv6 ei toimi. Tämä pitäisi automaattisesti tapahtua asiakaspäässä. Itsellä myös yli 50% liikenteestä kuusitunnelin kautta normaalisti.
 
Jees, parin kaverin kanssa myös todettiin, että kuoli noin 14:30.
 
Olipas erikoinen vika mutta nyt korjattu. Reititin jouduttiin kokonaan käynnistämään uudelleen.

Saisikos vähän teknisemmän post mortemin miksi näin kävi?
BGP kun ei varsinaisesti edes "kuollut", vaan liikenne vaan ei enää päässyt eteenpäin.
 
Saisikos vähän teknisemmän post mortemin miksi näin kävi?
BGP kun ei varsinaisesti edes "kuollut", vaan liikenne vaan ei enää päässyt eteenpäin.

Operaattorilta sain selvityksen että konfiguraatio muutos verkossa aiheutti fyysisen portin jumiutumisen jonka takia liikenne ei kulkeutunut oikein sisäisillä reiteillä. Koko reititin joutui käynnistämään uudelleen niin palautui toimintaan.
 
@olkitu Onnistuisikos kuusitunneliin se /48 prefixit kuten HE:n tunneleissa? Olisi huomattavasti mukavampaa vaikka itse juuri en todennäköisesti tarvitsekkaan.
 
@olkitu Onnistuisikos kuusitunneliin se /48 prefixit kuten HE:n tunneleissa? Olisi huomattavasti mukavampaa vaikka itse juuri en todennäköisesti tarvitsekkaan.

Valitettavasti ei onnistu ja kehitys ollut nollaa kuusitunnelin osalta parin vuoden aikana - aika muissa projekteissa.

Mutta katsotaanpas jospa tänävuonna saisi omaa aikaa tämän kehitykseen - ainakin palvelinpuolen päivitys odottaa.

Pakko sanoa että odotin jo natiiivista IPv6:tta operaattoreille kiinteään mutta kun ei tunnu näkyvän niin varmaan pitäisi kehityksen jatkua tämän osalta.
 
Pakko sanoa että odotin jo natiiivista IPv6:tta operaattoreille kiinteään mutta kun ei tunnu näkyvän niin varmaan pitäisi kehityksen jatkua tämän osalta.

Ainakin Elisan osalta ihan älyvapaata touhua, kiinteisiin liittymiin ei tahdota tarjota IPv6:sta sitten millään.
 
Hmm, en tiedä onko kuusitunnelilla samoja ongelmia, mutta ainakin DTNET:n BGP tais syödä itsensä? 2a0b:a700::/29 rangen osoitteet toimii kyllä, mutta oma BGP sessio ei vaan halua tulla pystyyn.
 
Jooh, reititys hajosi.

Edit: Tietysti status sivu ei ois hullumpi idea.
 
Viimeksi muokattu:

Statistiikka

Viestiketjuista
261 347
Viestejä
4 535 699
Jäsenet
74 790
Uusin jäsen
anykanen

Hinta.fi

Back
Ylös Bottom