IPv6 a vše kolem

[hapi]

tak koncepce platná pro 99.5% zákazníků co přijdou domu a připojej si zařízení a jedou. Víc je nezajímá. Připojení firmy je většinou něco extra a defakto /56 která je vyhrazená pro všechny na jednom APčku se dá tý firmě i když pochybuju že by to nějak využily ale ta možnost tu prostě je.

Mě by ale zajímala uplně jiná věc. Dneska je moderní, nebo mělo by být, že přijdu domu, vemu si telefon a pomocí DLNA/UPNP si pustim nafocený fotky na televizi. To docela slušně funguje. Nicméně pokud UPC říká že vyhradí pro každý rozhraní routeru jeden /64 prefix tak se defakto přes wifinu na ethernet broadcastem nedosatnu a DLNA zařízení se nenajdou... super to ale pak musí bejt rozsekaný i ipv6 na nějaký menší subnety ne? nicméně problem s těmito službami zůstává.

[Majklik]

DLNA a UPnP používá multicast.
Problém je, pokud máš zařízení s podporou IPv4 jen a router, který při aktivaci IPv6 oddělí wifinu od LAN (některé DLinky to dělají a jejich fóra je plná křiku, že po aktivaci IPv6 tohle přestane jít).

Co se týče, UPnP, tak to přímo IPv6 podporuje a funguje přes víc subnetů (ale koncových zařízení s IPv6 UPnP moc není). DLNA snad dosud ani nemá pro IPv6 specifikaci (pro UPnP je 9 let)?
UPnP používá site local multicast při IPv6 (ffx5::/16), to znamená, že router jej předává mezi všema subnety, které patří do dané fyzicky lokální sítě a tím se ty krámy vzájelmně můžou najít i když jsou na různých /64 subnetech. Jiná věc je, že podpora IPv6 multicastu v koncovch routerech také není nejlepší (ROS nevyjímaje).
Funkční UPnP s IPv6 mají mít nkteré novější LG televize třeba.

[hapi]

no ale s TTL1 takže se to přes router nedostane což musí když to má jít do jinýho subnetu a to ono nejde. Právě si s tim teď hraju. Už kvůli bezpečnosti to jít nemůže. DLNA je docela nechutně otevřený.

[Myghael]

Že by úprava TTL s tím, že to router propustí pouze do LAN rozhraní? Což se dá mimochodem ještě ošetřit, pokud se tyhle věci bez pardonu dropujou mezi WAN/LAN.

[Majklik]

Multicast paket má mít vždy TTL=1. A spousta zařízneí to nedodržuje a cpe tam 64 nebo kolik mají default hodnotu. Router nikdy nesmí multicast paket tupě zaroutovat, ať má TTL jakékoliv, vždy na základě adresy má rozhodovat, co s ním. Že je realita jiná a většina routerů je tupě pošle obvykle směrem k default bráně, když dojde multicast s TTL>1, je věc jiná. Slušný firewall by to měl vždy dropovat.
U IPv6 je přímo v adrese zakódován rozsah platnosit toho multicstu a router ho má předat dle toho předávat na další lokální ozhranní (pokud je to třeba ten local site) i v případě, že mu došel s hop limit=1. Takže u IPv6 multicastu o tom, kdy se paket už zlikviduje a nepustí dál nerozhoduje hop limit (ekvivalent TTL v IPv4), ale ty 4 bity definující rozsah platnosti a patřičně tak nakonfigurované routery ty hranice platnosti tvořící. Ono dokonoce u IPv4 specifikace vyžaduje, že multicast paket musí mít TTL=1 (ale hodně zařízení na tokašle) a u IPv6 je to už, že by multicast paket měl mít hop limit=1.

[helapc]

Pročetl jsem to celý (hapi se drží super) a rád bych se zeptal na přidělování IPV6 prefixů.
Mám vlastní AS a dvě konektivity. IPV4 jsem získal jako PI /21 dodatečně jsem se zaregistroval u RIPE a udělal tam Router Object. NESTAL jsem se LIR. To se mi fakt nechtělo. IPV6 prefix mi odmítli dát. Na IPV6 day mi potvrdili, že když to odůvodním tak mi ho daj. Jesli jsem vše správně pochopil tak, ale stejně dostanu jen /48. Opravdu není cesta jak se dostat k /32 bez investice 80k? Protože při týhle konfiguraci jsem někde uprostřed mezi tím co popisujete.

[Majklik]

Pokud řešíš získání prefixu přes jiného LIRa, lze naráz získat max prefix /47 (po formálním dopředném souhlasu RIPE, jinak max /48).
Pokud chceš prefix kratší, těch /32, tak musíš jít přímo za RIPE.
Možná pro to /32 ani lézt do RIPE nemusíš, existuje procedura direct assignment od RIPE. Nicméně poplatek za ní je stejný, nebo větší, jak když se staneš LIRem. Navíc prostředky získané v rámci DA můžeš používat jen pro svoji potřebu a nepřidělovat dalším subjektům, což jako ISP budeš asi chtít dělat.

[helapc]

Tak jak jsi to napsal to chápů. Jen mě truchu zaráží, že na IPV4 jsem mohl udělat sám jako PI router object a u IPV6 to nejde. No nic budu IPV6 testovat a čekat, až půjde € dolů.

[Majklik]

Jsem se díval, tak cenově tě vyjde stejně, jestli se staneš LIRem a nebo požádáš o DA. Jediný rozdíl je v tom, že při DA dostaneš opět jen PI /48, kdežto LIR za stejnou cenu /32. Evidentně RIPE nechce, aby je každý obtěžoval a tu /48 si bral přes jiného LIRa (alá isp servis).

Myslím, že kurz eura se za chvilku bude velmi hroutit, jen aby RIPE patřičně poplatek nezvedlo...

Apropo, nezkoušel jste někdo náhodou v novějších ROSech, zda už funguje OSPFv3 přes GRE tunely? Nebo stále není možnost nastavit fiktivní link local adresy na GRE (jak jde v Juniperu a podobných) a tím pádem je OSPFv3 pasé a člověk se musí stále párat s BGP a případně confederacemi v něm...

[hapi]

tak, téměř měsíc využívám IPv6 a pomocí pluginu ve firefoxu (sixornot) sleduju přes jaký protokol přistupuji k webům a nestačim se divit. Naprostá většina webů má fungující přístup přes IPv6. Je tedy čas začít z ostra nasazovat IPv6 i ke klientům. Jsem připojen přes testovací router kde mám advertise a win7 si berou IPčko skrz to.

DNS se řeší stále přes IPv4 takže moje otázka zní velmi jednoduše a to jakým způsobem dostat do win7 i DNS IPv6 a jak rozchodit DHCPv6 na mikrotiku.

Wiresharkem jsem zjistil, že v RA se DNS servery posílají v luxusní podobě ale win7 si je z toho neberou a čekají na DHCPv6. DHCPv6 jsem tak nějak nastavil, popřepínal přepínače v RA ale win7 nic. Nevzali si nic ačkoliv wireshark ukazoval přítomnost DHCPv6 paketů. Funguje někomu DHCPv6? Jak ho máte nastavený?

Extrémní problém nastává v mikrotiku, když si člověk hraje s IPv6 adresami a Neighbor discovery tak zjistí že najednou si z PCčka nepingne na router v lokání síti přes IPv6 a musí se zakázat a povolit IPv6 adresa na routeru. Nebo prostě adresa na řádku zčervená jako že je špatná a nefunguje. Dost zabugovaný. OSPFv3 stále hází do logu chybu o "locally originated" a mikrotik o tom říká že to někdy odstraní a že to je jenom chyba která se nemá ukazovat.

[ludvik]

Na tohle jsem si musel udělat script ... po bootu načte IP adresy (link local, fe80) a firewall dropuje OSPF s těmito source adresami. Pak je konečně klid. Stává se to, pokud je na daném interfacu i nějaké Queue, tak ať mi neříkají, že je to jenom chyba logování ...
Mimochodem to musí být udělané jednotlivě v chainu. Přes address-list to nefungovalo.

OSPFv3 stále hází do logu chybu o "locally originated" a mikrotik o tom říká že to někdy odstraní a že to je jenom chyba která se nemá ukazovat.

[hapi]

jo tak s tim se ještě dá žít. Ale už několik hodin se snažim aby win7 získaly DNS skrz DHCPv6 a prostě nic ačkoliv by to mělo být údajně normální chování windowsů.

[ludvik]

Umí vůbec MK stateless DHCPv6?

jo tak s tim se ještě dá žít. Ale už několik hodin se snažim aby win7 získaly DNS skrz DHCPv6 a prostě nic ačkoliv by to mělo být údajně normální chování windowsů.

[hapi]

podle me umi. Ale nepodarilo se mi to rozchodit. hdcp nikdy nepustilo ipcko.

[ludvik]

Ono to totiž na Win7 funguje. Adresa (a defaulta) z SLAAC, DNS servery ze stateless DHCP (jenže proti čistému linuxu - Quagga + Dibbler). Z toho bych usuzoval, že DHCPv6 v mikrotiku je pouze statefull - tedy musí dát jak IP adresu, tak DNS servery.
Ale co jsem s tím relativně nedávno laboroval, tak jsem to zahodil. Spolehlivě chodí tak SLAAC a DNS musí mít klienti normálně ipv4. Nic víc. Ještě hodně práce mají před sebou.

podle me umi. Ale nepodarilo se mi to rozchodit. hdcp nikdy nepustilo ipcko.