yoel caspersen blog bloghoved

Elastiske IP-adresser i metermål

Af 14

I dag skal det handle om, hvordan vi leverer en dedikeret, offentlig IP-adresse til de af vores kunder, som er koblet op gennem YouSees antennestik - også kendt som coax-nettet.

Vi ved, at cirka 10 % af vores kunder har brug for en offentlig IP-adresse, og det er derfor nødvendigt at have en løsning, når kunden efterspørger dette - og det skal helst være en løsning, der tager hensyn til den globale mangel på offentlige IPv4-adresser.

Layer 2 vs layer 3

Allerførst lidt teori. Den berømte og berygtede OSI-model inddeler vores netværk i flere layers eller lag, hvoraf de tre første er de vigtigste.

Layer 1 er det fysiske lag - det handler om kobberkabler, fiberkabler lignende. Fysisk udstyr, lys og elektriske forbindelser.

Layer 2 er det såkaldte link layer, og en helt almindelig, "dum" kontorswitch er et glimrende eksempel på et layer 2 domain. Hvis man tilslutter en computer til en port, kan den uhindret kommunikere med en computer på en anden port, stort set som om de to computere var direkte forbundet med et kabel.

På layer 2 foregår kommunikationen ved hjælp af MAC-adresser, og de enkelte computere holder styr på de andre computeres MAC-adresser i den såkaldte ARP-tabel, hvor man mapper en IP-adresse til den underliggende MAC-adresse.

Alle computere i et layer 2 domain holder styr på hinandens MAC-adresser, og det betyder, at det fungerer bedst i mindre skala - typisk sætter man grænsen ved 200 - 300 enheder i det samme netværk.

Det skyldes både, at baggrundsstøjen i form af broadcasts m.v. stiger eksponentielt med antallet af tilsluttede computere, samt at computere i det samme layer 2 domain kan forstyrre hinanden og sniffe på hinandens trafik.

Når vi alligevel kan koble mere end 200 computere på internettet skyldes det, at man i næsten alle layer 2-netværk har en layer 3-gateway.

En layer 3-gateway, også kaldet en router, arbejder med IP-adresser og router trafikken det rigtige sted hen baseret på IP-adresser i stedet for MAC-adresser.

Det er den funktion, der gør internettet mulig - i stedet for at have et enkelt, kæmpestort netværk med en masse baggrundsstøj, er internettet i stedet sammensat af en hel masse mindre netværk, og routere sørger for at bringe trafikken fra det ene netværk til det næste, indtil trafikken når til den rigtige destination.

Coax æder flere IP-adresser end DSL

I vores tilfælde er det oftest TDC, der ejer den sidste strækning af netværket ud til kunden, og vi skal derfor udveksle kundens trafik med TDC på et såkaldt Point of Interconnect, også kaldet en POI-port.

På eBSA, som er det, der bruges til vores DSL-kunder, modtager vi trafikken som layer 2. Det betyder, at trafikken er delt op i en masse separate layer 2-netværk ved hjælp af VLAN. I hvert VLAN eksisterer der lige præcis to enheder - kundens router og vores egen.

Illustration: Privatfoto

Det er en utrolig fleksibel løsning. Vi kan selv styre DHCP, og vi kan selv tildele de IP-adresser til kunden, som vi har lyst til, både på IPv4 og IPv6.

Ved at samle flere VLANs på de enkelte porte i vores routere, kan vi uddele offentlige IP-adresser drypvis. En IP-adresse til en kunde i Aalborg, den næste IP-adresse til en kunde i Odense, den næste IP-adresse til en kunde i Tønder osv.

Derved får vi en optimal udnyttelse af de offentlige IP-adresser, vi har til rådighed, da vi kun skal sætte nogle få, store IP-blokke af til de kunder, der skal have offentlige IP-adresser.

På layer 2 er det vores eget udstyr, der agerer default gateway for den enkelte kunde, og vi kan se alle broadcasts, MAC-adresser og lignende, som lever på nettet mellem os og kunden.

Coax-nettet fungerer væsentligt anderledes - her får vi trafikken leveret på layer 3.

Det betyder, at vi ikke har nogen direkte forbindelse til den enkelte kunde. I stedet router YouSee den udgående trafik til en router hos os, mens vi router den indgående trafik til en router hos YouSee.

Illustration: Yoel Caspersen

Derudover er coax-nettet i dag delt op i ca. 80 separate, geografisk fordelte netværk, og YouSee er i fuld gang med at øge dette antal voldsomt.

De er nemlig i gang med at opgradere deres coax-netværk fra DOCSIS 3.0 til DOCSIS 3.1, og i den forbindelse splitter man de enkelte netværk op i endnu flere, separate enheder, der geografisk kommer tættere på den enkelte kunde.

Hvert netværk skal have sin egen IP-blok, man kan dele ud til kunderne, og YouSee har fastsat, at den minimale størrelse på en sådan blok skal være /27, dvs. 32 IP-adresser.

Lidt hovedregning siger, at vi som udbyder derfor skal sætte 80 x 32 = 2.560 IP-adresser af, hvis vi vil dække hele landet i dag, mens behovet i fremtiden vil vokse til minimum det dobbelte, og sandsynligvis endnu mere - og det er endda før, den første kunde er kommet på.

Uanset hvor mange kunder, vi får, vil vi konstant have et stort spild af IP-adresser, da vi er nødt til at tilføje nye blokke, når en blok bliver brugt op.

Derudover tager YouSee sig fyrsteligt betalt for at ændre i opsætningen, når vi tilføjer en blok, så vi er nødt til at planlægge et godt stykke ud i fremtiden, når vi sætter IP-adresser af til coax-nettet.

Det betyder, at mange blokke vil stå ubrugte hen i længere tid, indtil der kommer kunder på.

Løsningen: Elastiske IP-adresser

Ved at bruge Carrier Grade NAT kan vi løse dette problem. I stedet for at sætte blokke af offentlige IP-adresser af til coax-nettet, sætter vi i stedet blokke af CGN-adresser af.

CGN-adresser er IP-adresser i området 100.64.0.0 - 100.127.255.255.

Det er en slags private IP-adresser, som bruges af internetudbydere - de er ikke offentlige IP-adresser, og kan derfor genbruges af flere udbydere, men samtidig er der ikke overlap mellem CGN-adresser og de almindelige private IP-adresser, der bruges af kunderne på deres lokalnetværk.

I sidste indlæg gennemgik jeg, hvordan vi i vores CGN-setup anvender CGN-routere i par af 2 maskiner, der kan tage over for hinanden i tilfælde af nedbrud.

Vi kan derfor sætte en blok af offentlige IP-adresser af på ydersiden af disse CGN-routere og lave en 1:1 NAT mellem en offentlig IP-adresse på ydersiden og en CGN-adresse på indersiden.

Lad os tage et eksempel:

IP-adressen 185.107.12.100 mappes til CGN-adressen 100.64.64.10, der tilhører kunden Jens Hansen, der bor i Odense.

Illustration: Yoel Caspersen

Jens Hansen vil gerne opstille en web-server på sin nye coax-forbindelse, og han sætter den til at lytte på port 80, som er standard for HTTP.

Så sætter han port forwarding op på sin coax-router, således at forespørgsler til 100.64.64.10 på port 80 forwardes til hans webserver på lokalnetværket.

Når Kviknet modtager en HTTP-forespørgsel på den offentlige IP-adresse 185.107.12.100 på port 80, sendes den ind til Jens Hansens CGN-adresse 100.64.64.10 på samme port.

Det samme gælder forespørgsler til en hvilken som helst anden port - så længe forespørgslen sendes til 185.107.12.100, sendes den videre ind til Jens Hansen med uændret portnummer.

På samme måde omskriver vi udgående trafik fra Jens Hansen - vi ændrer afsender-adressen til 185.107.12.100, men vi bibeholder afsenderportnummeret i forespørgslen, da Jens Hansen ikke deler IP-adressen 185.107.12.100 med andre kunder, men har den for sig selv.

Derved opnår Jens Hansen i praksis samme effekt, som hvis han havde haft den offentlige IP-adresse 185.107.12.100 siddende direkte på ydersiden af sin coax-router - og Kviknet sparer en masse offentlige IP-adresser.

Det er i øvrigt præcis samme koncept som Amazon anvender i deres EC2 cloud, og de har valgt at kalde konceptet for Elastic IP.

Analogien er da også ligefor - i stedet for at sætte en IP-blok med 32 IP-adresser af til en enkelt kunde eller to, som kun skal bruge en enkelt IP-adresse hver, strækker vi i stedet blokken ud over mange kunder på flere lokationer, så vi udnytter blokken optimalt.

Hos Amazon får man således ikke en offentlig IP-adresse direkte på sin server - men man kan 1:1-mappe en offentlig IP-adresse til serverens private IP-adresse, så det ikke gør nogen forskel.

Hvis det er godt nok til Amazon, går det nok også an hos os.

IPv6, tak!

Når YouSee ikke giver os en layer 2-forbindelse til den enkelte kunde, er det så meget vigtigere, at de lukker op for IPv6.

Det har de på trods af utallige opfordringer ikke gjort endnu.

Status er derfor, pr. marts 2017, at man som coax-kunde på YouSees netværk ikke får IPv6 - uanset om udbyderen hedder YouSee, Kviknet eller noget helt tredie.

Det ændrer sig nok en dag, når YouSee kommer ind i fremtiden - men indtil da skal man have DSL eller fiber, hvis man vil have IPv6.

Relateret indhold

Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Baldur Norddahl

Der bør lægges pres på YouSee for at implementere IPv6. Det er en del af DOCSIS så der er ingen undskyldning. Med IPv6 vil AO få mulighed for at levere IPv4 via IPv6 teknologier som NAT64, 464XLAT, DS-Lite og MAP. Mangel på IPv6 er dermed en urimelig forhindring for at AO kan arbejde sig udenom de begrænsninger et layer 3 POI giver.

Modsat IPv4 er der ingen mangel på IPv6 adresser. Derfor er der ingen udfordringer ved at tildele adresserum af rimelig størrelse med offentlige IPv6 adresser til hver CMTS, sådan som YouSee selv gør med IPv4. Det er også en urimelig begrænsning, når YouSee udnytter at de har rigeligt med adresser, men ikke giver konkurrenterne mulighed for i det mindste at matche med IPv6 adresser.

  • 13
  • 0
#2 Baldur Norddahl

Her er en uddybning af hvordan IPv6 kan hjælpe AO (alternativ operatør) med at levere på YouSee Coax. Jeg beskriver to teknologier, NAT64 og DS-Lite da de er nemmest at forstå, men specielt MAP er også en spændende mulighed.

Lad os antage at en ny operatør melder sig. Vi kalder dem Kviknet6. Kviknet6 kører et IPv6 only netværk. De har ingen IPv4 i backbonen og kunderne får ikke IPv4 på traditionel vis. Kviknet6 har dog fået tildelt 1024 IPv4 adresser af RIPE ligesom alle andre. Disse IPv4 adresser bruges til NAT for sites der ikke har IPv6 support og til de nævnte 10% kunder der stiller krav om fast IPv4 adresse.

Kviknet6 meddeler YouSee at de ikke har 80 IPv4 subnets de kan tildele. Men Kviknet6 har 80 (og mange flere) IPv6 subnets. Hvert område får som standard tildelt et IPv6 /40 subnet. Det er nok til 256 kunder der hver skal have et /48 subnet. Da Kviknet6 fik tildelt et /29 IPv6 subnet af RIPE, så er der plads til 2048 tildelinger af størrelse /40.

Opgaven for YouSee er at lave en IPv6 only opsætning til Kviknet6. Der er simpelthen ikke noget IPv4.

Kviknet6's kunder kan naturligvis tilgå sites med IPv6 support direkte. Det vil blandt andet sige diverse streaming tjenester som Netflix, alt fra Google og Facebook. Målt i trafikmængde er det en væsentlig del der kører uden om NAT servere med mere, og hvor Kviknet6s kunder har den "ægte" og direkte internet forbindelse.

Der er dog en del sites der stadig lever i stenalderen. Eksempelvis dr.dk. Der er flere løsninger på dette og det bedste er at YouSee slet ikke behøver at involvere sig i det. Det er en sag mellem kunden og Kviknet6.

Den første løsning er NAT64 / DNS64. Det fungerer ved at Kviknet6 har givet kunderne en DNS server (kaldet DNS64) som oversætter IPv4 adresser til IPv6. Når kundens browser skal i forbindelse med dr.dk, så spørger computeren DNS serveren om IP adressen på dr.dk. Da der ikke er nogen IPv6 adresse for dr.dk har vi et problem. DNS64 har et system så at IPv4 adresser kan konverteres til IPv6 adresser efter et snedigt system, så at trafik til disse adresser går til den tilhørende NAT64 server. Kundens computer får altså en kunstigt genereret IPv6 adresse for dr.dk. Denne IPv6 adresse indeholder IPv4 adressen som en del af adressen. Det lader sig gøre da IPV6 adresser er på 128 bits og IPv4 adresser kun er på 32 bits. Man lader simpelthen de sidste 32 bits i IPv6 adressen være lig med IPv4 adressen.

Kunderne vil opleve et internet som engang i fremtiden hvor alt er IPv6. Kunderne kommunikere kun IPv6 med omverden. YouSee skal derfor kun transportere IPv6 pakker og kan glemme alt om IPv4. YouSee skal ikke vide noget om Kviknet6s NAT64, det er helt transparent for dem.

Ulempen ved NAT64 er at nogle kunder måske har noget udstyr der ikke forstår IPv6. Det kan særligt være "IoT" dimser, eksempelvis kameraer og LED pærer der kan styres fra en app etc.

Den anden løsning jeg vil beskrive er DS-Lite. Igen er det en IPv6 only løsning set fra YouSees synsvinkel. I stedet for at køre NAT64, så konfigurerer man kundens CPE router med adressen på en DS-Lite server. Kundens CPE router laver herefter en tunnel til DS-Lite serveren. IPv4 trafik bliver sendt via denne tunnel. Tunnelen er IPv6 på "ydersiden" og transporterer IPv4 på "indersiden".

Konfigurationen foregår via DHCPv6. Det er blot en option i DHCP pakken hvor IPv6 adressen på DS-Lite serveren angives, samt oplysninger om IPv4 adresse etc.

Med DS-Lite kan Kviknet6 100% selv styre IPv4 opsætningen på kundens router. Trafikken sendes via en tunnel, så YouSee ser den aldrig og skal ikke konfigurere deres netværk efter det.

Det eneste ekstra som man kunne bede YouSee om er at tillade en MTU på nogle få bytes ekstra, da det vil muliggøre at IPv4 pakkerne kan sendes med normal MTU 1500 bytes uden fragmentering. Pakkerne bliver en smule større end normalt da der vil være både en ydre IPv6 tunnel header og den indre oprindelige IPv4 header.

Jeg kender ikke den CPE router som YouSee tvinger Kviknet6 til at benytte. Men det er ekstremt sandsynligt at de har support for DS-Lite. Det har stort set alle routere i dag.

Med DS-Lite kan Kviknet6 levere en løsning som opleves identisk med den DSL løsning som Kviknet leverer i dag. Der vil være mulighed både for at køre med private og offentlige IPv4 adresser, sådan som udbyderen nu selv vælger det.

  • 10
  • 0
#3 Peter Glad

Måske nogen kan hjælpe mig med at forstå det her...

Jens har en private space 100.64.0.0 adresse, der bliver NAT'ed til en offentlig pool. Jens portforwarder port 80 til sin webserver. Hvordan ved CGN routeren der NAT'er til den offentlige IP at Jens port forwarder på sin private IP adresse derhjemme?

Skal han styre sin port forward over en kundeportal som taler med CGN routeren?

  • 2
  • 0
#4 Yoel Caspersen Blogger

Hvordan ved CGN routeren der NAT'er til den offentlige IP at Jens port forwarder på sin private IP adresse derhjemme?

Meget relevant spørgsmål. Når vi har sat Jens op til 1:1 NAT i vores system, bliver alle forespørgsler til den offentlige IP-adresse sendt videre til Jens' CGN-adresse med samme portnummer, som de kom ind på.

CGN-routeren ved således ikke hvorvidt Jens har sat port forwarding op i sin coax-router eller ej. Den ved blot, at den skal sende alt videre til Jens' CGN-adresse med uændret portnummer - uanset om der er tale om HTTP, SSH eller noget helt tredie.

Jeg har opdateret blog-indlægget, så det fremstår tydeligere.

  • 4
  • 0
#5 Yoel Caspersen Blogger

Ulempen ved NAT64 er at nogle kunder måske har noget udstyr der ikke forstår IPv6. Det kan særligt være "IoT" dimser, eksempelvis kameraer og LED pærer der kan styres fra en app etc.

... eller legacy software, eller VPN-klienter på brugerens arbejds-PC, der er sat op til at køre med IPv4-adresser og ikke med host names.

NAT64 er en af de løsninger, vi på et meget tidligt tidspunkt fravalgte på grund af de mange frustrationer, der ville ramme kundeservice som konsekvens.

DS-Lite er i den sammenhæng en langt pænere løsning, men vi fravalgte den på grund af kravet om, at det skulle supporteres af CPE'en. Vi har kunder, der af uransagelige årsager gerne vil køre videre med deres egen gaming-router, der lyser blåt og har antenner, der stritter i alle retninger, eller en gammel D-Link-fætter, som alle PC'erne i forvejen er koblet op på.

Som en stor, etableret udbyder kunne man sandsynligvis slippe afsted med at påføre sine brugere ekstra besvær, men som en ny, mindre udbyder er man pr. definition bagud på point fra starten. Derfor har vi fra starten valgt at køre dual stack, hvor det kan lade sig gøre, så overgangen til IPv6 bliver så smertefri for brugerne som muligt.

  • 4
  • 0
#6 Baldur Norddahl

Vi har kunder, der af uransagelige årsager gerne vil køre videre med deres egen gaming-router

Har i da fået lov til at erstatte YouSees tvungne coax router? Hvis ikke, så står den og agerer DS-Lite gateway, således at kundens egen (ekstra) router kan køre en helt normal opsætning. Der er ikke nogen grund til at gøre det samme på DSL, men man kunne egentlig godt, da kunderne også her er tvungne til at bruge ISPens router som gateway på grund af vectoring og whitelist af CPE.

Jeg vil tro at man kan finde en opsætning der fremstår som om ISP routeren var i transparent / modem mode.

Vi er endvidere der hvor stort set alle routere har support for DS-Lite. Problemet er folk der vil køre en hjemmebygget løsning på Linux, BSD eller en firewall til professionelt brug. På vores net ville det være et problem på fiber, hvor vi kører med egentlige modems, der ikke har intelligensen til at agere gateway.

  • 2
  • 0
#7 Michael Cederberg

Hvorfor ikke bare lave en tunnel fra kundens coax router til jeres router? I princippet kunne man direkte wrappe IP6 pakken i en IP4 pakke med fast afsender og modtager (kundens router og jeres router). Hvad er max MTU for YouSee's netværk?

  • 0
  • 1
#8 Yoel Caspersen Blogger

Har i da fået lov til at erstatte YouSees tvungne coax router? Hvis ikke, så står den og agerer DS-Lite gateway, således at kundens egen (ekstra) router kan køre en helt normal opsætning.

Vi er bundet til YouSees coax-router indtil videre, og vi har ingen adgang til at provisionere den. Måske kan DS-Lite konfigureres på coax-routeren via DHCP, men jeg gætter på, at de har deaktiveret den del. Intentionen fra YouSee er helt klart, at vi ikke skal ændre på opsætningen af coax-routeren.

Når vi har fravalgt DS-Lite, er det på DSL-platformen, da vi her kan køre full dual stack og derved have et mere kundevenligt setup, inkl. transparente bridges i form af rene modems uden indbygget router.

  • 3
  • 0
#9 Yoel Caspersen Blogger

Hvorfor ikke bare lave en tunnel fra kundens coax router til jeres router?

Det er den slags tricks, der kunne laves, hvis YouSees netværk udelukkende kørte IPv4 på grund af en teknisk begrænsning.

Imidlertid er YouSees løsning langt hen ad vejen farvet af, at de dybest set ikke har lyst til at åbne deres netværk og heller ikke er blevet tvunget til at gøre det ordentligt. Derfor kan vi ikke provisionere routeren selv, og mit bud er, at 6-in-4- og 6rd-tunneler m.v. er udelukket af samme årsag.

Det virker også grundlæggende forkert at skulle lave tunneler i et spritnyt netværk - Huawei, som leverer YouSees DOCSIS 3.1-netværk, har helt sikkert styr på native IPv6, så det er kun et spørgsmål om YouSee har viljen til at bede Huawei aktivere det for dem.

  • 6
  • 0
#10 Thomas Hedberg

Jeg har en NTP server kørende herhjemme der modtager 4000+ NTP forespørgsler i sekundet som så forwardes af min firewall ind til min NTP server. Det tager rimeligt hårdt på min firewall (faktisk i en grad hvor den genstarter spontant hvis belastningen kommer op på 10.000+ over en længere periode.

Hvordan sikrer I jer imod denne type belastninger på jeres CGN router? eller er jeres udstyr bare i en anden klasse som slet ikke har problemer med den slags belastninger?

  • 1
  • 0
#13 Yoel Caspersen Blogger

Hvordan sikrer I jer imod denne type belastninger på jeres CGN router? eller er jeres udstyr bare i en anden klasse som slet ikke har problemer med den slags belastninger?

Vores udstyr er Linux-servere, som vi tuner til formålet.

Lige netop NTP-forespørgsler af den slags du beskriver er slemme, for UDP er pr. definition stateless - og når man sender UDP gennem en stateful firewall, vil den være nødt til at danne en virtuel session, som timer ud efter x antal minutter uden trafik.

Det er nok det samme, du oplever på din egen firewall. Hukommelsen bliver fyldt op af lingering sessions, der ikke når at time ud hurtigt nok.

Vi holder løbende øje med antallet af sessioner på vores CGN-routere og justerer hukommelsesforbruget efter dem, og lige netop for 1:1 NAT eksperimenterer vi også med at lave en stateless NAT, så vi slet ikke behøver at tracke forbindelserne. Når det bliver implementeret i produktion, forsvinder issuet med tracking af UDP-forbindelser.

  • 3
  • 0
#14 Henrik Størner

Som en der sidder på YouSee's coax-net er det virkelig lærerigt at læse Yoel's blogindlæg om teknikken bag - og alle de sjove krumpspring, som TDC præsterer for at undgå at slippe konkurrenterne ind på "deres" netværk.

Jeg har selv oplevet hvordan en TDC tekniker afbrød min forbindelse ude i det lille skab i vejen, simpelt hen fordi der på hans YouSee kunde-liste ikke stod noget om at jeg var koblet op via en alternativ operatør. De kan mange små julelege ...

Og manglende IPv6 support er simpelt hen for ringe her i 2017.

  • 2
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen