Dette indlæg er alene udtryk for skribentens egen holdning.

IPv6 med egen CPE

Af Yoel Caspersen16. juni 2018 kl. 22:3665
Artiklen er ældre end 30 dage

Hvis du ligesom Henrik Kramshøj insisterer på at anvende din egen CPE i stedet for den, din internetudbyder udleverer, og er du samtidig kunde hos Kviknet, har du muligvis oplevet nogle udfordringer med at få DHCPv6 til at virke.

Den situation stod Stéphane Guedon for nylig i, og vores kundeservice havde desværre begrænsede muligheder for at debugge på hans udstyr, da han bruger en CPE, han selv har bygget vha. OpenBSD.

Vi kunne blot konstatere, at selv om vores BNG i form af en ZTE-router modtog DHCPv6-forespørgslen, blev den ikke sendt videre til vores DHCPv6-servere, og derfor fik han ikke noget svar.

Konklusionen var, at der måtte være noget i hans DHCPv6-forespørgsel, der gjorde, at ZTE's relay agent ikke ville acceptere den - hvilket var lidt spøjst, da forespørgsler fra Inteno-CPE'er glider lige igennem, som de skal.

Artiklen fortsætter efter annoncen

Hvis bjerget ikke vil komme til Muhammad, må Muhammad komme til bjerget - en modifikation af CPE'ens DHCPv6-forespørgsel virkede umiddelbart som en mere farbar vej end en større reverse engineering af ZTE's firmware.

Stéphane fik derfor en PCAP-fil med en fungerende DHCPv6 solicit-forespørgsel fra en Inteno-CPE, og han gik straks i gang med at hacke sin DHCPv6-klient.

Det kom der et ganske interessant blogindlæg ud af.

65 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
65
21. februar kl. 15:30

Hej,

Er der nogen, der har fået IPv6 til at virke på Fortigate?

Jeg har sat de indstillinger, der nævnes fra supporten på min gate.

Jeg kører herefter lige en tcpdump for at se efter ipv6 pakker. Der er intet at komme efter.

Har nogen udfærdiget en guide til det?

Jeg får leveret Kviknet via Waoo, har en fast ipv4 adresse i forvejen. Kan være det er det, der driller her?

63
3. januar kl. 13:21

...ser nu ud til at virke!

Jeg har ikke fiflet med problemet i nogle måneder, men affandt mig med at konfigurere en static route.

Men, efter et par opdateringer af UDM Pro enheden (nu 1.11), og Network controller (nu 7.0.15), har jeg ikke mistet default route.

Jeg har ikke sniffet(!), så jeg har ikke set om noget er anderledes; om jeg er kommet på den nye gateway løsning.

Så, et forsigtigt "Tak for indsatsen" herfra.

62
30. december 2021 kl. 22:09

Kan du komme ind på lidt omkring løsningen?

Enkelte kunder har oplevet problemer med at få IPv6 til at virke vha. SLAAC + DHCPv6 på vores hardware-BNG'er.

Vi har eksperimenteret med at flytte disse kunder over på en Linux-baseret BNG med statisk IPv6-opsætning i stedet - det har p.t. kørt test i et par måneder, og det ser umiddelbart ud til at fungere fint. Vores næste mål er at gøre Linux-opsætningen dynamisk, så den også fungerer med DHCPv6.

Vores overvejelser går lige nu på, om vi skal køre med en BNG-løsning fra Juniper, eller om vi skal videreudvikle på vores Linux-BNG i stedet.

Fordelen ved Juniper-løsningen er, at den skalerer godt, og at der er tale om kendt teknologi, som vi relativt nemt kan finde teknikere, der kan arbejde med.

Ulempen er, at der er tale om en blackbox-løsning, hvor man er 100 % afhængig af, at Juniper kan løse eventuelle fejl, man støder på. Samtidig er der tale om et dynamisk setup, hvor kundens forbindelse oprettes første gang, man modtager en DHCP-pakke. Hvis BNG'en genstartes, vil kunderne ikke komme online med det samme, men skal først vente på, at DHCP-leasen timer ud, så CPE'en forsøger at forny den. Det er ikke nødvendigvis et problem, men det er ikke specielt elegant.

Fordelen ved Linux-løsningen er, at fejlsøgning faktisk er muligt - man kan tcpdump'e på de enkelte kunders VLAN-interfaces, hvis man skal debugge. Derudover kan vi på Linux shape trafikken på en mere optimal måde, end hvad der er muligt på Juniper-løsningen (hvilket i sidste ende kan give en bedre netkvalitet).

Ulempen ved Linux-løsningen er skaleringen, samt at man som ISP skal bruge teknikere med et indgående kendskab til netværksstakken i Linux-kernen.

61
30. december 2021 kl. 21:25

Kan du komme ind på lidt omkring løsningen?

60
29. december 2021 kl. 17:56

Jeg har fået hjælp af Kviknet til at få IPv6 kørende igen - retfærdigvis skal det nævnes at det var relativt kort efter jeg skrev herinde, og ikke først nu.

59
30. november 2021 kl. 15:08

Samme oplevelse, men er dog i dialog med support. Dog uden nogen form for IPv6 - sender jeg en RS (via rtsol) får jeg så intet svar. Så ikke helt samme situation.

  1. rtsol: checking if vmx3 is ready...
  2. rtsol: vmx3 is ready
  3. rtsol: set timer for vmx3 to 0s
  4. rtsol: New timer is 0s
  5. rtsol: timer expiration on vmx3, state = 1
  6. rtsol: send RS on vmx3, whose state is 2
  7. rtsol: set timer for vmx3 to 4s
  8. rtsol: New timer is 4s
  9. rtsol: rtmsg type 2, len=240
  10. rtsol: New timer is 2s
  11. rtsol: timer expiration on vmx3, state = 2
  12. rtsol: send RS on vmx3, whose state is 2
  13. rtsol: set timer for vmx3 to 4s
  14. rtsol: New timer is 4s

57
23. november 2021 kl. 21:52

Jeg har desværre også oplevet problemer med IPv6 den sidste ca. 1½ måned hvor jeg pludselig mistede default route efter det har kørt fint i lang tid. Jeg har været i dialog med deres support, men uden der rigtigt er kommet det store resultatet ud af det - de mener ikke at have ændret på noget omkring det tidspunkt.

Om det er samme problem skal jeg ikke gøre mig klog på, men timingen lyder rigtigt (omkring første uge af oktober ish hvor jeg lagde mærke til det).

Så vidt jeg har debugget mig frem til sender deres router/BNG ikke længere unsolicited route advertisements løbende, men udelukkende solicited (hvor CPE'en eksplicit spørger efter en route). Så jeg oplever konkret at IPv6 virker fint de første x minutter (afhængig af ra-lifetime) efter boot af routeren , hvorefter default routen udløber. Min router (Ubuquiti EdgeRouter) sender kun route solicitation ved boot/start af interface, og forventer derefter der løbende kommer unsolicited route advertisements for at holde den kørende (Vist en helt "efter bogen" forventning). (Jeg har ikke pcaps fra tidligere gemt til at underbygge et, men jeg antager at der tidligere er udsendt unsoclited RA's løbende - det er eneste logiske forklaring jeg er kommet på)

Jeg har gaffatape-fixet det ved at lave en statisk default route på routeren, og det har sådan set virket helt fint indtil videre - og indtil de ændrer IP eller lign. på routeren :)

set protocols static route6 '::/0' next-hop 'fe80::32:1' interface eth0

Jeg sidder på EWII's net med Ubuquiti EdgeRouter.

56
23. november 2021 kl. 19:59

Det er med stor ærgelse jeg må konstatere, at min tidligere problemfri oplevelse er ... gået over. Jeg kan se, at jeg nu har den oplevelse, som Rasmus B havde for omkring et år siden - nu står der bare 'searching' under DHCPv6 klienten - uanset hvad jeg prøver, uanset hvad jeg sætter IAPD værdier til, oma.

Min gamle rb750gr3 fra sidste år, blev taget ned og lagt i en kasse i en virkende config - den virker heller ikke mere. Det nye setup på en rb4011 har virker indtil for en 1½ måneds tid siden - og så er jeg IPv6-less igen. Jeg har ikke prøvet alt, men jeg har prøvet meget.

Nogen der kører Mikrotik RouterOS på Norlys/PON, som kan byde ind?

55
23. september 2021 kl. 21:17

Tjaa, hul igennem - i 15 minutter!

Jeg oplever nøjagtig det samme som du beskriver på UI foraet, på en pfSense. Jeg er i stand til at deklarerer fe80::26:1 som en static route og så mister klienterne ikke længere forbindelsen. Selve pfSense boksen har dog ingen ipv6 forbindelse. Er på TDC Fibernet.

54
23. september 2021 kl. 16:05

Tjaa, hul igennem - i 15 minutter!

Og, der er ganske stor forskel på USG og UDM/UDMP (network controller kører som container i Unifi OS).

Men, faktisk kører UDMP "out of the box" med Unifi OS 1.10 og Network Controller 6.4.54 på Kviknet med IPv6.

Desværre kun i 15 min. stints hjemme hos mig i Norlys land...

https://community.ui.com/questions/My-IPv6-troubles-warning-loong-story/ed04038c-4e52-4b30-a4bd-70f32d92a603

Noget nyt om ny DHCPv6 Relay agent?

/Kim Bjørn

53
6. januar 2021 kl. 21:23

Lige en opfølgning på IPv6 med Unifi USG på Kviknet. Det lykkedes for mig i aftes at få hul igennem. :-)

Til interesserede fandt jeg det sidste information til løsningen her: https://community.ui.com/questions/WAN-DHCPv6-options/8174cfee-1c23-4c8b-947f-11542400e83b#answer/d2fe8e90-6171-4afe-b18c-2b08d301bb27Det ændrer både ia-na og ia-pd til 1 i USG'ens konfigurationsscript, hvorefter IPv6 kan sættes op via Unifi Controller.

Det ser ud til, at Unifi devices er lidt anderledes end EdgeRouter-serien i forhold til interface-navne, hvorfor løsningen i #24 ikke virker på USG. Til gengæld vil jeg tro, at dette også virker på UDM og UDM Pro.

Jeg har endnu ikke gennemført en firmware update på routeren efter ændringen, så jeg kan ikke svare på, om ændringen overlever en sådan.

52
6. januar 2021 kl. 21:07

Hej Yoel, af ren nysgerrighed; vil du ikke smidt en post her når i har udskiftet jeres ZTE DHCPv6 realay agent? Det kunne være sjovt at se om min FortiGate firewall vil spise IPv6 med PD så. Fortinet selv mener nemlig ikke at FortiGaten gør noget forkert så jeg er gådt lidt i stå så længe at i er på ZTE'en :-)

På forhånd tak.

51
17. december 2020 kl. 11:25

Jeg har givet metoden i #24 et forsøg på min USG. Det retter ganske rigtigt na til 1 i Perl-scriptet, men jeg får stadig ikke en IPv6-adresse på USG'en. Jeg har også kaldt 'configure' og kørt de øvrige kommandoer i #24 inkl. 'commit ; save', men det ændrer ikke umiddelbart noget. Jeg er på ingen måde ekspert i hverken IPv6 eller USG'ens CLI, så det er bestemt muligt, at jeg har overset noget, der for andre forekommer indlysende. Hvis jeg får lidt nørdetid til overs, kigger jeg gerne ind i det igen. IPv6 var en af de primære årsager til, at jeg droppede arbejdsgiveraftalen med Eniig/Norlys/Stofa og skiftede til Kviknet, så det skal komme til at virke på et tidspunkt.

Ang. speedtest, så havde jeg på dag 1 hos Kviknet meget ringe performance. Under 200 Mb/s down, men ~910 Mb/s up med pc'en direkte i fiberboksen (her fik jeg i øvrigt en IPv6-adresse) til Kviknets egen server. Dagen efter havde det dog rettet sig, så jeg fik ca. 915 Mb/s begge veje gennem egen router mv. Jeg har ikke gravet i, hvad der er sket, men det er der sikkert en god forklaring på. Latency har jeg ikke sammenlignet grundigt nok til at kommentere på. Men alt dette er som sådan også lidt off topic for denne tråd. ;-)

Og tak, Yoel, for imponerende hurtigt svar den anden dag. 3 minutter må siges at være en meget fin svartid for off band support.

50
17. december 2020 kl. 10:59

Jeg blev Kviknet kunde for 1 måned siden, hvor jeg skiftede fra Eniig/Norlys. Jeg bruger en Edgerouter 4 og via metoden omtalt i #24 kom IPv6 op at køre. ER-4 kører version 2.9

Jeg vil tro metoden også virker på en USG. Det ligner at Perl scriptet er det samme - "na 0" er default i scriptet på den USG enhed, jeg har liggende.

Jeg har sat SLAAC op for alle LAN / WLAN netværk. Fra alle netværk er status ok på https://ipv6-test.com/

Mine AP's er AC-Lite og Nano-HD. Det ene AP er forbundet til min "master" switch via en anden switch. Jeg har ingen problemer med hverken Chromecast eller Spotify enheder. Spotify enhederne er kablede, da deres WiFI support er elendig. For WiFi har jeg ændret sendestyrken for 2.4GHz (low/auto) og 5GHz (High), samt øget bredden i 5Ghz. SSID's er de samme på 2.4 og 5Ghz

Hastighedsmæssigt (speedtest.net mod Tåstrup) har jeg målt 870Mbit download en sen nattetime via LAN. For en router med firewalls enabled burde det være godkendt - max skulle være 928Mbit for Ethernet? Upload var noget lavere. Pingtiden var 7 ms.

På de hverdage, hvor jeg har testet, ligger tallene oftest mellem 650-750 Mbit begge veje

48
15. december 2020 kl. 20:36

Jeg er også netop kommet på Kviknet på Norlys fiber men får ingen IPv6-adresse på min Unifi USG.

Yoel, kom I nærmere en løsning på at udfase ZTE DHCPv6 relay agent? Hvis det nu løser sig selv i næste uge, er der jo ingen grund til at begynde at lave diverse krumspring.

47
14. december 2020 kl. 18:21

Ohøj! Nogen med IPv6 erfaringer på Norlys fiber endnu - eller kvalificerede bud på tidshorisont?

Har benyttet en Unifi Dream Machine Pro med fast IP hos Kviknet på Norlys fiber i nogle måneder nu, og tænker på at slippe for fast-IP gebyret (benyttes primært til VPN).

46
13. november 2020 kl. 23:05

er der nogle der har et bud på en opsætning til en Cisco ASA ?

45
12. november 2020 kl. 20:25

EdgeRouter ER5 PoE med et UniFi AP AC Pro powered fra den ene port. UniFi Controller 6.0.28 på en Raspberry Pi, som i øvrigt også kører PiHole for netværket. Klient er en Win10 Pro som fint får IPv6 adresse på LAN men ikke på WLAN. Android-dimser og IOS dimser får også kun IPv4 adresse.

44
12. november 2020 kl. 18:21

Det virker fint med EdgeRouter og mit lidt ældre UniFi AP Pro AP. Har ikke lavet nogen ændringer, det virkede bare. Er dit AP forbundet direkte til din router? Hvad tester du med som klient? Jeg brugte bare min iPhone.

43
12. november 2020 kl. 18:09

Nu fik jeg også hul igennem med min EdgeRouter på de kablede klienter vha. tricket med at ændre scriptet som beskrevet i #24. Men jeg kæmper stadig med at få WiFi klienterne med. Er der nogen der har fået UniFi AP til virke med IPv6 uden USG? Nogen steder er der nævnt at man skal slå "Block LAN to WLAN Multicast and Broadcast Data" fra i UniFi Controller. Men det er slået fra på alle SSID'er. Nogen der har fundet en løsning?

42
11. november 2020 kl. 15:24

Tusind tak Ronni, det var ganske enkelt problemet. Det spiller nu!

41
11. november 2020 kl. 14:44

Det ligner at du ikke er i configure mode. Prøv at skrive "configure". Så skulle "~$" gerne blive til !"#". Se her:https://i.imgur.com/0k9bskc.png

Jeg forsøger ihærdigt at få min FortiGate firewall til at fungere på IPv6. Det er åbenbart en større udfordring. Jeg skal nok skrive når jeg (forhåbenligt) finder en løsning. :)

39
7. november 2020 kl. 17:35

Der vil jeg tro du skal høre support, for det var det eneste jeg gjorde. Sørg om ikke andet for at du har været inde i 'System' -> 'Packages' og opgraderet til nyeste Stable.

Gem evt din config hhv. en backup til et sdkort etc., og derefter også i en 'export terse' som du hiver over i en tekst. Prøv at nulstille config på den, og se om det virker bagefter. Deres standard config ændrer sig med tiden, og bliver bedre og bedre - især deres ipv6 default ruleset er ret godt, og det giver nogen gange mening at flytte ens egne customizations over i en ny default config, hvor en hw-feature f.eks. kører hurtigere.

38
5. november 2020 kl. 17:56

Hej med Jer,</p>
<p>Jeg er også - i dag - blevet ny Kviknet kunde, og kører native IPv6 fremfor gennem HE (eller, den beholder jeg nu også ;-).</p>
<p>Jeg kunne i RouterOS blot bede om 'IPv6 prefix' + 'Address' i DHCPv6 klienten, og angive at jeg ville have prefixet i en pool - det spillede bare efter første sekund. Angive at alle lokale indadvendte IF skulle tage et prefix fra poolen, eui64 + ra, og vupti - afsted afsted. Dejlig oplevelse.

Har du en kopi af opsætningen ? Jeg har også prøvet at bede om IPv6 prefix + Address i RouterOS, men der sker ikke mere end searching.

Jeg ved ikke om det er fordi det er via Ewiis infrastruktur.

37
22. oktober 2020 kl. 16:20

Efter en del bøvlen frem og tilbage, er det her hvad der endte med at få hul igennem med IPv6 på OPNsense med kviknet:

Lad os antage vi fik: 2a06:4004:8888::/48 tildelt (eksempel)

  1. Interfaces -> <navn på wan interfacet>: IPv6 Configuration Type: DHCPv6
  2. På samme side, længere nede under "DHCPv6 client configuration":
  3. Configuration Mode: Advanced
  4. Interface Statement -> Send Options: ia-pd 1, ia-na 1
  5. Identity Association:
  6. Check "Non-Temporary Address Allocation":
  7. id-assoc na ID: 1
  8. Address IPv6-address: ::/0
  9. Check "Prefix Delegation"
  10. id-assoc pd ID: 1
  11. Prefix IPV6-Prefix: 48
  12.  
  13. Interfaces -> <navn på lan interface>: IPv6 Configuration Type: Static IPv6
  14. Static IPv6 configuration:
  15. IPv6 address: 2a06:4004:8888:a::1/64 ( erstat med et af 64 subnetsne under /48 prefixet)
  16. Bruger :000a i det her eksempel til mit klient LAN, kan findes via <a href="http://www.gestioip.net/cgi-bin/subnet_calculator.cgi">http://www.gestioip.net/cgi-bin/subnet_calculator.cgi</a>
  17. Vælg IPv6 -> IP Adress: 2a06:4004:8888::/48
  18. Vælg Prefix Length 48 (65,536 /64s), tryk calculate
  19. Nederst på siden under "subnet-level I", tryk more, og find "65,536 networks /64", klik på den.
  20. Der er nu kommet et link under "subnet-level I", (2a06:4004:8888::/64 - 2a06:4004:8888:ffff::/64), klik der.
  21. Under "Number of networks to display" vælg 16 eller hvor mange du nu har brug for
  22. IPv6 Upstream Gateway: Auto-detect
  23.  
  24. Services:
  25. Router Advertisements -> <navn på LAN interface>:
  26. Router Advertisements: Stateless
  27. Advertise Default Gateway: Checked
  28. Advertise Routes:
  29. Prefix: 2a06:4004:8888:a::1
  30. Length: 64

Eller som screenshots her: https://imgur.com/a/jHchkbN

36
19. oktober 2020 kl. 11:02

Vi har omkring 5000 ipv4 adresser. Det er nok til 1 million kunder, eller cirka halvdelen af markedet i Danmark for internet på en fast adresse. Hvis vi løber tør og må købe flere adresser, så er det ikke på grund af CGN kunderne men på grund af salg af fast ipv4. Det vil sige traditionel brug af ipv4.

Prisen på ipv4 presses fra begge ender. En højere pris øger udbuddet, idet flere får lyst til at rydde op og sælge. Samtidig får en høj pris flere til at investere i CGN eller andre løsninger, der sparer på adresserne og dermed reducere efterspørgslen.

Gigabit er et godt eksempel. Ved 10 USD per adresse købte vi en adresse til alle brugere. Ved 20 USD opgav vi og implementerede CGN.

Bare 1% af de mulige cirka 3 milliarder ipv4 adresser er nok til at alle på jorden kan få CGN.

35
19. oktober 2020 kl. 08:07

Men ved 90% ipv6 kan der være ti gange så mange brugere per ipv4 adresse på din CGN. Da kun 10% af trafikken i så fald skal igennem CGN.

Ja, måske.

Der er to faktorer, der afgør, hvor mange brugere man kan have bag samme IP-adresse:

  1. Antallet af samtidige sessions pr. bruger (der er lidt under 65.000 mulige sessioner pr. IP-adresse ved den mest åbne form for NAT)
  2. Antallet af klager fra kunderne

Den sidste faktor er det største problem. Tag nu fx Sony, der insisterer på at blokere delte IP-adresser i deres PlayStation Network - og samtidig insisterer på ikke at bruge IPv6.

Så længe der er nogle enkelte, populære services, der er IPv4 only, vil det være svært at øge antallet af brugere pr. IP-adresse - også selv om størstedelen af brugernes øvrige trafik er IPv6.

34
19. oktober 2020 kl. 00:06

Angående markedsværdi af ipv4 allokeringer, så er det en svær en. Årsagen til at prisen ikke for længst er gået helt igennem loftet er at der eksisterer enorme ikke udnyttet og dårligt udnyttet puljer derude. Specielt har amerikanerne været meget rundhåndet med deres tildelinger. Det er højst halvdelen af adresserne der reelt er i brug.

Jeg tror ikke prisen vil være særlig høj hvis det kun er til CGN brug. Prisen drives af efterspørgsel til traditionel brug. Hvis prisen bliver for høj, så finder de folk ud af de alligevel ikke har brug for så mange adresser. Det har holdt prisen relativ stabil i mange år.

33
18. oktober 2020 kl. 23:57

Der kommer til at gå meget lang tid, før vi rammer det tipping point. Selv hvis vi opnår 90 % penetration på IPv6, er det ikke nok til at vi kan slukke for IPv4, og dermed vil der stadig være behov for IPv4 til hosting og Carrier Grade NAT.

Men ved 90% ipv6 kan der være ti gange så mange brugere per ipv4 adresse på din CGN. Da kun 10% af trafikken i så fald skal igennem CGN.

Derfor er målet på kort sigt ikke at lukke ned for ipv4 men at få så meget trafik som muligt over på ipv6.

Heldigvis er der allerede mange tunge indholdsleverandører der tilbyder ipv6. Google, Netflix, Akamai etc.

32
17. oktober 2020 kl. 17:30

Puha - IPv4 bliver ikke billigere i anvendelige allokeringer. :-/ De bliver vel mere og mere værd indtil et tipping point, og så ...

Nu skal man være meget forsigtig med at spå om fremtiden, men her er min spådom:

Der kommer til at gå meget lang tid, før vi rammer det tipping point. Selv hvis vi opnår 90 % penetration på IPv6, er det ikke nok til at vi kan slukke for IPv4, og dermed vil der stadig være behov for IPv4 til hosting og Carrier Grade NAT. Og i takt med at en stadig større andel af jordens befolkning kommer på internettet, vil det understøtte behovet for IPv4.

Det siges, at når frisøren eller taxachaufføren anbefaler en bestemt investering, er det på tide at komme ud af den, fordi et kursdyk er nært forestående - og hvis det også gælder i denne case, vil det glæde mig, for en udfasning af IPv4 kunne løse mange problemer. Men jeg vil vove pelsen og påstå, at en investering i IPv4-adresser er en ualmindeligt god investering, både på den korte og på den mellemlange bane.

30
16. oktober 2020 kl. 18:11

Jeg vil klart anbefale alle der er interesserede i IPv6, at tage Hurricane Electrics IPv6 "certificering" - den giver en super intro/primer til IPv6 - og man kan komme op at køre med IPv6 inden Kviknet kommer forbi (over TDC). Når de så dukker op, så er du forberedt til at hoppe lige på og nyde det uden-om tunnel. :-)

Og, hvis du mister lysten til IPv6 inden du når i mål, så ved du, at det ikke skal være en driver for valget af ISP :-)

28
16. oktober 2020 kl. 16:56

Jeg kører RouterOS version 6.47.4, på en Hex; https://mikrotik.com/product/RB750Gr3

Hvis det Mikrotik forgiver at gøre faktisk er effektueret, så er det samme software, compilet til forskellige hardware platforme i deres routerboards. Jeg vil med udgangspunkt i det tro, at ~alle Mikrotik routere giver samme oplevelse.

God idé med oversigt - det kan måske hjælpe nogle videre. Jeg er bare glad for, at den del gik problemfrit. :-)

Puha - IPv4 bliver ikke billigere i anvendelige allokeringer. :-/ De bliver vel mere og mere værd indtil et tipping point, og så ...

27
16. oktober 2020 kl. 14:28

Jeg kunne i RouterOS blot bede om 'IPv6 prefix' + 'Address' i DHCPv6 klienten, og angive at jeg ville have prefixet i en pool - det spillede bare efter første sekund. Angive at alle lokale indadvendte IF skulle tage et prefix fra poolen, eui64 + ra, og vupti - afsted afsted. Dejlig oplevelse.

Godt at høre - det kan være, vi skulle samle alle erfaringerne omkring IPv6 på vores website. Hvad er det for en Mikrotik-model du kører?

@Yoel, hvordan ser det ud med net-kapacitet til de nye kunder? Det lyder til der er en stor tilstrømning til butikken.

Indtil videre ser det fint ud - men ja, der er kommet ganske mange kunder til på det sidste. Vi har fx været nødt til at indkøbe ekstra IPv4-adresser, da vores nuværende puljer så småt er ved at løbe tør.

26
16. oktober 2020 kl. 14:19

Hej med Jer,

Jeg er også - i dag - blevet ny Kviknet kunde, og kører native IPv6 fremfor gennem HE (eller, den beholder jeg nu også ;-).

Jeg kunne i RouterOS blot bede om 'IPv6 prefix' + 'Address' i DHCPv6 klienten, og angive at jeg ville have prefixet i en pool - det spillede bare efter første sekund. Angive at alle lokale indadvendte IF skulle tage et prefix fra poolen, eui64 + ra, og vupti - afsted afsted. Dejlig oplevelse.

@Yoel, hvordan ser det ud med net-kapacitet til de nye kunder? Det lyder til der er en stor tilstrømning til butikken.

25
15. oktober 2020 kl. 18:23

Tak Dennis Glindhart for tippet!

Det virker for mig på en EdgeRouter X v1.10.11.

Jeg var dog nødt til at sætte "Identity Association for Prefix Delegation" til 1 - mit tidligere setup med 0 virkede ikke. I praksis et er det nemt at rette - bare brug "dhcpv6-pd pd 1" som i Dennis' eksempel.

24
8. oktober 2020 kl. 21:02

Hej Anders + andre der har Kviknet og ønsker at bruge egen CPE.

Jeg er lige blevet kunde hos Kviknet og har ligeledes forsøgt mig med at få det til at virke med en Ubiquiti edgerouter - og det er faktisk lykkedes mig at komme igennem uden at skulle bruge specielle klienter.

Den option der ser ud til at gøre udslaget er IAID for NA (Non-temporary address) skal have værdien 1 (istedet for 0 som vist er default i de fleste DHCP-klienter).

Det burde være muligt at indstille i de fleste DHCP-klienter uden det store.

Specifikt på en EdgeRouter (vyatta baseret) eksiterer den option dog ikke i mangement-laget hvor den er hardcodet til id-assoc na 0, men man kan snyde lidt ved at replace na 0 med na 1 i scriptet der generer dhcp-config'en. (Testst på EdgeRouter firmware v 2.0)

$ sudo sed -i 's/na 0/na 1/g' /opt/vyatta/sbin/dhcpv6-pd-client.pl

Derefter er det bare at fyre de normale PD-settings af og commit'e så config'en bliver regenereret.

set interfaces ethernet eth0 dhcpv6-pd pd 1 prefix-length 48

set interfaces ethernet eth0 dhcpv6-pd pd 1 interface switch0 prefix-id ':1'

set interfaces ethernet eth0 dhcpv6-pd pd 1 interface switch0 host-address '::1'

set interfaces ethernet eth0 dhcpv6-pd pd 1 interface switch0 service slaac

Håber det kan hjælpe :)

23
22. juni 2019 kl. 11:26

Noget nyt mht. at understøtte IPV6 med egen router?

Har brugt en del timer på at grave i de obskure DHCP options men er slet ikke sikker på andre klienter understøtter dem alle.

Skiftede til jer fra fullrate pga. den elendige router de leverede men der virkede IPV6 i det mindste med en ganske almindelig Ubiquiti edgerouter.

20
21. juni 2018 kl. 08:13

Positivt. Må jeg prøve i aften...

Succes :) - Ser ud til det er fikset.

Men der er forskelle i konfigurationerne i de forskellige CMTS'er. På et tidspunkt kunne der ikke routes dns forespørgsler til TDC Sveriges nameservere fra min forbindelse. Support kunne ikke se problemet, for det virkede fint hos dem... Lang dag :(

14
18. juni 2018 kl. 18:13

Er der noget nyt om IPv6 på YouSee coaxen? Jeg savner den...!

Det er fortsat på TDC's roadmap under "Ønsker til produktudvikling" i form af et generelt layer 2-produkt. TDC kommer næppe til at tilbyde IPv6 selv, men det er et stort ønske fra branchen at få layer 2-adgang til kunderne og har været det fra dag 1, og layer 2-adgang vil givetvis gøre det muligt at levere IPv6.

Så svaret er: Når TDC en dag holder op med at obstruere adgangen til coax-nettet for konkurrenterne, får vi mulighed for at tilbyde IPv6.

Desværre kan vi se, at TDC for tiden sætter forhindringer op som aldrig før, og vi er jævnligt nødt til at klage til Erhvervsstyrelsen. Før eller siden ender det i en anmeldelse til KFST (konkurrencemyndighederne), for det er på tide, der bliver sat en stopper for TDC's chikane af de alternative operatører.

12
18. juni 2018 kl. 11:19

Er der noget nyt om IPv6 på YouSee coaxen? Jeg savner den...!

11
18. juni 2018 kl. 01:02

Hos Gigabit sælger vi også Inteno og bruger ZTE i backbonen. Nu virker DHCPv6 med ZTE og Inteno. Hvis vi et øjeblik lader som om det ikke gjorde, så har vi langt større mulighed for at påvirke Inteno end ZTE.

Der er altså større chance for at vi får Inteno til at lave et fiks der arbejder udenom en ZTE bug end at vi får ZTE til at fikse buggen. Og endnu værre hvis det kan debatteres om det er en bug eller bare mangel på en feature eller en fortolkning af standarden. Der er endvidere problemer med det sproglige når man skal have kineserne til at forstå problemet.

Det kan altså ske at vi ved at vores udstyr ikke har den perfekte IPv6 implementering. Men hvad kan vi gøre? Selv Cisco og Juniper har deres issues foruden at de er for dyre til at business casen hænger sammen.

9
18. juni 2018 kl. 00:44

Sku da spændende hvordan ISP'er tjekker om deres udstyr er oppe eller nede

Vi tjekker ikke om udstyr hos kunden er oppe på den måde. Nogle slukker hver nat, mange slukker når de tager på ferie. Vi kan naturligvis se om linjen er oppe ved at tjekke udstyret i centralenden. Men vi kontakter ikke kunden hvis linjen er nede. Kunden kontakter os hvis der er et problem.

På erhvervsløsninger er det nogen gange anderledes med aktiv overvågning af udstyr og linjer. Men sjældent på private linjer. Det er simpelthen ikke praktisk.

8
17. juni 2018 kl. 23:15

Fordi du måske lige skal geare lidt ned

Ja det kan ikke komme på tale og selvfølgelig stiller jeg spørgsmål når jeg ikke føler artiklen giver dem af sig selv eller jeg ikke fanger meningen.

Eksempelvis så henter udstyret absolut ingen ting i bridge mode. Intet. Ingen ID , IP eller anden identifikation

...

Super. Bridge mode udstyr kan bare ikke identificeres, vi har ingen ID's, IP's eller noget. Sku da spændende hvordan ISP'er tjekker om deres udstyr er oppe eller nede, sikkert god vilje og vilde svampe.

Jeg har selv routet mellem IPv4 og IPv6 netværk tilbage i 2011 - 2013 somewhere og leget med MPLS, OSPF samt Frame Relay, men tja. Boller fra Kohberg.

Jeg forstår stadig ikke hvorfor dette blev så svært, og jeg kan ikke blive Kviknet kunde (så vidt jeg ved) så jeg selv kan lege med dette.

7
17. juni 2018 kl. 22:44

Som Baldur skiver, så er IPv6 på papiret gammelt, men der findes altså de underligste IPv6 implementeringer derude.

Og netop derfor er det vigtigt med grundige test. Jeg har selv en CPE hylde netop grundet IPv6, og bizart nok var den vores egen CPE som havde problemer, selvom leverandøren har påstået at den kan IPv6 i databladet i et par år nu.

Men på indlægget virker det jo nærmest somom man ikke har testet men andet end 1 CPE.

6
17. juni 2018 kl. 18:40

Og drenge hvis i trykker ned på et indlæg så må i da gerne lige sige hvorfor, takker

Fordi du måske lige skal geare lidt ned. Rent faktisk forholder det sig præcis sådan som Yoel beskriver tingene og ikke sådan som du spekulerer i det kunne være i stedet.

Eksempelvis så henter udstyret absolut ingen ting i bridge mode. Intet. Ingen ID , IP eller anden identifikation. Og ja, der medfører at der ikke kan kommunikeres med udstyr i bridge mode. Det er der heller ikke brug for.

IPv6 er ikke helt ung mere, men der er stadig tonsvis af fejl og halve implementeringer. Det kan du jo læse i blog indlægget, idet brugeren måtte bede om en patch for at tilføje option værdier, der har været standardiseret i et årti.

5
17. juni 2018 kl. 17:38

I bridge mode henter vores udstyr ingenting

I tildeler vel udstyret et ID, IP eller anden identifikation for at i kan kommunikere med det baseret på hvordan jeres infrastruktur er sat op.

Fordi vi bevæger os i et relativt nyt territorium. ZTE's IPv6-implementation er tydeligvis ikke komplet, og derfor må man lave et workaround eller to, når udstyret opfører sig anderledes end det, man har testet med.

Arghhhh Yoel, godt nok bor jeg lidt ude på bøgeren men denne slipper du altså ikke godt fra. IPv6 har været brugt i årevis (ude i verden), så det tænker jeg altså at man på nuværende tidspunkt burde have styr på <3 Nu kender jeg ikke til ZTE, men der er jo andre leverandører.

Jeg finder der hele ganske interessant, jeg syntes bare det blev hurtigt bøvlet for begge parter.

Og drenge hvis i trykker ned på et indlæg så må i da gerne lige sige hvorfor, takker.

4
17. juni 2018 kl. 16:07

Jeg fanger ikke dette, hvis Kviknet tilbyder IPv6 og i sender noget ISP udstyr ud til jeres kunder når de tilmelder sig jeres service, hvorfor sætter i så ikke jeres eget udstyr i bridge mode? Hvis kunden gerne selv vil have mere kontrol.

Det er præcis, hvad vi gør. Hvis kunden efter at have bestilt en router gerne vil køre bridge mode, sætter vi routeren i bridge mode. Bestilles bridge mode fra starten af, sender vi som regel et TDC-modem, der allerede er i bridge mode ved levering.

Så henter jeres udstyr en IPv6 adresse og så skal kunden enten selv bruge IPv6 i sit LAN

I bridge mode henter vores udstyr ingenting. I router mode beder vores CPE om en /64 IPv6-adresse til sig selv, samt et /48 delegated prefix, der kan uddeles til klienter på LAN-siden.

eller selv konvertere imellem IPv4 og IPv6 hvilket man sagtens kan.

Både og. I teorien kan man, men i praksis giver det alle mulige problemer afhængigt af måden, man gør det på. Native IPv6 er absolut at foretrække.

Eller hvorfor sat jeres kunde ikke bare jeres udstyr til, samt noget udstyr i promiscuous mode imellem jeres udstyr og væggen? Så kunne han jo se præcis hvad der skete og derefter sætte sit eget udstyr til med den rette konfiguration.

Fordi vi sendte ham en PCAP-fil fra en Inteno-router og dermed sparede ham for den manøvre.

Jeg fanger slet ikke i disse to artikler hvorfor det blev så kompliceret.

Fordi vi bevæger os i et relativt nyt territorium. ZTE's IPv6-implementation er tydeligvis ikke komplet, og derfor må man lave et workaround eller to, når udstyret opfører sig anderledes end det, man har testet med.

3
17. juni 2018 kl. 15:29

Jeg fanger ikke dette, hvis Kviknet tilbyder IPv6 og i sender noget ISP udstyr ud til jeres kunder når de tilmelder sig jeres service, hvorfor sætter i så ikke jeres eget udstyr i bridge mode? Hvis kunden gerne selv vil have mere kontrol.

I actually asked to set the CPE on bridge mode, that means it is acting like a modem on my point of view.

Så henter jeres udstyr en IPv6 adresse og så skal kunden enten selv bruge IPv6 i sit LAN eller selv konvertere imellem IPv4 og IPv6 hvilket man sagtens kan. Problem løst?

Hvorfor bliver det er virvar af DHCP options hovedpine? Jeg tænker at Kviknet må vide hvilke options der skal til for at jeres infrastruktur virker, og dette kan i sige til kunden.

Hvis du ikke vil bruge vores udstyr så skal du bruge options 1,2 og 4.. Bum.

Eller hvorfor sat jeres kunde ikke bare jeres udstyr til, samt noget udstyr i promiscuous mode imellem jeres udstyr og væggen? Så kunne han jo se præcis hvad der skete og derefter sætte sit eget udstyr til med den rette konfiguration.

Jeg fanger slet ikke i disse to artikler hvorfor det blev så kompliceret.

2
17. juni 2018 kl. 15:11

Hvad var problemet?

Jeg antager, problemet var, at ZTE-routeren forventede en bestemt DHCPv6 option, muligvis endda flere i kombination.

Vi kunne konstatere, at hans oprindelige DHCPv6 solicit-pakker så helt halal ud, men alligevel blev de ikke forwarded til vores DHCPv6-servere, mens Intenos DHCPv6-forespørgsler gik igennem som de skulle. Derfor var det en oplagt løsning at få hans pakker til at ligne Intenos, da vi ikke har kildekoden til ZTE's firmware liggende og derfor ikke kan pinpointe præcist, hvorfor pakkerne ikke sendes videre.

Man kunne givetvis komme nærmere årsagen hvis man fjerner Intenos options, en efter en, indtil man når det punkt, hvor pakkerne ikke længere forwardes.

Det har vi ikke gjort, da vi alligevel sysler med tanken om at udskifte ZTE's DHCPv6 relay agent med en hjemmebrygget en af slagsen, der kan distribuere routes til delegated prefixes til resten af netværket via ExaBGP.

Hardware-routere er suveræne, når det kommer til at forwarde trafik i store mængder, men vi må bare konstatere, at hardware-routeres svage side altid er softwaren, som er buggy og umulig at reparere, da det er closed source.

1
17. juni 2018 kl. 10:56

Hvad var problemet? Jeg synes ikke rigtigt at han finder ud af det. Det er ikke nødvendigt at sende præcis de samme options som Inteno. ZTE har trods alt ikke lavet deres software til kun at fungere med Inteno.