Neoficiálna dokumentácia k novým Orange DSL prípojkam s IPv6

Istý čas už Orange ponúka svoje DSL prípojky s IPv6 pre nových zákazníkov. Existujúci zákazníci môžu o zmenu požiadať, zmena je bezplatná, ale iba smerom z IPv4 k IPv6. Smerom z IPv6 na IPv4 alebo len IPv4 sú možné poplatky. To by ale nemal byť problém, keďže moderný internet je IPv6 a IPv4 pomaly, ale isto kape. Ono to bol škandál, že sa ISP (internetoví service provideri) zobudili až po 15tich rokoch a začali ponúkať IPv6 až teraz. V prípade nemecka napríklad u Kabeldeutschland (teraz Vodafone) to začalo skôr, ale aj to je neskoro. Medzitým existovalo kopec providerov, ktorí robili oboje veci. MNet napríklad mal na svojich DSL prípojkach vždy možnosť pre každého zákazníka pridaním nejakého prefixu, alebo suffixu za prihlasovacím menom pre PPPoE aktovovať dodatočnú, ale experimentálnu, čiže nepodporovanú možnosť, sa dostať k IPv6 prefixom.

Prefix verzus adresa

Už pri poslednej vete úvodu, sme prišli k tomu, že musíme najprv ujasniť terminológiu, čo myslíme pri IPv4 adrese a čo je toho ekvivalent pri IPv6. Teda prefix. Orange ešte stále používa termín IPv6 adresa, čo je fakticky nesprávne používanie. IPv4 pripojenie do internetu cez DSL funguje tak, že sa vytvorí PPPoE tunnel cez Ethernet spojenie k modemu, ktorý je cez telefónnu linku spojený s DSLAMom, ktorý toto zas mixuje do Ethernetu (svetlokábel) na strane providera. V prípade T-Comu to ide potom vo VLANoch do BRASov, ktoré prideľujú IPv4 adresy. U Orangu je to tá istá posledná míľa, čiže môžeme vychádzať z toho, že to funguje tak isto. V každom prípade sa ale stane to, že keď je PPP spojenie úspešné, po authentifikácii cez meno a heslo, je tomuto PPPoE tunnelu pridelená IPv4 adresa a štandardná cesta (defaultroute) von do internetu cez providerov router. Keď potom router toto skombinuje so schopnosťou NATovať, čiže prepisovať interné adresy na ceste von tak, že to vyzerá, ako keby boli všetky poslané z tejto jednej adresy, ktorú sme dostali pridelenú, tak môžeme pripojiť na toto DSL pripojenie celé siete doma. Pri IPv6 toto skončilo definitívne. A bolo aj na čase, keďže NAT prinášal ďaľšie problémy, ktoré sa zas potom riešili port-forwardingom a podobnými preverznosťami. V tomto dokumente sa chcem zaoberať výlučne IPv6 pripojením cez DSL od Orangu a nie inými providermi, lebo tých možností je tu viac. To treba vedieť, že nie je prípojka ako prípojka a PPPoE komplikuje situáciu ešte viac. A práve tento problém v prípade Orangu zákazníkovi hneď pri začiatku zaoberaním sa s týmto prechodom udre do tváre. Prechod u Orangu je z toho čo som ja videl, a toho som ja videl už mnoho, nie len na DSL, ale aj na DoCSIS prípojkach, najbrutálnejšie. Preto je aj tento dokument tak dôležitý. Na teraz je ale len dôležité vedieť, že IPv6 pripojenia nedávajú IPv6 adresu, ale prefix, ktorý je použitý každým počítačom v sieti na to, aby si mohol podľa neho dať verejnú (globálne routovateľnú adresu). Ano, adresu si prideľuje každý počítač, router, smartfón, televízor, tlačiareň, alebo ktorýkoľvek IPv6 kompatibilný prístroj sám. Od providera je len tzv. prefix čiže niečo ako predvoľba u telefónov. U Orangu je táto predvoľba dlhá 56 bitov. 8 bitov teda ostáva pre router, z ktorých si môže vybrať na pomenovanie svojich sietí. A zostatkových 64 bitov je pre každý prístroj v sieti na vygenerovanie si vlastnej adresy z MAC adresy, alebo vymyslenia si nejakeho čísla (tzv. privacy extensions). S takto vygenerovanou 56 + 8 + 64, teda 128 bitovou adresou potom ide každý prístroj pripojený na sieť do internetu.

Fundamentálne Orange riešenie pripojenia IPv6 pre DSL

Fundamentalizmus Orangu v tejto veci sa prejaví v prvom rade v tom, že po prechode na IPv6 človek najprv príde o komplet pripojenie IPv4. Toto som ešte nezažil. Namiesto pridelení nejakej privátnej IPv4 adresy, ktorá je potom carrierNATovaná, ako to poznáme u mobilných internetových pripojeniach už roky (3G/UMTS, 4G/LTE a pod), alebo ozajstného dualstacku, kde je pridelená verejná IPv4 adresa a dodatočne ešte k tomu aj IPv6 prefix, ako to poznáme u káblových providerov (káblovej televízie - DoCSIS), Orange v tomto prípade používa tunel, na získanie IPv4 konektivity, ako som mal ja predtým riešenú IPv6 konektivitu cez HE tunel. Veľmi podobne funguje aj toto. Nevýhoda tohoto je ale samozrejme, že kým si toto človek nastaví, dostane sa len do IPv6 internetu, čiže google a facebook pôjde, ale iné stránky (okrem iného aj orange.sk) nepôjdu, lebo sú len na IPv4. Úsmevne teda môžeme podotknúť, že pre veľa užívateľov smartfónov sa nič nemení, keďže facebook IPv6 pripojený bol už vždy. Ďaľší šok je ale, keď ľudia zistia, že im cez PPPoE bol pridelený len link-local. Čiže vlastne nič. Toto je síce konsekventné, ale najprv je človek pripojený k Orangu a prd z toho vypadne. Teda PPPoE už nie je tá technológia, ktorá prideľovala adresy, čo je aj logické, keďže teraz už nemáme adresy, ale len prefixy. Cez náš PPPoE už len musíme získať tento prefix. To celé znie komplikovane, ale v skutočnosti je to jednoduchšie ako sa zdá. Treba si len uvedomiť, že na druhej strane tejto PPPoE linky je Orangacky router. Ak tento cez jeho link-localnu adresu pingneme, tak zistíme, že tých ca. 20 ms trvá odpoveď je naša latencia na DSL linke. Čo je psychologicky dôležitá vec, lebo tam už vidíme svetlo na konci tunela. Teraz ale toho železničného.

/etc/hostname.pppoe0

pppoedev cnmac1 authproto pap authname '...@orangenet.sk' authkey '...' up
inet6 eui64
!/sbin/route add -inet6 default -ifp pppoe0 fe80::
  

Sem s tým prefixom, čúl

Ak má človek na routeri nainštalovaný OpenWRT, tak nemusí robiť nič, keďže štandardné nastavenie je pre každý WAN interface žiadať si prefix cez DHCPv6. Ak ale toto nemáme, tak si musíme nainštalovať DHCPv6 klienta, ktorý podporuje Prefix Delegation. A tu sa začína prúser, keďže ISC DHCP nepodporuje PPPoE interface, resp. všeobecne DHCP na tuneloch (layer3). WIDE-DHCPv6 nedokáže zaobchádzať so situáciami kde máme viac sietí, aj keď je to dokumentované, že to údajne dokáže, okrem iného je známe, že ten software nebol aktualizovaný od roku 2008, čiže je aj zbytočné robiť k tomu bug report. Prdel človeku zachráni len dhcpcd. dhcpcd dokáže DHCPv6 PD a rozhádže toto aj po viacero sieťovkách správne. Konfigurácia je až smiešne jednoduchá.

noipv6rs
interface eth0
ia_pd 3 eth2/1 eth3/2
  

Toto nie je moja konfigurácia, ale príklad z manuálu pre dhcpcd.conf, ale niečo v tomto zmysle je OK. Tie router-solicitationy sú pri tuneloch na hovno. Človek mu musí dať meno WAN interfacu. A potom PD pre interfacy rozhádzať. Manuál dokumentuje syntax. Šokujúco triviálne, tak to má byť. Ostatné nastavenia majú estetický charakter. V sieti sa tieto prefixy samé distribuujú cez router advertisementy nášho routera.

Pre porovnanie moja konfigurácia

slaac hwaddr

ipv6only
noipv6rs
interface pppoe0
ia_pd 1/::/56 cnmac0/32/64/0 cnmac2/19/64/0
  

No dobre, IPv6 funguje, a čo teraz s IPv4

Ako som už spomenul, IPv4 konektivitu zabezpečuje tunel. Čiže ho najprv treba vytvoriť. Na Linuxe je to jednoducho tunnel cez IPIP6 mode parametrom. To znie jednoducho, ale zbytočne komplikované na nastavenie. BSD má gif interface a ten je totálne jednoduchý na nastavenie. Hlavná výhoda tohoto riešenia je, že ho môžem ľahko nakonfigurovať a potom riešiť iba tunnel parameter, keď mám IPv6 spojenie. Tohoto ale výber človek nemá, keďže každý router má iný set podporovaných operačných systémov a na starej MIPS32 architektúre už ich nie je moc. Pre MIPS32 je to teda len Linux (a možno raz NetBSD). Tento tunel musíme teda už nech sme ho vytvorili akokoľvek, nakonfigurovať s nejakou IPv4 adresou na našej strane a v prípade Linuxu aj na ich strane. Túto adresu si môžeme voľne vymyslieť, ale nemala by byť použitá ani u nás, ani niekde v internete, čiže by to mala byť adresa privátneho subnetu, ktorý ale nepoužívame inde. Cez túto IPv4 adresu si nakonfigurujeme východziu cestu (default gateway). Opcionálne môžeme na túto nastaviť NAT, dôležité to ale nie je. Bez NATu si človek ušetrí nejaké takty na CPU routera, keďže NAT nám robí provider aj tak. Adresa von je zdieľaná so všetkými napojenými na tento tunel. Jediné, čo potrebujeme vedieť, keď máme tunel nastavený je IPv6 adresu druhej strany, čiže tzv. AFTR-servera od Orangu. Tento AFTR server sa dá vyžiadať cez DHCPv6. Sám by som na to neprišiel, keď by som ho nevidel v dumpe. Na ten DHCPv6 PD príde človek logicky preto, lebo to je štandardný a jediný spôsob rozdávania prefixov, ale keď by na to človek náhodou neprišiel ako je riešená IPv4 konektivita, tak by bol človek dosť v prdeli, keďže Orange sa k tomu nevyjadruje, pravdepodobne preto, lebo sami nevedia, ako to funguje, a boh vie kto im to tam nastavoval u nich. Vec funguje ale tak, že IPv4 packety sú cez IPv6 tunel k AFTR-serveru posielané a hotovo. Všetko ostatné jednoducho funguje resp. o to sa stará AFTR server.

/etc/hostname.gif0

inet 192.168.0.1 255.255.255.255
mtu 1452
up
!/sbin/route add -inet default 192.168.0.1
  

Tam ale ešte chýba vytvorenia tunela, ale pri štarte ešte nemáme konektivitu, takže na to používam zatiaľ manuálny skript:

zisci_ipv6global.sh

#!/bin/ksh
ifconfig cnmac0 inet6 | awk '{ af=$1; addr=$2; if ( af == "inet6" ) { if ( substr(addr, 1, 1) == "2" ) { print addr; exit } } }'
  

fixni_ipv4tunnel.sh

#!/bin/ksh
ipv6globaladdr=`/root/zisci_ipv6global.sh`
ipv6aftrserver=`cat /root/orange_aftr.txt`
if [ -n "$ipv6globaladdr" ]
then \
  ifconfig gif0 tunnel "$ipv6globaladdr" "$ipv6aftrserver"
fi
  

Všeobecné problémy s PPPoE

Testovaním som prišiel na to, že niekedy nenabehne PPPoE ani po dlhom čase a stále sa pripája a odpája, čo vedie k ozvaniu chybe ako:

pppoe0: host unique tag found, but it belongs to a connection in state 3
pppoe: received PADO but could not find request for it
  

Toď vidíme, že sa chnápu o spojenie PPPoE dva BRASy, v mojom prípade sú to N-101-BA-BAS-10-G61BQ1911Q03P5 a N-005-BA-BAS-10-G61BQ1311Q0352, a vždy jeden zoberie prípojku, potom ju chce zobrať druhý a prvému povie nech ju odpojí, pričom už prvý povedal jasne, že ju má, čiže sa terminuje spojenie a potom ten cirkus začína odznova a tak ďalej donekonečna.

Moje riešenie je, že blokujem všetko, čo má MAC addressu 02:03:45:04:a2:c3, čo je jeden z tych BRASov a tým ostane len ten druhý. Teraz by ale bolo blbé, keď by Orange vyriešil najblyžšie problém tým spôsobom, že tam nechá iba ten, keďže potom by nešiel internet vôbec, bez toho aby sa to zas prehodilo naspátek.

Tu nám ale naozaj kreatívne pomáha OpenBSD skrz ich bridge implementáciu, skrz ktorej pridaním mám možnosť packety filtrovať na Ethernet karte/porte, na ktorej mám napojený DSL modem.

/etc/hostname.bridge0

add cnmac1
rule block on cnmac1 src 02:03:45:04:a2:c3
rule block on cnmac1 dst 02:03:45:04:a2:c3
up
  

Linky

Kontakt

Lars Schotte
Mudroňova 13
92101 Piešťany

Email: gustik@gustik.eu