obud
OK, doplním informace:

Roouter:
/ipv6 dhcp-server option
add code=23 name=mydns value=0x2a03xxxx001000000000000000000001
/ipv6 pool
add name=pool1 prefix=2a03:xxxx:14::/47 prefix-length=51
/ipv6 address
add address=2a03:xxxx:10::1 advertise=no comment=DNS interface=bridge1
/ipv6 dhcp-server
add address-pool=pool1 allow-dual-stack-queue=no dhcp-option=mydns \
interface=ether4 lease-time=1d name=server1
/ipv6 dhcp-server binding
add address=2a03:xxxx:14:2000::/51 allow-dual-stack-queue=no comment=AP3 \
duid=0x744d28d56d6b iaid=8 life-time=1d prefix-pool=pool1 server=\
server1
/ipv6 nd
set [ find default=yes ] disabled=yes
add hop-limit=64 interface=ether4 managed-address-configuration=yes \
other-configuration=yes
/ipv6 route
add distance=1 gateway=2a03:xxxx:1:100::11
/ipv6 settings
set accept-router-advertisements=yes

AP:
/ipv6 dhcp-server
add address-pool=AP allow-dual-stack-queue=no interface="AP3" \
lease-time=1d name=server1
/ipv6 pool
add name=AP prefix=2a03:xxxx:14:2000::/51 prefix-length=56
/ipv6 dhcp-client
add add-default-route=yes interface=bridge2 pool-name=AP pool-prefix-length=\
56 rapid-commit=no request=prefix
/ipv6 dhcp-server binding
add address=2a03:xxxx:14:2100::/56 allow-dual-stack-queue=no \
duid=0xd4ca6d3ee487 iaid=2 life-time=3d prefix-pool=AP server=server1
add address=2a03:xxxx:14:2200::/56 allow-dual-stack-queue=no \
duid=0xb869f401a97f iaid=1 life-time=3d prefix-pool=AP server=server1
/ipv6 nd
set [ find default=yes ] other-configuration=yes
/ipv6 settings
set accept-router-advertisements=yes max-neighbor-entries=1024

CPE:
/ipv6 dhcp-server
add address-pool=Client interface=ether1 name=server1
/ipv6 address
add eui-64=yes from-pool=Client interface=ether1
/ipv6 dhcp-client
add add-default-route=yes interface=wlan1 pool-name=Client rapid-commit=no \
request=prefix
/ipv6 nd
set [ find default=yes ] advertise-dns=yes other-configuration=yes
/ipv6 settings
set accept-router-advertisements=yes

radek_kovacik
Z klienta se toho moc nedostane. Některé stránky nejdou, jde to pomalu...
Vypnutí ipv6 adresy s Advertisment v CPE problém odstranilo.

    mirek_k Já to vidím tak, že buď máme v konfiguraci stejné chyby nebo je tam nějaký bug, protože to stejné se mi děje také, ovšem i na počítači, takže není to způsobené tím, že je to mobil a Samsung.
    Mně např. blbne mapy.cz, sbazar.cz (tyto nejedou vůbec, ovšem pouze za určitých podmínek), zatímco bosch-home.com jede hodně pomalu (ale možná je to jejich serverem).
    Tyto anomálie se mi začali dít také po spuštění IPv6 na mém Mikrotiku. Zkus se podívat do IPv6 Firewall Filter, jestli se ti tam neztrácejí spojení někde v DROPu. Já mám na to podezření.

    Ahoj přidám se do skupiny lidí co válčí s IPv6 😀

    Na hraničním routeru přebírám skrze bgp celý prefix /29. Jakmile na tenhle router přiřadím na jakýkoliv interface globál adresu /120 ( vypnuty advertising ) tak si z internetu tuhle adresu dopingam.

    Tento router je spojen kabelem s dalším routerem - ten má adresu jako hlavní router +1/120 a rozjetou ospv3 kvůli propagaci. Mezi sebou mi ping letí ( zkusil jsem to i na další routery a ospv3 mi funguje) - v routovacce uvnitř sítě vidím vše a i pingam všechno. Dokonce i defaultky jsou na routerech diky ospfv3 v pohodě ( link-lokal adresy) ... Jakmile ale pustím z internetu ping na router dál v síti tak se mi zastaví na bgp hraně a dál už nedoputuje.
    V nastavení OSPFv3 na bráně mám distribuci default roury zkoušel jsem i propagaci prefixů z bgp - objeví se v routovacce dál po síti ale ping stejně neprolete ... Route filter teď nemám na bgp nastavené žádné, upstream provider nepropaguje full bgp ale jen své rozsahy ( mám 5 záznamu které od něj přebírám ).

    Jo a taky nejsem schopnej nastavit pptp tak aby rozdávalo i IPv6 - v nastavení PPTP mám přidělen prefix, když se naváže PPTP tak se v routovacce ukáže /56 která by měla projít ale PC s win10 už na vpnce IPv6 neobrží. Wiki Mikrotik rádi jen jak to řešit v rámci tunelu Mikrotik vs Mikrotik - EDIT: pptp už funguje, snažil jsem se jako na DHCP nasadit range /56 a o ten si win nezažádají - stačilo v PPP secret změnit na /64 a už jsem dostal adresu

    já jsem také měl obdobné problémy s rychlostí a zjistil jsem že mi to v baráku rozbíjel mikrotik switch na kterém byl nainstalovaný ipv6 balíček nicméně konfigurace tam žádná nebyla, takže divné...

      okoun
      To je zajímavé. Já mám mezi Routerem a APčkama spoje v bridge, kde vůbec není balíček IPv6 povolen.
      Může to vadit?
      Jinak až tak úplně blbě to nemůžu mít, protože IPv6 provoz je cca 20 %.

      tak ted nerozumím těm 20% jestli jako čekáš provoz který se blíží 100% tak zapomenout zatím....

        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).

                        📡 Telekomunikace.cz