IP verze 6 dlouhodobě trpí problémem „slepice nebo vejce“. Uživatelé se do něj moc nehrnou, protože novým protokolem je dostupných méně služeb než jeho předchůdcem. A kdo by převáděl služby pod IPv6, když tam nejsou uživatelé… Jedním z prostředků, které by měly pomoci rozetnout tento začarovaný kruh, je překlad protokolů.
Jeho základním kamenem je Stateless IP/ICMP Translation Algorithm (SIIT) definovaný v RFC 2765. Tento algoritmus definuje pravidla, podle nichž se překládají IPv4 datagramy na IPv6 a naopak. Cílem je umístit překladatele mezi části sítě komunikující odlišnými protokoly a předstírat strojům z obou světů, že jejich komunikační partner mluví stejným protokolem.
SIIT je ovšem pouze základ. Algoritmus je bezstavový, neukládá si žádné informace o probíhající komunikaci a neřeší například vzájemné vazby mezi adresami obou protokolů. K tomu potřebuje dodatečné mechanismy. Přesněji řečeno je to opačně, SIIT slouží jako součást (překladová jednotka) složitějších mechanismů, které zajišťují kompletní překlad.
Mezi ně patří Network Address Translation – Protocol Translation (NAT-PT) podle RFC 2766. Jeho cílem je především umožnit koncové síti využívající protokol IPv6 komunikovat s IPv4 Internetem. Na rozdíl od obyčejného NATu nemění jen adresy, ale celé datagramy, které podle pravidel SIIT převádí z jednoho protokolu do druhého. Navíc upravuje procházející DNS dotazy a odpovědi. Díky tomu je možné navázat spojení oběma směry. O něco podrobnější popis najdete v našem starším článku.
Právě možnost komunikovat se stávajícími IPv4 službami, aniž by koncové počítače věděly o konverzi datagramů, stála v pozadí velkých nadějí vkládaných do NAT-PT. V praxi však k jejich naplnění nedošlo. NAT-PT se nikdy nedočkal masového nasazení a naopak experimenty s ním postupně odhalovaly řadu problémů a nedostatků. Během prázdnin teď vyšlo RFC 4966 s jejich neradostným souhrnem.
Problémy rozděluje do tří skupin podle jejich vztahu k mechanismu měnícímu DNS, který se ukázal být jedním z kritických míst NAT-PT. Do skupiny problémů nezávislých na změnách DNS patří v první řadě tradiční problém všech NATů – protokoly přenášející v aplikační vrstvě IP adresy. Zde je problém ještě horší, protože IPv4 adresa je jinak dlouhá než IPv6, takže kromě obsahu zprávy a kontrolních součtů se mění i její délka, což může způsobit přetečení maximální délky paketu a další nepěkné situace. NAT-PT proto musí znát některé aplikační protokoly a zasahovat do přenášených dat, což mimo jiné znamená hodit přes palubu bezpečnostní mechanismy IPsec.
Ty ale nejsou jedinou obětí. Převod podle SIIT má určitá omezení a řadu pokročilejších prvků IPv6 není schopen převést do IPv4. V důsledku toho některé mechanismy (mobilita, multicast apod.) budou fungovat špatně nebo vůbec ne a aplikace nutně budou mít problémy. Přidávají se časové obtíže, protože vazby mezi adresami v tabulkách NAT-PT mívají omezenou platnost. Pokud se komunikace odmlčí, nebude později možné v ní pokračovat, protože příslušné záznamy již zmizely z tabulek NAT-PT.
Do druhé skupiny byly zařazeny problémy, které modifikace DNS přímo nevyvolává, ale zhoršuje je. Vyplývají například z toho, že NAT-PT musí stát v cestě mezi koncovými stroji a IPv4 Internetem, a to jak z hlediska datových přenosů, tak z hlediska DNS. To omezuje síťovou topologii a navíc staví NAT-PT do pozice úzkého místa limitujícího přenosový výkon sítě. Jeho selhání bude mít pro koncovou síť fatální důsledky. Přitom nasazení několika synchronizovaných NAT-PT pro rozdělení zátěže a vzájemné zálohování nebylo uspokojivě vyřešeno.
V této skupině se podruhé hlásí o slovo čas, protože i DNS přiděluje svým záznamům určitou životnost. Sladit ji s životností záznamů v převodových tabulkách adres uvnitř NAT-PT není vůbec jednoduché. Zásadní problém pak mají aplikace požadující trvalé IP adresy. Z hlediska bezpečnosti NAT-PT představuje lákavý cíl DoS útoků usilujících o vyčerpání jeho zdrojů.
Třetí skupinu tvoří problémy přímo způsobené převodem DNS. Je definován tak, že tazateli z koncové sítě bude podstrkovat záznamy typu A (IPv4) převedené na AAAA (IPv6) i v situacích kdy se to nehodí. Důsledkem může být nevhodná volba cílové adresy či použití překladu i v situacích, kdy by to nebylo nutné. Pokud si aplikace předávají výsledky získané z DNS, znamená to další komplikaci a požadavky na změny aplikačních dat v NAT-PT. Jelikož překlad mění DNS záznamy pro vnitřní síť, nelze je zabezpečit pomocí DNSSEC.
Konečné účtování, které najdete v závěru RFC 4966, je nemilosrdné. Konstatuje, že NAT-PT trpí řadou vážných problémů a zároveň se s ním v popsaných scénářích přechodu k IPv6 příliš nepočítá. Jedinou výjimkou je 3GPP (RFC 4215), kde se ovšem předpokládá upravený NAT-PT nasazený za omezujících podmínek. Autoři proto doporučují, aby IETF přestala NAT-PT doporučovat jako obecný přechodový mechanismus pro IPv6 a změnila statut RFC 2766 s jeho definicí na historický. Což se stalo.
Jako vhodná řešení pro převod datagramů doporučují buď transparentní konverze v koncových počítačích (BIS, BIA), nebo aplikační proxy servery. Eventuálně připouštějí existenci upraveného NAT-PT při rozumných omezujících podmínkách.
Osobně bych důvody k opuštění NAT-PT viděl spíš v oblasti praktické než ve výčtu jeho nešvarů. Od samého začátku bylo zřejmé, že konverze datagramů bude mít k dokonalosti daleko a že nutně bude způsobovat určité problémy. Očekávalo se ale, že přínosy budou větší. Klasický IPv4 NAT má také řadu nectností, přesto se těší obrovské popularitě. Zde se ale očekávání nenaplnila a NAT-PT zůstal experimentální raritou namísto masově používaného nástroje. Čest jeho památce.
