INNSIKT: Har du bare «gammeldags» internett? Flere skal få IPv6 i 2020 [Ekstra]

bmork · 14. mai 2020

On 12/13/2019 at 11:56 AM, trrunde said:

Det kommer til neste år,

Og det skrev du altså i fjor...

Den samme leksa har vi hørt fra Altibox i snart 10 år. Ser ikke at jeg har fått native IPv6 fra dem ennå. De har i mellomtiden oppgradert CPE og mediakonverter i flere runder, til de nå er tilbake til start med en kombinert boks. Mest sannsynlig er alt annet de har i resten av nettet også byttet ut i løpet av de 10 årene, uten at jeg vet så mye om det. Men native IPv6 - det får de fremdeles ikke til. Alltid en unnskyldning på lager.IPv6 er visst så mye vanskeligere for dem. For vi tror vel ikke at det er viljen det står på?

Jeg oppfordrer Digi til en skikkelig 10-årsmarkering av denne aritkkelen 29. okt. 2020: https://www.digi.no/artikler/snart-kommer-de-norske-isp-ene-med-ipv6/291566

En passelig anledning å grille de som ennå ikke har gjort jobben?

Merk at det var "neste år" for Altibox den gangen også ?

Endret 14. mai 2020 av bmork

trrunde · 14. mai 2020

hvor bor du? utrullingen er nesten ferdig. Mener det gjenstår litt i Viken og BKK.

bmork · 14. mai 2020

2 hours ago, trrunde said:

hvor bor du? utrullingen er nesten ferdig. Mener det gjenstår litt i Viken og BKK.

Jeg bor i Viken-land, også kjent som Oslo.

Merkelig lite info å finne om denne utrullingen hvis det er slik at de fleste har fått. Alt de har er jo denne ganle 6RD-infoen, som jo må være svært forvirrende for en kunde med native IPv6: https://www.altibox.no/privat/bredband/ipv6/

EDIT: Sjekket forresten grafene til Tore, og jeg tillater meg å betvile at det er noen betydelig andel av Altibox-kundene som har fått IPv6. https://munin.fud.no/vg.no/www.vg.no/vg_ipv6_byisp.html

Endret 14. mai 2020 av bmork

trrunde · 14. mai 2020

Kjenner ikke til årsaken til lite info ut, regner med de vil bli ferdig med utrullingen først slik at de slipper klager fra kunder som ikke har mulighet for å få enda. Regner med 6RD info vil bli fjernet så snart DS er klart.

Du vil få tildelt en /56

trrunde · 14. mai 2020

27 minutes ago, bmork said:

EDIT: Sjekket forresten grafene til Tore, og jeg tillater meg å betvile at det er noen betydelig andel av Altibox-kundene som har fått IPv6. https://munin.fud.no/vg.no/www.vg.no/vg_ipv6_byisp.html

Støtten fra nettverket sin side er der, men per nå er det vel kun kunder med bridgemode eventuellt egne routere og har aktivt skrudd på ipv6 selv som har det. Ergo ganske lite bruk foreløpig.

bmork · 14. mai 2020

Høres flott ut. Da antar jeg det er DHCPv6-PD involvert. Blir veldig spennende å se om de rekker det før 29. oktober ?

Er absolutt ikke meg imot om jeg tar feil i mine bange antagelser om at det blir "neste år" nok en gang.

trrunde · 14. mai 2020

det er korrekt ja, sett opp routeren din klar så skal du nok se du får deg et prefix ganske snart. Viken (partneren ikke fylket) mener jeg er neste på listen. Og om jeg ikke husker helt feil så skal de være ferdig før juni med utrullingen.

bmork · 14. mai 2020

rotueren min har vært klar siden 23. juli 2010. Husker ikke så godt, men sjekket cvs (sic) log for /etc/wide-dhcpv6/dhcp6c.conf . Det var da jeg la inn "id-assoc pd" første gang.

14. mai 2020

Har altibox. Kjører jeg Ping så er IPv6 det som brukes primært om det støttes. Må aktivt velge IPv4. Jeg har ikke gjort noe aktivt her.

trrunde · 18. mai 2020

On 5/14/2020 at 7:39 PM, bmork said:

rotueren min har vært klar siden 23. juli 2010. Husker ikke så godt, men sjekket cvs (sic) log for /etc/wide-dhcpv6/dhcp6c.conf . Det var da jeg la inn "id-assoc pd" første gang.

du får oppdatere om noe skulle endre seg da vet noen kunder hos viken i Oslo fikk mulighet for DS idag, så mulig du har fått ipv6 nå.

bmork · 18. mai 2020

1 hour ago, trrunde said:

du får oppdatere om noe skulle endre seg da vet noen kunder hos viken i Oslo fikk mulighet for DS idag, så mulig du har fått ipv6 nå.

Skulle du sett! Nå står ikke verden til påske, men det var vel forsåvidt allerede klart.

Der var det plutselig RAer som ikke var der for et par dager siden:

canardo:/tmp# tshark -ni br0.102 -f ip6 -c 500
Running as user "root" and group "root". This could be dangerous.
Capturing on 'br0.102'
    1 0.000000000 fe80::209:ff:fe02:1 → ff02::1      ICMPv6 86 Router Advertisement from 00:09:00:02:00:01
    2 1.297116813 fe80::209:ff:fe02:1 → ff02::1      ICMPv6 86 Router Advertisement from 00:09:00:02:00:01
^C2 packets captured

Og jammen var det ikke en DHCPv6 server som ga ut et prefiks også. Spennende. Dette kvalifiserer jo nesten for kake.

Noen idé om hvor stabilt prefikset er? Er det koblet til linje-info, eller tildeles det dynamisk fra en pool? Jeg har mistet troen på de full-atuomatiske omaddresseringene IPv6 var laget for. Det finnes alltid en aksessliste du må oppdatere manuelt hver eneste gang....

Endret 18. mai 2020 av bmork

trrunde · 18. mai 2020

Tildeles dynamisk fra en pool.

HawP · 20. mai 2020

bmork skrev (På 18.5.2020 den 20.51):

Noen idé om hvor stabilt prefikset er? Er det koblet til linje-info, eller tildeles det dynamisk fra en pool? Jeg har mistet troen på de full-atuomatiske omaddresseringene IPv6 var laget for. Det finnes alltid en aksessliste du må oppdatere manuelt hver eneste gang....

Spurte de om det, siden jeg har fått nytt PD etter router-restarter og det jo vel egentlig ikke er noen grunn til at vi ikke skulle kunne få vårt eget ipv6-prefix (slik jeg har forstått det ut i fra antall mulige prefix) ...
Svaret var (ikke ordrett) at etter deres erfaring var det like statisk som ipv4, men at ipv6 fortsatt er i utviklingsfasen og at det at jeg fikk ny PD kan skyldes pågående endringer på tjenesten.

Så vi får vente og se det an ... kjedelig å "stadig vekk" måtte oppdatere brannmur-regler og andre ip-baserte allow/deny-regler fordi PD endrer seg.

bmork · 21. mai 2020

19 hours ago, HawP said:

Så vi får vente og se det an ... kjedelig å "stadig vekk" måtte oppdatere brannmur-regler og andre ip-baserte allow/deny-regler fordi PD endrer seg.

Ja, det er min erfaring også. Jeg legger nok inn "mine" adresser mange flere steder enn gjennomsnittet, men jeg er ganske overbevist om at de aller fleste vil ende opp med minst en konfigurasjon de må oppdatere hver gang de bytter prefiks.

Alternativet er ofte at man bare gir opp og åpner for hele verden. Det "virker" , men er jo en dårlig løsning, som ISPen så absolutt ikke ønsker.

For min del ligger alle lokale prefiks i

/etc/mail/acces - sendmail relaying for mitt lokalnett
/etc/dkimkeys/internal-hosts - for at OpenDKIM skal vite hva den skal signere og hva den skal validere
/etc/spamassassin/local.cf - så spamassassin kan vite at den kan stole på lokale maskiner
/etc/bind/name.conf.options - så BIND tillater rekursjon for lokale maskiner
/etc/milter-greylist/greylist.conf - for å unngå at lokale maskiner må gjennom greylisting
/etc/ntp.conf - så ntp tillater lokale peers
/etc/squid/squid.conf - for at squid skal tillate http proxying

Samt selvsagt i "brannmur"-regler for å bestemme hva som kan rutes hvor.

Når det ikke er enda mer, så er det fordi jeg fprsøker å være "smart" (tror det selv, ihvertfall) ved å plukke opp adresser fra interface der det er mulig. Slik har jeg unngått å legge de dynamiske prefiksene i radvd.conf eller dhcpd.conf f.eks.

Nå burde jeg i teorien være i stand til å automatisere de resterende tingene. Men det er et herk. Alle konfig-filene har sitt eget pussige aksessliste-format, og noen av dem er veldig merkelige. ntp bruker en IPv6 nettmaske(!), mens sendmail ikke har noen måte å indikere prefiks-lengde annet enn ved å skrive "halve" adresser. Hvis prefikslengden ikke passer med inndeligen, så må du lage X antall linjer for å dekke alt. Flere av tjenestene mangler mulighet for "include", så du må tillate scriptet å redigere en hel konfigurasjonsfil. Ingen av tjenestene takler at du refererer til en include-fil som ikke finnes, så det er ikke mulig å referere til en aksesslistedefinisjon som vil genereres dynamisk senere.

Så i praksis har jeg endt opp med en halvveis fiks, der jeg auto-genererer det viktigste og driter i resten.

Jeg har også et par server-tjenester som kan lytte på den uspesifiserte adressen, men som jeg helst skulle hatt til å lytte på kun "riktig" adresse. Men da må i så den konfigurasjonen også oppdateres hver gang prefikset endres, Det kan muligens gjøres indirekte via DNS, men du får fort problemer pga caching da. Boot-rekkefølge blir ihvertfall håpløst.

DNS-oppdateringer kommer selvsagt i tillegg, men det er jo forholdsvis overkommelig å automatisere. Unntatt hvis du ønsker å kjøre din egen autoritative server, da. Ihvertfall hvis den trenger lim. Det betyr fort en manuell oppdatering hos registrar.

Det går selvsagt an å klare seg uten mye av dette, og rett og slett bare benytte eksterne tjenester i stedet for å tilby dem lokal på eget nett. Men hos meg så har alt dette vokst frem organisk siden 90-tallet ? Og når jeg begynte å fikle med IPv6 så innså jeg fort at jeg ønsket meg et prefiks som var enda mer stabilt enn en typisk DHCP-tildelt IPv4-adresse. Så når jeg skulle lage et system for tildeling av IPv6-prefiks, så var stabilitet et viktig kriterium. Men selvsagt ikke det eneste. Aggregering er f.eks. helt nødvendig når vi snakker om flere hundre tusen prefiks, og det legger en begrensing på stabilitet ifm flytting eller andre nettverksendringer.

Men jeg respekterer at det er to fundamentalt motsatte syn på stabile adresser. Noen har faktisk etterspurt mer dynamiske prefiks basert på personvernargumenter. Jeg mener det er nokså naivt å tro at dynamiske adresser påvirker personvernet, men det finnes faktisk presumtivt opplyste myndighetsorganer som argumenterer på den måten (i andre land - har ikke hørt det fra noen i Norge).

bmork · 21. mai 2020

er det forresten bare meg som synes RAene ser litt pussige ut? De kommer så tett som om de skulle vært unicastet, og det ser også slik ut på ethernet destination. Men IPv6 destination er mulitcast-adressen ff02::1 (all hosts). En helt merkelig kombo av IPv6 multicast og ethernet unicast. How comes?

canardo:/tmp# tshark -ni br0.102 -f 'icmp6 and ip6[40] == 134' -T fields -e frame.time_relative -e eth.src -e eth.dst -e ipv6.src -e ipv6.dst
Running as user "root" and group "root". This could be dangerous.
Capturing on 'br0.102'
0.000000000     00:09:00:02:00:01       b8:d5:26:0a:60:c8       fe80::209:ff:fe02:1     ff02::1
3.596006865     00:09:00:02:00:01       5c:e2:8c:51:70:c8       fe80::209:ff:fe02:1     ff02::1
4.650524239     00:09:00:02:00:01       b8:d5:26:1e:fd:1d       fe80::209:ff:fe02:1     ff02::1
6.544513865     00:09:00:02:00:01       98:0d:67:0f:a7:20       fe80::209:ff:fe02:1     ff02::1
10.092543916    00:09:00:02:00:01       98:0d:67:0f:e3:44       fe80::209:ff:fe02:1     ff02::1
15.440934677    00:09:00:02:00:01       98:0d:67:0f:da:bc       fe80::209:ff:fe02:1     ff02::1
16.709579452    00:09:00:02:00:01       c8:54:4b:e1:d0:f0       fe80::209:ff:fe02:1     ff02::1
19.001845314    00:09:00:02:00:01       5c:e2:8c:51:7c:e8       fe80::209:ff:fe02:1     ff02::1
19.654741663    00:09:00:02:00:01       98:0d:67:0f:a3:48       fe80::209:ff:fe02:1     ff02::1
32.368652854    00:09:00:02:00:01       2c:4d:54:d9:57:d8       fe80::209:ff:fe02:1     ff02::1
33.034803804    00:09:00:02:00:01       04:bf:6d:37:3c:78       fe80::209:ff:fe02:1     ff02::1
35.903628178    00:09:00:02:00:01       98:0d:67:0f:e0:b0       fe80::209:ff:fe02:1     ff02::1
37.403754924    00:09:00:02:00:01       5c:6a:80:c1:ab:80       fe80::209:ff:fe02:1     ff02::1
38.460786918    00:09:00:02:00:01       98:0d:67:0f:a4:f8       fe80::209:ff:fe02:1     ff02::1
41.635809436    00:09:00:02:00:01       5c:6a:80:52:b6:e8       fe80::209:ff:fe02:1     ff02::1
42.782694302    00:09:00:02:00:01       60:31:97:d0:d5:90       fe80::209:ff:fe02:1     ff02::1
42.955887326    00:09:00:02:00:01       5c:e2:8c:ef:88:50       fe80::209:ff:fe02:1     ff02::1
43.015732521    00:09:00:02:00:01       b0:2a:43:de:a7:af       fe80::209:ff:fe02:1     ff02::1
47.454143850    00:09:00:02:00:01       4c:9e:ff:bb:84:60       fe80::209:ff:fe02:1     ff02::1
49.172046270    00:09:00:02:00:01       98:0d:67:0f:9e:80       fe80::209:ff:fe02:1     ff02::1
51.596667765    00:09:00:02:00:01       5c:f4:ab:37:08:88       fe80::209:ff:fe02:1     ff02::1
52.226857113    00:09:00:02:00:01       54:83:3a:bd:b4:78       fe80::209:ff:fe02:1     ff02::1
53.486987719    00:09:00:02:00:01       5c:6a:80:4e:55:a8       fe80::209:ff:fe02:1     ff02::1
53.689228759    00:09:00:02:00:01       b8:d5:26:0b:68:bc       fe80::209:ff:fe02:1     ff02::1
54.578042995    00:09:00:02:00:01       98:0d:67:0f:a7:68       fe80::209:ff:fe02:1     ff02::1
54.594256574    00:09:00:02:00:01       98:0d:67:0f:df:0c       fe80::209:ff:fe02:1     ff02::1
54.836865827    00:09:00:02:00:01       b8:d5:26:25:1f:19       fe80::209:ff:fe02:1     ff02::1
54.903051667    00:09:00:02:00:01       b8:d5:26:1e:fc:5d       fe80::209:ff:fe02:1     ff02::1
55.059857894    00:09:00:02:00:01       98:0d:67:0f:e3:a4       fe80::209:ff:fe02:1     ff02::1
58.468835991    00:09:00:02:00:01       b8:d5:26:1e:fc:bd       fe80::209:ff:fe02:1     ff02::1
60.382013159    00:09:00:02:00:01       1c:74:0d:08:e3:90       fe80::209:ff:fe02:1     ff02::1
^C31 packets captured

Hmm, jeg ser at https://tools.ietf.org/html/rfc6085 presiserer at dette er lov "when it is clear that only one address is relevant.", uten at jeg ser hvordan det kan gjelde her.

Jaja, det virker jo så da er det sikkert OK. Men snodig er det.

trrunde · 21. mai 2020

mener RA blir sendt som unicast istedet for multicast ja, husker ikke helt årsaken, men det var gyldig årsak for å ha det som unicast.

bmork · 21. mai 2020

25 minutes ago, trrunde said:

mener RA blir sendt som unicast istedet for multicast ja, husker ikke helt årsaken, men det var gyldig årsak for å ha det som unicast.

Men det er jo ikke unicast. Det er multicast på lag 3 og unicast på lag 2. For meg så henger ikke det på greip. Men det finnes sikkert en god grunn. Ser den bare ikke.

Tiresias · 11. juni 2020

Jeg satte akkurat min unifi security gateway til å be om DHCPv6 og /56. Jeg har Altibox Viken Fiber og bridged mode på modemet. Jeg fikk utdelt en /128 global adresse.

trrunde er det slik hos deg også?

trrunde · 11. juni 2020

du får det på linknet mellom altibox router og din egen boks. I tillegg til denne får du et prefix som du kan bruke på lan.

update: nei, du skal få en /64 adresse på wan interfacet ditt, og et /56 prefix du kan bruke på lan

Men mellom altibox router og wan brukes det nok bare link-local adressene uansett, så skal funke fint selv om du bare har en /128 også

linknet mellom din router og altibox router vil være 2a01:798:x:x og prefix du får tildelt vil være 2a01:799:x:x

Slik ser dette ut hos meg på mikrotik:

[admin@torvmyrveien] > /ipv6 dhcp-client print
Flags: D - dynamic, X - disabled, I - invalid
# INTERFACE STATUS REQUEST PREFIX ADDRESS
0 ;;; Altibox pd
vlan-isp bound address 2a01:799:60:a00::/56, 5h34m58s 2a01:798:100:100:f193:5f2:8e4d:a7f3, 5h34m58s
prefix

Endret 11. juni 2020 av trrunde

Tiresias · 11. juni 2020

1 hour ago, trrunde said:

du får det på linknet mellom altibox router og din egen boks. I tillegg til denne får du et prefix som du kan bruke på lan.

update: nei, du skal få en /64 adresse på wan interfacet ditt, og et /56 prefix du kan bruke på lan

Men mellom altibox router og wan brukes det nok bare link-local adressene uansett, så skal funke fint selv om du bare har en /128 også

linknet mellom din router og altibox router vil være 2a01:798:x:x og prefix du får tildelt vil være 2a01:799:x:x

Slik ser dette ut hos meg på mikrotik:

[admin@torvmyrveien] > /ipv6 dhcp-client print
Flags: D - dynamic, X - disabled, I - invalid
# INTERFACE STATUS REQUEST PREFIX ADDRESS
0 ;;; Altibox pd
vlan-isp bound address 2a01:799:60:a00::/56, 5h34m58s 2a01:798:100:100:f193:5f2:8e4d:a7f3, 5h34m58s
prefix

Hmm, på min unifi kan jeg velge DHCPv6 og skrive inn Prefix Delegation Size, der jeg prøvde meg med /56. Da fikk jeg en /128 global på eth2, som er WAN-interfacet på unifi.

Da lager den en config fil med dette inholdet:

dhcp6c-eth2-pd.conf:

interface eth2 {
    send ia-na 0;
    request domain-name-servers, domain-name;
    send rapid-commit;
    send ia-pd 0;
    script "/opt/vyatta/sbin/ubnt-dhcp6c-script";
};

id-assoc na 0 {};

id-assoc pd 0 {
    prefix ::/56 infinity;
};

som den igjen starter med:

/usr/sbin/dhcp6c -c /var/run/dhcp6c-eth2-pd.conf -p /var/run/dhcp6c-eth2-pd.pid -df eth2

Har du Altibox-routeren din i Bridge mode?

Endret 11. juni 2020 av Tiresias

INNSIKT: Har du bare «gammeldags» internett? Flere skal få IPv6 i 2020 [Ekstra]

Anbefalte innlegg

Lenke til kommentar

Videoannonse

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Gjest Slettet+9817234

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Opprett konto

Logg inn

Hvem er aktive 0 medlemmer