Dansk deltagelse i World IPv6 Launch

Flere store internetvirksomheder har annonceret at 6. juni 2012 tændes der permanent for IPv6:

http://www.internetsociety.org/news/world-ipv6-lau...
http://www.worldipv6launch.org/

På listen over deltagende virksomheder finder man tre amerikanske internetudbydere og fire internetudbydere fra hhv. Frankrig, Australien, Japan og Holland.

Kan vi mon håbe på at få en dansk internetudbyder til at hoppe med på vognen? Er der noget vi som enkeltpersoner kan gøre for at overbevise dem om at de ikke skal lade Danmark sakke agterud?

Nu stopper du sgu'
At du gerne vil tjene flere penge er helt okay.

Men hold op med at maskere det som om vi er ved at blive en IT-ørksen herhjemme.

Igen, du kan råbe op alt du du vil..men at et par udbydere kan kan tilbyde IPv6 til et begrænset kundesegment er mere PR end produktion.

Terra - Væk mig igen sidste på året ;)

Ud over at der skal skiftes udstyr hos ISP-kunderne, hvad afholder så egentlig vores hjemlige ISP'er fra at begynde at tilbyde IPv6? Man må vel gå ud fra at deres dyre udstyr på centralerne har kunnet understøtte IPv6 i årevis eller hvad?

@#3 - godt spørgsmål. Vel primært at der helst skal være efterspørgsel før der overhovedet bruges penge på det (altså ud over alm. fremtidsikring på centralerne).

Jeg håber at dette kan være med til at løse hønen og ægget problematikken, således at det bliver mere alment at man som "internetvirksomhed" også altid tilbyder sine services over IPv6.

mathiass (3) skrev:

Ud over at der skal skiftes udstyr hos ISP-kunderne, hvad afholder så egentlig vores hjemlige ISP'er fra at begynde at tilbyde IPv6? Man må vel gå ud fra at deres dyre udstyr på centralerne har kunnet understøtte IPv6 i årevis eller hvad?

Udstyr på centraler har ikke kunne understøtte IPv6 i årevis (DSLAM's), mange typer udstyr understøtter kun IPv6...delvist.

Og der er stadig mange tekniske issues (specielt med firewalls).

Der er mange der skal ud og købe mere(dyrt!!!) udstyr, skal vi f.eks. terminere IPv6 kunder på en MX'er, så hedder det ca. max 8K kunder per MX.
Og en MX koster +$50K...uden interfacekort...

Og så er efterspørgelsen ikke noget jeg har lagt mærke til...ud over et par (og jeg mener vitterligt et par!!!) enkelte nørder er der pt. ingen interesse for IPv6 hos private eller erhvervskunder ved os.

Da vi heller ikke mangler IPv4 adresser, efterspørgelsen ikke er der så haster det ikke for os...men som sagt....væk mig igen sidste på året.

mathiass (3) skrev:

Ud over at der skal skiftes udstyr hos ISP-kunderne, hvad afholder så egentlig vores hjemlige ISP'er fra at begynde at tilbyde IPv6?

Hvilket udstyr der skal udskiftes kan til tider være lidt svært at vurdere. Det første spørgsmål er hvilket udstyr der overhovedet skal understøtte IP.

En router skal selvfølgelig understøtte den IP version man ønsker at bruge den til. Men udstyr der arbejder på lavere niveauer er ligeglad med hvad for en protokol man bruger. Man behøver ikke udskifte de kabler man har liggende i jorden for at kunne køre IPv6. Switches og modems er heller ikke noget problem, de kører også på et lavere lag og er derfor ligeglade med hvilken IP version man kører ovenpå.

Men, der er en del udstyr der arbejder på flere lag i stakken. Med noget udstyr afhænger opførslen af hvordan det konfigureres. Og det er ikke usædvanligt for udstyr at se på headers og data på højere niveauer end den klasse af udstyr burde kigge på.

Derfor kan man f.eks. se kabelmodems der delvist opfører sig som en switch og delvist opfører sig som en router. Og der er f.eks. også kabelmodems som i en konfiguration blot switcher pakkerne men i en anden konfiguration laver NAT.

Så for den slags udstyr er man enten nødt til at have IPv6 support i udstyret eller sætte det op på en måde hvor det er ligeglad med IP versionen og kan håndtere begge protokoller uden at vide hvad det er.

Her kan man potentielt løbe ind i et dilemma med noget udstyr. Det kan f.eks. være at man for at køre IPv4 er nødt til at slå NAT til i udstyret pga. mangel på adresser, men at udstyret ikke kan håndtere IPv6 og derfor er nødt til at være sat op som en switch for at man kan få IPv6 pakker gennem det.

Derfor er det ikke utænkeligt at der er tilfælde hvor man står med udstyr hvor det uden problemer kan understøtte enten IPv4 eller IPv6 men ikke begge dele på en gang.

Da den type udstyr ofte konfigureres af udbyderne er det ikke nemt som kunde at finde ud af hvordan det kan konfigureres og om det overhovedet understøtter IPv6.

Det er heller ikke usædvanligt at integrere switch, WIFI access point, router og modem i en enkelt enhed. Det er kun routeren der absolut skal understøtte IPv6, men da det er en enkelt enhed kan man være nødt til at udskifte det hele.

Udstyr af nyere dato bør selvfølgelig have IPv6 support, men der er nogle klasser af udstyr hvor supporten er kommet for sent til at man har kunnet nå at få IPv6 support ud som en del af den almindelige opgraderingscyklus.

Og selvom IPv6 er lidt simplere og dermed kan gøres mere effektivt har der været udstyr hvor IPv4 support er lavet i software og IPv6 support er lavet i hardware. I nogle tilfælde har det betydet at udstyr der på papiret har haft IPv6 support i praksis kun har kunnet bruges med IPv4.

Nogle af problemerne opdager man kun hvis man faktisk prøver at slå IPv6 til. Derfor har fremsynede udbydere forsøgt at få IPv6 ud til alle de kunder der har efterspurgt det for at finde problemerne tidligt nok til at kunne få dem udbedret før IPv6 bliver til den eneste mulighed.

Indenfor kabelmodems har version 3 af DOCSIS standarden fra 2006 krævet IPv6 support. Der er vist mange udbydere der er ved at opgradere til DOCSIS 3 fordi den giver bedre performance end tidligere versioner. Så på de netværk burde IPv6 supporten være til stede.

Det er også ca. den måde man burde får IPv6 supporten ud på, men det er sket for sent til at man nødvendigvis kan nå at opdage fejlene. Hvis alle DOCSIS 3 enheder har IPv6 support der faktisk er brugbar burde IPv6 over kabelnettet ikke blive noget problem. Men hvem tror på at alle enheder i den første generation med krav om IPv6 support har en fejlfri IPv6 support?

Jeg ved ikke hvordan det ser ud indenfor andre teknologier som f.eks. ADSL og fiber.

mathiass (3) skrev:

Man må vel gå ud fra at deres dyre udstyr på centralerne har kunnet understøtte IPv6 i årevis eller hvad?

Ud fra hvad jeg har hørt er IPv6 support til stede på backbone routerne. Men du får nok et mere præcist svar hvis du får det fra en internetudbyder. Jeg har ikke kendskab til alle de typer hardware de bruger.

ykok (4) skrev:

Vel primært at der helst skal være efterspørgsel før der overhovedet bruges penge på det

Den "plan" der har været for udrulning af IPv6 har antaget at i hvert fald halvdelen af internetudbyderne ville være fremsynede nok til at vælge udstyr med IPv6 support og begynde at gøre IPv6 tilgængeligt tidligt nok til at IPv6 kunne være i almindelig brug længe før IPv4 adresserne slap op.

Sådan er det ikke gået i praksis. Flertallet af udbyderne har truffet beslutningerne ud fra kortsigtede betragtninger om efterspørgsel fremfor en langsigtet betragtning om hvad der skal til for at fortsat kunne sælge internetopkoblinger når IPv4 adresserne slap op.

Kunder som både tænker langsigtet nok og som har forstået behovet er et mindretal. Derfor har kunderne ikke efterspurgt IPv6. Det er ikke fordi de ikke har brug for det, det er fordi de ikke opdager behovet før de står midt i behovet.

Så længe hovedparten af aktiviteten foregår over IPv4 er de virksomheder som får problemer primært dem der ikke har nået at få IPv4 adresser mens der stadig var nogen. Virksomheder som har sikret sig et stort antal IPv4 adresser men intet gjort for at udrulle IPv6 bliver ikke berørt så meget.

De kortsigtede beslutninger går altså i højere grad ud over andre end dem der træffer beslutningerne. Når de beslutninger man træffer i højere grad påvirker andre er der behov for regulering. Men jeg har ikke kendskab til et eneste land der har reguleret området.

Ikke engang information for at sikre at kunderne ved hvad de får har der været ret meget af. Jeg tror der er flere danskere der ved at der er en forskel på MPEG2 og MPEG4 end dem der kender til IPv4 og IPv6.

kasperd (6) skrev:

Sådan er det ikke gået i praksis. Flertallet af udbyderne har truffet beslutningerne ud fra kortsigtede betragtninger om efterspørgsel fremfor en langsigtet betragtning om hvad der skal til for at fortsat kunne sælge internetopkoblinger når IPv4 adresserne slap op.

Det giver ikke mening at opgradere år i forvejen...så spilder du en masee penge på udstyr med funktioenr du ikke bruger.
Og som kunne bruges bedre når behovet reelt set er der.

Jeg kan godt se hvor du kommer fra (du vil tjene penge på IPv6)...men du kan råbe op lgie så tosset du vil...og det eneste du vil få ud af det er IPv 6 PR-stunts...og ikke IPv6 produktion.

Ingen udbyder vil lancere et produkt der ikke er rentabelt....ikke ne der vil overleve ihvertfald.

#7: At understøtte IPv6 kan vel ikke være noget der fordyrer udstyret væsentligt? Jeg mener, det er vel stort set bare et andet header-format på de data-pakker man sender rundt. Det må vel være dét at udstyret skal skiftes som er det omkostningstunge i det her.

Der er vel en erkendelse af at man på et eller andet tidspunkt bliver nødt til at skifte. Når man løber tør for adresser, så har man jo et reelt problem.

mathiass (8) skrev:

#7: At understøtte IPv6 kan vel ikke være noget der fordyrer udstyret væsentligt? Jeg mener, det er vel stort set bare et andet header-format på de data-pakker man sender rundt. Det må vel være dét at udstyret skal skiftes som er det omkostningstunge i det her.

Der er vel en erkendelse af at man på et eller andet tidspunkt bliver nødt til at skifte. Når man løber tør for adresser, så har man jo et reelt problem.

Det kan det når IPv6 skal termineres på en MX'er i stedet for IPv4 der terminere på en DSLAM.
Du er så nødt il at købe ekstra udstyr for at få alle kunder termineret...og vi snakker ikke Belkin routere her...

(kan se pewbe heller ikke ved en hat om core network)

mathiass (8) skrev:

At understøtte IPv6 kan vel ikke være noget der fordyrer udstyret væsentligt? Jeg

Næppe. Den største del af udgiften er en engangsudgift i forbindelse med designet. Produktionsomkostningerne per enhed kan ikke stige ret meget.

mathiass (8) skrev:

Jeg mener, det er vel stort set bare et andet header-format på de data-pakker man sender rundt.

Det er dog noget som i mange tilfælde skal håndtere i hardware. Man er altså nødt til at lave to separate kredsløb til hhv. håndtering af IPv4 og IPv6 plus logik der kan se hvilket af de to der skal evaluere hver enkelt pakke.

Men IPv6 er simplere så kredsløbet til at håndtere IPv6 må formodes at være mindre end det tilsvarende kredsløb til IPv4. Og selv hvis IPv6 kredsløbet var lige så stort som IPv4 kredsløbet, så ville det samlede kredsløb ikke blive dobbelt så stort, da der også er logik til at håndtere de lavere protokollag.

Så spørgsmålet er om det samlede kredsløb kan være på samme størrelse ASCI eller om man bliver nødt til at gå et skridt op i størrelse.

På længere sigt er jeg ikke i tvivl om at udstyr der kun kan håndtere IPv6 bliver billigere end udstyr der kun kan håndtere IPv4.

Men det interessante spørgsmål er hvornår man begynder at se udstyr hvor man vælger at lave IPv6 i hardware og IPv4 i software.

mathiass (8) skrev:

Det må vel være dét at udstyret skal skiftes som er det omkostningstunge i det her.

Ja.

Dog er der en anden omkostning som nok er større end dem du har nævnt.

Hvis man vil have nogen indflydelse på hvad producenterne laver, så er man også nødt til at vælge producent efter features selvom der kan være en prisforskel. Hvis man begrænser sig selv til at vælge blandt de producenter der har IPv6 support, så har man et mindre udvalg og dermed sandsynligvis en højere pris.

Ekstra udgiften til at få IPv6 support når udstyr alligevel skal udskiftes er betydeligt mindre end den udgift man får hvis man bliver nødt til at udskifte udstyr før tid udelukkende fordi det gamle ikke har IPv6 support.

Jeg tror der er virksomheder som vil opleve at de kortsigtede besparelser de valgte tidligere vil vise sig at føre til betydeligt større udgifter på langt sigt.

At man ikke har IPv6 support i sit core netværk forhindrer dog ikke at man kan gå igang med at tilbyde IPv6 til kunderne.

Man kan anvende IPv4 som et link layer niveau under IPv6. I store træk er det det samme som en tunnel, men det kan gøres betydeligt mere pålideligt hvis det holdes indenfor en udbyder. Teknologien til det kaldes 6rd. Så vidt jeg ved var der en enkelt fransk internetudbyder ved navn Free, der brugte det til at få IPv6 ud til en ganske betydelig procentdel af den franske befolkning.

Der er sikkert ingen internet udbydere i Danmark der deltager, selvom man skulle kunne få IPv6 som erhverv ved TDC er det hvis noget svært at få dem overbevist om de kan levere det...har jeg hørt.

Men jeg har fået alle vores servere, inkl. webserver på IPv6, så rigtige mange af vores kunders hjemmesider er tilgængelig på IPv6 i dag. Man er vel nørd ;-)

Det rigtigt for den almene danske forbruger der ikke i dag grund til at have en IPv6 adresse, og nok heller ikke de næste 5-10-15 år... Men hvis man udbyder nogle services fra Danmark der kunne være interessant for udlandet går der nok ikke længe før man er nød til at være tilgængelig over IPv6.

kasperd (1) skrev:

Kan vi mon håbe på at få en dansk internetudbyder til at hoppe med på vognen? Er der noget vi som enkeltpersoner kan gøre for at overbevise dem om at de ikke skal lade Danmark sakke agterud?

Lige nu er der meget fokus på at kunne levere sine services i gemmen IPv6. Men det er enlig det forkerte sted at bruge sine resurser. Hvis en service allerede fungere fint i gennem IPv4 NAT. Ja så vil den sikker også fungere de næste 10 år.

Det som derimod er vigtigt, er at få IPv6 ud til klienterne, som lige nu lider under at P2P i mellem to klienter bag NAT er umuligt eller meget besværligt.

For eksemplet blev IP-telefoni baseret på standarter aldrig rigtigt til noget. I stedet vandt Skype, som gør alle mulige triks for få trafikken igennem.

Men IPv6 har desværre lade sig venter på sig i lang tid fordi:
1 IPS'erne gør ikke noget før kunderne efterspørger IPv6.
2 Kunderne efterspørger ikke IPv6, før der er programmer der drager fordel af IPv6.
3 Programmene vil ikke drager fordel af IPv6, før det er udbredt.

CableCat (12) skrev:

Hvis en service allerede fungere fint i gennem IPv4 NAT. Ja så vil den sikker også fungere de næste 10 år.

Ikke nødvendigvis. Der er flere grunde til at det muligvis ikke vil blive ved med at fungere.

For det første er der applikationer der ikke som udgangspunkt kan fungere gennem NAT, men som med forskellige tricks kan bringes til at virke alligevel. I nogle tilfælde vil udviklere bruge mange kræfter på at udvikle workarounds til at komme omkring problemerne med NAT. Havde de ikke behøvet at bekymre sig om NAT kunne de i stedet have brugt kræfterne på at udvikle nye features.

Vi er allerede tæt på grænsen for hvor mange enheder vi kan presse ind med NAT systemer som vi kender dem. Hvis der skal presses flere enheder ind på nettet vil der være behov for en ny type NAT som eksisterende workarounds ikke nødvendigvis fungerer med.

Der findes protokoller som applikationer kan bruge til at kommunikere med en NAT enhed som er et enkelt hop væk fra dem selv til at oprette indgående forbindelser. Disse protokoller vil ikke virke hvis NAT enheden rykkes fra brugeren til internetudbyderen.

Der er ingen garanti for at udbydere der vælger at placere mange kunder bagved en NAT enhed vil give kunderne ekstra IP adresser af den grund. Kunderne kan være nødt til at stadigvæk have en NAT enhed derhjemme.

To niveauer af NAT er der mig bekendt overhovedet ikke tænkt på i de protokoller som bruges til at kommunikere mellem applikation og NAT enhed. Derudover giver to niveauer af NAT højere risiko for adressekonflikter. RFC 4193 har en løsning på adressekonflikterne, men kun for IPv6.

En anden metode til at opnå kommunikation mellem to enheder der begge er bagved NAT er ved at starte kommunikationen i parallel således at begge NAT enheder ser kommunikationen som startende lokalt.

Dette kan kun virke hvis NAT enhederne tildeler portnumre på en forudsigelig måde. Der er to måder en NAT enhed kan gøre portnumrene forudsigelige. Den kan garantere at et lokalt portnummer tildeles et fast portnummer på ydersiden af NAT uanset hvem der kommunikeres med. Eller den kan så vidt muligt bevare portnummeret således at pakker der sendes ud gennem NAT blot får ny IP adresse men ikke nyt portnummer.

Den slags garantier er sværere at give når man har mange brugere bagved en enkelt NAT, og det bliver ikke bedre af at man kan have to niveauer af NAT og begge skal opfylde kravet for at forbindelsen kan virke.

Start med at overveje om følgende protokol vil virke med en NAT enhed. C1 er en computer bagved en NAT enhed, C2 og C3 er computere på offentlige adresser:
C1 sender en UDP pakke til C2
C2 sender en UDP pakke til C3 som indeholder IP adresse og portnummer på C1.
C3 sender en UDP pakke til C1.

Med nogle NAT enheder virker det, med andre gør det ikke. Hvis du har en NAT enhed hvor det virker åbner der sig en ny mulighed. C1 og C3 er nu bagved hver deres NAT enhed og C2 er på en offentlig addresse.
C3 sender en UDP pakke til C2
C1 sender en UDP pakke til C2
C2 sender en UDP pakke til C3 som indeholder IP adresse og portnummer på C1.
C3 sender en UDP pakke til C1.

Det første skridt er nyt, de sidste tre skridt er det samme som før. At C2 kan sende en pakke til C3 virker kun fordi der allerede er sendt en pakke gennem NAT enheden i den anden retning. Hvis den NAT enhed som C1 sidder bagved tillod den første kommunikation, så vil den anden kommunikation også virke. Det gjorde altså ingen forskel at der blev introduceret en NAT enhed mere.

Bemærk at i andet eksempel er der en symmetri hvor C1 og C3 næsten kan byttes om. Men pakken der skal sendes mellem de to computere bagved NAT sendtes kun i den ene retning. Men hvis nu det var den anden enhed ville det være bedre at sende pakken i den anden retning. Der kan også være NAT enheder hvor den indkommende pakke aldrig accepteres fordi der ikke har været en pakke i den anden retning først.

Hvis man i stedet for kun at sende en pakke fra C1 til C3 prøver at sende en pakke i hver retning på samme tid har man bedre chance for en forbindelse. Man slår dermed tre fluer med et smæk. Hvis den ene NAT enhed ville virke i første scenarie behøver man ikke vide hvilken af de to. Og hvis der kræves en udgående pakke før den indgående pakke kan det også opfyldes ved at de to sidste pakker passerer hinanden på nettet mellem de to NAT enheder.

C1 og C3 sender hver en UDP pakker til C2
C2 sender en UDP pakke til hhv. C1 og C3 med hinandens IP adresse og portnummer.
C1 og C3 sender UDP pakker til hinanden (med god sandsynlighed passerer de to pakker hinanden på nettet mellem de to NAT enheder).

Hvis blot en af de to sidste pakker kommer gennem skynder man sig at sende en pakke tilbage baseret på den man netop modtog. Med lidt held vil ovenstående virke. Jeg implementerede selv ovenstående for ca. 10 år siden, og det virker ofte. Jeg har til tider oplevet at den kode jeg skrev til det får pakker igennem i tilfælde hvor jeg ikke selv kan forklare hvordan pakken kom igennem på den måde den gjorde.

Metoden kan i princippet også bruges til at oprette en TCP forbindelse. Men jeg har dog aldrig prøvet det, og jeg tror ikke det har store chance for at virke i praksis. Så jeg tror stort set alle protokoller af denne type bruger UDP.

Men det er så afhængigt af hvordan NAT enhederne virker at idet du sætter flere NAT enheder imellem reduceres chance for at det virker.

Metoden kræver stadig at der er en computer på en offentlig adresse som kan koordinere kommunikationen. Hvis metoden ikke lykkes vil nogle peer-to-peer applikationer vælge at lade trafikken blive sendt gennem den computer som har en offentlig adresse. Det øger forbruget af båndbredde betydeligt på de computere i peer-to-peer systemet, der har en offentlig IP adresse.

Og her ligger den næste grund til at det ikke længere vil blive ved med at fungere. Peer-to-peer applikationer som i dag fungerer på trods af NAT er afhængige af at have en kritisk masse af brugere på offentlige IP adresser. Jo mere udbredte NAT enheder bliver, des mindre procentdel vil være på offentlige IP adresser, og til sidst vil de computere som er på offentlige IP adresser ikke længere kunne håndtere trafik nok.

Endnu et problem er timeout på forbindelser gennem NAT enheder. Jeg så det for nyligt nævnt, men jeg kan ikke huske hvor. Eksemplet der blev givet var ikke peer-to-peer, men derimod AJAX applikationer. Før i tiden var http requests noget man sendte og så fik svar på så hurtigt som serveren var i stand til det. Men med introduktionen af AJAX blev det mere almindeligt at man sender en request og så får man først et svar når der er noget nyt at fortælle.

Det betyder et større antal TCP forbindelser som er åbne og idle og som er afhængige af at fortsat kunne sende trafik når der er noget nyt at rapportere. Det der nemt kan ske er at en klient sender en besked til serveren og venter på et svar når der sker noget nyt. Forbindelsen går gennem en NAT enhed som glemmer forbindelsen efter et stykke tid uden trafik. Når serveren omsider sender en besked til klienten når den kun til NAT enheden. Hvis man er heldig sender NAT enheden på det tidspunkt en RST pakke til serveren, så den ved at forbindelsen er lukket.

- Klienten ved ikke at forbindelsen er lukket
- Det er kun klienten der kan åbne en ny forbindelse
- Det er kun serveren der ved at det er nødvendigt med en ny forbindelse
- Serveren kan først fortælle klienten om det når den nye forbindelse er blevet åbnet

Den eneste måde at løse det problem på er keepalive beskeder fra klienten til serveren uanset om applikationen er fuldstændig idle.

De spilder resourcer både i browsere og på netværket. NAT enhederne skal bruge RAM på at huske på flere forbindelser, og der er måske heller ikke port numre nok.

Hvis ikke man har RAM nok og portnumre nok, så er NAT enheden nødt til at fjerne forbindelser fra sin tabel tidligere. Efterhånden som det sker bliver AJAX applikationer nødt til at reducere deres keepalive interval. Men det løser ikke magisk problemet med manglende resourcer og betyder blot at de fjernes endnu hurtigere.

Personen som beskrev dette problem frygtede at der ville ske det at de mest stabile AJAX applikationer ville være dem som brugte de korteste intervaller og dermed spildte flest muligt resourcer. Og det ville resultere i en kamp om at bringe intervallet længst muligt ned.

Med mange brugere bagved hver NAT enhed hos internetudbyderne vil ovenstående være dræbende for deres performance og stabilitet.

CableCat (12) skrev:

Det som derimod er vigtigt, er at få IPv6 ud til klienterne, som lige nu lider under at P2P i mellem to klienter bag NAT er umuligt eller meget besværligt.

Det er jeg fuldstændigt enig i. Og det burde sådanset være sket allerede for ti år siden. Hvis man havde fået IPv6 ud på flere klienter for at bruge det til peer-to-peer ville servere på IPv6 være fulgt efter ret naturligt.

Men du har jo selv forklaret hvorfor det ikke skete. Der var ikke nok peer-to-peer applikationer som pressede på for at få IPv6 ud til brugerne.

Tænk hvis man i stedet for at NAT applikationer bruge deres egne NAT holepunching metoder havde sigtet efter at anvende 6to4 og Teredo og så bruge det til at bygge applikationerne på.

Jeg må indrømme at jeg har ikke tænkt den idé helt igennem. Så jeg ved ikke om man uden videre ville kunne få Teredo til at virke på den måde. Udfordringen man ville skulle løse er hvor man skulle gøre af sine Teredo servere.

CableCat (12) skrev:

For eksemplet blev IP-telefoni baseret på standarter aldrig rigtigt til noget. I stedet vandt Skype, som gør alle mulige triks for få trafikken igennem.

Korrekt. Og det er lidt sørgeligt at alt den opfindsomhed kun kunne bruges på at finde på mange måder at få trafikken igennem.

Der så vi en applikation med en anvendelse men måske 10 eller 100 måder at transportere data. Hvis samme opfindsomhed var brugt på en anden måde kunne vi have set 10 eller 100 anvendelser men kun en måde at transportere data på.

Og Skype lider jo også under at for mange brugere er bagved NAT. Så vidt jeg husker var det i december 2010 at det førte til et stort nedbrud for Skype. Det var en kombination af en software bug, for få resourcer på de peers med en offentlig IP adresse og en tilfældig hændelse der fik en del klienter til at gå ned samtidigt.

De var nødt til at leje et antal maskiner (hos Amazon så vidt jeg husker) og starte Skype op på alle de maskiner med offentlige IP adresser for at få systemet stabiliseret igen.

De fik fejlen rettet, så det er vist ikke et kritisk problem for Skype lige nu. Men det demonstrerede hvad der kan ske, og næste gang skal der måske ikke nogen bug til. Hvis NAT bliver ved med at blive mere udbredt kan den type nedbrud blive mere almindelige. Om det lige bliver Skype næste gang er ikke til at forudsige.

Hvor mange af den slags nedbrud skal der til?

kasperd (13) skrev:

Med mange brugere bagved hver NAT enhed hos internetudbyderne vil ovenstående være dræbende for deres performance og stabilitet.

Egentlig synes jeg det ville være rimeligt at stille nogle krav til de udbydere som finder det nødvendigt at lave NAT for deres brugere.

Hvis en internetudbyder laver NAT og der laves en fælles NAT for flere brugere eller blot en NAT som brugerne ikke selv har mulighed for at undgå, så er det et rimeligt krav at de udbydere samtidigt giver hver brugere native IPv6 adgang med et prefix på 48-60 bits. (I den forbindelse ville jeg sidestille en 6rd løsning med native IPv6).

Samtidigt bør udbyderen give hver kunde et /24 netværk af IPv4 adresser så ingen brugere bliver nødt til at have deres egen NAT bagved udbyderens NAT. Et /24 netværk til hver kunde sætter godt nok en grænse på 65k brugere bagved hver NAT pulje. Men i praksis vil en NAT pulje nok slet ikke kunne trække så mange brugere alligevel.

Hvis man alligevel udruller IPv6 til kunderne er der et par andre muligheder til NAT løsningen. Man kunne bruge NAT64 eller 4rd. Både NAT64 og 4rd er designet til at fjerne behovet for at køre både IPv4 og IPv6 på udbyderens netværk, men tillader at det meste af netværket kun kører IPv6.

NAT64 ville køre IPv6 helt ud til kunderne således at kunderne kun har IPv6 og det først er ved udbyderens NAT enhed at det laves om til IPv4.

NAT64 lider stadig af begrænsninger på RAM forbrug og portnumre. Og jeg tvivler på at der er ret mange af de workarounds omkring IPv4 NAT som virker med NAT64. Alt i alt er NAT64 næppe nogen fordel for kunderne, men det kan simplificere udbyderens netværk. Der er mindst en mobiludbyder (i USA så vidt jeg husker) der har erklæret en intention om at deres 4G netværk vil være ren IPv6 og bruge NAT64 til at nå IPv4 websites.

Til mobiltelefoner hvor der nok ikke er så stort behov for legacy applikationer er sådan et valg nok acceptabelt.

4rd løser nogle af problemerne med NAT hos udbyderen ved at flytte tilstanden fra udbyderen til kundens eget udstyr. Der bruges en række tilstandsløse enheder hos udbyderen som har en pulje af IPv4 adresser. Denne pulje af IPv4 adresser resulterer i en pulje af portnumre, som fordeles mellem kunderne. Hvor mange portnumre hver kunde får afhænger så af udbyderens valg, dog vil antallet altid være en potens af 2. På en måde kan man sige at man har fortsat subnetting helt ned i portnumrene.

F.eks. kan det være at en kunde tildeles 8192 portnumre som går fra 192.0.2.113:8192 til 192.0.2.113:16383. Det er også muligt at tildele mere end 65536 portnumre til en kunde hvorved de får mere end en enkelt IPv4 adresse for dem selv. Det er dog ikke sandsynligt at se 4rd blive brugt på den måde.

Ved at fast tildele portnumre til kunder kan alt tilstand flyttes fra udbyderens udstyr til en NAT enhed hos kunden. Denne NAT enhed hos kunden skal kende 4rd, og pakkerne mellem kundens NAT enhed og udbyderens udstyr sendes som IPv6 pakker således at udbyderens netværk ikke behøver håndtere IPv4.

Med 4rd kan udstyret hos kunden supportere alle de gængse workarounds for NAT problemer. Kunden kan også forwarde IPv4 porte til interne adresser (men selvfølgelig kun blandt portnumrene tildelt den pågældende kunde).

Det største problem med 4rd er nok at standarden ikke er færdig endnu.

Carrier-grade NAT (ISP'en køre NAT) vil snart blive almindeligt. Det blive allerede brugt på nogle mobile netværk.

Men hvor slemt er Carrier-grade NAT? De fleste klienter får deres internet-forbindelse i gennem NAT. I private hjem er det typisk dårligt udstyr der bliver brugt til det. Udstyr som ikke kan huske nok forbindler, og derfor går server call backs tabs (som beskrevet af Kasperd).

Derfor kan Carrier-grade NAT faktisk give en bedre internet forbindelser for gennemsnittet. Forudsagt at folk så stopper med at selv at kører NAT.

CableCat (15) skrev:

Derfor kan Carrier-grade NAT faktisk give en bedre internet forbindelser for gennemsnittet. Forudsagt at folk så stopper med at selv at kører NAT.

Hvor mange stopper med selv at køre NAT? Mange brugere bliver sikkert ved med det fordi det nu engang er det deres router er sat op til. Jeg tror omtrent alle routere bliver solgt med en default konfiguration der henter en enkelt IPv4 adresse fra udbyderen og så kører NAT mellem lokalnet og udbyderens netværk.

Hvis der skal køres uden NAT skal routeren bruge lidt flere oplysninger fra udbyderen. Jeg ved ikke om automatisk konfiguration af de ekstra oplysninger overhovedet er supporteret med IPv4, men det er supporteret med IPv6. Selv hvis det er standardiseret til IPv4 er det sikkert et fåtal af routere der supporterer det.

Så enten skal manuelt konfigurere sin router med alle de nødvendige oplysninger, eller også skal man i hvert fald som et minimum slå NAT fra. Hvor mange brugere ved egentlig at NAT kan slås fra på sådan en router?

Alt i alt gætter jeg på at hovedparten af de kunder der har en router vil stadigvæk have NAT på den router og dermed have dobbelt NAT. Det vil sige at i bedste fald får de en stabilitet svarende til den dårligste af de to NAT implementationer.

Man kan droppe routeren og have et antal enheder forbundet direkte og lave DHCP imod udbyderen. For de enheder kan udbyderen dog sikre at de får en statisk adresse og at de alle vil være i samme subnet og dermed ikke skulle ud over internetforbindelsen for at kommunikere med hinanden.

Samtidigt er udbyderen nødt til at sikre at der er mulighed for at bruge en router for de kunder der selv vil sætte deres router op med en statisk konfiguration.

De kunne f.eks. bruge 172.17.0.0-172.17.255.255 til statiske IP adresse til kundernes routere og 172.18.0.0-172.30.255.255 til en DHCP pool til kunder uden routere. Alle sammen kan sættes op med 255.240.0.0 som deres netmask.

Så kan 10.0.0.0/8 bruges til addresserne på lokalnettet hos brugere med en router. 172.17.x.y skal så bruges som gateway til 10.x.y.0/24.

På den måde er der op til 65536 routere på det fælles segment og hver router har et /24 segment til lokalnettet. Derudover er der adresser nok i DHCP poolen til at kunderne i gennemsnit kan have 29 enheder på uden at bruge en router.

I praksis tror jeg ikke man har lyst til at køre så mange kunder bagved en enkelt NAT. Så antallet af adresser i RFC1918 er ikke problemet. Problemet er at det nok kommer til at kræve manuel konfiguration for at give kunderne den bedste stabilitet. Og det er nødvendigt for udbyderen at supportere både en fornuftig konfiguration for de kunder der kan finde ud af det og en noget anderledes konfiguration for de kunder der ingen router har fordi det er for besværligt at sætte op.

Jeg har på fornemmelsen at udbyderne ikke vil gøre så stor en indsats som det jeg har beskrevet for at få det til at fungere godt.

Selv hvis man slipper for dobbel NAT, så er der ingen garanti for at kunden får en bedre forbindelse. De ringste routere kan sagtens tænkes at være dårligere end den NAT løsning udbyderen vælger. Men der vil nok også være kunder som havde en NAT løsning derhjemme, som fungerede bedre end det udbyderen kan tilbyde.

Protokoller til at modtage forbindelser udefra kan så vidt jeg ved kun bruges hvis man er forbundet direkte til NAT enheden og ikke hvis der er en router mere imellem.

Desuden er muligheden for at permanent forwarde porte ind på lokalnettet ret begrænset hvis det er udbyderens NAT enhed.

Hvis endeligt der skulle opstå problemer med tilstanden i NAT enheden kan man ikke selv genstarte den, og hvis udbyderen (med eller uden en god begrundelse) vælger at genstarte deres NAT enhed for at løse problemer vil det påvirke alle brugerne.

Derudover vil brugere også blive påvirket af hvad andre brugere foretager sig, selv når NAT enheden opfører sig som den skal. Tag f.eks. websites der håndterer misbrug ved at blokere IP adressen. Så kan der være websites du ikke kan komme ind på fordi din nabo begik noget misbrug.

Og mængden af forbindelser en NAT enhed kan håndtere er begrænset. Hvis ikke enheden er intelligent nok risikerer man at nogle få brugere kan opbruge alle forbindelserne og give dårligere stabilitet til de andre brugere.

terracide (7) skrev:

Ingen udbyder vil lancere et produkt der ikke er rentabelt....ikke ne der vil overleve ihvertfald.

Så er det godt at der findes udbydere, som ikke skal lave penge. Foreningen Kollegienet Odense er på vej med IPv6-support. De har, så vidt jeg har forstået, al hardware på plads (jeg fik at vide at firewallen var alt for dyr - men der var en stor egenkapital) og mangler kun noget konfiguration. Det er et halvt år siden jeg hørte om det, så jeg har sikkert husket noget forkert.

kasperd (10) skrev:

Næppe. Den største del af udgiften er en engangsudgift i forbindelse med designet. Produktionsomkostningerne per enhed kan ikke stige ret meget [...] Det er dog noget som i mange tilfælde skal håndtere i hardware.

Og netop det er dyrt. Alle løsninger skal udvikles fra bunden. Det kommer til at koste meget i starten for de første produkter. Lige nu er nogle løsninger kun mulige at lave i software - og så koster det kassen i hardware.