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.
