mboost-dp1

Flickr - saschaaa
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Hvilket resultat man når frem til afhænger jo af hvor man måler det henne. Og selv hvis man kunne måle samtlige pakker, der blev sendt, så er det uklart hvad man egentlig ønsker at få med. Hovedparten af IPv4 trafikken sendes sandsynligvis over private netværk. Og denne trafik er i sagens natur den sværeste at lave en global måling på.
Skal trafik over private netværk tælles med? Er det afgørende om der anvendes RFC 1918 adresser eller ej? Hvad med IPv6 hvor en større procentdel af trafikken bruger globalt routebare adresser, fordi der ikke er nogen grund til at lade være, når man har adresser nok. Hvis man ikke kan definere en måde at tælle pakker på, som giver mening for både IPv4 og IPv6 kan man vel ikke sammenligne de to.
Hvad med tunneler? Skal en tunnel tælles efter den yderste header eller den inderste header? Hvis man tæller efter den yderste header, hvor mange gange skal en pakke så tælles? Den tid pakken eksisterer før tunnelen og efter tunnelen skal vel også tælles med.
Hvorfor tælles der kun native IPv6? Og hvad forstår de egentlig ved native IPv6? Hvis en pakke sendes over en tunnel et lille stykke ad vejen (f.eks. med 6rd), skal den så ikke tælles med som IPv6?
En stor mængde trafik der sendes som IPv6 i en tunnel over IPv4 indgår i den overgang som mange har forventet fra IPv4 til IPv6. Efterhånden som mange bruger IPv4 over IPv6 kan man så flytte mere og mere til native IPv6.
I praksis går det dog ikke så godt. Den måske mest udbredte tunnel type 6to4 lider af det problem, at kommunikation imellem en 6to4 host og en anden IPv6 host skal sendes igennem tredjeparts relays i begge retninger. Som regel to forskellige tredjeparts relays i hver retning.
Da man ingen garanti har for kvaliteten af disse tredjeparts relays, og man kun har meget lidt kontrol over hvilke relays der bruges, og nogle gange ikke engang ved hvilke relays der bruges, er resultatet ofte en upålidelig forbindelse. Pakker der sendes fra ens egen computer har man en lille smule kontrol over. Pakker der går den anden vej har man stort set ingen måde at debuge, hvis de går tabt på vej forbi tredjeparts relay.
Resultatet er, at kommunikation imellem to 6to4 maskiner er stabilt, og kommunikation imellem to native IPv6 maskiner er også stabilt, men kommunikation imellem en 6to4 maskine og en native IPv6 er mindre stabilt.
Pga. af dette problem har der i det seneste par år været fokus på at undgå at sende trafik over 6to4, hvis det kan sendes over gammeldags IPv4. Er trafik imellem en 6to4 maskine og en native IPv6 maskine talt med i denne opgørelse? Hvis den er, så kan et fald i denne type trafik forklare det samlede fald.
Skal trafik over private netværk tælles med? Er det afgørende om der anvendes RFC 1918 adresser eller ej? Hvad med IPv6 hvor en større procentdel af trafikken bruger globalt routebare adresser, fordi der ikke er nogen grund til at lade være, når man har adresser nok. Hvis man ikke kan definere en måde at tælle pakker på, som giver mening for både IPv4 og IPv6 kan man vel ikke sammenligne de to.
Hvad med tunneler? Skal en tunnel tælles efter den yderste header eller den inderste header? Hvis man tæller efter den yderste header, hvor mange gange skal en pakke så tælles? Den tid pakken eksisterer før tunnelen og efter tunnelen skal vel også tælles med.
Hvorfor tælles der kun native IPv6? Og hvad forstår de egentlig ved native IPv6? Hvis en pakke sendes over en tunnel et lille stykke ad vejen (f.eks. med 6rd), skal den så ikke tælles med som IPv6?
En stor mængde trafik der sendes som IPv6 i en tunnel over IPv4 indgår i den overgang som mange har forventet fra IPv4 til IPv6. Efterhånden som mange bruger IPv4 over IPv6 kan man så flytte mere og mere til native IPv6.
I praksis går det dog ikke så godt. Den måske mest udbredte tunnel type 6to4 lider af det problem, at kommunikation imellem en 6to4 host og en anden IPv6 host skal sendes igennem tredjeparts relays i begge retninger. Som regel to forskellige tredjeparts relays i hver retning.
Da man ingen garanti har for kvaliteten af disse tredjeparts relays, og man kun har meget lidt kontrol over hvilke relays der bruges, og nogle gange ikke engang ved hvilke relays der bruges, er resultatet ofte en upålidelig forbindelse. Pakker der sendes fra ens egen computer har man en lille smule kontrol over. Pakker der går den anden vej har man stort set ingen måde at debuge, hvis de går tabt på vej forbi tredjeparts relay.
Resultatet er, at kommunikation imellem to 6to4 maskiner er stabilt, og kommunikation imellem to native IPv6 maskiner er også stabilt, men kommunikation imellem en 6to4 maskine og en native IPv6 er mindre stabilt.
Pga. af dette problem har der i det seneste par år været fokus på at undgå at sende trafik over 6to4, hvis det kan sendes over gammeldags IPv4. Er trafik imellem en 6to4 maskine og en native IPv6 maskine talt med i denne opgørelse? Hvis den er, så kan et fald i denne type trafik forklare det samlede fald.
Findes der ikke en uskreven regel om, at hvis man gerne vil have folk læser ens indlæg, så holder man det korterer end nyheden? Kan det mon forklarer hvorfor meget få læser og svarer på ovenstående indlæg? Hvis man nu vil tælle alle kommentarer i denne tråd, ville man da tælle ovenstående flere gange? Ville man tælle hvert afsnit for en kommentar eller måske hvert andet? Ville det give mening kun at læse nogle af afsnittene? I så fald ville flere måske læse det...
#2
Så med andre ord er IPv6 udbredelse fucked, så længe at 6to4 ikke virker fra 6to4 -> v6
Er det pga. informationstab at denne kommunikation ikke virker ?
Vi må vel nok bare vente på at den parallelle V6 verden vokser og vokser sideløbende med V4... sådan at man uden at vide det, surfer på begge net samtidig... så kan man en dag slukke for V4 stille og roligt...
Men som det er i dag - er vi fucked fordi alle ISP'erne ikke kan finde ud af at sende V6 udstyr ud til kunderne, endsige fortælle kunderne om V6 !!
Men ehm... fuck v6 - alle os i vesten + en helvedes masse andre, nåede at få en V4 - så det er vel ikke os som har et problem :D
Så med andre ord er IPv6 udbredelse fucked, så længe at 6to4 ikke virker fra 6to4 -> v6
Er det pga. informationstab at denne kommunikation ikke virker ?
Vi må vel nok bare vente på at den parallelle V6 verden vokser og vokser sideløbende med V4... sådan at man uden at vide det, surfer på begge net samtidig... så kan man en dag slukke for V4 stille og roligt...
Men som det er i dag - er vi fucked fordi alle ISP'erne ikke kan finde ud af at sende V6 udstyr ud til kunderne, endsige fortælle kunderne om V6 !!
Men ehm... fuck v6 - alle os i vesten + en helvedes masse andre, nåede at få en V4 - så det er vel ikke os som har et problem :D
Det virker skam. Men selv med de bedste protokoller vi har kan en inkompetent systemadministrator ødelægge det. Om det er den ene eller anden vej der fejler afhænger af hvilken router der har en inkompetent administrator. Nogen gange fejler den ene, nogen gange fejler den anden. Men som bruger kan man være ret ligeglad med om det er den ene eller den anden der fejler, for de skal jo begge virke på samme tid, for at man kan få kommunikationen til at virke.Montago (4) skrev:Så med andre ord er IPv6 udbredelse fucked, så længe at 6to4 ikke virker fra 6to4 -> v6
Det er primært pga. fejlkonfigurerede routere som modtager pakkerne uden at kunne sende dem videre. Nogle gange ser man stort pakketab. Nogle gange ser man 100% pakketab. Nogle gange bliver pakkerne bare meget forsinket.Montago (4) skrev:Er det pga. informationstab at denne kommunikation ikke virker ?
I begge retninger skal pakkerne igennem et relay, og de sendes automatisk til det relay, der er tætest på afsenderen. Hvis ikke der er et relay hos den udbyder, pakkerne sendes fra, kan de sendes til en anden udbyder for at blive relayet derfra. Pga denne omvej kan pakkerne gå gennem et netværk som ikke har noget ansvar overfor hverken det ene eller det andet endepunkt i kommunikationen.
Når trafik routes normalt (altså uden tredjeparts relays som med 6to4), så vil alle routere på forbindelsen imellem to endepunkter være hos udbydere, som har enten det ene eller det andet endepunkt som kunde direkte eller indirekte.
Det er også sådan det er meningen at det skal foregå. Og den dato hvor man lige så stille og roligt slukker for IPv4 er sidste år før paniken omkring mangle på adresser gik igang.Montago (4) skrev:Vi må vel nok bare vente på at den parallelle V6 verden vokser og vokser sideløbende med V4... sådan at man uden at vide det, surfer på begge net samtidig... så kan man en dag slukke for V4 stille og roligt...
Det kan blive meget værre. Den dag udbyderne begynder at lave CGN uden at give native IPv6 adgang kan opkoblingen ikke med nogen rimelighed kaldes for en internetopkobling længere.Montago (4) skrev:Men som det er i dag - er vi fucked fordi alle ISP'erne ikke kan finde ud af at sende V6 udstyr ud til kunderne, endsige fortælle kunderne om V6 !!
For at undgå afhængighed af overgangsløsninger som f.eks. 6to4 skal alle internetudbydere installere native IPv6 før midten af 2011.
Sugardad2 (7) skrev:hvad er problemet, når der ikke er flere ipv4, så er de lige som NØDT til at gå over til ipv6, probrem solved
ehh... NEJ....
som du sikkert har lagt mærke til - virker internettet...
det er kun afrikanere og folk i 3. verden som ikke har gaflet en masse IP-ranges som er fucked... alle os 2-3 milliarder mennesker i vesten + kina/indien som har en IP4 kan være ligeglade.
Det er så omtrent så forkert som det kan være. Asien og Stillehavsregionen er nået til det punkt, hvor adresser rationeres. Hvis en internetudbyder i den del af verden indsender et ønske om at få tildelt flere IPv4 adresser for at dække vækst i deres netværk, så vil de få et nej.Montago (8) skrev:det er kun afrikanere og folk i 3. verden som ikke har gaflet en masse IP-ranges som er fucked... alle os 2-3 milliarder mennesker i vesten + kina/indien som har en IP4 kan være ligeglade.
Om et par måneder vil det samme gøre sig gældende i Europa, og der går næppe et år før det samme gør sig gældende i Nordamerika.
Afrika har derimod adresser nok til at dække væksten de næste fire år. Men efterhånden som resten af verden vil være tvunget til at bruge IPv6 vil Afrika selvfølgelig være nødt til at følge med hvis de stadig vil kunne kommunikere med resten af verdenen. Men mangel på IPv4 adresser til nye enheder i Afrika vil ikke være et problem.
Dem der vil have det største problem er brugere i Asien og Europa, som ikke kan få en IPv4 adresse, og må nøjes med IPv6 og en mere eller mindre stabil NAT løsning for at kommunikere med IPv4 netværket. Det vil også være et problem for de brugere måske allerede har IPv4, men hvor udbyderen vælger at fratage brugerne deres adresse og lave en CGN løsning i stedet.
Hvis ens internetudbyder vælger at lave en CGN løsning uden samtidigt at levere en fornuftig IPv6 løsning, så bør man skifte udbyder. Og de skal selvfølgelig advare om indførelse af en CGN løsning lang tid i forvejen, da det ellers vil være kontraktbrud fra udbyderens side.
Når andelen af brugere med dårlig forbindelse til IPv4 netværket når op på 1% vil det argument større serviceudbydere har haft for ikke at understøtte IPv6 for alle brugere forsvinde. På det tidspunkt vil mængden af indhold tilgængelig over IPv6 hurtigt vokse. Yahoo har allerede annonceret, at de vil gøre deres indhold permanent tilgængeligt over IPv6 inden udgangen af året.
Der er ingen der ønsker en situation, hvor man skal bruge forskelligt hostnavn til IPv4 og IPv6. Det bruges nogle steder, men det er kun for at eksperimentere med IPv6 indtil man synes man er klar til at gøre det tilgængeligt for alle.greylion (10) skrev:Måske er det et nyt banner der skal til;
"dette website kan bruges via IPv6" / "This website is available via IPv6", og så et link, som specifikt resolver til en IPv6-adresse.
Hvis man har et website, er det ønskeligt at alle brugere kan tilgå det med samme URL, uanset hvilken protokol, der ligger under http. Prøv at forestille dig hvis det var et andet lag i stakken, hvor man skelnede på den måde. Hvis nu brugere med ADSL skulle bruge en URL, og brugere med DOCSIS skulle bruge en anden URL.
Hver gang du så en reklame for et website, ville der stå 2-4 forskellige URLer, og så var det op til brugerne selv, at gennemskue hvilken af disse URLer, der var gældende for deres internetopkobling. Og 10% af brugerne ville ikke kunne komme ind på sitet, fordi reklamen havde glemt at nævne URLen for deres type opkobling.
Den situation vi ønsker os er, at brugeren blot indtaster URLen på præcist samme måde hver gang, og browseren automatisk forbinder til serveren på den rigtige måde.
Sådan er det allerede i dag mere end 99% af tiden. Og det der skal fokuseres på er at få det til at virke 99,999% af tiden.
Hvis et website er klar til at lancere IPv6 adgang, men der er problem med brugere, der ikke kan tilgå sitet fordi deres computer tror den har IPv6, men kun har IPv4, så er den bedste vej frem nok at identificere de berørte brugere, og advare dem. Fremfor at fortælle alle brugere om IPv6, når over 99% af brugerne ikke har brug for at vide det.
Et website kan teste hvilke brugere der er berørt ved at inkludere et billede eller javascript fra et subdomæne, som er tilgængeligt over både IPv4 og IPv6. Det vi har brug for er en nem måde at lave den test på, så flere server administratorer kan sætte det op, og brugere med en fejlbehæftet forbindelse får en advarsel på halvdelen af de sites, de besøger.
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.