okoun
Samozřejmě nečekám, je mi ty procenta přijdou jako správný podíl IPv6.
Takže usuzuji, že většina klientů běží.

    Vezmu to postupne, co me napada:

    • na PPTP interface (server) by nemelo byt /56 ale spis /64 a nejspis bude potreba mit zapnuty advertise (v mikrotiku, pokud lze)
    • nepingnutelnost /120 ve vnitrni siti z Internetu vypada jako problem firewallu; jak vypada traceroute z nejakeho takoveho stroje ven do Internetu?
    • "nejak nefungujici" stranky indikuji problem bud ve firewallu (zahazovane icmpv6, dropovany provoz ve forward chainu), MTU (na ceste je MTU mensi nez 1500 a nekdo zahazuje ICMPv6 packet too big) nebo blackholing (pakety nejsou doruceny, cestou se ztrati)
    • pokud se spojeni navaze, podari se odeslat http pozadavek, ale nevrati se odpoved od serveru (lze overit pomoci curl -v http://...), je to na 99 % problem s MTU
    • fallback na IPv4 se v browserech typicky provadi pokoci happy eyeballs (existuji dve verze, starsi ma cislo rfc6555) a probehne do nekolika stovek milisekund. To ovsem plati jen pro spojeni, ktera po IPv6 nelze navazat - pokud se spojeni navaze, ale zatuhne (viz vyse - problem s MTU, blackholing, firewallovani icmp...), tak to uzivatel popisuje jako "nefunkcni Internet, nekde se stranky dlouho nacitaji")
    • z prikladu s Routerem, AP a CPE mi neni jasne, kde bezi DHCPv6 server pro prefix delegation - nemuze bezet zaroven na routeru i AP, pokud jsou v jedne L2 siti. Pokud je AP ciste jen AP, vypnul bych tam DHCPv6 server. Jinak muze pridelovat prefixy, ktere nebudou routovane do Internetu. Na routeru ma bezet bud DHCPv6 server nebo DHCPv6 relay, ale relay pokud vim dlouho u mikrotiku neinstalovala prefixy z DHCPv6 PD do routovaci tabulky mikrotiku (coz z toho cini nepouzitelnou komponentu, pokud si to clovek nedobastli skriptem sam).

      zajdee
      PPTP jsem vyzkoušel a /64 je nutnost, s tou /56 to opravdu nefunguje.

      No právě to je ten problém - tracert z venku se dostane až na mou adresu k bgp a dál už ne,
      Obráceně se ven taky nedopingam. Ve firewallu není nic, a bgp route filter také nejsou ( takže bych měl mít full bgp ale to blokuje upstream provider - jdou od něj jen jeho prefixy )

          zajdee

          • PPTP nepoužívám.
          • MTU zní zajímavě - vyzkouším CURL.
          • DHCPv2 běží na routeru i na APčkách. Z Routeru se přidělují prefixy pro AP /51 a ty přidělené pak AP přiděluje klientům /56

              zajdee k tomu MTU 1500 by mě tedy zajímalo jak to dělá PPFka a ostatní VDSLkaři když jejich MTU určitě není 1500 🙂

                  okoun Moje MTU je kvůli PPPoE 1492 (jestli si dobře pamatuji) a možná právě to je ten problém. Příkaz curl mi vypsal následující:

                  • Rebuilt URL to: https://sbazar.cz/
                  • Trying 2a02:598:a::78:23...
                  • TCP_NODELAY set
                  • Connected to sbazar.cz (2a02:598:a::78:23) port 443 (#0)
                  • schannel: SSL/TLS connection with sbazar.cz port 443 (step 1/3)
                  • schannel: checking server certificate revocation
                  • schannel: sending initial handshake data: sending 174 bytes...
                  • schannel: sent initial handshake data: sent 174 bytes
                  • schannel: SSL/TLS connection with sbazar.cz port 443 (step 2/3)
                  • schannel: failed to receive handshake, need more data

                  Taky se mi podařilo zjistit, že ty problémy jsou hlavně na protokolu https, takže např. http://mapy.cz projde, ale https://mapy.cz už ne a to i přesto, že při http se to automaticky přesměruje na https.
                  Co může být špatně? ICMPv6 mám průchozí, ale v IPv6 firewallu mi na DROPu vypadává hodně spojení jako invalid.

                      U mne je CURL takto:
                      `Microsoft Windows [Version 10.0.18363.836]
                      (c) 2019 Microsoft Corporation. Všechna práva vyhrazena.

                      C:\Users\Mirek>curl -v http://mapy.cz

                      • Rebuilt URL to: http://mapy.cz/
                      • Trying 2a02:598:a::79:138...
                      • TCP_NODELAY set
                      • Connected to mapy.cz (2a02:598:a::79:138) port 80 (#0)

                      GET / HTTP/1.1
                      Host: mapy.cz
                      User-Agent: curl/7.55.1
                      Accept: /

                      < HTTP/1.1 301 Moved Permanently
                      < Server: nginx
                      < Date: Mon, 18 May 2020 08:38:42 GMT
                      < Content-Type: text/html
                      < Content-Length: 162
                      < Connection: keep-alive
                      < Keep-Alive: timeout=60
                      < Location: https://mapy.cz/
                      <
                      <html>
                      <head><title>301 Moved Permanently</title></head>
                      <body>
                      <center><h1>301 Moved Permanently</h1></center>
                      <hr><center>nginx</center>
                      </body>
                      </html>

                      • Connection #0 to host mapy.cz left intact
                        `

                      Pro HTTPS to bypíše asi celý HTML kód.

                      radek_kovacik jasný ale všech lidí co mají VDSL také a ipv6 mají že 😃

                        Tak jsem se na to díval a MTU je automatikou nastavené na 1480, omlouvám se za chybný údaj. Konfiguraci toho PPPoE mám takto:
                        /interface pppoe-client
                        add ac-name="" add-default-route=yes allow=pap,chap,mschap1,mschap2 default-route-distance=1 dial-on-demand=no disabled=no interface=Port1 keepalive-timeout=10 max-mru=auto max-mtu=auto mrru=disabled name=WAN-PPPoE password=TO2 profile=PPPoE service-name=Data use-peer-dns=yes user=TO2
                        Proč ty zabezpečený stránky nefungují a proč jen na některých serverech?

                          jcltm Já musel nastavit u ND také MTU na 1460, ale PPPoE MTU mám na 1480. Pohrál bych si s tím, ale není to moje přípojka a takhle to momentálně funguje.
                          /interface pppoe-client add add-default-route=yes comment=WAN disabled=no interface=vlan848_ether1 max-mru=1480 max-mtu=1480 name=pppoe848_vlan848_ether1 password=O2 use-peer-dns=yes user=O2
                          /ipv6 dhcp-client add add-default-route=yes interface=pppoe848_vlan848_ether1 pool-name=IPv6_WAN request=prefix
                          /ipv6 nd set [ find default=yes ] advertise-dns=yes managed-address-configuration=yes mtu=1460 other-configuration=yes
                          E: Myslím si, že jako modem tam je ASUS DSL-N16, ale nejsem si jistý.

                              kmotrik Ve firewallu není nic

                              Není výchozí pravidlo firewallu DROP, tj. že by zahodil všechen provoz? Případně co je to za router (jaká platforma a software)? Pokud je to Linux/x86, je povolený forwarding?

                              mirek_k Z Routeru se přidělují prefixy pro AP /51 a ty přidělené pak AP přiděluje klientům /56

                              Tzn. AP jsou taky v režimu router?

                              okoun k tomu MTU 1500 by mě tedy zajímalo jak to dělá PPFka a ostatní VDSLkaři když jejich MTU určitě není 1500 🙂

                              Buď pomocí clamp-mss-to-pmtu nebo prostou úpravou MSS podle maximálního MTU PPPoE (1492). Samozřejmě nesmí blokovat ICMPv6, je to jen takový hack, který ovlivní downstream, problémy na upstreamu nezachrání. Základem je nefiltrovat na cestě klíčové ICMPv6 zprávy.

                              sidi k tomu je ještě potřeba snížít MTU u ND na IPv6

                              Je to tak, tohle pomůže stanicím zjistit IPv6 MTU a podle toho náležitě sekají pakety.

                              xjxM5qHeN Já musel nastavit u ND také MTU na 1460, ale PPPoE MTU mám na 1480

                              Teď jsem překonfiguroval jednu DSL přípojku - zrušil clamp-mss-to-pmtu a ověřil, že PPPoE MTU je 1492 (to posílám v RA do LAN). Pokud do LAN pošlu RA MTU 1493, mapy.cz se zaseknou. Pokud pošlu 1492, tak běží. (Zkouším pomocí curl -6 -v https://mapy.cz/.) Může se to samozřejmě lišit podle operátora a opět to narazí na situace, kdy někdo v Internetu bude blokovat ICMPv6 (např. pokud se ke mně připojí zvenku a nedorazí mu ICMPv6 Packet Too Big, takže nesníží velikost paketu tak, aby se mi vešel do MTU). Na tyhle situace ostatně ani MSS clamping nemusí vždycky pomoct (a navíc se cesty ode mě k někomu a od někoho ke mně mohou lišit, tj. mohou mít i různá MTU).

                                          jcltm A máš to nastavený ručně natvrdo nebo automatikou? Já mám modem taky v bridge (je to asi 10 let starý typ) a hlavní router je Mikrotik.

                                          sidi Na ND nemám MTU definováno (slovy RouterOS "unspecified").

                                          zajdee Dá se tedy říct, jaká hodnota MTU je pro DSL přípojky na PPPoE rozhraní správná? Je to těch 1480 nebo 1492? Já vím na beton, že někdy předtím (při starším RouterOS) jsem tam měl tu hodnotu 1492, ale v té době jsem nepoužíval IPv6 a v4 jela normálně a po nějakým update (nebo možná i při výměně hw) zřejmě došlo ke změně na 1480.

                                                  radek_kovacik Mikrotik nepoužívám, na té přípojce mám ASUS RT-AX56U s Merlinem. MTU a MRU jsem nastavoval ručně podle dat od poskytovatele. Pokud si dobře vzpomínám tak když jsem na jiné, konkrétně O2 VDSL přípojce rozjížděl IPv6, dával jsem tam ručně taky na PPPoE MTU a MRU 1492 a fungovalo to OK. Jako modem tam byl starý Comtrend v bridge.

                                                    Mám v IPv6 firewallu hodně invalid forward packetů - za pár dnů 400 000. Za sekundu skoro 10.
                                                    Všechno to vypadá jako odpovědi web serverů (z portů 443 a 80) TCP (RST), či TCP (SYN,ACK).
                                                    Nemyslím, že by to mělo takto fungovat. Můžu mít někde chybu?
                                                    Pravidlo je
                                                    add action=drop chain=forward comment="drop invalid" connection-state=invalid

                                                    Díky
                                                    Mirek

                                                      mirek_k U mne je to podobné a zatím jsem na ten důvod, proč se to tak děje, nepřišel. Pravidlo mám stejné.
                                                      Jinak MTU na PPPoE rozhraní jsem nastavil na hodnotu 1492 dle doporučení T-Mobile a můžu říct, že se tím odstranilo více různých problémů, než které jsem tomu původně připisoval včetně těch výše zmiňovaných webů, které běžely pomalu nebo vůbec. Původně jsem doufal, že to odstraní i ty invalidní spojení, ale ty zůstaly.

                                                        📡 Telekomunikace.cz