kramselund jereminsen

Hjælp til naboerne i IPv6 land

Nå, efter mange år hos den samme udbyder - som jeg har været super glad for - skiftede jeg for nyligt til Gigabit.

Jeg skiftede fordi min gamle udbyder fjernede mine statiske IPv6 adresser. Tror jeg fik det til at jeg har haft de samme IPv6 prefix adresser i 10 år med native IPv6.

Det burde være muligt at få et statisk IPv6 prefix, på samme måde som vi i dag betaler for een IPv4 adresse. Jeg betalte 40kr pr md for eeeeeen fucking IPv4 adresse, men OK det var en super fin udbyder og de havde jo også givet mig statisk IPv6.

Vi er i 2021, og de danske internetudbydere burde lige tage sig sammen og tilbyder IPv6 til deres kunder.

Det jeg mener vi som minimum burde forvente er:

  • IPv6 understøttelse
  • IPv6 DHCPv6 Prefix Delegation, mere nedenfor

Det er ikke slemt, og burde kunne gøres med relativt få enheder, relativt lille konfiguration. Specielt fordi DHCPv6 PD er dynamisk.

Det ville også være fint hvis "statisk IP" var en service med både IPv4 og IPv6 /48 prefix. I den forbindelse var der en som skrev på Twitter:

Så hermed lidt reklame for Kviknet!

Fejlfinding

Den primære grund til at jeg skriver dette indlæg er at jeg har fået IPv6 til at spille hos Gigabit, yay - tak til Baldur Norddahl. Jeg kender Baldur gennem DKNOG men forsøgte at gå via den sædvanlige support, efter at have læst FAQ på hjemmesiden.

Det er sgu skidt når en udbyder i 2021 ikke har vejledning til IPv6 på hjemmesiden, det giver unødig supportkald/emails. Man fristes til at sige, få det nu fixet!

Det lykkedes dog at søge, og finde andre kunder som havde lidt links og bidder af information. Tak til Lauer
IPv6 på EdgeRouterX router ved Gigabit.dk

som indeholdt: dhcpv6-pd rapid-commit enable og prefix-length 48

Cool, og andre har skrevet om OpenBSD med DHCPv6
https://lipidity.com/openbsd/router/

Jeg har således konfigureret min OpenBSD med følgende, beklager pastes, men de er ikke såååå lange.

Routing / forwarding enables i /etc/sysctl.conf

net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1

IPv6 har mange adresser, rigtig mange! Disse uddeles af RIPE NCC i størrelsen /32 /29 til LIR, eksempelvis til LIR dk.zencurity - mit firma - som har fået adresserne 2a06:d380::/29 - alt der starter med disse er "mine".

Gigabit har 2a00:7660::/32 og kan således uddele prefixes til kunder. Det gøres enten manuelt - tungt og besværligt, eller med IPv6 Prefix Delegation https://en.wikipedia.org/wiki/Prefix_delegation

TL;DR man bruger DHCPv6 til dette, og jeg har en konfigurationsfil /etc/dhcpcd.conf:

ipv6only
noipv6rs
duid
persistent
option rapid_commit
allowinterfaces em1
interface em1
  ipv6rs
  iaid 1
  ia_pd 1/::/48 em0/0

Mit eksterne interface er em1 og interne em0. Konfigurationen trækker således et /48 og sætter det på em0, dog som /64.

Router advertisement enables i /etc/sysctl.conf

interface em0

Når der kommer et prefix vil denne sende prefix ud til klienter, IPv6 Stateless Address Auto-Configuration (SLAAC)

Disse daemons, hjælpende ånder, enables sammen med lidt andet til boot med /etc/rc.conf.local

dhcpd_flags="em0"
ntpd_flags="-s"
rad_flags=
sshd_flags=""
syslogd_flags="${syslogd_flags} -u -a /var/unbound/dev/log -a /var/spool/postfix/dev/log"
unbound_flags=""
#pkg_scripts="dhcpcd zeek filebeat"
pkg_scripts=dhcpcd 

Det burde være nok, men det virkede desværre ikke. Jeg sendte requests men fik ikke konfigureret noget.

Endte med at skrive til Gigabit, vente, og så ringe noget tid efter.

Fun facts Neighbor Discovery Protocol

Problemet i dette tilfælde viste sig at være med Neighbor Discovery Protocol (NDP). NDP har samme funktion som Address Resolution Protocol (ARP) i IPv4. Basalt set er den bindeled mellem IP adresser og MAC/hardware adressering.

shito# ndp -an | grep em1
2a00:7660::xxxx                       e6:xx:37:xx:53:yy     em1 23h59m34s S R
2a00:7660::xxxy                       fe:xx:42:xx:c8:yx     em1 35s       R R
2a00:7660::82xx:xxff:feef:xxxx       80:xx:xx:ef:xx:xx     em1 permanent R l
fe80::82ee:73ff:feef:6755%em1        80:xx:73:ef:xx:xx     em1 permanent R l
...

NDP er en del af ICMPv6 - altså ICMP til version 6. Til forskel fra IPv4 hvor firewalls sjældent blander sig i ARP, så er det nødvendigt med firewall regler til ICMPv6!

Gentager, der skal åbnes for bestemte ICMPv6 beskeder ellers får man problemer med NDP og connectivity med IPv6

Det gøres elegant med OpenBSD PF:

pass in on egress inet6 proto icmp6 all \
  icmp6-type { routeradv neighbrsol neighbradv }

Det er så fræk en linie, egress betyder dit eksterne interface og det er en fin liste over de beskeder som skal tillades. Hvis du har en anden type firewall, så er det beskederne med type:

           134    routeradv     Router advertisement
           135    neighbrsol    Neighbor solicitation
           136    neighbradv    Neighbor advertisement

Sidenote: Nu du er igang med at rode med din firewall så er min anbefaling til IPv4 at du tillader 3,4,11,12 -

3 Destination Unreachable
4 Source Quench Message
11 Time Exceeded
12 Parameter Problem Message

Sidenote2: Du bør også lige samtidig checke at din firewall tillader port 53/udp OG 53/tcp. Check også lige at den dumme DNS inspicering er indstillet til store DNS pakker osv osv. Check med https://www.dns-oarc.net/oarc/services/replysizetest
https://dnsflagday.net/2020/

Nå, men Gigabit, nu Wizer sender deres NDP pakker med afsender IPv6 som er en global unicast adresse, ikke en fe80 link local, som man ellers plejer.

Jeg fik en fin forklaring fra Baldur, tilrettet minimal:

Man skal sætte flg. system tuneable: net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 på pfSense - dvs nok de fleste FreeBSD
Her er forklaringen fra https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc: "The solution described below causes IPv6 Neighbor Discovery Neighbor Solicitation messages from non-neighbors to be ignored. This can be re-enabled if required by setting the newly added net.inet6.icmp6.nd6_onlink_ns_rfc4861 sysctl to a non-zero value." "
Der er altså ikke enighed enige om det er kosher at bruge off link adresser i NDP. Det virker med Linux og de fleste "almindelige" wifi routere (dem du kan købe i El-giganten etc).

Min løsning inden jeg fik dette var at overbevise min OpenBSD om at det rent faktisk var et linknet mellem mig og deres routere.

Dette gjorde jeg ved at bruge min MAC adresse til at lave en globalt unik EUI-64 identifier, strækker bare MAC og flipper en bit.

Så min MAC 80:xx:73:ef:xx:xx blev altså til 82xx:73ff:feef:xx, som sammensat med prefix fra Gigabit blev til en enkelt linie i min /etc/hostname.em1:

inet6 alias 2a00:7660::82xx:73FF:FEEF:xxxx 64

Det virkede, for så kunne enhederne finde hinanden med NDP, DHCPv6 fik sit prefix, konfigurationen af netkort internt gik som smurt, og min router advertisement sprøjter /64 ud på lokalnet - som enhederne opfanger og laver til globalt unikke adresser (med privacy extensions).

Easy peasy!

Stats og opråb

Hvorfor nu alt det her besvær?! og hvad skal de stakkels internetudbydere få ud af det, og forbrugerne er sgu da ligeglade!

Vi mangler adresser, punktum. Business case for IPv6 er adressering. Når vi mangler adresserne, som man opdagede i start 1990erne så laver man krumspring. De krumspring inkluderer CIDR, NAT, mere NAT, CGNAT, STUN, TURN, ...
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Det er 10.000vis af kodelinier, flaskehalse, ekstra gøgl - klytkode som PHK måske ville sige.

Hvis man har IPv6 er der langt mindre state i netværket, back to basics - og det som gjorde internet til en success i første omgang. Når vi snakker sikkerhed vil jeg også meget hellere have en god adresseplan med IPv6, ingen NAT, fornuftigt design! Faktisk vil I kunne udnytte mange steder at I starter på en frisk og har NOK adresser.

Min opfordring er at I allesammen undersøger mulighederne for at slå IPv6 til på jeres udstyr og hos jeres ISP!

Jeg har målt over et par dage og ligger omkring 30-45% af mine connections er IPv6. Det er alt fra Netflix, Google services som Youtube og selvfølgelig en masse af mine egne services, egen mailserver med IMAP. Det er fordi så godt som alle enheder på mit netværk hjemme forstår IPv6.

Det betyder at hvis 1 million kunder skal streame over CGNAT skal de allesammen igennem noget udstyr hos udbyderen, der skal håndtere alt - fulde båndbredde i få enheder.

Hvis de samme kunder kunne bruge IPv6 ville udbyderen frit kunne route pakkerne stateless, effektivt, redundant, uden de store problemer.

PS Update 12:00
Jeg glemte sgu da et officielt lydspor til dette indlæg!

Jeg har derfor skyndt mig at søge på Better Late Than Never og blandt dem udvalgt, Better Late Than Never, Magnus Ringblom
https://www.youtube.com/watch?v=kPqMSAdEVOE Det er tilpas afslappet, og vil egne sig godt som baggrund til IPv6 konfiguration :-D

https://open.spotify.com/track/23QxD9s7JyiaU2qrKL4WsI?si=ea257df5f68b4cd8 for dem som har Spotify

Kl 14:18 Addendum ICMPv6

Der er som Benny i kommentarfeltet bemærker, tak Benny, også andre ICMPv6 beskeder man gerne ser bliver sendt videre, det er specielt de første her:

Allow ICMPv6 destination unreach
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 1  
Allow NS/NA/toobig (don't filter it out)
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 2    
Allow timex Time exceeded
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 3    
Allow parameter problem
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 4

Kommentarer (43)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jens Jönsson

Dette blog opslag forklarer meget godt, hvorfor mange udbydere (mig selv incl.) endnu ikke tilbyder IPv6. Det er simpelthen alt for omfattende ifht. slutbrugeren. Fint at 2% af kunderne er eksperter på området, som dig, som kan nørkle med det. Men hvad med de sidste 98% ?

Personligt vil jeg drøn gerne tilbyde IPv6 på vores netværk. Har skam fået tildelt adresserne. Men at skulle supportere slutbrugeren Hr. og Fru Jensen, der skal have det til at virke på en WiFi router til kr. 499,- er altså en gigantisk udfordring, specielt når det er så kringlet, som ovenstående illustrerer.

Så tænker at der producent mæssigt mangler noget, når så meget er så inkompatibelt og ikke virker "ud af boksen". For det er der vi er med IPv4, på trods af CGNAT og andre mystifystiske fikumdik løsninger. Det virker ud af boksen for Hr. og Fru Jensen.

Hvordan kommer vi derhen hvor IPv6 virker ud af boksen ? (Når Baldur, en der må betegnes som ret meget ekspert og du, i samme liga har udfordringer med at få det til at spille).

MVH

Jens, Skywire

  • 15
  • 1
#3 Jacob Pind

Dette blog opslag forklarer meget godt, hvorfor mange udbydere (mig selv incl.) endnu ikke tilbyder IPv6. Det er simpelthen alt for omfattende ifht. slutbrugeren.

Er ikke helt fair Henrik Kramselund har jo selv valgt at bruge det setup han beskriver, da fullrate eksisterre virkede ipv6 jo out of the box uden problemer, og hos kviknet virker det også med deres router, man må som minimum forvent at det virker med det udstyre udbyderen levere hvis det ikke kan fravælges.

CGNAT kommer i vejen for f.eks windows updates, eller teamview, som mener at der må være tale om kommerical brug da der er for mange forbindelse fra samme ip, så helt uden problemer er det ikke at bruge CGNAT.

Vil påstå at det langt henad vejen er mangle på faglig stolthed, at man ikke får det sat op, så rammer hverdagen og der er ikke tid eller bemandning til levere andet end minimal brugbart produkt.

  • 4
  • 1
#5 Benny Amorsen

Så vidt jeg kan se blokerer du packet-too-big både for IPv4 og IPv6. Det ødelægger path-MTU-discovery.

Det er en rigtig dårlig idé.

Helt generelt er det en dårlig idé at blokere ICMP. Man kan blokere echo og echo-reply, hvis man er modstander af ping, men resten af beskederne er vigtige.

ICMP er en simpel protokol og det er over 10 år siden der sidst blev fundet et alvorligt problem som involverede ICMP. Almindelige firewalls or NAT-routere håndterer som hovedregel ICMP korrekt i standardkonfigurationen.

  • 4
  • 0
#6 Palle Due Larsen

Kan du uddybe ?

Jeg har et /48 net hos Wizer (tidl. Gigabit), ligesom Kramse, men jeg ved ikke, hvad jeg skal gøre for at sætte det op på min EdgeRouter og få det til at virke med Windows 10, Chromecast, Raspberry Pi og SqueezeBox. Routeren kunne jeg nok finde ud af, men jeg skal jo også kunne udnytte det. Hvis jeg skal det samme igennem som beskrevet ovenfor og selv finde løsningerne, så vinder sofaen og EM i fodbold.

  • 2
  • 0
#7 Henrik Kramselund Jereminsen Blogger

Benny du har fuldstændigt ret! Ligesom 3,4,11,12 remsen har vi jo en tilsvarende til IPv6 men det fører nok for vidt at komme ind på her.

Men til en start er der ihvertfald starten her, hvor 1-4 er ~lig IPv4 udgaven:

Allow ICMPv6 destination unreach
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 1  
Allow NS/NA/toobig (don't filter it out)
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 2    
Allow timex Time exceeded
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 3    
Allow parameter problem
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 4    
IPv6 ICMP - echo request (128) and echo reply (129)
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 128,129  
IPv6 ICMP - router solicitation (133) and router advertisement (134)
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 133,134  
IPv6 ICMP - neighbour discovery solicitation (135) and advertisement (136)
    $fwcmd6 add pass ipv6-icmp from any to any icmptypes 135,136
  • 1
  • 0
#8 Claus Bruun

Hvis routeren er sat korrekt op med DHCP6 eller SLAC på et fx. /64 subnet af det /48 man har fået tildelt:

Windows 10 virker med det samme.

Al linux (som fx pi) skal have at vide under installation at den skal bruge IPv6 og DHCP. Så virker det også.

I følge nettet understøtter Chromecast ikke rigtig IPv6

Jeg kender ikke detailler omkring Squeezebox, men måske det er det samme som Chromecast (og en masse andre appliances, hvor enten leveradøren er ligeglad med IPv6 eller hvor alderen er ved at trykke).

  • 0
  • 0
#9 Henrik Kramselund Jereminsen Blogger

Du forklarer meget godt selv, hvorfor det er så svært....

Uenig.

  1. Forwarding Jeg angiver sysctl fordi jeg bruger et generelt OS. Enhver router har jo allerede denne indstilling

2a. Jeg bruger OpenBSD som i sagens natur er lidt krakilsk 2b. FreeBSD er også lidt krakilsk og endda skrevet det som Security Advisory 2c. Linux godtager det vist i de fleste tilfælde, ihvertfald som default på flere router platforme 2d. Det er dig som udbyder der indstiller dit udstyr til at sende. Så hvis du kan konfigurere det til IKKE at bruge unicast men link-local i NDP er der heller ikke noget problem

  1. Router advertisement er igen noget jeg konfigurerer på mit generelle OS, enhver router vil have det som default funktion i IPv6 land. Der er ingen konfiguration udover enable.

  2. ICMPv6 beskederne der skal tillades er igen de samme, uændrede i de +20 år jeg har rodet med IPv6. Det må formodes at en IPv6-ready router har dem med.

Jeg tror heller ikke Baldur havde de store problemer, han kendte problemet. I min ende da han pegede på NDP tog det mig vitterligt også kun 10min at finde løsningen. Endda en løsning som nu kan bruges generelt.

TL;DR Hvis du har en CPE du sælger med din forbindelse til dine kunder og selv konfigurerer dit netværk, evt. skriver "Du skal requeste /48" på dit FAQ på din hjemmeside. Så er der klart mindre support.

Jeg kunne være interesseret i at vide hvad prisen er på CGNAT, for det må være noget af en boks efterhånden. Ligeledes hvis du kan fortælle om pre-corona - med mange Zoom osv. Antal connections stigende generelt formoder jeg.

PS FYI Jeg kender Jens og er stor fan af hans arbejde med at udbrede internet! Jens, Du gør det super, og ring hvis du skal have sparring omkring IPv6 :-)

  • 2
  • 1
#10 Baldur Norddahl

Jeg vil lige indskyde at IPv6 bare virker af sig selv for de mest gængse routere, herunder dem vi selv sælger. Man skal med andre ord ikke foretage nogle indstillinger overhovedet. Det er plug and play.

Dem der har problemer med vores setup er de lidt mere avancerede kunder. Typisk er det pfSense eller andre BSD baserede routere. Og det skyldes at BSD har valgt at ignorere NDP pakker fra "off link" adresser og de skriver at de godt ved at dette valg ikke er fuldt RFC complaint.

Jeg er faktisk enig med BSD folkene i at vores NDP pakker ikke er "pæne". Det er desværre ikke mig der har kodet det, men sådan Junipers subscriber management løsning fungerer. Det er svært at lave en sag ud af det hos Juniper, når de bare kan pege på at deres løsning er RFC complaint og at BSD folkene godt ved at BSDs standard indstilling ikke er complaint. Og når det virker fint på langt de fleste routere, der er Linux baserede.

Jeg har dog en plan som vil løse problemet. Lad os se på min IPv6 opsætning hjemme hos mig selv:

Prefix: 2a00:7660:242a::/48

Lan: 2a00:7660:242a::/64

Wan: 2a00:7660:242a:ffff::2/128

Wan gateway: fe80::e65d:37ff:fe84:5317

Jeg har fået tildelt adresserummet 2a00:7660:242a::/48. Bemærk at 242a identificerer mit adresserum og alle kunder har en unik id her. Det mest almindelige er at bruge et mindre adresserum på /64 på LAN siden og der er plads til 65536 sådanne /64 adresserum i en /48. Jeg bruger nummer 0 og derfor er mit LAN blot 2a00:7660:242a::/64, dvs det samme men med /64. Hvis jeg havde et gæstelan, så kunne det være nummer 1 med 2a00:7660:242a:1::/64 og så videre.

På WAN siden har min router fået tildelt 2a00:7660:242a:ffff::2/128. Det er teknisk set lidt frækt da vi bruger en af dine /64 til WAN linket, nummer "ffff" (65535 decimal), men der er rigeligt :-).

Men se så WAN gateway'en. Den har en mærkeligt adresse: fe80::e65d:37ff:fe84:5317. Det er en såkaldt link local adresse og der er ikke noget tilsvarende i IPv4. Det er en link local adresse fordi Juniper routeren i vores ende ikke har en offentlig IP adresse på kundevente links. Det er et såkaldt "family inet6 unnumbered address" i juniper sprog.

Man kunne forvente at vores juniper router så også bruger fe80::e65d:37ff:fe84:5317 til NDP men i stedet bruger den en adresse 2a00:7660::248 som den har hentet fra et loopback interface. Det er så her BSD ikke vil være med.

Et andet problem er at vi ønsker at kunder har muligheden for at konfigurere statisk. DHCP er fint men det er frivilligt hos os. Vi ændrer ikke din IP adresse uden at have aftalt det først. Men folk har problemer med at konfigurere gateway med en link local adresse. Mange routere tillader det simpelthen ikke eller de har et UI hvor der mangler de nødvendige felter.

Jeg ønsker derfor at vores WAN blev:

WAN: 2a00:7660:242a:ffff::2/64

Gateway: 2a00:7660:242a:ffff::1

Det er simpelt og minder om hvad vi kender fra IPv4. Jeg er også sikker på at Juniper i dette tilfælde faktisk vil bruge 2a00:7660:242a:ffff::1 til NDP. Det vil virke også for BSD.

Jeg har det til at fungere 99% i lab. Der er dog en lille routing bug der forhindrer mig i at rulle det ud til kunderne. Jeg regner med at Juniper kan indse at dette er en bug, som de er nødt til at fixe. De har tidligere sagt at de ikke forstår hvad der er galt med at bruge link-local løsningen, men at de er enige i at mit nye forslag også burde fungere.

Det tager dog altid nogle kræfter at bokse med Juniper, så det er et projekt til efter sommerferien.

  • 6
  • 0
#11 Yoel Caspersen Blogger

Personligt vil jeg drøn gerne tilbyde IPv6 på vores netværk. Har skam fået tildelt adresserne. Men at skulle supportere slutbrugeren Hr. og Fru Jensen, der skal have det til at virke på en WiFi router til kr. 499,- er altså en gigantisk udfordring, specielt når det er så kringlet, som ovenstående illustrerer.

Men hvorfor skal det være en alt-eller-intet-løsning? Hr. og Fru Jensen vil jo aldrig bede dig om at hjælpe med IPv6-opsætningen, og de klarer sig fint uden. Hvis de køber en router af dig, kan du endda lave opsætningen for dem, så IPv6 bare virker, uden at de vil have nogen som helst idé om det.

I praksis er IPv6 vigtigt for internetudbyderen, fordi det sparer kapacitet på internetudbyderens Carrier Grade NAT-routere - og for kunder med IPv6 er det ret så store datamængder, der flyttes til IPv6, da næsten alle streaming services efterhånden kører IPv6.

At du så også kan gøre nogle nørder glade i processen, er bare et plus :)

  • 8
  • 0
#13 Uffe R. B. Andersen

Her til formiddag blæste Wizer fiberen igennem det føringsrør, som i et par måneder har været klar i mit bryggers. Man må sige, at din timing er perfekt (du kan nok fortælle en NTP-joke!).

Mit setup i dag er en Palo Alto PA-220 og en OPNsense, hvor PA-220'eren terminerer min IPv4-trafik og OPNsense er tunnel endpoint for en IPv6-over-IPv4-tunnel med en /48, hvoraf en /52 routes til PA-220'eren. Desværre understøtter PAN-OS ikke DHCPv6 PD, så jeg slipper ikke for OPNsense'n, men hvis det dur på pfSense, så gør det også på OPNsense.

Så når der kommer nogen og sætter noget i enden af fiberen, så har du - igen - klædt mig godt på, til at tage udfordringen op. Tak :-)

  • 0
  • 0
#15 Yoel Caspersen Blogger

Jeg er desværre låst til Fibia for nu, men forhåbenligt bliver det fibernet snart åbnet for andre udbydere.

Hos Kviknet havde vi egentlig planlagt at lancere IPv6 på Fibias net i først marts, siden i maj, men desværre er åbningen af Fibias net blevet udskudt yderligere pga. nogle tekniske problemer i Fibias ende. Vi har ikke fået noget tidsestimat, men vi håber på, det ikke varer længe endnu.

  • 6
  • 0
#16 Thomas Jensen
  • 1
  • 0
#17 Søren Steinmetz

Her den 30/6 er der et service vindue hos en del af Fibia, grundet udskiftning af udstyr i deres "server" rum (gætter på hopved router rummet i Svinninge)

Man siger der altid er håb, så lad os håbe det betyder udskiftning af udstyr til noget der kan snakke IPv6.

  • 1
  • 0
#19 Christian Nobel

Hvis man skal have en fast IP adresse, så tilbyder det fleste en fast (servertildelt) IP adresse som i alt optager 1 (en) IP adresse.

Hos f.eks. TDC og Nianet får man i stedet et /30 netværk, hvorved det optages fire adresser - en til netværket, en til selve adressen, en til gateway, og en til broadcast.

Hvad er rationalet i at gøre det på den måde, for som jeg ser det får man stadig til syvende og sidst det samme ud af det, nemlig en fast IP som alligevel kræver NAT indadtil?

Jeg er helt på det rene med at det er en helt anden historie hvis man har et /29, da man så i praksis har fem brugbare IP adresser.

  • 3
  • 0
#20 Michael Hansen

Har IPv6 fra kviknet (egen router(opnsense)), det virker fint, på alle mine maskiner uden problemer, Linux/BSD/Win/selv smart TV etc (selvf. på eget netværk, og jo reelt bare noget Linux af en art), virker alt sammen out of the box, så kan heller ikke se hvorfor windows skulle udgøre noget specielt problem her?

Mig bekendt er det største issue Android, i et rent IPv6 only miljø, ikke iOS/Win.

IPv6 forbrug ligger på ca 55-60% her, da de fleste af de sites jeg bruger mest tid/data på, allerede er IPv6 enabled (youtube/netflix etc), det der trækker mest ned er VPN til arbejdet, der er IPv4 only, men pusher på, for at alt nyt der sættes op, som minimum skal være dual stack udefra, og har mine kampe om dualstack/ren IPv6 internt, men det er en stor europæisk virksomhed, så det er lidt op ad bakke, selvom man sidder med der hvor beslutningerne bliver taget.

  • 1
  • 0
#21 Michael Hansen

Glemte at skrive, at selv MS arbejder på at køre ren IPv6 internt i deres netværk: https://teamarin.net/2019/04/03/microsoft-works-toward-ipv6-only-single-... spændene artikel om de udfordringer det har givet dem, jeg har været på en del cisco conferencer hvor Veronika McKillop har præsenteret (inden hun startede ved MS), de kan anbefales på cisco live, hun er sgu en guru indenfor IPv6 :)

  • 1
  • 0
#23 Brian Jensen

Hjemme har jeg IPv6, dvs på min "router" som er en linux box og jeg er stoppet med at announce dynamisk ipv6 til klienterne. Jeg har et par services jeg exponerer som har en ipv6 addresse så logisk nok bruger jeg IPv6, men i meget brgrænset omfang.

Flere steder på nettet er jeg stødt på sider som ikke fungerer på grund af IPv6. Der kan være mange grunde til det og indrømmet mange fungerer uden problemer. En del fungerer fx ikke fordi nogle ikke opsætter deres 4xA records korrekt og de opdager det ikke, da de kun har IPv4.

Men for mange har IPv6 bare ikke prioritet og det samme gælder for mig, Hr og Fru. Jensen. Brugerne er mest interesseret i at internettet bare virker, nede på bundlinien er vi pt. der, hvor livet uden IPv6 er nemmere, særligt når jeg læser denne blogpost.

Sikkerhedsmæssigt er jeg også der hvor jeg ikke har lyst til at eksponere alle devices på mit netværk med en public IPv6 adresse, internet-of-shit devices skal firewalles, fordi ens "Samsung IOT køleskab" leaker ens email/passwd credentials, fordi der er en bug i firmwaren. For mange non-IT experts er CGNAT en gave fra himlen fordi exponering bare er så meget mindre udfra et security perspektiv.

  • 1
  • 0
#24 Yoel Caspersen Blogger

Hvad er rationalet i at gøre det på den måde, for som jeg ser det får man stadig til syvende og sidst det samme ud af det, nemlig en fast IP som alligevel kræver NAT indadtil?

Årsagen er sandsynligvis, at det fra et teknisk synspunkt er væsentligt nemmere at levere et /30-net end at skulle dele fx et /28 eller /26 mellem flere kunder.

Løsningen med /30 kan nemlig laves ret simpelt, da der kan være sammenfald mellem layer 2 (kundens VLAN) og layer 3 (subnettet med de 4 IP-adresser).

Det understøttes af alle typer netværksudstyr, og den enkelte kunde vil ikke umiddelbart mærke noget til andre kunders eksistens.

Den åbenlyse ulempe ved /30 pr. kunde er selvfølgelig, at man spilder 3 IP-adresser pr. kunde. En renere løsning ville være /31, hvor man kun spilder 1 IP-adresse pr. kunde, men ældre netværkshardware vil have problemer med at håndtere /31.

Hvis man skal spare på IP-adresserne (og det skal alle andre end de store gamle udbydere), er man nødt til at lade flere kunder dele et IP scope, fx et /28, hvor disse kunder så har fælles gateway.

Men det er komplekst at lade flere kunder dele samme IP scope, især hvis man vil sikre sig, at de ikke forstyrrer hinanden. I den traditionelle netværksverden ender man med et subscriber-setup som det, Baldur anvender til Wizers kunder, typisk med en eller anden form for DHCP snooping.

  • 2
  • 0
#25 Jens Jönsson

Jeg kunne være interesseret i at vide hvad prisen er på CGNAT, for det må være noget af en boks efterhånden.

Vi bruger et par bokse til opgaven, og prisen for dem er nu ikke noget der skriger til himlen. Vi oplever ikke rigtigt nogen udfordringer, det virker faktisk rigtigt fornuftigt, selv under corona, hvor vi så en stigning i trafik på ca. 40-60% i dagstimerne (er ved at normalisere sig). Det var i øvrigt ikke noget, vores netværk ikke kunne klare. Trafikken i dagstimerne er normalt (før corona) normalt ikke særligt høj i fht. f.eks. primetime, som er søndag, hvor man tydeligt kan se at familien er samlet over streaming af en god film.

Vær opmærksom at jeg ikke er tilhænger af NAT/CGNAT osv. Må bare konstatere at fra det forretningsmæssige synspunkt, virker IPv4 rigtigt fornuftigt, f.eks. er CPEere sjældent et problem. Det er plugNplay, selv for de fleste også Hr. og Fru Jensen.

I praksis er IPv6 vigtigt for internetudbyderen, fordi det sparer kapacitet på internetudbyderens Carrier Grade NAT-routere - og for kunder med IPv6 er det ret så store datamængder, der flyttes til IPv6, da næsten alle streaming services efterhånden kører IPv6.

At du så også kan gøre nogle nørder glade i processen, er bare et plus :)

Vi har ikke så mange nørd kunder, en af de få er Claus, som læser med her (Hej Claus!), og det er skam ikke fordi jeg ikke vil gøre ham/ dem glade.

Og mht. CGNAT routeren, så se ovenfor....

Hr. og Fru Jensen vil jo aldrig bede dig om at hjælpe med IPv6-opsætningen, og de klarer sig fint uden. Hvis de køber en router af dig, kan du endda lave opsætningen for dem, så IPv6 bare virker, uden at de vil have nogen som helst idé om det.

Hvis vi ikke skal lave IPv6 til Hr. og Fru Jensen, og få deres udstyr til at bruge IPv6 til Netflix/Youtube osv. så ved jeg altså slet ikke, hvad vi skal lave IPv6 til ? Udfordringen er at vi ikke laver nødvendigvis kan lave det "gratis" og det er desværre lidt svær at sælge til Hr. og Fru Jensen, specielt fordi de aner 0 om IPv6 og hvad de skal bruge det til.

Men det hjælper nok når vi får flere kunder. Kan se at det nye XGSPON udstyr vi kigger på, kan en hel del provisionering, og der kan det være at vi kan få de løsninger vi sælger sammen med Internet til at spille mere automatisk ifht. IPv6.

  • 2
  • 0
#29 Baldur Norddahl

"For mange non-IT experts er CGNAT en gave fra himlen fordi exponering bare er så meget mindre udfra et security perspektiv."

For en mindre udbyder som os, er dette et kæmpe plus.

Hvad mener du med det? En CGNAT er optimalt sat op som full cone nat, det vil sige med mindst mulig sikkerhed. Formålet er at hjælpe diverse hole punching tekniker bedst muligt på vej og samtidig minimere mængden af state på CGNAT serveren.

Firewallen på kundens CPE er derimod præcis den samme på IPv4 og IPv6 og den blokkere alt indgående medmindre der specifikt er åbnet for det.

  • 3
  • 1
#30 Baldur Norddahl

Vær opmærksom at jeg ikke er tilhænger af NAT/CGNAT osv. Må bare konstatere at fra det forretningsmæssige synspunkt, virker IPv4 rigtigt fornuftigt, f.eks. er CPEere sjældent et problem. Det er plugNplay, selv for de fleste også Hr. og Fru Jensen.

Det er også plugNplay med IPv6. Det er længe siden at alle CPE'er fik styr på det. Der er et certificeringsprogram for IPv6 support, som producenter af CPE'er holder sig til for at kunne sælge til de store drenge.

På vores netværk er det stort set kun folk der leger med pfSense og BSD der har lidt udfordringer med IPv6. Og dem har du et kæmpe konkurrencehandicap overfor uden IPv6 da der er stort sammenfald mellem interessen for netværk, IPv6 og dem der bruger pfSense eller BSD.

Worst case hos os er at din router ikke henter en IPv6 opsætning og du må så finde dig i samme IPv4 opsætning som hos andre. Der er simpelthen ikke nogen ulemper for kunden ved at vi tilbyder IPv6.

  • 5
  • 0
#31 Yoel Caspersen Blogger

Hvis de har IPv4 adresser nok. Hvorfor benytter de så NAT på deres eget net, hvilket jo betyder at man ikke kan nå en server der står på et net leveret af Fibia, hvis man ex kommer fra et TDCnet leveret internet?

Det er et åbent spørgsmål, om Fibia har IPv4-adresser nok - umiddelbart ser det ud som om, de har ca. 300.000 IP-adresser - og med 160.000 kunder betyder det, at de i hvert fald ikke har nok til at levere et /30 pr. kunde. Måske kan de med en optimal udnyttelse af adresserne akkurat levere en enkelt IP-adresse pr. kunde, hvis de klemmer ballerne sammen, men det er nok en del af forklaringen på, at de åbenbart kører CGN.

Mon ikke, man kan tilkøbe en dedikeret IPv4-adresse hos Fibia, hvis man vil?

  • 1
  • 0
#33 Baldur Norddahl

Det kan man, mod et passende, månedligt vederlag.

Jeg må indrømme at sådan er det også hos os. For at kunne tilbyde billigst mulig internet er der ikke råd til at forære en resource væk, der konstant stiger i pris. På den anden side, så er en fast offentlig IPv4 adresse et sted hvor man som ISP kan tjene lidt ekstra og stort set alle tager mere end hvad det egentlig koster.

Eftersom at knaphed på IPv4 er kommet for at blive, så er eneste svar IPv6. Alt det IPv6 du kan bruge følger gratis med.

Det er også ved at blive mere anvendeligt til mange formål. Du kan eksempelvis tjekke dine kameraer derhjemme via din mobiltelefon fra 3 over IPv6. Og på den måde spare udgiften til en offentlig IPv4.

  • 2
  • 0
#34 Morten Christensen

Mon ikke, man kan tilkøbe en dedikeret IPv4-adresse hos Fibia, hvis man vil

Jeg har en dhcp-tildelt offentlig IPv4-adresse hos Fibia. Det krævede 5 min. telefonopkald til supporten. Derudover betaler jeg ikke ekstra. Samtidig blev fibermodemet sat i bridge-mode. IPv4-adressen ændres (kun) hver gang jeg skifter mac-adresse på routeren.

Jeg skifter alligevel til nogen kvikkere, når monopolet engang bliver brudt.

  • 1
  • 0
#35 Benny Amorsen

En renere løsning ville være /31, hvor man kun spilder 1 IP-adresse pr. kunde, men ældre netværkshardware vil have problemer med at håndtere /31.

Desværre ikke kun ældre. MikroTik understøtter f.eks. ikke RFC3021, men kan i nogle tilfælde bringes til at virke alligevel.

Den rene løsning på alt det hedder 4rd (RFC7600 https://en.wikipedia.org/wiki/IPv4_Residual_Deployment), hvor man fysisk kører rent IPv6 på netværket. IPv4 oversættes til IPv6 i udbyderens udstyr, og tilbage til IPv4 i kundens udstyr.

Det er desværre endnu ringere understøttet end RFC3021.

  • 1
  • 0
#37 Søren Steinmetz

Jeg har en IP hos Fibia, mener det er 10-15kr/md den koster, og det kører som en drøm.

Burde have 300/300 nu men i tests får jeg 320/320 så klager ikke.

Skulle jeg have en anke er det kvaliteten af deres strømforsyning til modemet, den er nu stået af 2 gange så jeg har skiftet til en af bedre kvalitet selv. (standard 12V brik, overvejede næsten at lave et udtag på min UPS så den kunne sidde direkte derpå ;) )

Prikker dem stadig fra tid til anden om IPv6, desværre uden held til nu.

  • 0
  • 0
#38 Yoel Caspersen Blogger

Jeg er åbenbart beta-kunde hos hiper over energifyn/fibias fiber.

Om knap en måned skal jeg i gang med at få en opnsense til at køre på vlan 101 og ipv6.

Vi forventer også at åbne for de første testkunder på Energi Fyns og Fibias net inden for de næste ugers tid - vi skulle have været oppe at køre i foråret, men desværre løb Fibia ind i en række tekniske problemer, som har gjort, at det først netop nu er ved at blive muligt at komme i gang.

  • 1
  • 0
#41 Leif Neland

Hvordan kommer man i betragtning som testkunde?

Måske fordi jeg på facebook en gang om måneden har spurgt EnergiFyn om de snart får IPv6, og hvornår de er klar til at åbne for mere moderne udbydere på deres net. (Så de vil nok gerne af med mig ...)

Måske fordi jeg har skrevet mig op som interesseret i et tilbud når de er klar hos hiper, fastspeed og hvem jeg ellers kunne.

PS: Det har jeg ikke kunnet gøre hos kviknet; det ville jeg hellere :-(

  • 0
  • 0
#43 Leif Neland

Efter et par tyvstarter, hvor jeg fik en dato, der ikke kunne holde og jeg måtte aflyse opsigelsen hos EnergiFyn, og jeg kører nu knap 1Gb fra Hiper. Knap er nok fordi min OPNsense på en "Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (4 cores)" er lidt underdimensioneret.

Jeg fik sat vlan101 på, og så kom det op og køre ved 11-tiden, efter at EnergiFyn hev stikket kl 08:03.

Efter lidt chat med support fik jeg min faste ipv4, og sat en ptr på den. Mit /48 reverse er sat til gratisdns, der så videredelegerer en /64 til min OPNsense, da jeg så kan lave reverse dns lidt hurtigere end at skulle logge på gratisdns. Men måske skulle jeg lave den til en hidden primær og lade gratisdns være sekundær DNS.

Efter at have åbnet for ICMP til det interne net, får jeg nu en 20/20 score på ipv6-test.com ;-)

Og jeg kan åbne for ipv6-adgang til de hosts indenfor, jeg ønsker.

  • 1
  • 0
Log ind eller Opret konto for at kommentere