Root.cz přes IPv6 se nezobrazí ve Firefoxu

[Grumpa]

Mám router Mikrotik s nastavenou IPv6 a některé weby (root.cz, freebsd.org,...) se ve Firefoxu nenačtou, ale v Chrome ano. Po zobrazení v Chrome se ukáží i ve Firefoxu.

Když použiji router TP-Link Archer C7, tak vše běží bez problému. Tam se dají zapnout nějaké autokonfigurace, takže nevidím dovnitř nastavení.

curl načte http:// bleskově, ale tam je přesměrování na https:// a tam se už zasekne. root.cz

Měl jsem Mikrotika s IPv6 několik let a vše běželo dobře. Teď jsem koupil novější model a současně přešel z WiFi providera na DSL/PPPoE.

Router je dostupný na vnější IPv6 adrese a routuje i na global IPv6 co jsou ve vnitřní síti. Konfigurace by měla být v pořádku.

Nejsem první, kdo se s tím párá: https://www.reddit.com/r/ipv6/comments/qdk8kf/firefox_cant_open_some_ipv6_websites/

Bohužel nevidím řešení. Poskytovatel taky ne, prodejce routeru taky ne.

Děkuji předem za pomoc.

[Reklama]

[M_D]

Co máš nastaveno na tom Mikrotiku pod /ipv6/nd za parametry ohlašované do LAN, zejména parametr mtu (ponížen patřičně o PPPoE záhlaví)? V kombinaci s nějakou blbostí v ipv6 firewallu (zahazující ICMPv6), tak je to dobrý způsob odstřelení provozu.

[Michal Šmucr]

Já bych to tipoval taky na MTU inzerované klientům přes RA z modemu/routeru.
V linuxu je to vidět v /proc/sys/net/ipv6/conf/<iface>/mtu
PPoE musí mít MTU 1492 a IPv6 provoz se nefragmentuje, Google servery chodí vždy, protože mají natvrdo 1280.
Na pokus můžete pak nastavit na síťovce u počítače natvrdo MTU 1492, uvidíte jestli to bude tím. A pak to případně řešit dál.

Nebo něco s DNS (udělal bych asi pár dotazů přes příkaz host s různými DNS servery). Je možné, že třeba jeden z prohlížečů používá DoH přes nějaký veřejný server jako Cloudflare, Google DNS.. atp.

Ale to jsou teď takové výstřely od boku.

[metabug]

Pro IPv6 přes PPPoE je MTU 1452 byte (1500-8-40), viz https://baturin.org/tools/encapcalc/?protocols=PPPoE,IPv6

[Michal Šmucr]

Pro IPv6 přes PPPoE je MTU 1452 byte (1500-8-40), viz https://baturin.org/tools/encapcalc/?protocols=PPPoE,IPv6

Tohle ale není délka MTU, co se posílá přes ICMPv6 RA.

Délka MTU je pro interface a o úroveň níž na linkové vrstvě L2 - tzn. s PPPoE je to 1500 (standardní délka rámce) - 8 (PPP header) = 1492 B.

A ano pak je tam nad ní L3 IP header (dalších 40 B pro IPv6) a následně na L4 typicky buď TCP (20-60 B) nebo UDP header (8 B). Tím se pak dostáváme k maximální velikost segmentu - MSS.

Jen teď rychle z hlavy. Možná když se zastaví Danny, tak dodá i odkazy na ta správná RFCčka

[Reklama]

[M_D]

Add to očekávání, že na PPPoE bude MTU1492, tak pozor na to - nemusí být. Zvláště pokud tam má Mikrotik, tak pokud při nastavování PPPoE klienta si MTU nenastavil ručně, tak má defaultně: max-mtu (integer; Default: 1460), max-mru (integer; Default: 1460)
Aktuálně platné hodnoty (které si server-klient odsouhlasili) je vidět v statusu toho PPPoE spojení jako MTU a MRU.  Pokud tam mám míň jak 1492, tak bych se i zeptal ISPíka, co max umí jeho síť a dle toho opravil. A nejlépe, zda i podporuje RFC 4638, pak i na PPPoE může být MTU 1500 - když už chceme, aby zaznělo i nějaké RFC. :-)

[Michal Šmucr]

Díky za další info a konečně i nějaké RFCčko

Já se s PPPoE v našich končinách setkával primárně na běžných xDSL připojeních CETINu a tam bylo MTU v podstatě vždycky 1492.

Uvidíme, co napíše tazatel, až si to vyzkouší.. třeba jsme úplně mimo a bude to něčím úplně jiným. Ale já jak slyším, že má někdo IPv6, servery Google chodí, ale nějaké jiné ne, tak mě vždy napadne tenhle problém jako první.

Asi i štěstí, že má router, kde se to dá ovládat. Zažil jsem i modem s routerem, co to posílal vždycky 1500 a nedalo se to nastavit. Jako workaround pak fungovalo to, že když naběhl, tak jsem se tam připojil povoleným telnetem , upravil radvd.conf a restartoval démona. Což vydrželo do dalšího restartu routeru

[jjrsk]

Vzivote sem nevidel ze by problem byl s mtu, ale opakovane sem videl, ze dotycny mel zafirewallovany icmpv6 (protoze na v4 se to tak prece dela) a pak se divil.

[Petr Krčmář]

Jenže to spolu přímo souvisí. Když se někde po cestě ztrácí ICMPv6, tak ke klientovi nedorazí paket Fragmentation needed a ten se nedozví o neprůchodné cestě, kde se mu ztrácí provoz.

Výsledkem je stav, kdy všechno padá do černé díry a vy to nevíte. Nějaký jednoduchý provoz (třeba HTTP s přesměrováním) ale projde, protože to jsou jen maličké pakety. Viz článek Velké trable s malým MTU.