IPv6 - přechodové mechanismy (2)

28. 3. 2002
Doba čtení: 6 minut

Sdílet

Po předchozím kursu tunelování se dnes podíváme na ty přechodové mechanismy, které usilují o soužití obou světů. Převádějí datagramy z jednoho formátu do druhého a umožňují, aby si třeba IPv6 aplikace popovídala s IPv4 serverem.

K dispozici jsou následující prostředky:

SIIT RFC 2765
NAT-PT RFC 2766
BIS RFC 2767
BIA draft-ietf-ngtrans-bia
TRT RFC 3142

SIIT aneb Praotec Převodník

Srdcem většiny konverzních mechanismů je vlastní převod mezi IPv4 a IPv6 datagramem. Je definován pod jménem SIIT (Stateless IP/ICMP Translation) v RFC 2765. Obsahuje přesná pravidla, jak se jednotlivé položky datagramu převádějí do položek druhého formátu.

Asi nejzajímavější je převod adres. Pro směr z IPv4 do IPv6 používá tak zvané IPv4-překládané adresy, které mají tvar 0::ffff:a.b.c.d. Čili v počátečních 80 bitech jsou samé nuly, následuje 16 bitů jedničkových a v závěrečných 32 bitech je IPv4 adresa, kterou chceme vyjádřit. Třeba adresa Lupy (62.84.129.156) by v IPv4-překládaném tvaru zněla 0::ffff:62.84­.129.156.

Horší je to v opačném směru – když je třeba převést IPv6 adresu do IPv4 světa. V tomto případě se SIIT zařízení musí chovat jako klasický NAT. Musí mít k dispozici sadu IPv4 adres, které k tomuto účelu používá, a IPv6 adresu prostě nahradí jednou z nich. SIIT sám o sobě neřeší otázku přidělování IPv4 adres – tohle ponechává na okolních mechanismech. V důsledku to znamená, že tvoří jen jakýsi základní stavební kámen, na kterém je třeba vybudovat něco, co bude doopravdy fungovat.

NAT-PT

Jedním z cílů IPv6 je smést NAT s povrchu zemského. Ovšem když teče do bot, je občas třeba spojit se i s nepřítelem. Proto vznikl návrh, jak zapojit NAT do práce pro světlou stranu Síly. Umožňuje strojům z lokální IPv6 sítě komunikovat s globálním IPv4 Internetem.

Netword Address Translation – Protocol Translation (NAT-PT) je v zásadě starý špatný NAT, ale tentokrát převádí mezi IPv4 a IPv6 adresami. Typická pozice pro něj je na hraničním směrovači mezi lokální sítí a Internetem.

Je založen na SIIT a doplňuje k němu chybějící prvky. Nevyžaduje striktně použití IPv4-překládaných adres, stačí mu libovolný prefix zvolený správcem sítě. Za něj se připojí 4 bajty s IPv4 adresou. NAT-PT stroj šíří do vnitřní sítě směrovací informaci, že „umí tento prefix“, aby se datagramy určené do vnějšího Internetu posílaly jemu.

Když některý z lokálních IPv6 počítačů odešle takový datagram, na NAT-PT se vytvoří vazba mezi jeho IPv6 adresou a některou z volných IPv4 adres, kterými NAT-PT disponuje. Podle pravidel SIIT se datagram přepracuje na IPv4 a odešle do Internetu. Když po chvilce dorazí odpověď, NAT-PT využije stávající mapování, změní jej na IPv6 s odpovídající adresou (odesilatele přemapuje na prefix:původní_IP­v4) a odešle do vnitřní sítě.

Návrh připouští statické mapování (každý z lokálních strojů má pevně přidělenu IPv4 adresu), i dynamické (přidělují se za chodu podle potřeby). NAT-PT také švindluje DNS. Při dotazech zvenčí předělává A (dotaz na IPv4 adresu) na AAAA či A6 a předává zdejší serverům. Když server odpoví, vytvoří si mapování pro IPv6 adresu z odpovědi a vrátí původnímu tazateli A záznam s mapovanou IPv4 adresou. Díky tomu lze navazovat spojení i směrem dovnitř zdejší sítě.

Pro DNS dotazy směřující z vnitřní sítě ven přidává k AAAA/A6 i dotaz na A záznam a pokud přijde odpověď, změní jej na AAAA či A6 s adresou v obvyklé podobě prefix:IPv4.

Existuje ještě divočejší podvarianta s názvem NAPT-PT, která vedle IP adres mapuje i porty. Klasický NAT-PT nechává porty být a mění jen adresy. V případě NAPT-PT se mapuje dvojice lokální IPv6 adresy a UDP/TCP portu na dvojici IPv4 adresy a portu. Díky tomu překladač vystačí s podstatně menším počtem adres (třeba i jen s jedinou).

Očekává se, že NAT-PT sehraje v přechodné fázi mezi IPv4 a IPv6 poměrně významnou úlohu. Rozhodně patří do „základní výbavičky“ přechodových mechanismů.

BIS aneb utajované operace v každém počítači

BIS čili Bump In the Stack řeší problém nedostatku IPv6 aplikací. Vychází z představy, že váš počítač podporuje IPv4 i IPv6 a je připojen k síti přenášející oba protokoly. Ovšem některé zdejší aplikace umí jen IPv4.

Proto uvnitř počítače (konkrétně mezi IPv4 a ovladačem síťové karty) číhá BIS. Zachytává IPv4 DNS dotazy a vedle původního dotazu na A záznam přidá i AAAA či A6. Dorazí-li IPv4 odpověď, předá ji aplikaci a nechá vše vyřídit starším protokolem.

Problém vznikne, když dojdou pouze odpovědi s IPv6 adresami. Těm by aplikace nerozuměla, takže je hbitě namapuje na IPv4 a předá aplikaci A záznam s mapovanou adresou. Když pak aplikace odesílá datagramy na danou IPv4 adresu, BIS je zachytává, transformuje na IPv6 a předává na původní adresu. Analogicky mění odpovědi.

Vzhledem k tomu, že mapované IPv4 adresy nikdy neopustí daný počítač (jsou vnitřní záležitostí mezi BIS a aplikací), klidně lze pro ně použít privátní adresní rozsahy 10.0.0.0 a spol.

BIS funguje i v opačném směru, když spojení navazuje protější IPv6 počítač. Tentokrát však není nutno harašit s DNS, stačí jen namapovat adresy a měnit datagramy.

Určitou variantou tohoto přístupu je Bump In the API (BIA), které dělá v podstatě totéž, ale jinde. Tentokrát není agent ukryt mezi IP a ovladačem karty, ale v systémových knihovnách zajišťujících přístup k síťovým službám. Když aplikace volá knihovní funkce pro IPv4, jsou interně změněny na volání IPv6 služeb. Čili nedochází k překladu datagramů, ale vytváří se již čisté IPv6 pakety, zatímco aplikace si myslí, že používá IPv4 služby.

Osobně bych neočekával závratné rozšíření těchto metod. Podle znalců není úprava aplikace pro podporu IPv6 nijak náročná a toto řešení je přece jen o poznání systémovější.

TRT

Transport Relay Translator se hodně podobá NAT-PT. Tentokrát se však překlad odehrává až v transportní vrstvě, nikoli v síťové. TRT překladač funguje podobně jako některé firewally. Umí IPv4 i IPv6, sedí mezi oběma komunikujícími partnery a každému z nich předstírá, že je ten druhý.

Zatím byl definován pouze postup při navazování TCP spojení ve směru od IPv6 počítače k IPv4 stroji. Jedinou překážkou pro opačný směr je nalezení vhodného mechanismu pro mapování adres. Pro mapování IPv4 na IPv6 se používá výše zmiňovaný postup: vyhradí se prefix (tentokrát 64 bitů dlouhý, pocházející z prefixu pro zdejší síť) a adresy počítačů z IPv4 světa se mapují jako prefix:IPv4_adresa.

Řekněme, že cílový počítač bude Lupa (62.84.129.156) a dotyčný prefix bude 3ffe:a:b:c::/64. Chce-li IPv6 počítač navázat TCP spojení s Lupou, pošle žádost o navázání spojení na 3ffe:a:b:c::6­2.84.129.156. TRT překladač šíří v lokální síti směrovací informaci, že on je ta pravá cesta do 3ffe:a:b:c::/64, takže mu tato žádost dorazí.

Iniciátorovi spojení odpoví sám a bude předstírat, že on je Lupa. Paralelně naváže spojení s Lupou – cílovou adresu si vyzvedne z posledních 4 bajtů původní adresy a pro odesilatele použije svou vlastní IPv4 adresu. Lupě pro změnu bude předstírat, že je onen klient.

Místo jednoho spojení mezi serverem a klientem budou tedy existovat dvě. Klient-překladač po IPv6 a překladač-server po IPv4. Následně bude prostě z datagramů přicházejících z jednoho vybalovat jejich obsah a předávat jej do druhého.

Pro UDP se chová obdobně, jen zde odpadá nutnost navazovat spojení. Návrh neřeší otázku, kde proběhne konverze adres z IPv4 do výše zmiňovaného IPv6 tvaru s vyhrazeným prefixem. Připouští modifikaci DNS serveru v síti, případně úpravu DNS klienta v jednotlivých počítačích.

Autor článku

Autor dělá nepořádek v příslovích, protože sítě nejen dělá, ale i učí a dokonce také řídí. Působí na Ústavu nových technologií a aplikované informatiky na Technické univerzitě v Liberci. Píše knihy.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).