Mikrotik, IPv6 a ISP Metronet

[PPK]

Ahoj.

Mam internet od poskytovatele Metronet poskytovany nad siti Cetinu.
Protoze informaci k Metronetu je na ceskem internetu minimum a co se tyce IPv6 tak prakticky nula, tak pokud se muj problem vyresi tak by to mohlo pomoci i nekomu jinemu. Navic jako nastaveni IPv6 bez pouziti dhcpv6 by to mohlo pomoci i nekomu jinemu u jineho poskytovatele co ma IPv6 pridelovano staticky obdobnym zpusobem.

Par informaci pro zacatek. Do baraku je optika od Cetinu. Po baraku ethernet zakonceny rj-45 u me v byte. Na tom pripojeny Mikrotik 751G-2HnD s RouterOS v6.44.3. Mikrotik byl resetovan do tovarniho nastaveni. Nad ether1 nastaveny vlan a nad vlan PPPoE client. Nastavena staticka verejna IPv4 a dns tak jak sem dostal od metronetu. WAN zmeneno z ether1 na mojeho PPPoE clienta (Metronet-PPPoE). V tuhle chvili je funkcni internet s IPv4.

Tak a ted k ty IPv6. Na webu Metronetu k tomu je pouze, ze davaji /56 blok a "Pro správné fungování IPv6 je zapotřebí mít zapnutou podporu SLAAC a DHCPv6 klienta na rozhraní kde je nakonfigurovaná IPv4."
V dokumentech od nich nic vic nebylo, takze nasledoval pokus s tim DHCPv6 klientem. Prekvapive neuspesny. Zadost o prefix ci adresu uplne bez odezvy. Nasledoval dotaz na podporu metronetu s patricnym popisem co sem nastavil a co nefunguje s zadosti, ze kdyby meli nastaveni pro mikrotik (maji ho v ceniku jako gbit router co prodavaji k pripojeni) tak by to pomohlo. Po trech tydnech strucna odpoved, ze mam v priloze novou technickou specifikaci.

Takze ted od nich mam:
IPv6 WAN: xxxx:yyyy:D5:3D::/64
IPv6 LAN: xxxx:yyyy:D501:3400: :/56

IPv6 DNS sem nedostal, takze sem na routeru pridal IPv6 DNS od google.

Prepnul sem v IPv6 settings Accept Router Advertisements na yes. Tim by melo byt funkcni SLAAC od isp do mikrotiku. Uz v tuto chvili se pres IPv6 mikrotik dopingne na google.com.

WAN IPv6 sem nastavil nad interface PPPoE klienta. IPv6 z tiku do internetu funguje. Ping to ma i kdyz jako src-addres pouziju nastavenou WAN IPv6. Zatim dobry.

Z toho /56 bloku sem si vytvoril pool. Z toho poolu nastavil ::1/64 jako adresu pro bridge a zapnul advertise. V tuhle chvili stroje (windows, linux, android) pripojene k mikrotiku maji IPv6 adresy i DNS a dopingnou se na tu xxxx:yyyy:D501:3400::1/64 co je nastavena na bridge rozhrani mikrotiku.

Tak a ted problem. Stroje pripojene k mikrotiku nemaji IPv6 konektivitu do netu. Traceroute konci na xxxx:yyyy:D501:3400::1/64 co je nastavena na bridge rozhrani. Sam mikrotik nema ping do netu, kdyz se jako src-address pouzije ta xxxx:yyyy:D501:3400::1/64

A ja ted netusim kde je problem. Driv sem mel ipv6 tunel nejdriv od sixxs a pak od he. Oboji roky funkcni s komplikovanejsim nastavenim. Tady sem cekal ze nativni ipv6 nebude problem a evidentne je. A moje znalosti ipv6 jsou dost chabe na to aby sem si s tim poradil. Google mi moc nepomohl. Asi se ho neumim spravne zeptat. Ten mi cpe vsude, ze se pouziva dhcpv6 client, ktery typicky prideli /56 z ktery se pouzije ::1/64 ne bridge a na wan nic nenastavuje.

Zkusil sem nekolik verzi RouterOS. Zkusil sem se zbavit vsech pravidel na ipv6 firewallu a povolit vsechno. Zadna zmena.

Uz nevim co s tim a tady se pohybuje par chytrych hlav, co by mohli poradit. S Metronetem je to pri dlouhem vedeni jejich podpory na dlouho (cekam na odpoved na mejl co sem posilal 6 kvetna).

Par vypisu z mikrotiku co by mohli byt uzitecne:

> /ipv6 address print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
 #    ADDRESS                  FROM-POOL   INTERFACE      ADVERTISE
 0 DL fe80::20c:42ff:fefc:a45d/64            bridge         no
 1 DL fe80::20c:42ff:fefc:a45c/64               Metronet-VLAN      no
 2 DL fe80::20c:42ff:fefc:a45c/64               ether1         no
 3 DL fe80::b/64                        Metronet-PPPoE      no
 4  G xxxx:yyyy:d5:3d::/64                  Metronet-PPPoE      no
 5  G xxxx:yyyy:d501:3400::1/64   IPv6-LAN      bridge         yes

> /ipv6 route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 #      DST-ADDRESS                   GATEWAY                  DISTANCE
 0 ADS  ::/0                              Metronet-PPPoE            1
 1 ADC  xxxx:yyyy:d5:3d::/64        Metronet-PPPoE            0
 2 ADC  xxxx:yyyy:d501:3400::/64     bridge                          0

> /ipv6 pool print
Flags: D - dynamic
 #   NAME         PREFIX                  PREFIX-LENGTH      EXPIRES-AFTER
 0   IPv6-LAN      xxxx:yyyy:d501:3400::/56         56

> /ipv6 nd print
Flags: X - disabled, I - invalid, * - default
 0  * interface=bridge ra-interval=3m20s-10m ra-delay=3s mtu=unspecified reachable-time=unspecified retransmit-interval=unspecified ra-lifetime=30m hop-limit=unspecified
      advertise-mac-address=yes advertise-dns=yes managed-address-configuration=no other-configuration=yes

[Reklama]

[byl_jsem_donucen_se_registrovat]

Ahoj, já jsem k Metronetu přešel před cca dvěma týdny. Mám OpenWRT (snapshot) a IPv6 se nakonfigurovala na první dobrou sama - takže u tebe bude asi problém někde na straně konfigurace. V nastavení vidím že jsem dostal od Metronetu pomocí SLAAC + DHCPv6 stateless delegovaný IPv6 prefix /56. OpenWRT je na IPv6 asi dobře připraveno - i klienti v interní síti dostávají IPv6 adresy z delegovaného prefixu.

[PPK]

Evidentne mam jine parametry sluzby od metronetu. Kdyz mam IPv6 staticky pridelenou a napsanou v technicke specifikaci sluzby, tak si to router nema jak sam nakonfigurovat. Kdyby jim chodilo DHCPv6, tak si to mikrotik nakonfiguruje. Tak jako to chodi u jinych poskytovatelu... napriklad na ceskem O2.

[byl_jsem_donucen_se_registrovat]

Podle toho co píšeš tam máš parametry asi stejné - VDSL po drátech které patří Cetinu. Pevná IPv4 a IPv6 pro LAN /56 pro WAN /64. Delegovali prefix přes DHCPv6 - viz screenshot https://imgur.com/a/VsiAmOc, úplně dole je IPv6-PD a to je prefix který jsem nikde nekonfiguroval.

[PPK]

Parametry stejne opravdu nemame. Ja nejsem na DSL, ale na optice (ping na seznam 4ms a uz ted mi muzou pustit 1000/100mbps)
S DHCPv6 klientem sem stravil spoustu casu. Vygooglil spoustu lidi co jim to s mikrotikem u jinych postkytovatelu funguje. Me DHCPv6 server na zadost o prefix nereaguje. To samy na zadost o adresu. Jeste mikrotik umi zadost o info a to bylo jedinny kde sem dostal odpoved v ktere byla link-local adresa. Firewall sem proveril a  tam problem nebyl. Potencialne rozbity RouterOS sem proveril downgradem na ruzne starsi verze az nekam asi rok zpatky. To taky na problem nevypada.
Vzhledem k tomu, ze odpoved na nefunkcni dhpcv6 byla nova technicka dokumentace s doplnenyma adresama pro ipv6 sem dosti zmaten proc jiny ma funkcni dhcpv6
Me pride, ze mi chybi v nastaveni neco co tomu routeru vysvetli vztah mezi /56 pro lan a /64 pro wan. Protoze /64 do netu je ok. /56 do lan je ok. Ale mezi tim to nekde drhne.

[Reklama]

[Ondřej Caletka]

Takze ted od nich mam:
IPv6 WAN: xxxx:yyyy:D5:3D::/64
IPv6 LAN: xxxx:yyyy:D501:3400: :/56

Podle mě to bez DHCPv6 klienta nebude fungovat. Na straně operátora totiž musí existovat záznam ve směrovací tabulce pro /56 LAN prefix směrem k vašemu routeru a ten se obvykle vyrábí dynamicky na základě analýzy DHCPv6 zpráv, které přes zařízení poskytovatele prochází. Pokud si tedy o prefix neřeknete, tohle zařízení se nedozví, kam má data směřující do vašeho LAN prefixu posílat.

Můžete to vyzkoušet tak, že traceroutujete svůj LAN prefix z internetu. Posledním hopem by měl být WAN prefix vašeho routeru. Pokud se ve skutečnosti bude směrování cyklit někde dřív, je to chybějící záznam ve směrovací tabulce. Pokud jsem správně odanonymizoval adresy tazatele, vypadá to přesně na tenhle případ.

Kód: [Vybrat]

$ traceroute 2a01:510:d504:3400::
traceroute to 2a01:510:d504:3400:: (2a01:510:d504:3400::), 30 hops max, 80 byte packets
 6  * * *
 7  2001:1a48:ffff::52 (2001:1a48:ffff::52)  9.756 ms  9.769 ms  9.755 ms
 8  2a01:510:0:90dd::1 (2a01:510:0:90dd::1)  12.421 ms  10.426 ms  10.416 ms
 9  2a01:510:0:90dd::2 (2a01:510:0:90dd::2)  10.406 ms  10.399 ms  10.839 ms
10  2a01:510:0:90dd::1 (2a01:510:0:90dd::1)  10.369 ms  10.388 ms  10.382 ms
11  2a01:510:0:90dd::2 (2a01:510:0:90dd::2)  13.500 ms  13.903 ms  13.930 ms
12  2a01:510:0:90dd::1 (2a01:510:0:90dd::1)  10.889 ms  10.888 ms *
13  2a01:510:0:90dd::2 (2a01:510:0:90dd::2)  110.929 ms  113.123 ms  114.105 ms

[PPK]

Dekuji, dekuji, dekuji. Ano to byl ten chybejici stripek do skladacky. Vubec me nenapadlo zkusit znova dhcpv6 klienta po tom, co sem dostal novou technickou specifikaci s IPv6 WAN.
Tim se veskere nastaveni IPv6 u Metronetu na mikrotiku smrsklo na rucni nastaveni IPv6 wan a pak uz klasicky DHCPv6 klient s prislusenstvim Zase sem se neco naucil.

[Ondřej Caletka]

Dekuji, dekuji, dekuji. Ano to byl ten chybejici stripek do skladacky. Vubec me nenapadlo zkusit znova dhcpv6 klienta po tom, co sem dostal novou technickou specifikaci s IPv6 WAN.
Tim se veskere nastaveni IPv6 u Metronetu na mikrotiku smrsklo na rucni nastaveni IPv6 wan a pak uz klasicky DHCPv6 klient s prislusenstvim Zase sem se neco naucil.

Myslím si, že ani ruční adresu WAN nastavovat není potřeba. Když tam nebude žádná, router si půjčí pro sebe svou adresu z LAN. Prostě, mělo by to fungovat Plug&Play, tedy kromě MikroTiku, kde ve výchozím stavu podpora IPv6 vůbec není.

[PPK]

Mikrotik ve vychozim stavu ma IPv6 podporu zapnutou. Tam normalne naskakali patricne link-local adresy pro jednotliva rozhrani. ND bylo zaply a ::/0 routu nastavil PPPoE client na spravnou gateway.
Jenze DHCPv6 server Metronetu zrejme nereaguje na pozadavek poslany z link-local adresy. Na tom sem byl zasekly, protoze nejakou chybou mi Metronet zapomel do puvodni technicke specifikace napsat IPv6 prefixy.
Proto mi jako odpoved na nefunkcni DHCPv6 prisla od Metronetu nova technicka specifikace s IPv6 prefixama a tim, ze uz to bude fungovat.
Jakmile sem na WAN rozhrani nastavil adresu z toho bloku co mi pro WAN Metronet dodal, tak se na DHCPv6 posila pozadavek z adresy co ten server zna a vratil mi muj prefix pro IPv6 LAN.
Dava to perfektni smysl. Sit Metronetu se dozvi jakou adresu z /64 bloku sem na wan rozhrani nastavil a vytvori tak patricne smerovani. Bez ty adresy na WAN to netusi od koho prisel pozadavek... a jak by to pak vratilo routeru ten spravny staticky prefix ? Asi kdyby to slo bez toho, tak neplytvaji /64 blokem z kteryho se pouzije pouze jedna adresa na WAN rozhrani routeru.

Jeste konfigurace mikrotiku pro IPv6 u Metronetu nad siti Cetinu. Mohla by se nekomu hodit. Je to uplne nejjednodusi varianta.

Pozadavky:
1 ) Mikrotik v zakladnim nastaveni s pridanym nastavenim pro Metronet podle technicke specifikace. VLAN, PPPoE client. IPv4 muze byt, ale neni potreba.
2 ) Technicka specifikace sluzby od Metronetu kde je IPv6 WAN a IPv6 LAN.

Bude to v terminalu, ale uzivatel mikrotiku si z toho odvodi jak to naklikat ve web gui nebo winboxu
Metronet-PPPoE je nazev meho interfacu PPPoE clienta.

Prvni nastavime IPv6 adresu pro WAN opsanou z technicke specifikace sluzby:

Kód: [Vybrat]

/ipv6 address add address=xxxx:yyyy:d5:3d:: advertise=no interface=Metronet-PPPoE
Cislo dve je nastaveni DHCPv6 klienta:

Kód: [Vybrat]

/ipv6 dhcp-client add add-default-route=yes interface=Metronet-PPPoE pool-name=Metronet-DHCP pool-prefix-length=56 prefix-hint=::/56 request=prefix
Ze DHCP funguje si muzeme overit. Musi by byt status bound:

Kód: [Vybrat]

/ipv6 dhcp-client print
Flags: D - dynamic, X - disabled, I - invalid
 #    INTERFACE                                                                                                 STATUS             REQUEST                                                                                                PREFIX                                                           ADDRESS                                                     
 0    Metronet-PPPoE                                                                                            bound              prefix                                                                                                 xxxx:yyyy:d501:3400::/56, 23h45m8s                               

Jsme ve stavu, ze mame vykomunikovany spojeni se siti poskytovatele do/z internetu.
Takze je potreba nastavit IPv6 do nasi site:

Kód: [Vybrat]

add address=::1 from-pool=Metronet-DHCP interface=bridge
Tim je mikrotik nastaven a zarizeni pripojena k nemu uz dostavaji z routeru patricne informace.
Takze uz nam jen zbyva si jen pro overeni funkcnosti pingnout treba na google z neceho co je k mikrotiku pripojeny:

Kód: [Vybrat]

ping -6 google.com

Pinging google.com [2a00:1450:4014:80c::200e] with 32 bytes of data:
Reply from 2a00:1450:4014:80c::200e: time=4ms
Reply from 2a00:1450:4014:80c::200e: time=4ms
Reply from 2a00:1450:4014:80c::200e: time=4ms
Reply from 2a00:1450:4014:80c::200e: time=4ms

Ping statistics for 2a00:1450:4014:80c::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 4ms, Average = 4ms
Takhle jednoduchy to je a ja nad tou blbosti stravil hodiny 

[Radek Zajíc]

Ahoj PPK,

situace je ve skutečnosti možná jednodušší než se může zdát. Metronet využívá referenční nabídku CETINu, takže z pohledu uživatele na PPPoE přípojkách:
- na WAN rozhraní (PPPoE) přichází IPv6 router advertisementy a router se podle nich může nakonfigurovat (někteří ISP vůbec nemají pro WAN rozhraní IPv6 prefix, ale nevadí to - na WAN je vždycky link-local adresa, kterou přiděluje protistrana, a ta pro DHCPv6 stačí, viz níže)
- pro LAN rozhraní je potřeba nakonfigurovat DHCPv6 klienta, aby zasílal požadavek na prefix delegation (PD)
- DHCPv6 dotazy chodí z klientského routeru z link-local adresy na multicast adresu ff02::1:2 a DHCPv6 server odpovídá z link-local adresy (viz např. https://www.cloudshark.org/captures/eeedef4dd779)

Referenční přípojka CETINu (na DSL i FTTB/H) vypadá takhle:
IP konektivita: Klientská-LAN <-> Klientský router <-- PPPoE --> CETIN BRAS <--> ISP router <--> Internet
IP alokace: CETIN BRAS <--> CETIN RADIUS <--> ISP RADIUS

BRASy mají ~stejnou konfiguraci pro DSL i FTTB/H.

Typicky navázání spojení pak vypadá takhle:
1. Klientův router (KR) vytočí PPPoE s aktivním IPv6CP
2. CETIN BRAS si od CETIN RADIUS a ten od ISP RADIUS zjistí, zda je uživatel aktivní, a vyžádá si informace o prefixech (WAN, Delegated)
3. CETIN BRAS odpoví na PPPoE a PPPoE spojení se sestaví s IPv6CP (zažil jsem špatně nakonfigurovaný BRAS, který IPv6CP odmítal - šlo o BRAS profil Avonetu, v tomtéž regionu IPv6 na DSL T-Mobilu fungovalo)
4. CETIN BRAS nainstaluje do své routovací tabulky WAN prefix a nasměruje ho do PPPoE rozhraní k uživateli
5. KR si nastaví na WAN link-local adresu z IPv6CP
6. CETIN BRAS vyšle unsolicited router-advertisementy (je-li přidělen WAN prefix)
7. KR aktivizuje DHCPv6 klienta a ten zašle požadavek na delegaci prefixu (PD)
8. CETIN BRAS v roli DHCPv6 serveru odpoví klientovi - informuje ho o přiděleném prefixu a jeho časové platnosti; zároveň na dobu platnosti nainstaluje do své routovací tabulky delegovaný prefix a nasměruje ho do PPPoE rozhraní k uživateli
9. KR si z přiděleného prefixu vybere jednu /64 a tu nainstaluje na LAN rozhraní. Zároveň začne do LAN oznamovat dostupnost prefixu pomocí router-advertisementů
10. Klient má funkční IPv6 konektivitu na LAN

CETINí BRASy provádějí reverse path filtering, tedy nepropustí ven provoz, pro který neexistuje mapování v routovací tabulce, a ani ke klientovi nepošlou provoz zvenku, který by byl nasměrován na prefix, který není nainstalován v routovací tabulce (to dává smysl). Zároveň se delegovaný prefix nikdy neinstaluje dřív než dojde k úspěšnému vyžádání prefixu DHCPv6 klientem.

RouterOS by default nepřijímá router advertisementy, pokud je zároveň routerem - musí se to explicitně povolit (https://wiki.mikrotik.com/wiki/Manual:IPv6/Settings). Pokud povolíš tohle nastavení, můžeš zrušit tu ruční adresu na PPPoE rozhraní.
Zároveň bohužel platí, že RouterOS má v defaultu balíček IPv6 zakázaný a musí se povolit. Pokud je povolen, pak skáčou link-local adresy na ethernetových rozhraních a objeví se link-local adresa na PPPoE rozhraní (je-li aktivní IPv6CP).

Pokud něco nefungovalo jak mělo (a není to tím, že by v Metronetu zapomněli nastavit svůj RADIUS, aby vracel CETINímu RADIUSu informaci o přiřazených prefixech - i to už jsem jinde viděl), mohlo by to být problémem ve firewallu (nepřijímání RA - zahozené ICMPv6, neúspěch DHCPv6 - zahozené odchozí/příchozí UDP na portech 546/547).

Rozhodně nedoporučuju nastavovat cokoli staticky - není to podporovaná konfigurace. Detaily má CETIN veřejně v technické specifikaci v sekci 5.8.4 (mají tam chybu; tvrdí, že delegovaný prefix je automaticky směrován, ale ve skutečností platí moje slova o nutnosti provedení DHCPv6 dotazu).

(Text jsem musel napsat podruhé, poprvé mi ho Root kvůli odhlášení z fóra sežral. :-/)

[PPK]

Resetoval sem mikrotika do tovarniho nastaveni za posledni mesic a pul nekolikrat. IPv6 balicek je defaultne zaply. Jedinne, ze by reset do tovarniho nastaveni nebyl reset do tovarniho nastaveni a pamatoval si, ze sem ipv6 kdysi davno zapnul.

Accept Router Advertisements prepnuty na yes sem mel. To sem psal uz v prvnim prispevku. To bylo prvni, kdyz sem si precet na webu Metronetu ze je potreba SLAAC tak sem vyhledal jak se to na mikrotiku zapina

Zapomel sem napsat nahore, takze to je:

Kód: [Vybrat]

/ipv6 settings set accept-router-advertisements=yes
Jenze tohle je takova seda zona v mikrotiku. Ono to asi neco dela. Ale z uzivatelskyho hlediska to neni videt, protoze se to nikde v nastaveni IPv6 nijak neprojevi.
Mikrotik v logu psal (logovani sem si musel taky nastavit), ze prisel router advertisement a dopingnul se na google. V tomhle stavu sem byl spoustu hodin, kdy sem marne googlil reseni a nic nefungovalo. DHCPv6 client psal pouze searching...

Firewall sem taktez psal. Mel sem default nastaveni od mikrotiku. Neslo to. Povypinal sem pravidla, vymazal pravidla, povolil vsechno. Nepomohlo. Mel sem tam i vyslovne UDP porty 546/547. Ted opet s defaultem od Mikrotiku je to funkcni. Default tam ma jen UDP 546 s poznamkou: "accept DHCPv6-Client prefix delegation."

Prijde mi, ze mam jako vzdy neco extra. Nebo u Metronetu zaroven s tim jak mi poslali novou technickou specifikaci provedli jeste nejakou zmenu...

[Radek Zajíc]

Ah. No a není to tím, že IPv6 v základu nedávají? (To tedy ani veřejnou IPv4 - jen na požádání.)
Nulová odpověď od DHCPv6 při pokusu o DHCPv6 PD totiž naznačuje, že na svojí straně Metronet nenastavil správně uživatelskou databázi/RADIUS a tedy CETIN nedostal vůbec informaci, že má IPv6 aktivovat. Třeba ji prostě zapomněli nastavit. :-)

Pokud už proběhne DHCPv6 výměna (tj. RouterOS dostane prefix), je třeba nakonfigurovat jen adresu na LAN ve tvaru "additivní adresy", tj. adresy, která se přičte k adrese IPv6 poolu, a informaci o poolu. Tj. pokud mám např. LAN a GuestNet:

Kód: [Vybrat]

/ipv6 address
add address=::0:0:0:0:1/64 from-pool=<DHCPv6Pool> interface=LAN
(...)
/ipv6 address
add address=::ff:0:0:0:1/64 from-pool=<DHCPv6Pool> interface=GuestNet
Pro pool prefix 2001:db8:baba:de00::/56 se pak pro LAN nastaví 2001:db8:baba:de00::1/64 a pro GuestNet 2001:db8:baba:deff::1/64.

Tenhle návod je sice na první pohled pro DSL, ale prakticky by měl fungovat i na FTTB/FTTH (je tam jen potřeba nastavit VLAN 848 a teprve nad ní vytáčet PPPoE): https://www.zemj.com/2018/10/19/mikrotik-o2-ipv6-klidne-multiiptv-nastaveni/
Téměř se shoduje s tím, cos napsal - s rozdílem, že vůbec nekonfiguruje adresu na WAN (PPPoE).

[Radek Zajíc]

Mimochodem, jakou máš verzi RouterOS? Nastavení

Kód: [Vybrat]

accept-router-advertisements=yes by mělo fungovat jako v Linuxu

Kód: [Vybrat]

accept_ra=2ale vypadá to, že to kluci v Mikrotiku měli/mají rozbitý.
https://forum.mikrotik.com/viewtopic.php?t=115735

Version 6.38rc52 has been released.
Changes since previous version:
...
*) ipv6 - fixed "accept-router-advertisements" behaviour;

[PPK]

Tak mi to vrtalo hlavou. Takze sem si dal dalsi restart mikrotiku do tovarniho nastaveni. A tim se kruh uzavrel. S nastavenim, ktere sem mel puvodne uz pred vic jak mesicem to funguje.
Takze se stala chyba co se stava jednou za deset let a Metronet zapomel od zacatku nastavit IPv6 i kdyz sem v objednavce mel, ze ji chci. A k nastaveni doslo az kdyz sem psal na podporu, ze to nefunguje Nejdriv me vytrolil metronet, ze mi to nenastavili. A pak sem se vytrolil sam, ze moje reakce na staticke IPv6 prefixy v technicke specifikaci sluzby byla smazani dhcpv6 klienta A ted zase nechapu jak to funguje. Podle ceho dhcpv6 identifikuje, kdo to zada o prefix aby to pridelilo ten spravny staticky ?

Takze nastaveni mikrotiku pro ipv6 u Metronetu nad Cetinem je takhle jednoduchy:

Kód: [Vybrat]

/ipv6 settings set accept-router-advertisements=yes
/ipv6 dhcp-client add add-default-route=yes interface=Metronet-PPPoE pool-name=IPv6-Pool \
    pool-prefix-length=56 prefix-hint=::/56 request=prefix
/ipv6 address add address=::1 from-pool=IPv6-Pool interface=bridge
Ano ten navod na zemj.com znam. To bylo jedno z prvnich co sem vygooglil, kdyz sem pred mesicem nestastny resil proc se se mnou ten zatraceny dhcpv6 server nebavi. Nasledovalo hledani na foru mikrotiku, jestli nemaji rozbity dhcpv6 client a zkouseni starsich verzi routeros... bez uspechu.

Mam RouterOS v6.44.3. Ty jejich rc a beta obchazim obloukem. Oni obcas umeji slusne rozbit i stable verzi
Nevim jak funguje accept_ra=2 v linuxu. Ale kdyz si pustim nejakou beznou linuxovou distribuci tak se mi tam ipv6 nastavi a kdyz si vypisu nastaveni site tak tam patricne polozky vidim. Na mikrotiku nic z toho co mikrotik z router advertisementu pouzil nikde nevidim a neprisel sem na to, jak to z neho vymlatit. Az kdyz sem si dal traceroute z venci tak vidim, co to vlastne pouziva za adresu na WAN. Z uzivatelskeho hlediska je to nastaveni u ktereho se dost blbe overuje ze funguje

[Radek Zajíc]

A ted zase nechapu jak to funguje. Podle ceho dhcpv6 identifikuje, kdo to zada o prefix aby to pridelilo ten spravny staticky ?

Je to jednoduchy. Pri vytaceni PPPoE spojeni jde provoz skrze CETIN DSLAM resp. GPON ONT. Ten na zaklade identifikace konkretniho DSL portu resp. GPON OLT (zakaznicky jednotky) obohacuje PPPoE pakety o tzv. cislo okruhu (circuit-ID). Kod, ktery tohle dela, se nazyva PPPoE Intermediate Agent.
CETIN BRAS (=druhy konec toho PPPoE tunelu; prvni konec je ten RouterOS u tebe doma), CETIN RADIUS a ISP (Metronet) RADIUS na zaklade tohohle circuit-ID identifikuje konkretniho zakaznika. A na zaklade znalosti zakaznika muze Metronet RADIUS pri pripojeni vzdycky poslat CETIN BRASu stejny prefix. A tohle plati i pro IPv4.
(Na ceste muze dochazet k ruznym obohacovanim a prekladum circuit-ID, na strane ISP je to obvykle prosty cislo - driv telefonni, dneska obecny cislo, prideleny CETINem, ktery si ISP musi na svy strane zanest do uzivatelsky databaze.)

Nevim jak funguje accept_ra=2 v linuxu. Ale kdyz si pustim nejakou beznou linuxovou distribuci tak se mi tam ipv6 nastavi a kdyz si vypisu nastaveni site tak tam patricne polozky vidim.

Linux (A tedy i RouterOS, protoze to je vlastne Linux kernel obaleny o spoustu proprietarnich ptakovin) funguje tak, ze je-li aktivni IPv6 forwarding a `accept_ra==1`, pak kernel neakceptuje RA a nenastavi si adresu podle SLAAC. Je-li aktivni IPv6 forwarding a `accept_ra==2`, pak kernel akceptuje RA a nastavi si adresu podle SLAAC. Je-li forwarding neaktivni, pak se `accept_ra` 1 i 2 chovaji stejne a vzdycky nastavi adresu podle SLAAC.
Na standardni stanici je IPv6 forwarding neaktivni a `accept_ra==1`. Na standardnim RouterOS boxu s aktivnim IPv6 balickem je IPv6 forwarding aktivni a `accept_ra` zustava `1`, proto si nevytvari adresu podle SLAAC, pokud mu prijde RA paket. Zapina se to prave tim extra prepinacem, kterej jim asi nefunguje.