Pokud čtete tento článek, je to i díky lidem, kteří se na konci osmdesátých let sdružili v organizaci s názvem IETF. IETF nebo-li Internet Engineering Task Force je hlavní organizací pro vývoj standardů pro internet. Nejedná se o žádnou státem vedenou organizaci. V této organizaci nejsou žádní členové. Přihlásit se do ní může doslova každý. Kdokoliv na světě (pokud tedy není za nějakým ošklivým firewallem). Prostě klikne, že chce být na „mailing listu“ dané pracovní skupiny, nebo se přihlásí na jednání IETF (virtuálně nebo fyzicky). To je vše. Každý rok se tímto způsobem aktivně zapojí do pracovních skupin více než sedm tisíc lidí. Dobrovolně. Bez nároků na odměnu. S jediným cílem – aby internet lépe fungoval.
RFC 9432: DNS Katalogové zóny
DNS zónu obvykle obsluhuje více autoritativních serverů, což je dokonce doporučeno z důvodu redundance. Velcí provozovatelé autoritativního DNS dokonce kombinují různé implementace name serverů, aby se vyhnuli úplnému výpadku infrastruktury v případě nějaké softwarové chyby. Pro synchronizaci obsahu zóny mezi autoritativními servery existuje pro DNS specifický mechanismus, který se nazývá transfer zóny. Je to osvědčený mechanismus, který podporují všechny běžné implementace DNS. Umožňuje jak transfer celé zóny (AXFR), tak inkrementální update (IXFR).
RFC 9432: DNS Katalogové zóny
DNS zónu obvykle obsluhuje více autoritativních serverů, což je dokonce doporučeno z důvodu redundance. Velcí provozovatelé autoritativního DNS dokonce kombinují různé implementace name serverů, aby se vyhnuli úplnému výpadku infrastruktury v případě nějaké softwarové chyby. Pro synchronizaci obsahu zóny mezi autoritativními servery existuje pro DNS specifický mechanismus, který se nazývá transfer zóny. Je to osvědčený mechanismus, který podporují všechny běžné implementace DNS. Umožňuje jak transfer celé zóny (AXFR), tak inkrementální update (IXFR).
Co má společného Postel, IETF a dnešní Internet
Ve dnech 16. – 21. července 2017 se v Praze bude konat konference IETF 99. O tom, co IETF je a jak funguje, už dřív česky psal můj kolega Ondřej Surý ve svých článcích Cesta do hlubin IETF, Odkud pochází Internetové standardy (aneb bylo jednou jedno RFC) nebo Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF. Ladislav Lhotka zase trefně popsal její neobvyklou geekovskou atmosféru. Proto stačí uvést, že IETF je organizace vydávající internetové standardy. Jejím cílem je vytvářet kvalitní technickou dokumentaci, která ovlivňuje vývoj Internetu a aplikací přes něj provozovaných.
Pozvánka na pražské setkání organizace IETF
O tom, jak vypadají a probíhají meetingy organizace IETF, tu psal nedávno kolega Ladislav Lhotka, který je jejich pravidelným účastníkem; kolega Lhotka je jedním ze dvou Čechů, kteří jsou podepsáni pod internetovými standardy, RFC dokumenty. Pokud by vám nestačil Láďův blogpost, podívejte se na Root.cz, kde dnes vyšel podrobnější popis toho, jak funguje IETF a co může čekat jeho návštěvníky v červenci v Praze. Tolik na úvod.
Před pražským meetingem IETF
Ve druhé polovině července bude Praha dějištěm 93. meetingu IETF, a stane se tak již potřetí v posledních osmi letech. CZ.NIC bude také podruhé za sebou jedním z hostitelů. To je jistě vyznamenání pro naše hlavní město, firmu i české pivo, zároveň se tím ale také české odborné veřejnosti nabízí možnost nahlédnout do kuchyně této významné mezinárodní organizace, která stojí za většinou internetových standardů a technologií.
Poslední výzva pro datové modely
Předseda pracovní skupiny NETMOD při IETF vyhlásil poslední výzvu (Working Group Last Call) pro tři Internet Drafty:
Tyto dokumenty obsahují specifikaci tzv. základních (core) datových modelů v jazyku YANG pro použití především s protokolem NETCONF. První z nich definuje konfigurační a stavová data síťových rozhraní a druhý k tomu přidává základní parametry IPv4 a IPv6. Třetí z dokumentů je pak zaměřen na IP směrování – kromě obecně potřebných parametrů vytváří i rámec, do něhož budou zasazeny budoucí datové modely směrovacích protokolů, route filtrů apod.
Zmíněné tři základní datové modely obsahují skutečně jen elementární parametry, které potřebuje téměř každé síťové zařízení. Jejich vývoj přesto nebyl úplně hladký, především proto, že jedním z hlavních požadavků byla kompatibilita s konfiguračními rozhraními (CLI) předních výrobců, tj. v první řadě Cisco Systems a Juniper Networks. Na tomto místě snad mohu přiznat, že jsem též přihřál naši polívčičku a při návrhu datového modelu pro směrování zohlednil i způsob konfigurace démona BIRD.
Právě proto, že jde o základní a široce použitelné věci, je velmi důležité, aby v těchto datových modelech nebyly žádné podstatné vady. Dovoluji si proto požádat všechny experty, kteří čtou tento příspěvek, aby se na uvedené dokumenty podívali. Pokud by zjistili nějaké nesrovnalosti, mohou je napsat buď přímo do mailing listu pracovní skupiny NETMOD, anebo jednoduše jako komentář k tomuto příspěvku – já bych je potom předal dále. Poslední výzva končí v pátek 30. listopadu, připomínky bude ale možné zapracovat i po tomto datu. Předem díky!
Ladislav Lhotka
Z IETF 84: standardizace konfiguračních dat
Během posledního meetingu IETF, který měl pořadové číslo 84 a konal se v kanadském Vancouveru, se výsledky mých „kmenových” pracovních skupin NETCONF a NETMOD objevily v zajímavé diskusi na širších fórech, konkrétně v mailing listu ietf@ietf.org, při jednání pracovní skupiny OPSAREA (Operations and Management Area), jakož i v kuloárních debatách.
Diskusi zahájil svým příspěvkem polský kolega Robert Raszuk. Pozastavil se nad tím, že ve specifikacích nových protokolů chybí schéma konfiguračních dat, a navrhl, aby všechna RFC povinně obsahovala oddíl s takovým schématem, protože bez něho si každá implementace vytváří svůj vlastní způsob konfigurace, který nemusí být s ostatními zrovna kompatibilní. Problém je to reálný, kdo by tomu nevěřil, ať si zkusí mezi sebou převést netriviální konfigurace směrovačů různých výrobců (včetně našeho BIRDa).
Navrhované řešení, tedy zavést toto jako povinnost, se ovšem setkalo s jednoznačným odporem. Robertovi se též dostalo doporučení, aby se seznámil s výsledky pracovní skupiny NETMOD, kde se již datové modely pro některé základní protokoly a subsystémy vyvíjejí.
V této souvislosti se ale ukázalo, že datové modely NETMOD tak docela nenaplňují vizi unifikace konfiguračních schémat. Jsou totiž poměrně pružné a umožňují definovat schémata v různých podobách, od odlišností v pojmenování objektů (klasickým příkladem jsou třeba jména síťových rozhraní) až po menší či větší rozdíly v logice a uspořádání konfiguračních dat. Důvody jsou nasnadě: Nelze očekávat, že přední výrobci směrovačů a jiných zařízení po zveřejnění datových modelů srazí paty a překopou svá konfigurační rozhraní, která si po léta hýčkají a školí na nich své zákazníky. Jistá míra pružnosti proto dává naději, že by se konkrétní implementace datových modelů mohly naopak přizpůsobit existujícím konfiguračním rozhraním. Lze pak ovšem očekávat, že nebude možné jednoduše vzít konfiguraci jednoho boxu a instalovat ji beze změn na obdobném zařízení jiného výrobce.
Toto je docela složité dilema, uvidíme, jak se věci vyvinou. Rozhodně by ale bylo dobré, kdyby se specifikace konfiguračního schématu staly součástí standardů aspoň pro nové protokoly – byť třeba nepovinně.
Ladislav Lhotka