- emailE-mail
- linkKopier link
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Nej, de fleste danske ISP'er er bare gamle nok til at have hamstret IPv4 addresser nok mens tid var.
Ja, enig. Og selv de hamstrede adresser slipper op på et tidspunkt, så der er ingen vej uden om.
Nej, de fleste danske ISP'er er bare gamle nok til at have hamstret IPv4 addresser nok mens tid var.
Det ser ud til at Danmark er ved a blive et u-land hvad det angår. Er danskerne bare for dovne til at tage IPv6 i brug eller hvad?Google fører i øvrigt statistik på IPv6 brugen. Godt 30% af Internet trafikken kører IPv6 i dag.
Det er alle lande udenfor Afrika. Herunder er vi specifikt i Danmark også løbet tør for IP adresser. Det betyder at nye internetudbydere leverer IPv6 native IPv4 by NAT som PHK formulerede det.
Ja, præcis. Google fører i øvrigt statistik på IPv6 brugen. Godt 30% af Internet trafikken kører IPv6 i dag. Statistikken ligger her: https://www.google.com/intl/en/ipv6/statistics.html
Alle behøver ikke af have IPv6. Det er vigtigst hvis man har trafik til lande hvor der ikke er flere IPv4 adresser
Det er alle lande udenfor Afrika. Herunder er vi specifikt i Danmark også løbet tør for IP adresser. Det betyder at nye internetudbydere leverer IPv6 native IPv4 by NAT som PHK formulerede det.
Det er jo ikke nok. Det svarer lidt til at Graham Bell da han havde opfundet telefonen ikke havde nogen at ringe til. Alle skal have det.
Jeg har fået leveret IPv6 tjenester fra TDC de sidste 6-7 år, på en helt almindelig erhvervsløsning. Mit nuværende website torbenrune. dk har helt automatisk fået tildelt en AAAA record fra hosting udbyderen. AAAA adressen er i øvrigt: 2a02:2350:5:108:4040:0:12dc:94a3
Alle behøver ikke af have IPv6. Det er vigtigst hvis man har trafik til lande hvor der ikke er flere IPv4 adresser, og hvor bredbåndsabonnementerne pr default er udstyret med IPv6. Det er lettest for dem at nå servere her på IPv6.
Øh jeg tror ikke nogen vil lave en hjemmeside som kun er IPv6 sålænge de fleste kunder kun har IPv4.
Nej men du kunne nemt lave en løsning hvor du kører din hjemmeserver IPv6 only og så bruger du eksempelvis Cloudflare som proxy for IPv4 folket.
Det er jo ikke nok. Det svarer lidt til at Graham Bell da han havde opfundet telefonen ikke havde nogen at ringe til. Alle skal have det.TDC er omsider igang, dog kun til pro løsninger, som udbydere ol, ikke slutbrugere !
Øh jeg tror ikke nogen vil lave en hjemmeside som kun er IPv6 sålænge de fleste kunder kun har IPv4.Løst refereret: "Hvis du handler med Asien, så kan det være relevant med en IPv6 adresse, men ellers kan du nøjes med IPv4".
TDC har fuldt ud implementeret IPv6: <a href="https://tdc.dk/kundeservice/hjaelp-til-produkt/internet/ip-adresse-for-…;.
Undskyld men jeg synes TDCs forklaring er en tynd kop te.
Løst refereret: "Hvis du handler med Asien, så kan det være relevant med en IPv6 adresse, men ellers kan du nøjes med IPv4".
Kan ikke se nogen grund til at fortsætte med at slæbe med fødderne, når det kommer til IPv6.
Om ikke andet, så burde diverse udbydere havde lært så meget af Covid-19.
Tak Torben ! TDC er omsider igang, dog kun til pro løsninger, som udbydere ol, ikke slutbrugere ! Deres datterselskab Dansk kabel tv (tidligere Fascom (som lagde kablerne for langt over tyve år siden)), har MONOPOL (tilmed ift søsterselskaber) i det område hvor jeg bor, Almenbo i Ballerup, og her benytter de så vidt jeg kan se udelukkende IPv4, vi må ikke have udvendige paraboler, og det er som med en 4G er ikke brugbare løsninger !
Kan IPv6's bedre kryptering være årsagen til at TDC har været og er så langsomme med implementeringen, at de ikke lige så let kan holde øje med hvad kunderne bruger deres net til ? Så vidt jeg har kunnet læse mig til, så vil det vare mægtig længe før vi løber tør for IPv6 adr 340,282,366,920,938,463,463,374,607,431,768,211,456 teoretiske adresser, og vi er ca 8 milliarder, så der er da en pæn håndfuld til alle inkl alle virksomhederne, så hvorfor så langsomt ?
Nåhh, men jeg må vel vente, håber ikke 4Gv2 = 5G tager lige så lang tid !
BTW har jeg intet problem med VPN her, der er klart nok en del spild undervejs, at hente den nye Win 10 2004 64bit tager mindre end 10 min, og et tilsvarende upload er næsten bedre !
I må alle have det forrygende !
Sorry, Så for sent Baldur's udmelding, og der er TDC stadig ikke imellem !Har TDC fået implementeret IPv6, eller hænger de stadigt gevaldigt i bremserne ?
Har TDC fået implementeret IPv6, eller hænger de stadigt gevaldigt i bremserne ?Og hvis man ser på IPv6 som eksempel, så skal du frem til 2060 før det så er ved at være implementeret på bare halvdelen af internettet. Og det er hvis alle er enige om at det er en god ide.
Mange af de klassiske amerikanske tech giganter har implementeret IPv6. Eksempelvis:
Det skyldes at de har mange kunder efterhånden som er IPv6 native, IPv4 by NAT, både i USA og Asien.
Endelig kan man stille sig selv spøgsmålet om tech giganterne er interesserede i at IPv6 slippes løs.
Mange af de klassiske amerikanske tech giganter har implementeret IPv6. Eksempelvis:
Akamai er underleverandør på meget indhold, så eksempelvis video fra dr.dk leveres via Akamai og med IPv6 selvom dr.dk domænet ikke har IPv6.
Danske internetudbydere med IPv6:
Jeg kender flere i branchen som slår syv kors for sig når de hører IPv6 nævnt. Det er ikke noget de vil beskæftige sig med, og der er sikkert mange andre som har de ligedan.Jeg tror det kommer til at gå hurtigere, bl.a. fordi det bliver kostbart at bruge IPv4 adresser når mangel situationen først er global - hvad den jo nærmest er ved at være.
Så de skal have kniven på struben først, men hvis et datacenter har nok IPv4 addresser, og ISP'en blot kan bruge Carrier grade, bliver de svære at flytte med.
Og nye spillere kan man holde ude af markedet fordi, de ikke kan få IPv4 addresser.
Endelig kan man stille sig selv spøgsmålet om tech giganterne er interesserede i at IPv6 slippes løs. IPv6 vil jo gøre det muligt at lave mange decentrale services, hvor man ikke ef afhængig af at data skal omkring et data center (og blive profileret) for at når frem til en anden person.
Og hvis man ser på IPv6 som eksempel, så skal du frem til 2060 før det så er ved at være implementeret på bare halvdelen af internettet.
Oh sh.. så er jeg 102 år. Nå pyt - bedre sent end aldrig.
Jeg tror det kommer til at gå hurtigere, bl.a. fordi det bliver kostbart at bruge IPv4 adresser når mangel situationen først er global - hvad den jo nærmest er ved at være.
Måske nogen finder på noget mere genialt i mellemtiden.
Men OK, de har også frem til 2030 at lave den i, så mon ikke det lykkes.
Og hvis man ser på IPv6 som eksempel, så skal du frem til 2060 før det så er ved at være implementeret på bare halvdelen af internettet. Og det er hvis alle er enige om at det er en god ide.
Med al respekt for ITU og de involverede - og uden at kunne kloge mig om det specifikke emne - så er det ikke ensbetydende med at det er en god ide eller at der er tekniske specialister i ITU som bakker op om udgangspunkt eller plan.
Det har du fuldstændig ret i. Og det gælder i særlig grad når vi taler om Fokus Grupper. Her er udgangspunktet næsten det modsatte - alle ideer skal på bordet så der er noget at vælge imellem, og en masse at smide væk. Standardiseringsmetodik som i gode gamle dage.
Når det gælder NET-2030 så er sagen, at denne fokusgruppe er meget fragmenteret, og der er gået politik i teknikken. Der er altså ikke tale om, at ITU har en bestemt god idé eller en bestemt dagsorden - mere at ITU er det forum man diskuterer i - lige som bloggen her på V2. Alle ideer kan prøves af - gode som dårlige. Og man behøver ikke at være enige - med mindre man altså er ITU og håber på at det hele ender med en fælles global standard for fremtidens Internet. Men OK, de har også frem til 2030 at lave den i, så mon ikke det lykkes.
Da jeg i sin tid havde ansvaret for udviklingen af WiFi 802.11a / Hiperlan standarden tog det omkring 6 år at få formuleret den, yderligere 3 år at få ryddet frekvensbåndet (i 5GHz), og derefter endnu et par år, før de første produkter begyndte at dukke op. Jeg var dog kun med de første 2 år af den aller første del af standardiseringsarbejdet i ETSI regi. Så den slags tager tid.
Det er jo ITU som har startet NET-2030 arbejdsgruppen, og det er ideerne og tiltagen fra den jeg bringere videre.
Med al respekt for ITU og de involverede - og uden at kunne kloge mig om det specifikke emne - så er det ikke ensbetydende med at det er en god ide eller at der er tekniske specialister i ITU som bakker op om udgangspunkt eller plan.
Jeg har et par gæt på, hvorfor du oplever lavere hastighed på VPN:</p>
<p>Din udbyder nedprioriterer VPN-trafik (da mere og mere ulovlig download-trafik er flyttet over på VPN)
Det skal jeg ikke kunne sige noget om, men det kan godt være.
Dog bruger jeg ikke min VPN til ulovlige ting.
Det eneste trafik til Internettet som går via min VPN er IPv6.
Fordi:
Hvordan skulle jeg ellers kunne eksperimentere med protokollen, når nu jeg kan ikke få den fra min udbyder? :-)
Det giver så det bøvl at jeg skal have en lokal DNS server, som kan filtrere AAAA records fra, hvis jeg vil bruge eksempelvis Netflix.
Netflix kan nemlig ikke lide VPN forbindelser.
Jeg har dog ingen problemer med HBO Nordic elle Amazon Prime, men det er nok mere fordi de har ikke offentliggjort AAAA records på deres servere.
Uanset hvordan man vender og drejer det, så ser jeg det ikke så meget som en teknisk diskussion, men en politisk diskussion.
Ja, det har du meget ret i. Da NET-2030 startede i 2018 var det som en teknisk fokus gruppe, som teoretisk skulle afsøge muligheder for løsninger. Nu, da forslagene er begyndt at komme ind, bliver diskussionen pludselig drejet over på den politiske betydning. Så meget, at nationale politikere er begyndt at have meninger om tekniske løsningsforslag, og deres potentielle trusler mod det enkelte lands nationale sikkerhed.
Jo, der sker noget i NET-2030 fokusgruppen.
Alle mulige har prøvet at lappe over hvor dårligt deres teknologi virker ved at lave dybere og dybere buffere og det er gift for TCP algoritmerne.
Helt enig. Og man kan godt se ITUs NET-2030 som endnu et forsøg i den retning - omend et meget ambitiøst og kompliceret forsøg - med dog et forsøg på at gøre noget ved problemstillingen.
Jeg synes dine indlæg i denne omgang har haft karakter af "nuværende systemer har mange udfordringer, vi har mange gode ideer, alting bliver bedre når vi får det implementeret".
Du har nok ret - men jeg er nok mere budbringer end "opfinder" i den sammenhæng. Det er jo ITU som har startet NET-2030 arbejdsgruppen, og det er ideerne og tiltagen fra den jeg bringere videre. Som jeg skriver, så er der både gode og mindre gode idéer i NET-2030 arbejdet, og der er klart idéer som ikke vil få gang på jord.
Det kan blive rigtig interessant at får udbydere med markante holdninger til spørgsmålene med i ITUs fokusgruppe. Alle kan være med - og det koster ikke noget: https://www.itu.int/en/ITU-T/focusgroups/net2030/Pages/default.aspx
Men det har vi en meget enkel løsning på: vi har indkøbt kapacitet så der ikke opstår congestion. Og det har alle vores upstreams også, de lever af at sælge trafik til os, så congestion er lig med tabt omsætning.
ITU mener ikke, at det at etablere mere infrastruktur kan løse problemet på en 10 årig horisont. Det er derfor man har iværktsat NET2030 initiativet. Det redegører ITU faktisk for i fokus gruppen.
Jeg stor fan af at holde det så simpelt som muligt og vil mene at det også i stor udstrækning er sådan internettet virker i dag. At lægge en masse ekstra administration og regler ovenpå internettet tvivler jeg på gavner forbrugerne - det vil give bedre mulighed for kontrol og overvågning hvilket er i nogle aktørers interesse.
Helt enig i denne her. Robustheden i internettet skyldes netop, at alt er designet efter at være "best effort" - og man har forladt den gamle telco-tankegang, hvor man skulle styre hele forbindelsen fra A til Z.
Tja jeg skal i hvert fald sætte keepalive til en værdi under 10 sekunder, ellers ryger forbindelsen på VPN eller SSH.
Det giver mening - men det bør i sig selv ikke være et performance-problem i forhold til antallet af pakker, der kan flyttes. Det er sandsynligvis en kort NAT-timeout, der er indført på CGN-routeren for at holde antallet af samtidige forbindelser i NAT-tabellen nede.
Jeg har kørt følgende kommando fra Linux:</p>
<p>ping -M do -s 1500 -c 1 min.vpn.server</p>
<p>Og efterfølgende ændret MTU i nedadgående retning med 10.</p>
<p>Jeg kunne penge min server ved en MTU på 1470.
Vær opmærksom på din route-tabel, hvis du kører en VPN-klient på din egen maskine - routen til VPN-serveren selv vil som det eneste typisk være en /32 route uden om VPN-tunnelen, da du ellers vil få en catch-22-situation, hvor din PC ikke vil vide, hvor den skal sende VPN-pakkerne hen.
Sagt på en anden måde, din ping til VPN-serveren kører sandsynligvis uden om VPN-tunnelen og dermed er din målte MTU ikke inde i tunnelen, men svarer til almindelig internettrafik. Og her er en pakkestørrelse på 1472 bytes det normalt opnåelige på en internetforbindelse med MTU 1500.
Jeg har et par gæt på, hvorfor du oplever lavere hastighed på VPN:
- Din udbyder nedprioriterer VPN-trafik (da mere og mere ulovlig download-trafik er flyttet over på VPN)
- Den lavere MTU inde i VPN-tunnelen giver retransmissioner (nok mere sandsynligt)
TCP's "congestion" algoritmer er alle designet med den grund-antagelse at pakker bliver ekspederet eller smidt væk.
Alle mulige har prøvet at lappe over hvor dårligt deres teknologi virker ved at lave dybere og dybere buffere og det er gift for TCP algoritmerne.
Prøve at lade en ping køre imod en eller anden server via mobiltelefon mens I bevæger jeg tværs over landet og I vil se talrige huller og bagefter dukker der pludselige pakker op som er både 10, 30 og 60 sekunder gamle.
< Jeg arbejder ved Telenor, men udtaler mig på egne vegne >Det lyder smart, og det er det måske også - men det er så absolut ikke noget der er nemt at få til at virke - og slet ikke hvis det skal virke på en fair måde og i hele nettet. Blandt udfordringerne er:
Torben: Tak for at få listet udfordringer. Jeg synes dine indlæg i denne omgang har haft karakter af "nuværende systemer har mange udfordringer, vi har mange gode ideer, alting bliver bedre når vi får det implementeret". Det er helt fint at tænke i at gøre tingene bedre, men listen af udfordringer er væsentlig.
Jeg stor fan af at holde det så simpelt som muligt og vil mene at det også i stor udstrækning er sådan internettet virker i dag. At lægge en masse ekstra administration og regler ovenpå internettet tvivler jeg på gavner forbrugerne - det vil give bedre mulighed for kontrol og overvågning hvilket er i nogle aktørers interesse.
Som Baldur skriver, har vi allerede en løsning på rigtigt mange af udfordringerne: Sørg for en fornuftig kapacitetsplanlægning og udvid når det er nødvendigt. Netværkskapacitet kan generelt udvides indenfor rimelige økonomiske rammer, og for det meste er der ikke direkte fysiske forhindringer, som der f.eks. opleves i radionetværket, hvor spektrum sætter en hård begrænsning. Ved at udvide kapaciteten får alle flyttet deres trafik i stedet for at vi diskuterer, hvilken trafik vi skal smide væk.
Jeg vil også gerne hypotetisk spørge hvor meget kriseinformation, der ikke er nået frem, fordi der blev kigget for mange kattevideoer? Min påstand vil være at det meste krisekommunikation kan udformes så det ikke kræver så meget båndbredde, og evt. laves så det kan håndtere et stort pakketab. Det er mere kosteffektivt end at indrette hele infrastrukturen efter nogle meget sjældent opståede situationer - og måske endda gøre det generelt mere skrøbeligt i processen.
Det er vel den slags man får, hvis man køber et MPLS produkt. Der er det kunden som bestemmer hvordan bittene skal fordeles.Skal alle behandles ens, eller skal man kunne købe "premium" så man kan få mere igennem på bekostning af andre.
Principielt er der i dag intet til hinder for at f.eks. Netflix oprettede deres egen MPLS på de enkelte ISP'ers net.
Spørgsmålet er bare prisen. I dag gør prisen at ikke Premium fylder klart mest.
Uanset hvordan man vender og drejer det, så ser jeg det ikke så meget som en teknisk diskussion, men en politisk diskussion.
Det minder også lidt om det gamle triple play koncept, hvor ISP'erne kunne levere både internet og TV (og telefoni) over samme linje.
Det i sig selv er ikke et problem, men bliver det når/hvis der opstår congestion.
Men det har vi en meget enkel løsning på: vi har indkøbt kapacitet så der ikke opstår congestion. Og det har alle vores upstreams også, de lever af at sælge trafik til os, så congestion er lig med tabt omsætning.
Jeg troede egentligt at IPv6 tilbød en løsning på disse ting.
Den del IPv6 ikke løser er, at antallet af meget båndbreddekrævende applikationer er stigende. Det i sig selv er ikke et problem, men bliver det når/hvis der opstår congestion.
I de tilfælde kan man i dag (uanset om der bruges IPv4 eller IPv6) ikke rigtig gøre andet end at fjerne datastrømmen - man kan ikke drosle den ned (nogle få typer af datastrømme kan faktisk godt neddrosles, men metoden virker ikke i det generelle tilfælde). Og heldigvis for det - for hvis dit teleselskab skal drosle ned, så skal de følge med i din datastrøm og det er du ikke interesseret i.
Hvad er løsningen? Det ved man ikke endnu. Lige nu er der masser af gode (og mindre gode) idéer på banen. Nogle af dem går - lidt simplificeret - ud på, at de kommunikerende parter - som en del af transmissionen - giver "metadata" om indholdet. Disse kan så bruges af teleselskabet til at fjerne dele af indholdet - dvs. de dele du har fortalt at du godt kan undvære hvis der er ved at opstå congenstion.
Det lyder smart, og det er det måske også - men det er så absolut ikke noget der er nemt at få til at virke - og slet ikke hvis det skal virke på en fair måde og i hele nettet. Blandt udfordringerne er:
Kan man være sikker på at teleserlskabet behandler alle ens.
Kan man være sikker på at kunderne ikke snyder med metadata, og hvordan opdager man snyd.
Skal alle behandles ens, eller skal man kunne købe "premium" så man kan få mere igennem på bekostning af andre.
Hvor sker afgørelsen af hvad der fjernes, og hvem kontrollerer det.
Får teleselskabet for meget viden om indholdet alene ved at kigge på metadata, og kan det misbruges.
Kan alle datastrømme beskrives med metadata på en brugbar måde.
Er metadata statiske, eller kan de ændres over tid (f.eks. så en overførsel af et vidoesignal mellem to hospitaler kan prioriteres lavt, men kan opprioriteres hvis der pludselig opstår komplikationer som kræver højere opløsning af billeder)
... Listen er meget længere - og den er kun min simple fortolkning af nogle rimeligt snørklede dokumenter, så bær over hvis jeg ikke har fortolket det helt korrekt.
Jeg troede egentligt at IPv6 tilbød en løsning på disse ting.
Det lyder meget mærkeligt. Din performance på VPN burde være upåvirket af CGN - det eneste, CGN gør, er at omskrive pakkens source IP og portnummer.
Tja jeg skal i hvert fald sætte keepalive til en værdi under 10 sekunder, ellers ryger forbindelsen på VPN eller SSH.
Jeg har kørt følgende kommando fra Linux:
ping -M do -s 1500 -c 1 min.vpn.server
Og efterfølgende ændret MTU i nedadgående retning med 10.
Jeg kunne penge min server ved en MTU på 1470.
Nu skal det retfærdigvis siges jeg bruger OpenVPN til server.
Anyway forskellen imellem at bruge UDP eller TCP var ret tydelig, fordi der var ikke noget hul igennem på UDP, mens TCP kan sagtens banke igennem CGNen.
En måling på rå båndbredde til min VPN server i Holland med IPerf.
- 307 mbps udenom VPN
- 29.8 mbps igennem VPN.
Jeg har ikke tested Wireguard endnu, men vil gerne fordi den skulle i teorien kunne sparke bagdel til OpenVPN.
Til gengæld opgav jeg StrongSwan (ipsec). Her savner jeg en guide, som er bygget på KISS-princippet. :-)
Men siden VPN er sløv som bare ... kan jeg blot konkluderer at CGN er ikke bygget til ægte to-vejs kommunikation.
Det lyder meget mærkeligt. Din performance på VPN burde være upåvirket af CGN - det eneste, CGN gør, er at omskrive pakkens source IP og portnummer.
Har du overvejet, om dit problem eventuelt kunne skyldes latency?
Dertil kommer, at du nok har en lavere MTU til rådighed, når du kører gennem VPN.
Ingen af disse dele har dog noget med CGN at gøre.
Hvad er formålet med denne kampagne fyldt med fejlinformation? På den ene side kritiserer man at der sælges høje hastigheder til private, for i næste afsnit at hævde at det i virkeligheden kun er erhverskunder der reelt får leveret høj hastighed. Det passer ikke. Båndbredde er i dag billig og enhver kan køre en speedtest - imod en server på en anden udbyders netværk - og se at hastigheden som regel er til rådighed.
At Netflix måler marginalt højere hastighed på coax end fiber skyldes ikke andet end tilfældigheder og at der i ligningen indgår Wifi og andre forhold hos kunden selv, ud over selve internetforbindelsen. Forklaringen, hvis der en ud over tilfældigheder, skal snareres findes i demografi og om den ene teknologi fortrinsvis dækker lejligheder i forhold til store villaer.
Trafikken fra Netflix kommer fra cache servere der står direkte placeret hos internetudbyderne. Hvorfor så kæde det sammen med international trafik? Det giver ingen mening. Selv mindre udbydere har direkte peering med Google, foruden muligheden for en cache server fra Google, og dermed gratis adgang til trafik fra YouTube.
Den internationale kapacitet er afgørende for din oplevelse, især når du bruger generelle internettjenester som Netflix og Youtube. Som forbruger har du ikke en chance for at få et svar fra udbyderne,« siger Lars Dittmann.
Det er simpelthen ikke rigtigt. Vores internationale kapacitet er irrelevant for Netflix og Youtube. For Netflix har vi en cache server og for YouTube har vi en direkte peering over NL-IX i de to datacentre Interxion (Ballerup) og Hørskætten ved Global Connect (Taastrup). Og vi kunne da ikke drømme om at lade disse links være i nærheden af kapacitetbegrænset.
»Det er hovedrystende, at man stadig vurderer internetforbindelsen efter kapaciteten i netværket de sidste to-tre kilometer ude ved slutbrugeren. Det siger intet om internetoplevelsen, hvis resten af netværket mangler kapacitet,« siger Lars Dittmann, professor i netværksteknologi ved DTU Fotonik.
Netværket mangler generelt ikke kapacitet. Du vil derfor også finde, at såfremt du på en dansk købt 1000 Mbps forbindelse laver en speedtest til en server hos en af konkurrenterne, så får du fuld hastighed. Når du bevæger dig længere ud i verden vil du opleve lavere hastighed, men det skyldes ikke mangel på kapacitet. Det er desværre en uheldig egenskab ved TCP, der automatisk får den til at levere lavere hastighed når latency stiger med afstanden. Men kapaciteten er der hvis du laver flere samtidige downloads.
Til gengæld er de meste indhold tæt på, jævnfør cache servere og lokale peerings med de store indholdsleverandører. Kun en mindre del af trafikken kommer langt fra, hvilket kun understreger det irrationelle i at fokusere på prisen på international trafik (der aldrig har været billigere!).
Ja det er rigtigt der kommer nye udfordringer, men umiddelbart vil jeg mene at fordelene opvejer ulemperne.
Enig - helt klart er fordelene størst. Ulempen er jo i sin yderste knsekvens, at Internettet falder fra hinanden / segmenteres i flere indbyrdes funktionelt forskellige net, og det er klart ikke ønskeligt.
At det så giver en lang række nye udfordringer er en anden sag, men mangel på adresser bliver ikke en af dem.
Ja det er rigtigt der kommer nye udfordringer, men umiddelbart vil jeg mene at fordelene opvejer ulemperne.
Den vigtigste ting folk skal vænne sig til et at alle IP adresser er synlige for alle - med mindre man har en firewall imellem som styrer hvem har adgang til at se hvad.
Det plejer at være kutyme med følgende standard indstilling:
- WAN -> LAN: Deny
- LAN -> WAN: Alllow
... og så lige en regel om at trafik fra internettet til LAN er tilladt, hvis den er relateret til en udgående forbindelse.
Alt andet indgående trafik skal tillades explicit på case-by-case basis.
Eksempelvis adgang til web og mail server.
Men derudover har de fleste private en yderligere beskyttelse mod at blive hacket på IPv6, hvis de har fået deres IP adresse igennem SLAAC med privacy extensions slået til.
Årsag: Deres IP adresse skifter hele tiden og det tager lidt tid at scanne alle IP-adresser i et /64 net - selv for NSA. ;-)
Men det er ikke ensbetydende med at du er usynlig på nettet.
Fordi I stedet for at bruge en specifik ip adresse som bevis for at du har downloadet noget noget ulovligt, så bliver der blot registreret at et-eller-andet /64 net har downloadet noget ulovligt - herefter er det trivielt at finde ud af hvilken kunde befinder sig på hvilket net.
Da vi har ikke nok IPv4 adresser til at alle kan have en offentlig IP adresse, bliver NAT brugt for at udskyde dette problem.
Ja, det er et meget væsentlig problem du har fat i der. Der er (desværre fristes jeg til at sige) ingen vej uden om IPv6.
På 4G mobilnettene kører man allerede i dag IPv6 internt og i 5G både internt og eksternt. Heldigvis findes der i dag rimelige gateways mellem IPv4 og IPv6, men det ender nok med til sidst at blive IPv6 det hele. At det så giver en lang række nye udfordringer er en anden sag, men mangel på adresser bliver ikke en af dem.
For at holde en to-vejs forbindelse åben kræves der at begge parter kender hinandens IP adresser og hvilken port begge parter lytter på.
Da vi har ikke nok IPv4 adresser til at alle kan have en offentlig IP adresse, bliver NAT brugt for at udskyde dette problem.
Ideen er at hvis du har 2 enheder, som skal deles om den samme ip adresse, så vil NAT forvarde en IP pakken til enten den ene eller anden enhed, baseret på hvilken port der modtog den oprindelige pakke.
Men her kommer fælden:
Antag at du er en udbyder med flere tusinde kunder.
Du er forholdsvis ny i branchen, så det bedste du kunne få fra RIPE er et /24 net (altså et net med 256 offentlige IP adresser).
TCP protokollen har op til 65535 porte, som NAT enheden kan bruge (best case), hvilket givet os en øvre grænse på 16.776.960 simultane forbindelser - hvis de alle sammen bliver brugt til NAT.
Desværre tror jeg at det praktiske tal er noget lavere.
For eksempel plejere de nederste 1024 porte at være reserveret til dedikerede service.
F.eks køre http på port 80, http på port 443, ssh på port 21 og så videre.
Læg dertil at hver enhed kan sagtens lave flere forbindelser uafhængig af hinanden, så lang tid de kører på hver sin port.
Dette gør at antallet af kunder, som du kan servicere igennem en NAT falder yderligere.
Jeg er selv i den situation at jeg har en fin 300 mbps forbindelse, men på grund af at jeg sidder bag 444 NAT, så kan jeg ikke udnytte VPN særligt optimalt.
Eksempelvis virker VPN via UDP protokollen overhovedet ikke, så jeg er tvunget til at bruge TCP.
For at holde VPN forbindelsen åben, er jeg nød til at sende et keepalive signal lidt oftere end hvert 10. sekundt.
Hvis jeg ikke gør det ryger min forbindelse i min udbyders NAT.
Dette gør at det bedste jeg har kunne trække over VPN er 13 mbps.
Nuvel. Jeg ved at der er en overhead på VPN, men jeg burde kunne trække 100-120 mbps, selv med overhead - eller hvad?
Hvis vi snakker ren streaming, download eller andet som er ikke nævneværdigt afhængig af et svar fra mig, så er der fint smæk på forbindelsen.
Dowloading af eksempelvis en 60 GB stor opdatering tager ingen tid, når man har 300 mbps til rådighed og jeg kan også uploade via FTP med en hastighed i samme skala.
Men siden VPN er sløv som bare ... kan jeg blot konkluderer at CGN er ikke bygget til ægte to-vejs kommunikation.
Hovedproblemet er TCP/IP. Som Lars Dittmann siger, så er TCP/IP ikke beregnet til så store netværk. Fremtiden byder på meget mere multimedieindhold, og på helt nye typer af indhold. Vi taler om holografisk mediestrømme som kan overføre information om hele rum, om gigabitstrømme fra selvkørende biler, og ikke mindst datastrømme fra et eksplosivt voksende 5G net. ITU definerer dette som Tactile Internet (Se: https://5g.co.uk/guides/what-is-the-tactile-internet/).
ITU nedsatte i juli 2018 en fokus gruppe (FG) som skal arbejde med udformningen af fremtidens Internet, og hvis formål er at udvikle nye netværksprincipper. En af udfordringerne er, at man netop er nødt til at tage brugen af TCP/IP protokollen op til vurdering. Det er ikke så lige til, efter som 100% af Internettet i dag er baseret på denne protokol.
Som nettet anvendes i dag, er princippet, at de to kommunikerende parter, f.eks. YouTube og brugeren foran TVet, etablerer en direkte - ofte krypteret - forbindelse med hinanden. Er der kapacitetsproblemer i nettet, kan parterne enes om at sænke hastigheden på deres overførsel.
Det er netop dette princip som udfordres i FG NET-2030 arbejdet. Det er nemlig langt mere effektivt, at det er netværket som fortæller parterne hvad det er muligt at overføre - på samme måde som man f.eks. i vejnettet regulerer hastigheden efter trafikken og kødannelserne.
Som et eksempel forestille man sig hvordan en holografisk transmission kan opdeles i komponenter som definerer de enkelte dele af indholdet, dvs. hvad der repræsenterer front, bagside, hjørner og kanter. Sendes sådan en strøm til et teater hvor der typisk ikke er tilskuere bag scenen, er den del af indholdet som beskriver de bagerste genstande, ikke vigtige for oplevelsen, og netværket kan derfor fjerne dem fra transmissionen, uden at det får betydning for tilskuernes oplevelse i teateret.
Her har vi så balladen. For hvordan kan netværket følge med uden at fortroligheden i kommunikationen brydes?
Svaret er, at der skal bruges helt nye paradigmer for, hvordan information overføres i netværk, og det er præcis det ITU nu kigger på i FG NET-2030. Er man interesseret i at følge denne spændende udvikling kan det gøres kvit og frit - ITU's fokus gruppe er åben for alle. Se mere: https://www.itu.int/en/ITU-T/focusgroups/net2030/Pages/default.aspx
Netflix og YouTube (og sikkert mange andre) har udstyr til proximity på de fleste (hvis ikke alle) udbyderes netværk. Det er meget sjældent, at danskere rammer "datacentre på udenlandske netværk" for de store streamingtjenester. Og derfor HAR hastigheden til din udyder naturligvis betydning.
Her er Netflix' løsning til ISP'er:
https://openconnect.netflix.com/en_gb/
I øvrigt er tykt/tyndt-sugerør jo hele grundpræmissen på Internet. Ingen kan jo garantere, hvad der ligger på bagsiden af næste hop på din rute ;)