Hjælp til naboerne i IPv6 land
Nå, efter mange år hos den samme udbyder - som jeg har været super glad for - skiftede jeg for nyligt til Gigabit.
Jeg skiftede fordi min gamle udbyder fjernede mine statiske IPv6 adresser. Tror jeg fik det til at jeg har haft de samme IPv6 prefix adresser i 10 år med native IPv6.
Det burde være muligt at få et statisk IPv6 prefix, på samme måde som vi i dag betaler for een IPv4 adresse. Jeg betalte 40kr pr md for eeeeeen fucking IPv4 adresse, men OK det var en super fin udbyder og de havde jo også givet mig statisk IPv6.
Vi er i 2021, og de danske internetudbydere burde lige tage sig sammen og tilbyder IPv6 til deres kunder.
Det jeg mener vi som minimum burde forvente er:
- IPv6 understøttelse
- IPv6 DHCPv6 Prefix Delegation, mere nedenfor
Det er ikke slemt, og burde kunne gøres med relativt få enheder, relativt lille konfiguration. Specielt fordi DHCPv6 PD er dynamisk.
Det ville også være fint hvis "statisk IP" var en service med både IPv4 og IPv6 /48 prefix. I den forbindelse var der en som skrev på Twitter:
Kviknet uddeler et fast /48 prefix. Tilbyder endvidere DNS delegation, så du selv kan håndtere reverse dns til f.eks. din mailserver.
— Claus Mattsson (@CKrogsgaard) June 27, 2021
Så hermed lidt reklame for Kviknet!
Fejlfinding
Den primære grund til at jeg skriver dette indlæg er at jeg har fået IPv6 til at spille hos Gigabit, yay - tak til Baldur Norddahl. Jeg kender Baldur gennem DKNOG men forsøgte at gå via den sædvanlige support, efter at have læst FAQ på hjemmesiden.
Det er sgu skidt når en udbyder i 2021 ikke har vejledning til IPv6 på hjemmesiden, det giver unødig supportkald/emails. Man fristes til at sige, få det nu fixet!
Det lykkedes dog at søge, og finde andre kunder som havde lidt links og bidder af information. Tak til Lauer
IPv6 på EdgeRouterX router ved Gigabit.dk
som indeholdt: dhcpv6-pd rapid-commit enable og prefix-length 48
Cool, og andre har skrevet om OpenBSD med DHCPv6
https://lipidity.com/openbsd/router/
Jeg har således konfigureret min OpenBSD med følgende, beklager pastes, men de er ikke såååå lange.
Routing / forwarding enables i /etc/sysctl.conf
net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1
IPv6 har mange adresser, rigtig mange! Disse uddeles af RIPE NCC i størrelsen /32 /29 til LIR, eksempelvis til LIR dk.zencurity - mit firma - som har fået adresserne 2a06:d380::/29 - alt der starter med disse er "mine".
Gigabit har 2a00:7660::/32 og kan således uddele prefixes til kunder. Det gøres enten manuelt - tungt og besværligt, eller med IPv6 Prefix Delegation https://en.wikipedia.org/wiki/Prefix_delegation
TL;DR man bruger DHCPv6 til dette, og jeg har en konfigurationsfil /etc/dhcpcd.conf:
ipv6only noipv6rs duid persistent option rapid_commit allowinterfaces em1 interface em1 ipv6rs iaid 1 ia_pd 1/::/48 em0/0
Mit eksterne interface er em1 og interne em0. Konfigurationen trækker således et /48 og sætter det på em0, dog som /64.
Router advertisement enables i /etc/sysctl.conf
interface em0
Når der kommer et prefix vil denne sende prefix ud til klienter, IPv6 Stateless Address Auto-Configuration (SLAAC)
Disse daemons, hjælpende ånder, enables sammen med lidt andet til boot med /etc/rc.conf.local
dhcpd_flags="em0" ntpd_flags="-s" rad_flags= sshd_flags="" syslogd_flags="${syslogd_flags} -u -a /var/unbound/dev/log -a /var/spool/postfix/dev/log" unbound_flags="" #pkg_scripts="dhcpcd zeek filebeat" pkg_scripts=dhcpcd
Det burde være nok, men det virkede desværre ikke. Jeg sendte requests men fik ikke konfigureret noget.
Endte med at skrive til Gigabit, vente, og så ringe noget tid efter.
Fun facts Neighbor Discovery Protocol
Problemet i dette tilfælde viste sig at være med Neighbor Discovery Protocol (NDP). NDP har samme funktion som Address Resolution Protocol (ARP) i IPv4. Basalt set er den bindeled mellem IP adresser og MAC/hardware adressering.
shito# ndp -an | grep em1 2a00:7660::xxxx e6:xx:37:xx:53:yy em1 23h59m34s S R 2a00:7660::xxxy fe:xx:42:xx:c8:yx em1 35s R R 2a00:7660::82xx:xxff:feef:xxxx 80:xx:xx:ef:xx:xx em1 permanent R l fe80::82ee:73ff:feef:6755%em1 80:xx:73:ef:xx:xx em1 permanent R l ...
NDP er en del af ICMPv6 - altså ICMP til version 6. Til forskel fra IPv4 hvor firewalls sjældent blander sig i ARP, så er det nødvendigt med firewall regler til ICMPv6!
Gentager, der skal åbnes for bestemte ICMPv6 beskeder ellers får man problemer med NDP og connectivity med IPv6
Det gøres elegant med OpenBSD PF:
pass in on egress inet6 proto icmp6 all \ icmp6-type { routeradv neighbrsol neighbradv }
Det er så fræk en linie, egress betyder dit eksterne interface og det er en fin liste over de beskeder som skal tillades. Hvis du har en anden type firewall, så er det beskederne med type:
134 routeradv Router advertisement 135 neighbrsol Neighbor solicitation 136 neighbradv Neighbor advertisement
Sidenote: Nu du er igang med at rode med din firewall så er min anbefaling til IPv4 at du tillader 3,4,11,12 -
3 Destination Unreachable 4 Source Quench Message 11 Time Exceeded 12 Parameter Problem Message
Sidenote2: Du bør også lige samtidig checke at din firewall tillader port 53/udp OG 53/tcp. Check også lige at den dumme DNS inspicering er indstillet til store DNS pakker osv osv. Check med https://www.dns-oarc.net/oarc/services/replysizetest
https://dnsflagday.net/2020/
Nå, men Gigabit, nu Wizer sender deres NDP pakker med afsender IPv6 som er en global unicast adresse, ikke en fe80 link local, som man ellers plejer.
Jeg fik en fin forklaring fra Baldur, tilrettet minimal:
Man skal sætte flg. system tuneable: net.inet6.icmp6.nd6_onlink_ns_rfc4861=1
på pfSense - dvs nok de fleste FreeBSDHer er forklaringen fra
https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc: "The
solution described below causes IPv6 Neighbor Discovery Neighbor
Solicitation messages from non-neighbors to be ignored. This can be
re-enabled if required by setting the newly added
net.inet6.icmp6.nd6_onlink_ns_rfc4861 sysctl to a non-zero value."
"Der er altså ikke enighed enige om det er kosher at bruge off link
adresser i NDP. Det virker med Linux og de fleste "almindelige" wifi
routere (dem du kan købe i El-giganten etc).
Min løsning inden jeg fik dette var at overbevise min OpenBSD om at det rent faktisk var et linknet mellem mig og deres routere.
Dette gjorde jeg ved at bruge min MAC adresse til at lave en globalt unik EUI-64 identifier, strækker bare MAC og flipper en bit.
Så min MAC 80:xx:73:ef:xx:xx blev altså til 82xx:73ff:feef:xx, som sammensat med prefix fra Gigabit blev til en enkelt linie i min /etc/hostname.em1:
inet6 alias 2a00:7660::82xx:73FF:FEEF:xxxx 64
Det virkede, for så kunne enhederne finde hinanden med NDP, DHCPv6 fik sit prefix, konfigurationen af netkort internt gik som smurt, og min router advertisement sprøjter /64 ud på lokalnet - som enhederne opfanger og laver til globalt unikke adresser (med privacy extensions).
Easy peasy!
Stats og opråb
Hvorfor nu alt det her besvær?! og hvad skal de stakkels internetudbydere få ud af det, og forbrugerne er sgu da ligeglade!
Vi mangler adresser, punktum. Business case for IPv6 er adressering. Når vi mangler adresserne, som man opdagede i start 1990erne så laver man krumspring. De krumspring inkluderer CIDR, NAT, mere NAT, CGNAT, STUN, TURN, ...
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Det er 10.000vis af kodelinier, flaskehalse, ekstra gøgl - klytkode som PHK måske ville sige.
Hvis man har IPv6 er der langt mindre state i netværket, back to basics - og det som gjorde internet til en success i første omgang. Når vi snakker sikkerhed vil jeg også meget hellere have en god adresseplan med IPv6, ingen NAT, fornuftigt design! Faktisk vil I kunne udnytte mange steder at I starter på en frisk og har NOK adresser.
Min opfordring er at I allesammen undersøger mulighederne for at slå IPv6 til på jeres udstyr og hos jeres ISP!
Jeg har målt over et par dage og ligger omkring 30-45% af mine connections er IPv6. Det er alt fra Netflix, Google services som Youtube og selvfølgelig en masse af mine egne services, egen mailserver med IMAP. Det er fordi så godt som alle enheder på mit netværk hjemme forstår IPv6.
Det betyder at hvis 1 million kunder skal streame over CGNAT skal de allesammen igennem noget udstyr hos udbyderen, der skal håndtere alt - fulde båndbredde i få enheder.
Hvis de samme kunder kunne bruge IPv6 ville udbyderen frit kunne route pakkerne stateless, effektivt, redundant, uden de store problemer.
PS Update 12:00
Jeg glemte sgu da et officielt lydspor til dette indlæg!
Jeg har derfor skyndt mig at søge på Better Late Than Never og blandt dem udvalgt, Better Late Than Never, Magnus Ringblom
https://www.youtube.com/watch?v=kPqMSAdEVOE Det er tilpas afslappet, og vil egne sig godt som baggrund til IPv6 konfiguration :-D
https://open.spotify.com/track/23QxD9s7JyiaU2qrKL4WsI?si=ea257df5f68b4cd8 for dem som har Spotify
Kl 14:18 Addendum ICMPv6
Der er som Benny i kommentarfeltet bemærker, tak Benny, også andre ICMPv6 beskeder man gerne ser bliver sendt videre, det er specielt de første her:
Allow ICMPv6 destination unreach $fwcmd6 add pass ipv6-icmp from any to any icmptypes 1 Allow NS/NA/toobig (don't filter it out) $fwcmd6 add pass ipv6-icmp from any to any icmptypes 2 Allow timex Time exceeded $fwcmd6 add pass ipv6-icmp from any to any icmptypes 3 Allow parameter problem $fwcmd6 add pass ipv6-icmp from any to any icmptypes 4

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.