Názory k článku Evropě došly volné IPv4 adresy, všechny jsou v rukou trhu

Díky, Petře! :)

Tady vidím selhání IANA. Měli bránit přeprodávání IPv4 adres, měli je stahovat z oběhu, aby byl co největší tlak na přechod na IPv6.

Souhlasim, IP adresy meli byt neprenosne - tj jen v rezimu propujceni do zaniku subjektu - a i v pripadne akvizic se melo stat, ze si novy vlastnik musi znova pozadat o pridel.

Takze, kdyz (priklad) Vodafone koupi UPC, maji se vsichni zakaznici kvuli te neprenositelnosti puvodniho pridelu preadresovat? To zni jako nesmysl, nemyslite? :-)

Popravdě, třeba by je to přinutilo zavést i použitelnou implementaci ipv6 ;-)

Nemyslíme. Rozsahy adres jsou propůjčované, takže např. pouze na IČO (či zahraniční obdobu). Jestliže nástupnická organizace (ve vašem příkladu Vodafone) neprokáže, že má oprávněný důvod k převzetí rozsahu (tj. např. 50% obsazení adres zákazníky, jinak posuzovat jako kšeftaření), bez milosti odebrat. A přečíslování? Proč by měla IANA řešit problém zákazníka, který si vybral špatného poskytovatele připojení???
Takže se taky domnívám, že to IANA totálně nezvládla.

Jestli Vodafone koupi UPC, tak zakaznici dostanou i novou smlouvu a zmena IP je takovy problem? Nerekl bych ze se to deje mesicne, ani rocne.. mate to jednou za desetileti :)

Mimochodem: Oni mají zákazníci UPC ve smlouvě, že dostávají po celou dobu smlouvy neměnnou IP???

Jenže vy si jako zákazníka představujete jen Šárku, Vlaďku, Romana a Tomáše. Těm je samozřejmě výměna adresy za jejich NATem úplně ukradená. Ale zkuste si představit jiný typ zákazníka, jako je velký obchodní řetězec, síť hotelů, krajský úřad včetně poboček nebo další poskytovatel připojení mající za sebou zase tisíce zákazníků. A takových sítí za sebou máte tisíce nebo desetitisíce. Zkuste si představit, že je poprosíte, aby pozítří přeadresovali.

Reaguju sice ponekud se spozdenim, ale... neni nikde sice specifikovano ze adresa je nemenna, ale primo ve smlouve mam spcifikovane opravdu konkreti adresy jak IPv4 tak IPv6.

Naopak. Měli se do toho montovat daleko méně.
Dřív by to vykristalizovalo a daleko dřív bychom tu měli IPv6. Stejně nás to čeká.

Toto se probíralo, v nějaké prezentaci člověka tuším z CZ.NIC nebo odkuď jsem k tomu slyšel vyjádření, že zákaz přeprodávání by způsobil pronajímání adres a bordelu v registrech.

Jednoduše pokud byste nemohl adresy prodat, tak je pronajmete jiné firmě, ale v registru jako vlastník budete uveden vy, což by znamenalo, že by černý trh jen kvetl a nastala totální anarchie.

Je to jako říct si, že protože spousta lidí umírá na alkohol, tak udělám prohibici a zakážu alkohol. Nápad je to pěkný, výsledky jsme viděli.

IPv4 Unicast Extensions

https://netdevconf.info/0x13/session.html?talk-ipv4-unicast-expansions

Dobrý den, chápu to dobře, že není možné již získat PA ani PI blok ?

IPv4 PI bloky není možné získat už od vyčerpání v roce 2012.

IPv4 PA blok lze získat po zařazení na čekací listinu (uvolní-li se nějaké adresy, např. po opuštění karantény), ovšem pouze v rozsahu 1 x /24 a to pouze tehdy, pokud Váš LIR ještě žádný IPv4 příděl od RIPE NCC nemá (https://www.ripe.net/publications/docs/ripe-733#51 The sum of all allocations made to a single LIR by the RIPE NCC is limited to a maximum of 256 IPv4 addresses (a single /24). If this allocation limit has been reached or exceeded, an LIR cannot request an IPv4 allocation under this policy.)

IPv6 PI i PA získat stále lze.

Blbý... Díky za info.

Kdyby měl někdo zájem, mohu přenechat 16 x "C" IPV4

To "C" je jako co?

Taková historická pikanterie:

https://en.wikipedia.org/wiki/Classful_network

„A classful network is a network addressing architecture used in the Internet from 1981 until the introduction of Classless Inter-Domain Routing in 1993.“

Tato pikanterie je 25 let mimo provoz!!!

Trochu důvptipný technik si umí domyslet, že "C" se v hantýrce dál označuje prefix /24.
Ostatním není ani článek, ani diskuse adresována.

Pokud to nevite, tak ty adresy nepotrebujete

Bohužel IPv6 je často rozbité. Ať už na straně klienta, nebo někde po cestě. A to může být jeden z důvodů.

Vazne? :-) A muzete byt trosku konkretnejsi? Zamerne podotykam, ze diskutujete s clovekem, co nativni IPv6 pouziva jiz mnoho let vsude mozne, vcetne svych pracovnich stanic... a nemyslim si, ze by v dnesni dobe problemy na IPv6 konektivite byly vetsi v porovnani s IPv4. Ano, je mezi nami spousta "odborniku", co je otroky minulosti. A na zaklade historickych zkusenosti - casto jeste z dob, kdy pouzivali IPv6 skrze nejaky tunel - siri prokazatelny FUD, ze IPv6 je rozbite. Ne, to uz davno neni.

Vážně. Viz diskuze: IPv6 Poda zde na root foru. To že provozujte IPv6 neznemená, že ostatní nemají problémy.

Cca před 1 rokem jsem pořídil fixni LTE místo satelitniho pripojeni na chatu. Jine moznosti nejsou. Zařízení hujaja b2368-22 či tak nějak.

1.Omezený přístup do administracniho rozhrani indoor unit. Po IPv6 ani vidu ani slechu.
2. Ve firmware omezeném vodafonem není vůbec přístup k položce ip passthrough takže mi nejde z mého ipv6 ready routeru udělat ani ipv6 tunel na hurricane electric
3. Ani pomoci NAT 1:1 tunel neudělám. Tunel packety z druhé strany mi zařízení prostě ignoruje.

V místě není alternativa. Maximálně koupit nějakou otevřenou IDU kterou se mi nedaří sehnat. Bohužel ta služba je nabízena jako celek a jiné koncové zařízení se mi nepodařilo protlačit. Krom toho zařízení na fixní LTE od mikrotiku co se týče zisku a nastavení MIMO je dost mizerné.

Co poradís pane chytrej?

Huawei B2338-168 od T-Mobile ve firmwaru podporu IPv6 má, umí prefix delegation i prefix sharing. Že to neumí operátor, to je jiná písnička...
IP Passthrough je bohužel operátory nepodporovaná featura, protože _to přece nikdo nechce_ a není to featura pro _standardního uživatele_. :-(

Celá tahle služba je dost nedotažená.

Ono ale není účelem vždy, všude a každému určitou technologii zpřístupnit.
Jde o obecnou přístupnost - a v obecném případě se IPv6 dá nasadit dobře. V některých místech za cenu výběru jiného dodavatele a (podstatně) dražší trasy.

Příměr: každému je dnes dostupné auto s ESP, airbagy a bůhví čím. To tvrzení je platné, a nijak se nevylučuje s tím, že spousta lidí koupí bazarový kus bez technologií - ať už kvůli osobní preferenci, nebo s ohledem na cenu. Někdo jezdí veřejnou dopravou, kde airbagy nejsou. Spotřební LTE je nutno přirovnat k té veřejné dopravě.

IPv6 je u mnoha operátorů stále jako otloukánek. Když to funguje, funguje to stoprocentně. Ale někdy se stane, že se zatoulají routy, prodlouží se latence, ..., a to všechno mají operátoři a jejich dohledy na IPv4 vychytané. Na IPv6 to tak slavné není.

Tak si přečti nařízení Evropského parlamentu 2015/2120. Podle něho máš právo:
1) Na volbu vlastního koncovýho zařízení pro telekomunikační službu. S výjimkou situace, kdy se jedná o nestandardní řešení a nejde to realizovat jinak, než zařízením od ISP. To ale asi nebude případ LTE a pokud je, musí ISP dokazovat, že to tak je, proč to tak je a proč nemohl použít standardní řešení.
2) Díky tomuto nařízení máme síťovou neutralitu. Provozovatel nesmí svévolně blokovat část obsahu internetu. Nesmí třeba jenom tak svévolně blokovat konkrétí IP adresy, URL a protokoly. IPv6 je plnohodnotný protokol a bez něj se na některý stránky nedostaneš (třeba na nebezi.cz).

Takže je na místě napsat ISPíkovi pěkně ostrý mail s odkazem na paragrafy a co odpoví s patřičným komentářem hodit na ČTÚ. A pokud ČTÚ nebude konat, tak to hnát až na ministerstvo a do médií. A vůbec se s nima nes*at. Ty máš podle platné legislativy právo něco požadovat a když o to požádáš, musí ti být vyhověno. Jenom se o to právo musíš aktivně hlásit (práva se totiž můžeš i dobrovolně vzdát, jinak by to byla povinnost).

https://eur-lex.europa.eu/legal-content/CS/TXT/?uri=CELEX%3A32015R2120

Problém IPv6 je ten, že se autoři snažili vyřešit deset věcí najednou, místo toho aby udělali nějaký minimální set funkčnosti s možností nějakého rozumného rozšíření v budoucnu a tlačili na rychlé zavedení toho minima. Ve srovnání s IPv4 je to příliš složité, klade to vysoké nároky na know-how i změny softwaru a hardwaru. Věřím, že to šlo udělat lépe a rychleji ale recept na úspěch upřímně nemám - bylo zcela jistě velmi těžké najít ten správný balanc a ne vše lze zavést později. Něco ale určitě ano.

Tohle tvrzení platí tak maximálně o automatické konfiguraci. Všechny ostatní části IPv6 jako mobilita, IPSEC, nebo třeba multicast jsou od jádra protokolu do jisté míry oddělené a je možné je zavádět kdykoli později. Bohužel, nejsložitější pro spoustu lidí je vymyslet znovu síť tak, aby byl všude přidělen dostatečný počet adres a nebylo tak nutné někde adresy sdílet. A to se ukazuje jako kámen úrazu zvlášť u celé generace ajťáků, kteří nikdy nezažili internet bez NATu a je to pro ně integrální součást návrhu sítí.

Stejný problém by ale musel řešit jakýkoli protokol s větším adresním rozsahem.

Automatickou konfiguraci jsem měl přesně na mysli, bohužel je to něco bez čehož je IPv6 nepoužitelné protože statické adresy by snad chtěl jen masochista (máme zákazníky se striktně statickými IPv4 sítěmi takže je to možné). Nicméně úplně tak nesouhlasím s tím že "ostatní části" jsou odděleny. Technicky možná ano, problém je že věci jako lokální link adresa (spojená s RADVD) je standardně v OS přítomna a správce to musí řešit, a to dokonce už v ranné fázi návrhu nebo implementace. Hned na to se dozví a tragedii s nutností kombinace IPv6 a RADVD z čehož mi zkrátka plyne že RADVD je slabým článkem celého IPv6 problému nasazení. Bohužel je to snad nejdůležitější součást protože tu, na rozdíl od mobility nebo IPSEC, potřebují s tak velkými rozsahy adres úplně všichni.

S tou generací ajťáků kteří zažili jen NAT máš pravdu, zajímavá myšlenka. Každopádně aby to neukončil tak černě, oceňuju práci kterou děláš nejen na root.cz a i ostatních včele s Petrem. Myslím si že se to nakonec podaří protlačit, jediná správná cesta je asi už jen osvěta protože vše je dané.

Jenže RADVD nepotřebuješ. Je to jenom jedna z možností, jak konfigurovat. Ještě je tady DHCPv6, AHCP a manuální konfigurace. A posílání RA z routeru se dá jednoduše vypnout (jediná možnost je to totiž jenom u Androidu, pokud mě paměť neklame).

AHCP vypada dost obskurne. Jaka je podpora v operacnich systemech?
Rucni konfigurace pravda RA nepotrebuje, DHCPv6 se ale pro nastaveni default gateway bez RA (a tedy i nejakeho RA demonu, napr. RADVD) neobejde.

RA nemusi obsahovat informaci o linkovem prefixu. Bez RA ovsem automaticky koncovym zarizenim nedokazete rict, jakou adresu ma Vase gateway.

Samozrejme pokud se nebavime o koncove LAN, jsou ve hre i routovaci protokoly, ktere informaci o sitovych cestach predaji (BGP, OSPFv3, IS-IS, ...).

> Jenže RADVD nepotřebuješ

No ale to já přece vím (platí to jen do jisté míry - když nepotřebuješ DNS), vždyť je to pointa mého komentáře. Je to balast který by tam neměl být, přesto v každé knize, příručce, školení atd atp se o RADVD dozvíš. K ničemu, celé to ten proces zpomalilo.

30. 11. 2019, 18:40 editováno autorem komentáře

Tak já mám nativně od ISP prefix /56. A jediná komplikace, na kterou jsem narazil (a zatím nevyřešil), je jak naprat mašiny do lokálního DNSka, abych se třeba z noťasu dostal na konzolu manželčinýho stroje a nemusel ji kvůli záplatování vyhánět. Bohužel, tohle je vlastnost docela zásadní, takže ačkoliv mám nativní IPv6, interně pro SSH vede IPv4 :( Zatím totiž byly k řešení důležitější věci, než konfigurování a vynucování DHCPv6.

No a k tvrzení "Ve srovnání s IPv4 je to příliš složité, klade to vysoké nároky na know-how i změny softwaru a hardwaru" - je tam několik nepravd:
1) Není to složité, je to jednodušší, než IPv4. Jenom to dělali jinak a lidi na to zatím nejsou zvyklí. Třeba konfigurace routeru. U IPv4 nastavím IP adresu WAN nebo metodu jejího získání, pak DHCP pool (velikost, masku, IP adresy), konfigurovat VPN. A řešit, že někdo jede někdo se stejným privátním rozsahem, takže se nedostanu do jeho VPN. U IPv6 stačilo zapnout router, dostal od ISP přes PD prefix, z něho vyloupl jednu /64 a poslal do LAN. Který klient chce, ten využije RA, kdo nechce, nechá se obsloužit DHCPv6. Pokud nechceš něčemu delegovat pevnou adresu, nemusíš o IP adresách nic vědět. A protože je prefix unikátní, můžu se bavit i s mašinou v jiné síti napřímo. A problém nastavení firewallu je všude stejný.
2) Nároky na know-how jsou menší. U IPv6 si nemusíš pamatovat finty na tunelování CGNATu, nemusíš si udržovat přehled o VPSkách a platbě za VPS, ...
3) Změny softwaru - Apple to umí, Android to umí, Linux to umí, BSD to umí, Widle od sedmiček výš to umí, OpenWRT/LEDE/Tu­rrisOS to umí, ... Co to neumí, to jsou většinou nepodporovaný zastaralý krámy a pokud jedeš na dual stack, bolí zatím spíš jejich díry, než absence IPv6.
4) Hardware měnit nemusíš. Jediný, co je potřeba, je, aby router dokázal na firewallu filtrovat IPv6, dokázal si převzít od ISP prefix a poslat ho dál. Zbytek tě netrápí. V pracovně třeba používám managovaný L2 switch TP Link TL-2218WEB, co si pamatuje ještě jak jsem ke komplu dostal OEM licenci na XPčka (na hraní s dev kitama a RPi bohatě stačí)). O IPv6 nemá jeho firmware ani tucha a stejně to proleze, dokonce i VLANama (jenom ten management je po IPv4 - v dual stack to není problém). Prozradím ti totiž tajemství, na téhle úrovni je IP protokol jenom payload a jede se jenom na MAC adresy. Takže L2 beze změny, L3 chce jenom update firmwaru. HW to s přehledem dá, pokud to není úplná troska, které se do paměti nevejde vlastní IPv6 adresa (a taková troska je na výmenu i bez přechodu na IPv6).
5) Spoustu HW můžeš s IPv6 prostě zahodit. Pokud máš třeba zvonkový tablo s VoIP, domácí router (+NAT), síť ISP (+CGNAT) a mobil (NAT na BTSce), musíš mít ještě někde server s veřejnou IP adresou, se kterým tablo i mobil udržují spojení a přehazuje to pakety z jednoho soketu do druhýho i v době, kdy nezvoní návštěva, protože NAT (a jsme zase u bodu 2 - jak to železo navíc konfigurovat?) Stojí to za to? Nebylo by lepší, kdyby se tablo s mobilem prostě viděli a po zazvonění návštěvy se tablo s mobilem spojilo třeba přes domácí router v roli home agenta (RFC3775 + RFC3776) místo udržování soketu přes prostředníka 24/7? Rozhodně by to zmenšilo traffic v sítích, ušetřilo energii i práci s VPSkou a samozřejmě náklady na to všechno... O železe u ISP (CGNAT, evidence trafficu kvůli policii,...) ani nemluvím.

(1), (2), (3) by řešil jednodušší protokol který by dal lidem jen větší rozsah, tudíž by byly přidělovány sítě a zmizela by téměř NAT. Bez jakýchkoliv dalších serepetiček typu lokální link adresy a RADVD. Moje tvrzení není žádná nepravda, je to jen jiný úhel pohledu.

(4) a (5) už se téměř dnes vyřešilo, to ano, taky to trvalo 25 let! Jak se říká po bitvě je každý generál. Moje poznámka směřuje k tomu, že kdyby býval byl protokol navržen jednoduše prostě jen jako IPv4 s větším rozsahem, tak by software a hardware mohl být k dispozici už po deseti letech. Třeba ano, třeba ne. Nepravda? Těžko.

Moje tvrzení že IPv6 klade vyšší nároky na know-how protože by mohl být vymyšlen daleko jednodušší přístup se těžko vyvrátí a stojím si za ním. Musím souhlasit že je to taková divoká teorie a spíš takový povzdech, prostě bych si přál si aby to bylo celé jednodušší. Já IPv6 myslím rozumím (základům), implementoval jsem IPv6 do velkého projektu a produktu pro správu serverů a sítí (ještě úplně není hotova integrace s ISC DHCP kvůli Kea) a můžu s klidem říct že zákazníci s tím mají problém. A strašně, strašně málo jich IPv6 v datacentrech má.

Je to přesně jak říkáš. Kdyby IPv6 bylo jen o rozšíření adresního prostoru, dávno už bychom ho nejspíš všichni používali. Jenže tím, jak se kromě tohohle zásadního problému pokusilo ještě vyřešit Všechny Myslitelné Problémy Lidstva(tm), se to celé zkomplikovalo. Je to složitější na naučení a pochopení, pokud teda nebereme jako postačující možnost, že to připojím a ono to nějak bude fungovat. Dalším problémem je, že čím je to celé košatější a čím víc možností to nabízí, tím větší prostor to taky skýtá pro všemožné bezpečnostní problémy, ať už z hlediska nějaké chyby v návrhu, implementaci nebo kvůli špatnému nastavení.

Pořád tu opakujete, že problém IPv6 je, že řeší úplně všechno, místo aby jen prodloužilo IP adresy. Jako příklad přitom uvádíte jen autokonfiguraci. To mi jednak jako úplně všechno nepřipadá, jednak ze své praxe vidím, že autokonfigurace není ani zdaleka takový problém jako nutnost uvědomit si povinnosti vyplývající z neexistence NATu.

Tedy například to, že na domácnost nestačí přidělit jen jednu adresu na WAN rozhraní domácího routeru. A když už to pochopí a adresy pro LAN přidělí (a pochopí, že /64 je fakt málo), nepochopí, že adresy nestačí jen přidělit, ale je potřeba taky přidat patřičný záznam do směrovací tabulky, aby provoz mířící na tyto adresy skončil tam, kde má. A nebo jako PODA nechtějí chápat, že existuje netriviální množství zákazníků, kteří si za jejich povinnou krabičku (ONT, DSL modem, DOCSIS modem) připojí svůj vlastní router a chtějí mít veřejné adresy i za ním.

Tohle všechno jsou problémy, které by bylo úplně stejně potřeba řešit i v jakékoli „IPv4 s delší adresou.“

Nic jsi nepochopil. Čím víc toho chceš umět nastavit a nakonfigurovat, tím víc toho musíš umět, tak už to v životě chodí. Když se ti to nelíbí, dělej něco, kde ty standalone znalosti nepotřebuješ, třeba zakopávej optiku do země. A pokud se rozhodneš věnovat něčemu odbornýmu, tak právě vědomosti jsou ta věc, za kterou jsi placený. Kdyby tvoje odborný znalosti mělo 95% populace, tak bys dělal za minimálku. Nechme autokonfiguraci těm, komu stačí a prodávejme naše znalosti těm, kdo by chtěli něco víc. BFU budou bez znalostí IP adresy klidně spát a my se znalostí, co je pod pokličkou, budeme mít vyšší kapesný.

V IPv4 je kolem vědomostí defakto socialismus, kdy BFU, power user a senior admin musí mít ty samý znalosti, aby to vůbec mohli používat a když se jako začátečník prokoušeš tím balastem, který by normálně měl jít mimo tebe, nabýváš pocitu, že se už dál nic učit nemusíš... Protože i ta blonďatá účetní v IPv4 světě musí vědět, co je to IP adresa a kde ji najít, aby se dostala přes VPN k serveru s účetnictvím, když má home office.

Připojím to a nějak to bude fungovat" je úroveň pro BFU, kterou tam dali schválně, právě aby se BFU nemuseli nic učit. Kdo chce víc, musí se to naučit, nebo zaplatit někomu, kdo se to naučil za něho. A tak to má být.

Ach jo, tak znovu.

"Moje tvrzení že IPv6 klade vyšší nároky na know-how protože by mohl být vymyšlen daleko jednodušší přístup se těžko vyvrátí a stojím si za ním."
V čem jsou ty vyšší nároky? Není to jenom obecný nepodložený blábol?
Z pohledu aplikace, když chci komunikovat v jakékoliv IP síti, prostě si otevřu soket, řeknu mu IP adresu a port protistrany a sypu/přijímá data. IP protokol je jenom jedna vrstva z celýho stacku, nad ním máš ještě TCP nebo UDP, pod ním stejnou MAC a PHY. Je to úplně stejný, až na délku adresy.
Nebo je snad složitější nakonfigurovat DNS, když místo A záznamu dáváš AAAA záznam a jinak se to neliší?
Nebo je potřeba rok studovat a dělat zkoušky z toho, že zařízení chytne RA paket, vezme z něj gateway a prefix, vygeneruje si zbytek adresy, zeptá se okolí, jestli to někdo používá a když ne, tak to začne používat samo?
Aha, ty myslíš CIDR notaci, když místo psaní ffff:ffff:fff­f:ffff:: stačí napsat /64 a je to.

" a můžu s klidem říct že zákazníci s tím mají problém."
Zvyk je železná košile. Třeba u nás v bývalé práci se používal Lync. Při připojování to chtělo IP adresu protistrany, takže když někdo svolával meeting, musel mailem rozeslat pozvánku s IP adresou jeho PC. Pokud to poslal ve čtvrtek, o víkendu stroj vypnul a v pondělí pak dostal jinou IP adresu, nastal obrovský problém s organizací meetingu. Takže obrovský problémy jsme měli i s IPv4. IPv6 by už byla jenom třešnička na dortu, protože by se opisovalo 4x delší hexa číslo, ale nebyl by to vůbec nový problém, jenom by to zviditelnilo stávající.
Prostě se furt nemůžu zbavit pocitu, že libovolná verze IP protokolu může přinášet problémy, pokud aplikaci nad ním píše pitomec. S IP protokoly obecně mám jenom čtyři problémy - NATy v IPv4, chybějící multicast v IPv4, autokonfiguraci v IPv6 a používání i tam, kde to není efektivní (např. udržování TCP/IP přes WiFi v bateriové aplikaci).

"A strašně, strašně málo jich IPv6 v datacentrech má." Nediv se. Pokud bys byl podnikatel, nerozuměl IT, najal si odborníka a ten tvrdil, že jsou dva protokoly a jeden z nich nefunguje, tak zvolíš ten druhý. Takže tímhle arguementem ses pěkně střelil do nohy.

Co se té správy serverů týká, všichni víme, že ta úplně nejhorší vlastnost IPv6 je nefunkční přidělování IP adres koncovýmu zařízení. Tohle kdyby pořádně (nebo aspoň trochu) fungovalo, po IPv4 neštěkne pes (mimo kompatibility s historií). Pokud je to tvoje jediná zkušenost, tak tvůj postoj docela chápu. Nemocný DHCPv6 podle DUID nebo RA+ND, u kterýho nevíš, co, kde a jestli vůbec v síti je, je peklo. Kdyby aspoň stroj po autokonfiguraci místnímu DNSku ohlásil "Tady stroj jménem ABC123, mám adresu 2001:1234:...", tak by šlo klidně nechat i servery na RA a řídit se tímhle.

To bol asi ešte NetMeeting, nie?

Nepovinny dhcpv6 je feature, nie bug. Android nepodporuje dhcpv6 zamerne, pretoze ten umoznuje pridelit jedinu /128 a zariadenie s tym nic nespravi.

Co je sice fajn pre spravcov siete, ale uplne zle pre pouzivatelov mobilnych telefonov, ktori by si v celularnej sieti chceli urobit tethering. Pretoze ano, prva vec co by mobilni operatori zaviedli, je povinny dhcpv6 a tethering za priplatok. Takto s RA si pre kazde tetherovane zariadenie vymyslia dalsiu ipv6 adresu a vsetko funguje.

Podobne je to s DNS: nechcete, aby sa vam kazde zariadenie registrovalo, alebo nebodaj aby registrovalu kazdu zo svojich ip adries. V manazovanych sietach je toto vyssie v stacku, pri AD alebo RH IdM zariadenie musi mat spravny keytab (joinute v domene), aby to vobec dokazalo spravit. Ano, cena toho je to, ze v logoch su ip adresy, ktore nejdu reverzne resolvnut. Pokial chcete mat prehlad, kto sa vam potuluje po sieti, tak 802.1x.

Ze vy pouzivate nieco od Turrisu?

Tam to maju chlapci trocha rozbite, kresd pri starte nacita aktualne zname ipv6 adresy a tym to konci, cokolvek sa rozda po starte kresd, uz sa resolvovat nebude.. Plati pre AAAA, pre A forwarduje na dnsmasq.

Ked sa vypne kresd a pouzije dnsmasq ako resolver, lokalny resolving funguje ako ma. Za cenu straty podpory DNNSEC. No, treba si vybrat svoje priority ;).

Jo, mám T1.0, ale takhle do hloubky jsem to nezkoumal.

Je fakt, že Linuxový stroje v LUCI vidím, ale z DNSka IP6 adresu nedostanu.
Taky je fakt, že jsou tam dva resolvery, jeden hlavní a druhý pro doménu .lan, ale pokud ten IPv6 ignoruje, tak je celkem jasno... Jenomže jak z toho ven?

Ako z toho von je presne to, co som napisal ako druhu moznost: vypnut kresd, obetovat DNSSEC, zapnut odhcpd (dhcpv6, pozor, nechat aj RA, ked mate v sieti androidy, a RA adresy nebudu mat dns zaznam). Plus po updatoch TurrisOS treba skontrolovat, ci ten nezapol kresd naspat, velmi rad to robi.

Aspon takto som to kedysi pouzival, potom som sa prestahoval, novy isp mi dal na vyber verejnu ip4 bez ipv6 alebo ds-lite, takze som zobral prvu moznost a po rokoch som zase bez ipv6.