V aktualnim stavu infrastruktury tedy neni mozne pridelit vetsi prefix ani pokud by zakaznik nepozadoval verejnou IPv4?
Odhadnete kdy asi tak (staci vyhledove, jako mesice/roky/petiletka)? Taky na to cekam jako na smilovani, uz to bude rok (tesil jsem se na bridge, resp. pochopil jsem tak slib kdyz jsem musel na optiku)…
To, ze mi ONT zere elektrinu jsem zkousnul, ze ukoncuje ssh spojeni uz hure, nicmene resim automatickymi restarty u klientu, ale IPv6 kdyby hezky pustil dal by bylo fajn.
Kazdopadne diky za registraci a komunikaci zde 
a hodne zdaru
4 Likes
Ne v tomto stavu nejde dat vetsi prefix nez /64 ani s privatkou. Problem je v tom ze IPv6 se generuje pevnym algoritmem na zaklade wan ipv4. Predchazime tak dvoji evidenci adres.
1 Like
Omlouvam se ale to opravdu nedovedu odhadnout. Naposledy jsem odhadoval 1Q 2020 ale bohuzel reseni jinych palcivejsich problemu nedovolilo venovat se tomuto.
SSH by rozhodne nemelo byt ukoncovano. Pokud mate verejnou IP, tak se nikde nic neNATuje a nemel by byt uplatnovan ani zadny firewall. Pokud mi k tomu poskytnete nejake konkretnejsi informace (zejmena postup jak problem reprodukovat), muzu se na to podivat.
Prosim ale mimo tuto diskuzi at nejsme prilis off topic.
Kdyz uz nevime termin, tak na co se muzeme tesit?
/64 per user + na vyzadani /56 nebo /48
/48 per user
/56 per user
vlastni ONT ano ( SFP, PPPoE) / ne
1 Like
No, algoritmus by určitě šel opravit.
Na Internetech jsem našel nějaké adresy z prefixu PODA:
2a00:ca8:a1f:a3e4:1c21:c28:f374:8032a00:ca8:a1f:50fa:f152:8ab8:c39d:a2f12a00:ca8:a1f:c735:9be:a1b5:57da:da632a00:ca8:a1f:390d::/642a00:ca8:a10:5000:7c54:6c7e:d5bc:62xx
Podle toho to vypadá, že dnes provádíte 1:1 kopii IPv4 adresy do IPv6 prefixu (a1f:390d → 10.31.57.13); při /32 od RIPE NCC pak skutečně nelze udělat nic jiného než /64 na zákazníka.
Pro /56 na zákazníka a kopii 1:1 byste potřebovali 56-32=/24 IPv6 prefix. A to vám asi RIPE NCC nepřidělí…
(Je škoda, že se vůbec takový adresní plán dostal do produkce. Při /56 na zákazníka by algoritmus mohl být už od počátku jiný, počítající například s reálně využívanými bity v přidělených/používaných IPv4 prefixech, kdy u veřejných adres se využívá max. /16, tj. 16 bitů v síti PODA, zbytek přidělen RIPE NCC.)
4 Likes
Jen pro zajímavost - NDP na turrisu se mi podařilo rozjet. A přitom jsem nic neudělal 
.Jen bylo potřeba instalovat ndppd package.
2 Likes
Tak jsem to take zkusil rozjet.
Install ndppd + nastaveni dle tipu od @Ondrej_Caletka = na Turris OS 5.x funkcni!
2 Likes
S dovolením bych uvedl na pravou míru, že ndppd vůbec nepotřebujete, stačí nastavení uvedené výše. ndppd je generický démon pro běžné unixové systémy (podobně jako třeba radvd). OpenWRT má mnohem pokročilejší nástroj netifd, který funkci obou zastane a navíc dokáže reagovat na dynamické změny. Měla by tedy stačit konfigurace relay módu uvedená výše, kterou jsem opsal z dokumentace OpenWRT. Teď to testuji na Turrisu Mox s aktuální hbt větví a zdá se, že to funguje dobře.
Pokud by to snad nefungovalo, jistě je možné nainstalovat ndppd a nakonfigurovat jej staticky, ale pak je dobré nekonfigurovat netifd, aby se tito dva démoni zbytečně neprali.
Jsou potreba nejake specialni zapisy ipv6 do interface/network (ip6assign, reqaddress, reqprefix, noserverunicast apod), nebo Vam to beha na default? Ze bych zkusil na trojkove vetvi… I kdyz ted po delsi dobe koukam, ze nemam IPv6 pridelenou ani na Omnii… Je fakt, ze jsem to prideleni ipv6 nekontroloval uz hoooodne dlouho; kdyz jsem to prestal sledovat, Omnie ipv6 mela.
V mém testu není zapotřebí nic speciálního, jen toto nastavení v /etc/config/dhcp (kompletní ukázka, pro relaying jsou relevatní řádky relay a označení master pro rozhraní wan):
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 relay
option ra relay
option ndp relay
list dhcp_option '6,192.168.1.1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
option dhcpv6 relay
option ra relay
option ndp relay
option master 1
Nastavení síťových rozhraní může zůstat ve výchozím stavu. Pro test jsem vynutil odmítnutí přidělení prefixu pomocí reqprefix no, neboť nadřazený router jinak ochotně nadeleguje podsíť. Tedy takto:
config interface 'wan6'
option proto 'dhcpv6'
option ifname '@wan'
option reqprefix 'no'
config interface 'lan'
option bridge_empty 1
option igmp_snooping 0
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign 60
Vypadá to trochu divně, že na rozhraní LAN není žádná veřejná IPv6 adresa, ale funguje to správně. Když se nějaké zařízení připojí do sítě LAN, instaluje se do směrovací tabulky individuální záznam s IP adresami toho konkrétního zařízení, takže komunikace může probíhat oběma směry.
2 Likes
Tak nevím… Já momentálně ipv6 nedostanu ani na omnii, s nastavením, kde jsem ji dříve dostával, ani s nastavením viz výše. Netipnu, zda jsem ji ztratil po přechodu z metaliky na GPON, nebo jindy 
Momentálně zase funkční ve verzi TOS5.1 na Omnii i na Moxu v síti PODA. Může souviset s nastavením DUID.
@Mracek
Dobrý den,
nějaké novinky k tomuto tématu?
Popř. bych se dozeptal:
Je možno používat TO s SFP modulem bez “Poda routru”?
Děkuji
Nějak se mi nechce instalovat TOS 5.1, když je vysoce experimentální, jen proto abych měl u PODY funkční IPv6…
TOS 5.x je stabilní. Jen automatická migrace konfigurace z TOS 3.x zatím ne.
Ahoj, automatická migrace konfigurace se týká asi jen “klasického” nastavení skrze rozhraní Luci/Foris, že? Ja jen, že mám na routeru i nestandartní konfiguraci a už si bohužel nepamatuju co všechno jsem nastavoval (OpenVPN, https parametry, etc…) a co vše by bylo třeba přenést.