Ustabil ipv6 prefix fra Altibox. Showstopper for ipv6?

[sveinse]

Altibox tilbyr native dual-stack ipv6 hvis hjemmesentralen står i bridge mode. Man blir delegert en /56 prefix igjennom DHCPv6-PD (prefix delegation) og kan sette opp flere lokale /64 nettverk. Problemet er at ipv6 prefixen man blir tildelt virker å være svært variabel. En omstart av router en nok til å få tildelt en helt annen prefix. I følge Altibox kundesupport deles disse prefixene ut fra en felles pool og at det ikke finnes noe konsept om "fast-ip" slik det er for ipv4.

Dette er en showstopper for utrulling av ipv6 i ett hjemmenettverk som har mer enn en PC for å surfe på nettet!

I ipv4 brukes NAT, som gjør at IP-addressen man har offentlig og nettverket på innsiden (LAN) er frikoblet hverandre. Det er fullt mulig å bygge opp et fullfunksjonerende internt nettverk med DNS-oppslag til f.eks. smarthus osv. uavhenig av den eksterne ipv4 addressen.

I ipv6 brukes ikke NAT. Det betyr at ipv6-prefixen man får blir basis til ipv6-addressene til utstyret på lokalnettverket. ipv6 addressene er "offesielle" ip-adresser som er gyldige på internett. Problemet er at dersom man får ny PD prefix hele tiden, vil ipv6 adressene på hjemmenettverket endre seg hele tiden også. Det gjør det umulig å bygge opp en stabil tjeneste, som f.eks. til smarthus, og det motvirker en overgang til å bare bruke ipv6.

Så hva kan man gjøre?

Jeg har et par alternativer:

• Overbevise Altibox om å dele ut/tilby mer stabile ipv6-prefixer
• Ta i bruk fe80:: på interne DNS-tjenester - men det bryter sammen hvis man har flere nettverk

Andre?

 

[kpolberg]

I stedet for link-local så kan du bruke ULA addresser internt (fc00::/7).

Men jeg ser helst at altibox får styr på PDen tilsvarende som de har for IPv4 tildeling. Telenor har jo ordnet det, så teknisk sett burde det jo ikke være det største problemet.

Kan det være det er gjort for senere å kunne tilby statisk prefix mot en kost?

[bmork]

4 hours ago, kpolberg said:

Men jeg ser helst at altibox får styr på PDen tilsvarende som de har for IPv4 tildeling. Telenor har jo ordnet det, så teknisk sett burde det jo ikke være det største problemet.

Jeg har også frustrert meg over det samme.  Ikke bare er det et herk for det lokale nettet at prefikset endrer seg, men om du har noe remote så vil du jo gjerne legge inn prefikset i aksesslister o.l der også.  Men tli Altibox' forsvar så er det muligens ikke helt rett fram å fikse dette. Inntil videre har jeg endt opp med et sammensurium av script som kjører hver gang prefikset endrer seg.

I Telenor bruker vi RADIUS som backend for en lokal DHCPv6-server på hver aksess-ruter. Dermed er det lett å lage en RADIUS-konto med statisk prefiks per linje/bruker.  Det er likevel noe herk ettersom vi ikke vil ha millioner av løse /48-ruter i nettet. For å unngå det har allokeringen et forhold til hvilken aksess-ruter en linje er terminert på, slik at vi kan aggregrere rutingen på et fornuftig nivå der. Dvs at du må regne med å bytte prefiks når du flytter, men også ved enkelte omlegginger i nettet.

På HFC var løsningen inntil ganske nylig pool-basert og dynamisk.  Men nå er CMTSene også over på samme løsning som fiber og dsl.

[kpolberg]

Som høres helt fornuftig ut. Jeg forventer heller ikke at altibox skal la meg ta med meg prefixet idet jeg flytter til en annen by. Men la oss si en PD med lease tid på 7 dager eller der omkring? I forhold til ruting, så kan de gjerne delegere utifra en pool basert på noderom eller hvorhen det er hensiktsmessig.

Selv har jeg faktisk ikke testet den nye IPv6 løsningen til Altibox. Men en forutsetning for å kunne flytte over fra løsningen jeg har idag, er at prefixet er noenlunde fast, tilsvarende hvordan IPv4 fungerer idag.

[sveinse]

DET VIRKER! Jeg trekker tilbake det jeg sa om ustabil PD fra Altibox. Begynte å debugge min DUID og om Altibox honorerer bruken av den. Det viser seg min router (Edgerouter ER5) sender DHCPv6 release ved nedstengning og omstart, noe som gjør at jeg ikke lengre har "dibs" på PDen jeg har gitt fra meg. Neste gang jeg starter, hjelper det lite å komme med samme DUID, Altibox må gi meg en ny PD.

Etter det jeg har klart å teste, så får jeg tilbake min forrige PD når jeg bruker samme DUID, og det betyr at ipv6 tjenesten fra Altibox blir betydelig mer stabil. Jeg har ikke testet dette over tid.

5 hours ago, bmork said:

Jeg har også frustrert meg over det samme.  Ikke bare er det et herk for det lokale nettet at prefikset endrer seg, men om du har noe remote så vil du jo gjerne legge inn prefikset i aksesslister o.l der også.  Men tli Altibox' forsvar så er det muligens ikke helt rett fram å fikse dette. Inntil videre har jeg endt opp med et sammensurium av script som kjører hver gang prefikset endrer seg.

Ja, det må være innen rimelighetens grenser når det gjelder hvor stabilt det behøver å være. Hvis (deres) router restartes eller flyttes, så må det være rimelig å kunne forvente en oppdatert PD. Litt på samme måte som vanlige ipv4 addresser forvaltes. Kunder ser det som stort sett likt, men endringer kan forekomme.

[Janvik]

5 hours ago, bmork said:

I Telenor bruker vi RADIUS som backend for en lokal DHCPv6-server på hver aksess-ruter. Dermed er det lett å lage en RADIUS-konto med statisk prefiks per linje/bruker.

Kun tilgjengelig for bedrift? 

[kpolberg]

@bmork hvor ofte opplever du at PDen endrer seg?

Forøvrig kjekt med info fra "innsiden" av telenor.

[bmork]

8 hours ago, Janvik said:

Kun tilgjengelig for bedrift? 

Nei, det er slik det virker for alle.

Bedrift har tilleggsfordelen at de får et innslag i rutingtabellen slik at prefikset heller ikke må endres ved flytting osv

[bmork]

15 hours ago, kpolberg said:

 hvor ofte opplever du at PDen endrer seg?

Normalt bare ved reboot. Unntaksvis ifm (sannsynligvis) arbeid i nettet, men det er så sjeldent at jeg ikke har nok grunnlag for noen statistikk.

Hadde ett tilfelle hjemme i forrige uke. Da hadde prefikset vært stabilt siden forrige reboot av "ruter" 27. mars.

Jeg har nettopp fått Altibox på "hytta" også, og har fiklet en del der i den forbindelse. Det har medført mye rebooting av "ruter" (som der er en RPi4) med tilhørende frustrasjon. Spesielt irriterende at jeg publiserer en /64 fra prefikset på LAN. Klientene får til slutt en liten stabel med adresser etter noen ruter-rebooter, og vet jo ikke at det bare er den ferskeste som virker.

Men de problemene er jo selvpåførte. Og det er kanskje problemene ved en ordinær reboot også? Jeg har jo tenkt tanken at jeg burde se nærmere på det. Veldig interessant det @sveinse skriver. Hadde jo i utgangspunktet samme problem på IPv4 også. Jeg kjører en standard Debian bullseye på RPien, og der er default av uforståelige grunner å gjøre release ifm shutdown/reboot. Helt idiotisk og noe jeg har slåss mot siden 90-tallet. Mulig vi bare ser det samme på IPv6

Jeg bruker "wide" klienten for DHCPv6. Det er noe som henger igjen i fingrene siden jeg eksperimenterte med v6 over PPPoE for et tiår siden. Var/er jo ikke alle DHCPv6 klienter som støtter den slags. Og da fikset jeg også muligheten for å spesifisere hvilken del av prefikset som tildeles hvilket interface, som er funksjonalitet jeg synes er kjekk å ha. Derfor har jeg beholdt den. Men denne klienten har jo ellers ikke vært vedlikeholdt på 15+ år, så det er godt mulig jeg skyter meg selv i foten med valget. Den har åpenbart mangelfulle muligheter for konfigurasjon og scripting. Står på listen over ting som bør sjekkes.

EDIT: Joda, wide-klienten gjør selvsagt release av alle IA når den får SIGTERM.  Og det får den jo normalt ved shutdown/reboot.  Sendte den en KILL før reboot nå, og fikk bekreftet at prefikset da beholdes.  Så dette var ikke Altibox sin feil.  Bare alle de dustete DHCP(v6)-implementasjonene.  Argh.  Måtte sjekke: I 1999 fikk jeg fikset tilsvarende problem i Redhats dhcpcd-0.70-pakke.  Historien er som en idiot.

Vet ikke om jeg gidder å gjøre noe med wide-klienten siden den er død og jeg sikkert er eneste gjenværende bruker...  ISC sin klient kan ihvertfall konfigureres til å det riktige for IPv4.  Får håpe det gjelder IPv6 også.

EDIT2: virker helt greit med ISC klienten så lenge du stanser den med -x og ikke -r når interfacet skal ned for boot. Litt krøkkete at det ikke ser ut til å være mulig å velge IA-ID? Ikke viktig kanskje, men det gjorde det vanskelig å bytte klient uten å få nytt prefiks.

Endret 5. juli 2021 av bmork

[sveinse]

Nå har jeg fått opp nettverket i det jeg vil kalle produksjonsnivå. Det tok meg litt tid (og hjelp fra diverse IRC-grupper) å brette hodet mitt rundt hvordan en kan få en effektiv utrulling av ipv6. Problemstillingen med DHCPv6-PD, er at når man får ny prefix, eller PD, så endres alle IP-adressene på nettverket. Uavhengig av hvor stabil prefix Altibox leverer over tid. Dette medfører at man må oppdatere interne DNS og tilgangslister, som @bmork påpeker.

Løsningen ble å rulle ut et ULA nettverk (fd01::) for mitt LAN og DMZ-nettverk i tillegg til de tildelte DHCPv6-PD addressene. Da bruker jeg ULA-addressene til alt som trenger infrastruktur og internkommunikasjon på nettverket (f.eks. fra et internt DNS AAAA-oppslag til UPSen), mens de samme klientene benytter den tildelte ipv6 prefixen på ordinær internet trafikk. Dette gjør at nettverket blir betydelig mer robust for eventuelle endringer i PD fra ISP.

Det eneste denne metodikken ikke fikser, er at hvis man har DNS AAAA records til innkommende tjenester, så må nødvendigvis den eksterne DNSen oppdateres med riktig prefix.

[bmork]

11 hours ago, sveinse said:

Det eneste denne metodikken ikke fikser, er at hvis man har DNS AAAA records til innkommende tjenester, så må nødvendigvis den eksterne DNSen oppdateres med riktig prefix.

Etter konvertering til ISCs dhclient for DHCPv6-PD også endte jeg opp med en mindre justering av det eksisterende scriptet jeg hadde for oppdatering av A. Det ser nå omtrent slik ut, etter litt sensur.  OBS, tar noen snarveier mht failsafing 🙂  Jeg "vet" at prefikset skal se ut som 2001:db8:cafe:f00::/56 og at adressen jeg da vil annonsere er 2001:db8:cafe:f00::1.  Derfor den noe forenklede konverteringen fra $new_ipv6_prefix til adresse.

#!/bin/sh

DYNZONE="dyn.example.com"
NSUPDATE_KEY=/etc/foo-ddns.key
NSUPDATE_SERVER=ns.example.com
LABEL=""
[ "$interface" = "eth0.102" ] && LABEL=foo
[ -n "$LABEL" ] || return

update_ddns () {
        local addr="$1"
        local type="${2:-A}"
        [ -z "$addr" ] && return

        # attempt to use address from dns
        old_dns_address=$(dig $type +short ${LABEL}.${DYNZONE}.)

        if [ "$addr" != "$old_dns_address" ]; then
                # clock will be unsyncronized on boot - delay update to allow ntp sync
                ( sleep 300; nsupdate -D -k "${NSUPDATE_KEY}" <<EOF >>/var/log/nsupdate 2>&1 ) &
server ${NSUPDATE_SERVER}
update del ${LABEL}.${DYNZONE}. 60 IN ${type}
update add ${LABEL}.${DYNZONE}. 60 IN ${type} ${addr}
send
EOF
        fi

}

# No need to continue if we're called with an unsupported option
case "$reason" in
  BOUND|RENEW|REBIND|REBOOT)
    update_ddns "$new_ip_address" A
    ;;
  BOUND6|RENEW6|REBIND6)
    [ -n "${new_ip6_prefix}" ] && update_ddns "${new_ip6_prefix%/*}1" AAAA
    ;;
  *)
    return;
    ;;
esac;

Den greia om ntp er fordi dette kjører på en Raspberry uten noen RTC.  Ikke så relevant for andre maskiner.

Nå er jo dette selvsagt tilpasset min variant av DDNS, som er en min egen DNS-server.  Men det burde jo være overkommelig å tilpasse det til andre typer dynamiske DNS-tjenester.

[sveinse]

3 hours ago, bmork said:

Nå er jo dette selvsagt tilpasset min variant av DDNS, som er en min egen DNS-server.  Men det burde jo være overkommelig å tilpasse det til andre typer dynamiske DNS-tjenester.

Vet du om det er trivielt å få oppdatert Domeneshop DNS på et slikt vis? Jeg har 2FA på kontoen min der, så det trenger kanskje ikke være helt rett frem å scripte det?

[bmork]

Ser ikke ut til at de støtter det men de har jo et utmerket forslag i FAQen sin: https://domene.shop/faq?id=106&section=7

Det spiller ingen rolle hva det dynamiske navnet er.  Du legger bare inn et fast alias (CNAME peker) i din egen sone.  Dette er jo generelt også en del sikrere siden du forhindrer dynamisk oppdatering av andre navn i din egen sone.

(jeg gjør det forsåvidt også sånn selv om jeg har kontroll over begge soner - nettopp for å unngå at den "årntlige" sonen kan endres av noen som får tak i en nøkkel)

[trrunde]

dersom en skal hoste ddns tjenesten selv ser det ut som komboen KEA dhcp server og powerdns kan være grei, ikke testet det selv enda, men fant en blogpost som forklarer hvordan en kan sette det opp.
Fordelen vil jo da være at en slipper script på hver enkelt klient som oppdaterer ddns, ulempen vil nok være at det kun funker for klienter som støtter dhcpv6, om en klient får adresse via slaac vil nok ikke denne bli oppdatert. (android f.eks får kun ipv6 adresse via slaac)

 

https://dnsandfunops.com/make-your-local-zone-dynamic-with-kea-and-powerdns/

 

det vil nok fungere med kea og powerdns om en har et statisk prefix, men når en får tildelt et dynamisk så funka nok ikke det så bra.

 

Endret 7. juli 2021 av trrunde

[Penguin]

On 7/7/2021 at 9:42 AM, sveinse said:

Vet du om det er trivielt å få oppdatert Domeneshop DNS på et slikt vis? Jeg har 2FA på kontoen min der, så det trenger kanskje ikke være helt rett frem å scripte det?

Domeneshop har da et API, har de ikke?

[bmork]

8 minutes ago, Penguin said:

Domeneshop har da et API, har de ikke?

Sannelig har de det.  Eller dvs, selvsagt har de det, men sannelig har de et public API også.  Men det var en godt bevart hemmelighet som jeg ihvertfall ikke klarte å finne via hjelp/faq. Men google fant https://api.domeneshop.no/docs/

[Penguin]

2 minutes ago, bmork said:

Sannelig har de det.  Eller dvs, selvsagt har de det, men sannelig har de et public API også.  Men det var en godt bevart hemmelighet som jeg ihvertfall ikke klarte å finne via hjelp/faq. Men google fant https://api.domeneshop.no/docs/

Men:

Quote

 

Testing period
The API service is in version 0, which means it is possible that the interface will change rapidly during the testing period. For that reason, the documentation on these pages may sometimes be outdated.

Additionally, we make no guarantees about the stability of the API service during this testing period, and therefore ask customers to be careful with using the service for business critical purposes.

 

Vet jeg fant dette for en hel del måneder siden. Har ikke prøvd. Men helt v0.0.1 er det kanskje ikke lenger.  🙂

[Eide'n]

For at eg skal kunne gå bort i fra IPv4 for mitt hjemmenettverk med VPN til andre familiemedlemmer, Så trenger eg  NAT66 på mine rutere. 

Dette gir meg forutsigbare interne ipv6 nett. 

https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Translation

https://tools.ietf.org/id/draft-mrw-nat66-00.html#anchor5

[knindi]

 

On 7/4/2021 at 11:48 PM, sveinse said:

… Det viser seg min router (Edgerouter ER5) sender DHCPv6 release ved nedstengning og omstart, noe som gjør at jeg ikke lengre har "dibs" på PDen jeg har gitt fra meg. Neste gang jeg starter, hjelper det lite å komme med samme DUID, Altibox må gi meg en ny PD. …

Jeg satte «option clientid» (DUID-Type, 4, pluss UUID, 128 bits, ref. RFC6355 avsnitt 4 ) og «option norelease '1'» i «/etc/config/network» på OpenWrt, versjon21.02.2, for «wan6» grensesnittet og jeg har fått tilbake PDen etter et par omstarter nå.