yoel caspersen blog bloghoved

IPv6 med egen CPE

Af 53

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.

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.

Relateret indhold

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

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.

  • 1
  • 0
#2 Yoel Caspersen Blogger

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.

  • 2
  • 0
#3 Cristian Ambæk

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.

  • 0
  • 6
#4 Yoel Caspersen Blogger

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.

  • 4
  • 0
#5 Cristian Ambæk

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.

  • 0
  • 10
#6 Baldur Norddahl

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.

  • 12
  • 0
#7 Peter Krüpl

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.

  • 3
  • 0
#8 Cristian Ambæk

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.

  • 0
  • 13
#9 Baldur Norddahl

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.

  • 10
  • 0
#10 Baldur Norddahl

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.

Du er mere end velkommen til at stille spørgsmål men tænk lidt over måden du gør det på. I stedet for at tale om vilde svampe kan du måske lidt mere ydmygt bare stille spørgsmålet. Ikke alt fungerer helt som du åbenlyst forestiller dig det.

  • 11
  • 0
#11 Baldur Norddahl

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.

  • 6
  • 1
#14 Yoel Caspersen Blogger

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.

  • 5
  • 0
#16 Kristian Klausen

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.

Kunne man ikke lave 6rd eller andre numre? eller i låst helt fast af TDC?

  • 0
  • 0
#23 Anders Bystrup

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.

  • 1
  • 0
#24 Dennis Glindhart

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 :)

  • 7
  • 0
#25 Søren Thing Andersen

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.

  • 0
  • 0
#26 Martin Jensen

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.

  • 0
  • 0
#27 Yoel Caspersen Blogger

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.

  • 0
  • 0
#28 Martin Jensen

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å ...

  • 0
  • 0
#29 Bjørn Agger

Godt at høre - det kan være, vi skulle samle alle erfaringerne omkring IPv6 på vores website.

Det ville være super med sådan en guide. TDC er tæt på at skyde fiber ind på vores adresse, så for en newbie på IPv6, som jeg er, så vil det være alle tiders.

Jeg kan se på min routers indstillinger, at den er IPv6-forberedt. Så jeg håber på en FAQ på jeres hjemmeside :)

Mvh Bjørn

  • 0
  • 0
#30 Martin Jensen

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 :-)

  • 0
  • 0
#32 Yoel Caspersen Blogger

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.

  • 0
  • 0
#33 Baldur Norddahl

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.

  • 1
  • 0
#34 Baldur Norddahl

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.

  • 1
  • 0
#35 Yoel Caspersen Blogger

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.

  • 0
  • 1
#36 Baldur Norddahl

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.

  • 2
  • 0
#37 Michael Hansen

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)

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

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

  • 3
  • 0
#38 Rasmus B

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.

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.

  • 0
  • 0
#39 Martin Jensen

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.

  • 0
  • 0
#43 Emil Mølgaard

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?

  • 0
  • 0
#44 Rasmus Haslund

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.

  • 0
  • 0
#45 Emil Mølgaard

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.

  • 0
  • 0
#50 Preben Trærup

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

  • 1
  • 0
#51 Asbjørn Baagø

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.

  • 0
  • 0
#52 Ronni Hansen

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.

  • 0
  • 0
#53 Asbjørn Baagø

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... Det æ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.

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