mboost-dp1
Nye features til IPv6 test
En gang for længe siden nævnte jeg i en tråd, at jeg havde lavet en IPv6 test.
Jeg har lige tilføjet en ny feature så den kan vise hvilken rækkefølge browseren prioriterer forskellige protokoller. Dog mangler den stadig at udskrive en advarsel hvis browseren vælger på en inkonsistent måde.
Jeg har tænkt mig at der skal tilføjes en ny feature per uge, så længe der er gode forslag. På nuværende tidspunkt er testen lavet sådan at der kun er scripting på server siden, og sådan synes jeg det skal blive ved at være.
Hvis I har forslag til features som kan tilføjes til testen uden at bruge javascript, så skyd løs.
Og for nu at komme spørgsmålene i forkøbet, så har jeg valgt at holde mig fra javascript fordi der allerede findes en udmærket javascript baseret IPv6 test.
Jeg har lige tilføjet en ny feature så den kan vise hvilken rækkefølge browseren prioriterer forskellige protokoller. Dog mangler den stadig at udskrive en advarsel hvis browseren vælger på en inkonsistent måde.
Jeg har tænkt mig at der skal tilføjes en ny feature per uge, så længe der er gode forslag. På nuværende tidspunkt er testen lavet sådan at der kun er scripting på server siden, og sådan synes jeg det skal blive ved at være.
Hvis I har forslag til features som kan tilføjes til testen uden at bruge javascript, så skyd løs.
Og for nu at komme spørgsmålene i forkøbet, så har jeg valgt at holde mig fra javascript fordi der allerede findes en udmærket javascript baseret IPv6 test.
Daniel-Dane (2) skrev:Nul IPv6 med Fullrate. Why am I not surprised?
Fordi vi ikke tilbyder IPv6 til kunder endnu.
Det betyder dog ikke at vi ikke leger med IPv6 internt...hvilket du ville finde ud af hvis du læste den orginale tråd.
Men jeg er ikke overrasket over du bare whiner løs på autopilot...
Jeg whiner ikke. Jeg observerer blot, at der stadig ikke er noget IPv6 til kunder.
Jeg får samme resultater med 3.
Jeg får samme resultater med 3.
Sådan der. Mit noname fiber klarer stadig det hele.
2067ba68f6ea6d315f4eb15be7c1a7ad063cd5d31319124908
2067ba68f6ea6d315f4eb15be7c1a7ad063cd5d31319124908
8d89ddf2468178e8a39698e8e32d83425acc81fd1319126710
7 billeder..
Man kan ikke komme tilbage til testen når man har trykket på menuerne?...
7 billeder..
Man kan ikke komme tilbage til testen når man har trykket på menuerne?...
6to4 og teredo. Jeg burde nok se at komme videre med den feature til at fortælle i testresultaterne hvilken type klientadresse der blev valgt for hver type server adresse.Daniel-Dane (9) skrev:Sådan der. Mit noname fiber klarer stadig det hele.
Min log siger godt nok at du fik 8. Jeg opdagede også at du nok har fået en advarsel der sagde:didriksen86 (10) skrev:7 billeder..
Du hentede nogle tiles over IPv6, men ikke dem alle. En forbindelse der virker nogle gange men ikke hele tiden vil på et senere tidspunkt give dig fejl som er svære at fejlfinde.Den advarsel skulle ikke have været der, og der er nok mange som har set den uden grund. Jeg havde været ved at ændre hvordan optællingen af billeder hentet over teredo foregik.
Hensigten var at man ikke skulle have advarsler omkring fejl der kun berørte de tiles der kunne hentes over teredo. Jeg vil ikke advare om det fordi jeg ikke kender nogen sites der kører på en teredo adresse.
Min ændring til at fjerne en teredo relateret advarsel resulterede uheldigvis i at jeg fik introduceret en anden advarsel, der ikke skulle have været der. Fejlen er rettet, men jeg må hellere restrukturere mit rapporteringsscript så jeg kan unit teste det med faktiske logfiler.
Der findes et link, men det er ikke nemt at finde, og det ligger på en side som ikke er helt opdateret. Jeg burde nok indsætte et link til testen i menuen i toppen.didriksen86 (10) skrev:Man kan ikke komme tilbage til testen når man har trykket på menuerne?...
Og så må jeg hellere gennemgå hele sitet og sikre mig at alt er opdateret før jeg lancerer det produkt jeg arbejder på.
Nu vi er i gang med at snakke IPv6 vil jeg lige høre om der er nogen som kender nogle officielle oplysninger om hvornår den næste store koordinerede test foregår.
Der har været snak om en uges test lignende den 24 timers test, der foregik 8. juni i år. Men jeg har ikke fundet nogen officiel kilde, der giver en dato.
Jeg har hørt 6. til 12. februar. Og jeg har også hørt at det muligvis vil blive en uge startende 6. juni.
Der har været snak om en uges test lignende den 24 timers test, der foregik 8. juni i år. Men jeg har ikke fundet nogen officiel kilde, der giver en dato.
Jeg har hørt 6. til 12. februar. Og jeg har også hørt at det muligvis vil blive en uge startende 6. juni.
Samme OS som #8. Det er ikke Stofa der er helt med, det er dit operativsystem der automatisk sætter 6to4 og teredo op for dig.gumleren (13) skrev:Stofa er tilsyneladende helt med, når det kommer til IPv6; 20 ud af 20.
Denne 6to4 feature som jeres OS har kræver nok at computeren har en offentlig IP og ikke er afskærmet fra internettet af en NAT enhed.
6to4 og teredo er ikke helt så stabile som man kunne ønske sig, og nogen personer har beskyldt stabilitetsproblemerne med 6to4 og teredo for at have sløvet overgangen til IPv6 ned.
Men mange af stabilitetsproblemerne med 6to4 og teredo skyldes NAT. Hvis man bruger 6to4 eller teredo fra en offentlig IP er det ikke nær så ustabilt. Så på en måde er det NAT der har skylden. NAT har også fået mange til fejlagtigt at tro at overgangen til IPv6 kan vente adskillige år endnu.
Tilbage til jeres testresultat. Jeres computere har kun 6to4 og teredo adresser, men ingen native IPv6 adresse. Rækkefølgen jeres browsere prioriterede serveradresserne i var: 6to4, IPv4, Teredo, Native IPv6.
Det er en usædvanlig rækkefølge, og jeg ville normalt forvente at de blev afprøvet i den modsatte rækkefølge. Men den rækkefølge jeres browsere bruger er dog nogenlunde fornuftig givet det udvalg af adresser jeres computere selv har.
Men I bruger to forskellige browsere, så hvorfor vælger begge den samme lidt usædvanlige prioritering? Mit gæt er at operativsystemet ordner rækkefølgen på adresserne og giver dem til browseren i den rækkefølge det synes de skal slås op.
Jeg burde nok tilføje en slags checklist der viser hvilke af de fire typer adresser klienten har.
Dagens nye feature er en forbedret algoritme til at afgøre hvornår browseren er færdig med at hente billeder.
Med den gamle version skulle computere som kun har IPv4 vente 12-20 sekunder før serveren ville aflevere et resultat. Det var fordi serveren ikke vidste om der stadig ville komme flere forespørgsler.
Den nye version venter højst 3 sekunder efter den sidste request.
Det vil sige langt hurtigere svar for dem der ikke har IPv6. Brugere som har både IPv4 og IPv6 og kan hente alle 20 tiles vil ikke se nogen stor forskel endnu.
Med den gamle version skulle computere som kun har IPv4 vente 12-20 sekunder før serveren ville aflevere et resultat. Det var fordi serveren ikke vidste om der stadig ville komme flere forespørgsler.
Den nye version venter højst 3 sekunder efter den sidste request.
Det vil sige langt hurtigere svar for dem der ikke har IPv6. Brugere som har både IPv4 og IPv6 og kan hente alle 20 tiles vil ikke se nogen stor forskel endnu.
Ang. IPv6. Jeg snakkede med et par medlemmer af Foreningen Kollegienet Odense. De fortæller at de måske kan blive den første ISP med IPv6 til private - og at de har fået så mange IPv6-adresser, at hver eneste bruger på Kollegienet får flere adresser end der er til rådighed i IPv4. Mener det var 5-6 mia. adresser de snakkede om...
Et par, måske :)
Når de så også får skiftet multimode-fiberen ud med en singlemode, så vi kan få 1 Gbit backbone i stedet for 100 Mbit backbone bliver jeg glad. Al hardware kan trække 1 Gbit - men ham som stod for nedgravning af fiber benyttede multimode fordi de var billigere. Samtidig dokumenterede han ikke hvad han lavede, eller hvor der blev gravet kabler ned. Det er lidt et problem, nu hvor han er druknet i en sø. Kort sagt er der ingen der ved hvor kablerne ligger henne.
Når de så også får skiftet multimode-fiberen ud med en singlemode, så vi kan få 1 Gbit backbone i stedet for 100 Mbit backbone bliver jeg glad. Al hardware kan trække 1 Gbit - men ham som stod for nedgravning af fiber benyttede multimode fordi de var billigere. Samtidig dokumenterede han ikke hvad han lavede, eller hvor der blev gravet kabler ned. Det er lidt et problem, nu hvor han er druknet i en sø. Kort sagt er der ingen der ved hvor kablerne ligger henne.
#20
De blev først sure efter han døde - indtil da så det jo fint ud. Der blev gravet fiber ned, alle dele af Kollegienet (med undtagelse af et enkelt sted; 40 brugere og min. ½ mio. kr i etableringsomkostninger) blev forbundet med min 100 Mbit, 1 - 10 Gbit i backbone. Men da han døde fik de ligesom øjnene op for hvordan det stod til.
Enkelte steder ligger fiberkablerne endda direkte i jorden. Som minimum kunne man da lægge kablerne i nogle rør, så det var billigere at opgradere dem senere, men næ nej - der skulle spares penge :/
De blev først sure efter han døde - indtil da så det jo fint ud. Der blev gravet fiber ned, alle dele af Kollegienet (med undtagelse af et enkelt sted; 40 brugere og min. ½ mio. kr i etableringsomkostninger) blev forbundet med min 100 Mbit, 1 - 10 Gbit i backbone. Men da han døde fik de ligesom øjnene op for hvordan det stod til.
Enkelte steder ligger fiberkablerne endda direkte i jorden. Som minimum kunne man da lægge kablerne i nogle rør, så det var billigere at opgradere dem senere, men næ nej - der skulle spares penge :/
De burde som minimum have 1.2 kvadrillion adresser at gøre med. Og hvis ikke de giver minimum 295 trillioner til hver bruger, så mener de jo ikke det der med IPv6 alvorligt.Alrekr (17) skrev:de har fået så mange IPv6-adresser, at hver eneste bruger på Kollegienet får flere adresser end der er til rådighed i IPv4. Mener det var 5-6 mia. adresser de snakkede om
jeg har kun IPv4 Connectivity :( 160fd7e07a8489a29f37ea5938523c079942f25c1320137771
Men, mit dd-wrt build understøtter heller ikke ipv6 :)
Men, mit dd-wrt build understøtter heller ikke ipv6 :)
Jeg har nu omskrevet hele den iframe der genererer resultatet af testen.
Den gamle var lavet som et shell script, og den var lidt sløv og problematisk at teste. Det med manglende test fremgår også af #11
Jeg startede med at lave nogle unit tests og sikrede mig at jeg havde 100% coverage på mit shell script. Jeg har så lavet en ny implementation i C, som godt nok er dobbelt så lang som shell scriptet, men til gengæld er det mange gange hurtigere og også nemmere at teste og udvide på.
På nuværende tidspunkt burde den øgede hastighed være den eneste synlige forskel. Som det ser ud nu er det eneste som stadig sker i shell scriptet er validering af at det bliver kaldt med et gyldigt test-id. Derefter kalder det først et C program der venter på at browseren er færdig med at hente billeder, og dernæst et andet C program der genererer resultatet.
Jeg ville gerne have testet gennem en ekstern proxy igen for at se hvordan det ser ud fra en anden IP end min egen. Men desværre er ipv6webproxy.com forsvundet, og det var desværre den eneste jeg kendte til, som kunne kombinere IPv4 og IPv6 indhold på samme side.
Jeg vil prøve om jeg kan skrue et script sammen, som kan løbe gennem samtlige testid i mine logfiler og undersøge om den gamle og den nye implementation giver samme resultat på hver af dem. Når det er testet er jeg klar til at tilføje nye features.
Nogle af de idéer til nye features jeg selv nævnte tidligere i tråden burde jeg få lavet senere på ugen eller måske i næste uge. Jeg havde håbet at der ville være kommet forslag til nye features ud over dem jeg selv kunne finde på. Men tilsyneladende er der ikke ret mange af jer, der har IPv6 adgang overhovedet.
Ugen startende 6. juni var en idé som Vint Cerf nævnte i en video som Hurricane Electric lagde på facebook for nogle uger siden. Jeg har ikke hørt om andre har tilsluttet sig idéen, men der er andre Google ansatte som har nævnt at de gerne så en hel uges test, så jeg gætter på at Google gennemfører en hel uges test på et tidspunkt i 2012, men hvilken dato det bliver må stadig bero på gæt.
I samme video nævnte Vint Cerf også at han gerne så en skæringsdato i starten af 2013 hvor man definitivt skifter fra IPv4 til IPv6. Det ville være en pæn rund dato fordi det da ville være 30 år siden man skiftede til IPv4. Men han erkendte også at det nok var lidt for optimistisk.
Den gamle var lavet som et shell script, og den var lidt sløv og problematisk at teste. Det med manglende test fremgår også af #11
Jeg startede med at lave nogle unit tests og sikrede mig at jeg havde 100% coverage på mit shell script. Jeg har så lavet en ny implementation i C, som godt nok er dobbelt så lang som shell scriptet, men til gengæld er det mange gange hurtigere og også nemmere at teste og udvide på.
På nuværende tidspunkt burde den øgede hastighed være den eneste synlige forskel. Som det ser ud nu er det eneste som stadig sker i shell scriptet er validering af at det bliver kaldt med et gyldigt test-id. Derefter kalder det først et C program der venter på at browseren er færdig med at hente billeder, og dernæst et andet C program der genererer resultatet.
Jeg ville gerne have testet gennem en ekstern proxy igen for at se hvordan det ser ud fra en anden IP end min egen. Men desværre er ipv6webproxy.com forsvundet, og det var desværre den eneste jeg kendte til, som kunne kombinere IPv4 og IPv6 indhold på samme side.
Jeg vil prøve om jeg kan skrue et script sammen, som kan løbe gennem samtlige testid i mine logfiler og undersøge om den gamle og den nye implementation giver samme resultat på hver af dem. Når det er testet er jeg klar til at tilføje nye features.
Nogle af de idéer til nye features jeg selv nævnte tidligere i tråden burde jeg få lavet senere på ugen eller måske i næste uge. Jeg havde håbet at der ville være kommet forslag til nye features ud over dem jeg selv kunne finde på. Men tilsyneladende er der ikke ret mange af jer, der har IPv6 adgang overhovedet.
Jeg undersøgte det lidt mere og fandt ud af, at ugen fra 6. til 12. februar er en idé som nogle udbydere i Brasilien har fundet på. Tilsyneladende er der ingen udenfor Brasilien som har tilsluttet sig idéen.kasperd (12) skrev:Jeg har hørt 6. til 12. februar. Og jeg har også hørt at det muligvis vil blive en uge startende 6. juni.
Ugen startende 6. juni var en idé som Vint Cerf nævnte i en video som Hurricane Electric lagde på facebook for nogle uger siden. Jeg har ikke hørt om andre har tilsluttet sig idéen, men der er andre Google ansatte som har nævnt at de gerne så en hel uges test, så jeg gætter på at Google gennemfører en hel uges test på et tidspunkt i 2012, men hvilken dato det bliver må stadig bero på gæt.
I samme video nævnte Vint Cerf også at han gerne så en skæringsdato i starten af 2013 hvor man definitivt skifter fra IPv4 til IPv6. Det ville være en pæn rund dato fordi det da ville være 30 år siden man skiftede til IPv4. Men han erkendte også at det nok var lidt for optimistisk.
kasperd (25) skrev:I samme video nævnte Vint Cerf også at han gerne så en skæringsdato i starten af 2013 hvor man definitivt skifter fra IPv4 til IPv6. Det ville være en pæn rund dato fordi det da ville være 30 år siden man skiftede til IPv4. Men han erkendte også at det nok var lidt for optimistisk.
Mon ikke det bliver på 35 eller 40 års dagen det endelige skift sker...?
Man kan jo prøve at ekstrapolere på forbruget af IPv4 adresser. Der er i alt 3.7 milliarder IPv4 adresser som kan routes på Internettet. IANA har uddelt de sidste af dem. Hvornår ville IANA være nået til 7.4 milliarder, hvis der havde været nok IPv4 adresser at dele ud af?drbravo (27) skrev:Mon ikke det bliver på 35 eller 40 års dagen det endelige skift sker...?
På det tidspunkt hvor IANA ville være nået til 7.4 milliarder IPv4 adresser er der kun adresser nok til at dække halvdelen af behovet, hvad sker der for den anden halvdel af enhederne?
I dag er der websites som holder tilbage med at implementere dual stack fordi en brøkdel af en procent af brugerne har fejlopsætninger som gør at de ikke kan tilgå en dual stack server.
Men der kan ikke gå mange uger fra RIPE og ARIN er løbet tør før antallet af enheder uden IPv4 adresse vil overstige den lille gruppe af brugere som ikke kan tilgå en dual stack server. På det tidspunkt vil der altså være et argument mindre for at have servere, som kun har IPv4.
Til de enheder der ikke kan få en IPv4 adresse har man fire muligheder.
- Native IPv6
- NAT64
- NAT44 (hvilket også kaldes for CGN hvis det er implementeret hos udbyderen og ikke brugeren)
- Proxies
De fire muligheder udelukker ikke hinanden, men det vil dog være et noget underligt valg at kombinere NAT64 og NAT44. Derudover er man nødt til at have Native IPv6 før NAT64 er en mulighed.
NAT64 og NAT44 lider af ca. de samme problemer. Dog er der nogle få nye problemer i NAT64 som man ikke har med NAT44. Så den eneste grund til at vælge NAT64 frem for NAT44 er at hvis man vælger NAT64 kan man køre det meste af sit netværk og slutbrugernes enheder på ren IPv6 helt uden IPv4 support.
Hvis man vælger at bruge NAT44 eller proxies har man nogle enheder som skal holde styr på mange connections, og for at aflaste de enheder vil det give mening at anvende native IPv6 til at få så meget trafik som muligt udenom disse flaskehalse.
Det er altså et realistisk gæt at en betydelig procentdel af de enheder der ikke har mulighed for at få deres egen IPv4 adresser vil få en IPv6 adresse. Og der er nok også en del af de enheder som har en IPv4 adresse, som også tildeles en IPv6 adresse.
Så når den ekstrapolerede graf krydser 7.4 milliarder er det realistisk at der vil være lige så mange enheder med en IPv4 adresse som dem med en IPv6 adresse. Jeg har ikke regnet på hvornår det vil ske, men da der har været en tilnærmelsesvis eksponentiel vækst behøver der ikke gå mange år.
Det er et tidspunkt hvor ethvert fornuftigt site vil køre dual stack. Det vil på det tidspunkt give lige så lidt mening at køre en server med kun IPv4 som det vil at køre den med kun IPv6.
Når alle websites af betydning har fået dual stack support vil der nok være internetudbydere der vælger at reducere det antal segmenter på deres netværk der kører IPv4 for at simplificere administrationen. Med andre ord man vil måske vælge at køre et netværk der kun har IPv6 og bruge NAT64 til adgang til de få resterende IPv4 servere, selvom man havde IPv4 adresser nok til at man ikke havde behøvet at gøre det.
Den dag udbydere begynder at lave sådan et træk vil kunne betragtes som et vendepunkt fordi det betyder at efterspørgslen efter IPv4 adresser da vil være faldende. Hvor lang tid der går fra efterspørgslen begynder at falde før den når under 3.7 milliarder igen er ikke til at sige. Det kunne gå hurtigt.
Hvilken af hændelserne i sådan et forløb ville man sige var tidspunktet hvor skiftet skete?
Efter det punkt hvor efterspørgslen på IPv4 adresser begynder at falde vil der stadig gå lang tid før de sidste holder op med at bruge det. En væsentlig hændelse man kan forvente i det forløb er en dag hvor IPv4 netværket begynder at fragmentere fordi nogle af backbone udbyderne dropper IPv4 support.
Jeg bemærkede lige i min log at der har været en bruger inde på testen med en lidt usædvanlig kombination af IP adresser. Vedkommende besøgte testen i går aftes klokken 23:23:54 og havde en IPv4 adresse fra Cybercity og en IPv6 adresse fra Telenor og et teredo relay fra Hurricane Electric.
Hvem bruger sådan en kombination af adresser?
Hvem bruger sådan en kombination af adresser?
Jeg har tilføjet en tabel der for hver type adresse på serversiden viser hvilken type adresse der vælges på klientsiden.
De valg af adresser som jeg anbefaler er:
1. Native IPv6 Native IPv6
2. IPv4 IPv4
3. 6to4 6to4
4. Teredo Native IPv6
Er tabellen nem nok at forstå, eller kan den sættes op så den er nemmere at forstå?
Er I enige i den rækkefølge jeg anbefaler adresserne, eller er der argumenter for at der bør vælges i en anden rækkefølge?
De valg af adresser som jeg anbefaler er:
1. Native IPv6 Native IPv6
2. IPv4 IPv4
3. 6to4 6to4
4. Teredo Native IPv6
Er tabellen nem nok at forstå, eller kan den sættes op så den er nemmere at forstå?
Er I enige i den rækkefølge jeg anbefaler adresserne, eller er der argumenter for at der bør vælges i en anden rækkefølge?
For de brugere der kun har IPv6 adgang gennem 6to4 eller Teredo kommer der nu et afsnit der informerer om tunneller og nævner HE og SixXS. Daniel-Dane og gumleren burde se denne besked (hvis de stadig kører med samme opsætning).
Jeg overvejer om jeg burde justere anbefalingerne af valg af adresser afhængigt af hvilke typer klient adresser der er til rådighed.
Jeg anbefaler native IPv6, IPv4, 6to4, Teredo. Men det er baseret på en antagelse om at man har native IPv6 fra klienten.
Daniel-Dane og gumleren anvender begge rækkefølgen 6to4, IPv4, Teredo, Native IPv6. Og det er nok et bedre valg, hvis man ikke har native IPv6 adgang. Dog ville jeg nok stadigvæk foretrække at tilgå serverens native IPv6 adresse fremfor dens Teredo adresse. Men det er en ubetydelig detalje da ingen burde køre en server på en Teredo adresse med mindre den kun er til test formål.
Så kunne jeg også tilpasse anbefalingerne omkring valg af klient adresser. Jeg anbefaler at man anvender native IPv6 adressen på klienten hvis man tilgår en server adresse der er native IPv6 eller Teredo. Men hvis ikke man har native IPv6 er man jo nødt til at bruge 6to4 eller Teredo adressen, så det kunne jeg tilpasse mine anbefalinger efter.
Jeg overvejer om jeg burde justere anbefalingerne af valg af adresser afhængigt af hvilke typer klient adresser der er til rådighed.
Jeg anbefaler native IPv6, IPv4, 6to4, Teredo. Men det er baseret på en antagelse om at man har native IPv6 fra klienten.
Daniel-Dane og gumleren anvender begge rækkefølgen 6to4, IPv4, Teredo, Native IPv6. Og det er nok et bedre valg, hvis man ikke har native IPv6 adgang. Dog ville jeg nok stadigvæk foretrække at tilgå serverens native IPv6 adresse fremfor dens Teredo adresse. Men det er en ubetydelig detalje da ingen burde køre en server på en Teredo adresse med mindre den kun er til test formål.
Så kunne jeg også tilpasse anbefalingerne omkring valg af klient adresser. Jeg anbefaler at man anvender native IPv6 adressen på klienten hvis man tilgår en server adresse der er native IPv6 eller Teredo. Men hvis ikke man har native IPv6 er man jo nødt til at bruge 6to4 eller Teredo adressen, så det kunne jeg tilpasse mine anbefalinger efter.
kasperd (34) skrev:Daniel-Dane og gumleren burde se denne besked (hvis de stadig kører med samme opsætning).
Lige præcis.
Also, nogle gange skal jeg F5'e et par gange for at hente alle tiles.
Jeg kan se i logfilen hvilke tiles det er. Dem du har flest problemer med er i12 og i44. De to tiles kan kun hentes over Teredo.kasperd (36) skrev:Er det de samme tiles der giver problemer hver gang?
De andre du har problemer med er i21 og i35. Dem har du dog ikke problemer med lige så tit. De to kan hentes over enten Teredo eller Native IPv6.
Din browser foretrækker at hente et billede over Teredo fremfor native IPv6. Det er nok derfor du har problemer med de to der kunne hentes fra en native IPv6 adresse. Nogle gange går den i stå i forsøget på at hente den over Teredo og får den aldrig afprøvet over native IPv6.
Det bekræfter så at jeg havde fat i noget rigtigt da jeg sagde
kasperd (34) skrev:Dog ville jeg nok stadigvæk foretrække at tilgå serverens native IPv6 adresse fremfor dens Teredo adresse.
Når din browser har valgt at tilgå serverens Teredo adresse skal dit operativsystem vælge om det vil bruge din 6to4 adresse eller din Teredo adresse til forespørgslen. Det vælger Teredo adressen således at der kommunikeres mellem to Teredo adresser. Det er ikke nødvendigvis et fornuftigt valg, men vi kan ikke se af den her test om det gør nogen forskel fordi din computer tilsyneladende aldrig prøver at bruge sin 6to4 adresse til at kommunikere med min Teredo adresse.
Kommunikation mellem to Teredo adresser kan kræve NAT hole punching, hvilket generelt er ustabilt. Men min server kører ikke bag NAT, så der burde ikke være brug for hole punching.
Til gengæld bruger min server ikke en rigtig Teredo klient men derimod en fake Teredo klient som jeg selv har bikset sammen. Der var flere grunde til at jeg valgte at gøre det på den måde. Den primære årsag var at jeg gerne ville kunne registrere hvilket teredo relay der blev brugt og vise det på siden.
Da jeg skrev min teredo kode havde jeg ikke forestillet mig at modparten jeg kommunikerede med også ville bruge Teredo. Jeg prøver at køre et pakkedump således at næste gang du oplever problemet kan jeg måske se i mit pakkedump, hvad der gik galt.
Jeg har denne tcpdump kommando kørende
tcpdump -ni eth1 '(host <teredo-server> || host <din-ip>) && port 3544' -s 0 -w daniel-dane.dumpIP adresserne på din teredo server og på din computer står selvfølgelig i den kommando jeg har kørende, men dem er der jo ingen grund til at nævne her.
Jeg går ud fra at du selv kender de to IP adresser. Måske skulle jeg udvide min rapport til også at nævne IP adressen på den Teredo server man bruger.
Under alle omstændigheder er det ikke noget stort problem at man ikke kan tilgå en server på en Teredo adresse. Ingen sites af betydning kører deres servere på en Teredo adresse. Jeg bør nok lave en feature i testen der kan fortælle hvis man kun har problemer med tiles over Teredo. Hvis man kan hente alle de andre tiles er man rimelig godt med.
kasperd (37) skrev:Jeg kan se i logfilen hvilke tiles det er. Dem du har flest problemer med er i12 og i44. De to tiles kan kun hentes over Teredo.
De andre du har problemer med er i21 og i35. Dem har du dog ikke problemer med lige så tit. De to kan hentes over enten Teredo eller Native IPv6.
Det lyder meget rigtigt. Nå, jeg skal nok spamme dig nu, så du kan få en masse logfiler at lege med.
Det starter sgu ikke godt.
Nå, den siger sgu 20/20 hele tiden. Jeg prøver igen senere.
Det ville have været lidt nemmere at forklare hvad der foregik, hvis jeg havde logget lidt flere oplysninger og hvis apache havde logget tidspunkter med millisekund præcision og ikke kun sekunder.Daniel-Dane (39) skrev:Det starter sgu ikke godt.
Men jeg tror jeg har forklaringen på hvorfor min rapport sagde 18 ud af 20 til dig.
Klokken 11:32:34 logger apache at de første 16 tiles bliver hentet. Samtidigt logger xinetd at der modtages en connection til rapport scriptet. Rapport scriptet går i gang med at parse apaches access_log. Det ser de 16 tiles og venter 50ms for at se om der kommer flere requests. Da der stadig ikke er kommet flere efter 50ms venter det lidt længere og lidt længere indtil der er gået ca. 3 sekunder.
Efter 3 sekunder stopper den process der venter på requests i access_log udfra en antagelse om at du ikke kommer tilbage efter resten af billederne. Dernæst startes rapport genereringen. De præcise tidspunkter herefter kunne jeg kun finde frem til fordi de resterende requests netop var dem som tcpdump dumpede og tcpdump har højere præcision
11:32:37.385 Teredo setup starter
11:32:37.434 Request for i35.jpg
11:32:37.448 Request for i44.jpg
11:32:37.490 Request for i21.jpg
11:32:37.496 Request for i12.jpg
Det vil sige at scriptet har opgivet at vente på flere requests på et tidspunkt før 11:32:37.434, men da processen der skal generere rapporten har læst igennem access_log er der kommet to requests mere. Det vil sige at rapporten må være blevet afsluttet mellem 11:32:37.448 og 11:32:37.490. Der var altså et 52ms interval hvor den process ville se præcist 18 ud af de 20 tiles.
Det er altså noget tilfældigt at den holdt op med at vente præcist samme sekund som de sidste 4 requests blev sendt. Timingen skulle kun have været ganske få ms anderledes for at den ville have sagt enten 16 eller 20.
Scriptet kunne selvfølgelig have ventet længere tid. I en tidligere version ventede det minimum 12 sekunder. Men det virkelige problem er at der går 3 sekunder før Teredo setup starter. Hvad foregår der i de 3 sekunder der går fra din browser har hentet de første 16 billeder og indtil den sender den første Teredo pakke til serveren?
Jeg kan ikke svare på hvad der foregår i de 3 sekunder. Et pakkedump kørt på din computer kunne måske kaste lidt lys over sagen. Tilsyneladende bliver Teredo serveren aldrig involveret, så det er altså ikke belastning på serveren, der er årsagen.
Set herfra ser det ud som om din computer venter 3 sekunder uden nogen god grund. Da Teredo setup var gennemført modtog jeg til gengæld 12 SYN pakker fra 7 forskellige TCP forbindelser i løbet af 7ms. Så mens Teredo klienten på din computer har taget sig god tid, har TCP laget stået og sat flere SYN pakker i kø, og browseren har allerede opgivet nogen af TCP forbindelsen og åbnet nye, hvilket satte endnu flere SYN pakker i kø.
Nu tilpasses anbefalingerne omkring adressevalg således at der bruges forskellige anbefalinger afhængig af hvilke typer adresser klienten har til rådighed. Der er fem forskellige profiler, og navnet på den detekterede profil fremgår af den sidste linie i testresultatet.
Tabellen over hvilke adresser klienten vælger viser nu om de følger anbefalingen. Alle celler der følger min anbefaling vises med grøn.
Det kan ikke udelukkes at jeg på et senere tidspunkt vil vælge at ændre anbefalingerne. F.eks. er det uklart om man skal vælge 6to4 eller Teredo, hvis det andet endepunkt bruger Teredo.
Desuden vises lidt flere Teredo oplysninger i rapportens første afsnit.
Den næste ændring bliver nok at jeg ændrer den advarsel man får, hvis man henter nogle IPv6 tiles men ikke dem alle. Hvis man kun har problemer med en server på en Teredo adresse, så er det ikke noget stort problem og skal ikke lyde så alvorligt som det gør nu.
Bortset fra det har jeg ikke selv flere idéer til hvad der bør ændres på testen. Jeg havde håbet at I havde nogle idéer.
Har I nogle idéer, eller synes I at testen har alle de features sådan en test bør have?
Tabellen over hvilke adresser klienten vælger viser nu om de følger anbefalingen. Alle celler der følger min anbefaling vises med grøn.
Det kan ikke udelukkes at jeg på et senere tidspunkt vil vælge at ændre anbefalingerne. F.eks. er det uklart om man skal vælge 6to4 eller Teredo, hvis det andet endepunkt bruger Teredo.
Desuden vises lidt flere Teredo oplysninger i rapportens første afsnit.
Den næste ændring bliver nok at jeg ændrer den advarsel man får, hvis man henter nogle IPv6 tiles men ikke dem alle. Hvis man kun har problemer med en server på en Teredo adresse, så er det ikke noget stort problem og skal ikke lyde så alvorligt som det gør nu.
Bortset fra det har jeg ikke selv flere idéer til hvad der bør ændres på testen. Jeg havde håbet at I havde nogle idéer.
Har I nogle idéer, eller synes I at testen har alle de features sådan en test bør have?
Hvis man ikke kan tilgå en webserver på en Teredo-adresse får man nu lidt flere oplysninger der gerne skulle hjælpe med at finde ud af hvor ens Teredo relay kører.
Den del er ikke helt færdig endnu. Hvem finder først den besked man får, når man kommer ind i den del af koden som ikke er helt færdig?
Den del er ikke helt færdig endnu. Hvem finder først den besked man får, når man kommer ind i den del af koden som ikke er helt færdig?
Til gengæld har jeg netop konstateret at vedkommende er en af de meget få brugere, der har både native IPv6 og optimal valg af adresser.kasperd (29) skrev:Jeg bemærkede lige i min log at der har været en bruger inde på testen med en lidt usædvanlig kombination af IP adresser. Vedkommende besøgte testen i går aftes klokken 23:23:54 og havde en IPv4 adresse fra Cybercity og en IPv6 adresse fra Telenor og et teredo relay fra Hurricane Electric.
Brugere med sådan en optimal IPv4+IPv6 opsætning får nu en ekstra besked i bunden af siden om at deres opsætning er optimal. (I hvert fald på de punkter som denne test kan undersøge).
Jeg bemærkede netop i min logfil en klient der var fejlkonfigureret på en måde som jeg ikke vidste var muligt.
Brugeren kører Chrome på Windows og tilgår nettet gennem en VPN udbyder med adresse i Stockholm. Test-id: 46d7eedb1a098801fc70582e8ff7e3252fd121881321001021
Denne bruger kunne hente de 8 tiles der er tilgængelige over IPv4 og ingen af de andre 12 tiles. Dette i sig selv er der intet usædvanligt i, og testkoden kom derfor til den fejlagtige konklusion at brugeren havde fuldt fungerende IPv4 adgang og ingen IPv6 adgang, og gav derfor ikke nogen advarsler.
Men de to tiles der var tilgængelig over både IPv4 og 6to4 blev hentet over 6to4. Det vil sige at brugeren har 6to4 adgang men var ude af stand til at tilgå en server der kun var tilgængelig over 6to4.
Jeg er meget nysgerrig efter hvordan man har båret sig ad med at fejlkonfigurere netværket på den måde. Jeg gætter på at brugen af VPN har noget at sige, men jeg har ikke fantasi til at gætte hvordan den fejl er opstået.
Brugeren kører Chrome på Windows og tilgår nettet gennem en VPN udbyder med adresse i Stockholm. Test-id: 46d7eedb1a098801fc70582e8ff7e3252fd121881321001021
Denne bruger kunne hente de 8 tiles der er tilgængelige over IPv4 og ingen af de andre 12 tiles. Dette i sig selv er der intet usædvanligt i, og testkoden kom derfor til den fejlagtige konklusion at brugeren havde fuldt fungerende IPv4 adgang og ingen IPv6 adgang, og gav derfor ikke nogen advarsler.
Men de to tiles der var tilgængelig over både IPv4 og 6to4 blev hentet over 6to4. Det vil sige at brugeren har 6to4 adgang men var ude af stand til at tilgå en server der kun var tilgængelig over 6to4.
Jeg er meget nysgerrig efter hvordan man har båret sig ad med at fejlkonfigurere netværket på den måde. Jeg gætter på at brugen af VPN har noget at sige, men jeg har ikke fantasi til at gætte hvordan den fejl er opstået.
Det ville have været en interessant metode til at identificere personer, som forsøger at skjule deres identitet bag VPN.didriksen86 (46) skrev:VPN kører kun IPv4 og 6to4 kører igennem hans default gateway?
Men sådan fungerede det ikke. Både IPv4 og 6to4 adgangen skete gennem samme IPv4 adresse hos pågældende udbyder.
Det ser ud til at VPN udbyderen tildeler en offentlig IPv4 adresse til brugeren, og det er Windows indbyggede 6to4 kode der anvendes. VPN udbyderen forwarder sandsynligvis trafikken uden at vide at det er 6to4.
At jeg tror det er Windows indbyggede skyldes måden adressen ser ud på. Der var tale om en 6to4 adresse på følgende form: 2002:c000:240::c000:240 med samme IPv4 adresse indkodet i adressen to gange.
Testresultater indtil videre:
1565 Tests i alt.
733 Fuldt funktionel IPv4
558 Fuldt funktionel IPv4+IPv6
274 Har tilsyneladende et problem
Ovenstående er opgjort udelukkende ved at se på hvilken delmængde af tiles der blev hentet for hvert test ID. Der er altså 1565 ID i min log.
Uheldigvis er det sådan at en betydelig procentdel udgøres af mine egne tests og af søgemaskiner som crawler testen. Disse giver nemt anledning til fejlagtige resultater, og derfor bør jeg finde en måde at få dem filtreret fra for at lave en mere brugbar statistik.
1565 Tests i alt.
733 Fuldt funktionel IPv4
558 Fuldt funktionel IPv4+IPv6
274 Har tilsyneladende et problem
Ovenstående er opgjort udelukkende ved at se på hvilken delmængde af tiles der blev hentet for hvert test ID. Der er altså 1565 ID i min log.
Uheldigvis er det sådan at en betydelig procentdel udgøres af mine egne tests og af søgemaskiner som crawler testen. Disse giver nemt anledning til fejlagtige resultater, og derfor bør jeg finde en måde at få dem filtreret fra for at lave en mere brugbar statistik.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund