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.
menu close Teknologiens Mediehus
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Er der noget nyt om IPv6 på YouSee coaxen? Jeg savner den...!
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.
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?
Jeg har prøvet at lave en tunnel til HE i Stockholm, men TDC blokerer IP protokol 41 i YouSee infrastrukturen. Gælder også Hiper kunder... Den juleleg er lukket :(
Ikke alle steder så ... jeg har kørt sådan en tunnel først med ADSL og nu med et Sagemcom i bridge mode og min Ubiqity router bagved, og det virker fint med min HE tunnel til Stockholm.
/Niels
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 :(
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.
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 :)
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.
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.
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.
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å ...
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
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 :-)
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.
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.
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.
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:
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.
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.
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: 64Eller som screenshots her: https://imgur.com/a/jHchkbN
