Zdroj: Lupa.cz

V první polovině roku jsme na tomto místě publikovali několik možných způsobů, jak si poradit s nedostatkem IPv4 adres, ať už to byl návrh na využití tzv. base adres jednotlivých rozsahů nebo možnosti nasazení nevyužívaných adres tzv. třídy E (díl první, díl druhý). Tyto zmíněné možnosti mají společné to, že v prostředí IETF nemají rozhodně snadný život, publikované drafty zatím nezískaly v rámci pracovní skupiny intarea podporu a mají tedy zatím jen status tzv. individuálních draftů.

Dnes nás čeká úplně jiný případ, který podporu získal a ke kterému už řadu let existují i příslušné RFC dokumenty, byť vzešly z jiné pracovní skupiny IETF, konkrétně bess (BGP Enabled ServiceS). Budeme si totiž povídat o možnosti oznamovat protokolem BGP IPv4 prefixy s IPv6 next-hop parametrem podle RFC 8950 (který v listopadu 2020 nahradil předchozí RFC 5549, také řešící tuto problematiku). Nejdříve si vysvětlíme, jak přesně to funguje a k čemu je to dobré.

MP-BGP, tedy multiprotokolové rozšíření protokolu BGP, umí oznamovat v jedné BGP relaci v rámci takzvaných „address families“ (AFI/SAFI) různé věci. Samozřejmě v první řadě unicastové IPv4 a IPv6 routy, ať už samostatně, nebo oddělené do různých L3 VPN (VPNv4, VPNv6), multicastové skupiny (i ve VPN), informace pro bridging L2 VPN, filtrovací pravidla (flow specification) atd., je toho opravdu hodně. Toto rozšíření BGP protokolu tu je někdy od roku 1998, byť v průběhu času samozřejmě doznalo výrazných změn, nicméně jedna věc v něm bývala jednoznačná – šířím-li v IPv4 unicast AFI IPv4 prefix, musí mít jako parametr „next-hop“, tedy adresu stroje, na který se má provoz pro dotyčný prefix poslat, zásadně IPv4 adresu (a naopak prefix v IPv6 unicast AFI IPv6 adresu).

Tohle paradigma ovšem už s příchodem RFC 5549 v roce 2009 padlo a routery se postupně naučily věc do té doby nevídanou: poslat IPv4 packet na IPv6 next-hop. Co to znamená? Zjednodušeně, má-li router někam poslat IP packet, nejprve se podívá do „routovací tabulky“ – ne, tenhle pojem raději nebudeme používat, není totiž zcela jednoznačný. Podívá se nejprve do FIB (Forwarding Information Base) a tam si najde záznam pro příslušný prefix.

Z onoho záznamu si vezme parametr next-hop a podívá se znovu do FIB na záznam pro tu adresu, kterou získal z toho next-hop parametru. Následně z tohoto záznamu zjistí příslušné rozhraní, ať už fyzické nebo virtuální, kam ten packet má poslat. Pak se podívá do ARP databáze (v případě IPv4) nebo do neighbor databáze (v případě IPv6), vytáhne si z nich L2 MAC adresu příslušející k dotyčné IPv4/IPv6 next-hop adrese a tu použije jako cílovou L2 MAC adresu nově vytvořeného L2 rámce (frame), do něhož náš milý IP packet zapouzdří. Nakonec tento rámec oním příslušným rozhraním, které si našel o pár řádek tohoto textu výše, už konečně odešle (no dobře, uloží jej do bufferu toho rozhraní a tam nechá čekat až do okamžiku, kdy jeho odeslání bude reálně možné).

Změna, kterou tato funkcionalita, nazývaná také extended next-hop čili ENHE, přináší, pak spočívá v tom, že pokud router najde v příslušném FIB záznamu pro IPv4 prefix jako next-hop parametr nikoli IPv4, nýbrž IPv6 adresu, nebere si cílovou L2 MAC adresu z ARP tabulky, ale z tabulky IPv6 sousedů (IPv6 neighbor table). Takhle jednoduché to celé je, není v tom žádné další zapouzdřování packetů do jiných packetů, žádné tunely, nic takového.

Samozřejmě je nezbytné, aby to operační systém onoho síťového routeru podporoval, bez toho by to opravdu nefungovalo – a dobrá zpráva je, že většina výrobců velkých páteřních směrovačů tuto funkcionalitu podporuje. V Quantcomu jsme to otestovali jak na routerech s operačním systémem IOS XR od společnosti Cisco Systems, tak na JunOS od Juniper Networks, nicméně autorovi je známa i podpora této funkcionality u směrovačů od společností Nokia a Arista. Samozřejmě u softwarových řešení je situace jednodušší, Linux to umí, OpenBSD také, stejně tak nad nimi běžící směrovací software BIRD a OpenBGP, celkem podrobný přehled podpory této funkcionality je k nalezení například zde. Cílem našich testů nebylo jen ověřit základní funkčnost, ale i stabilitu implementací této funkcionality, a na významnější problém jsme nenarazili.

K čemu je to celé dobré? Předně, současné sítě využívají velké množství IPv4 adres pro adresování své infrastruktury. Na point-point propojích se používají prefixy /30, v lepším případě /31, což představuje 2 nebo 4 IPv4 adresy na každý páteřní a v řadě případů i zákaznický spoj. Snižuje se počet nezbytných BGP relací na polovinu, což přináší úsporu výkonu a přenesených dat. Využívají-li BGP relace mechanismu BFD pro rychlou detekci problémů na trase, postačuje opět poloviční množství navázaných BFD spojení a ty generují poloviční množství provozu. Pokud nepoužíváme transportní IPv4 subnety, není možné na IPv4 adresy (ne)přidělené takovým propojovacím rozhraním útočit, chráníme tedy méně zdrojů, což znamená jednodušší a transparentnější filtrovací pravidla (a menší prostor pro chyby v nich), velikost bráněného perimetru se zmenšuje.

Internetové peeringové uzly (IXP) používají pro své sdílené peeringové LAN segmenty poměrně velké adresní rozsahy, například v NIX.CZ je to rozsah /22, čili 1024 IPv4 adres, německý DE-CIX a nizozemský AMS-IX pak rozsah /21, tedy 2048 IPv4 adres. To vše za situace, kdy každá jedna IPv4 adresa dosáhla tržní hodnoty asi 50 amerických dolarů neboli přibližně 1120 Kč. Pro velké zaběhnuté IXP jsou to samozřejmě zanedbatelné sumy, ale u malých začínajících IXP to může být výrazná překážka.

Pro IXP potom má implementace RFC 8950 ještě další výhody, může spravovat už jen jeden seznam přidělených adres namísto současných dvou, zjednoduší se mu také konfigurace route-serverů a zejména se zcela zbaví broadcastového ARP provozu na sdíleném segmentu. Sdílené segmenty peeringových uzlů pracují dnes typicky v režimu dual-stack, tedy každý připojený směrovač vytváří jak ARP, tak i IPv6 ND provoz. Při vyšších stovkách zapojených zařízení už představuje stovky kilobitů provozu vysílaného do všech směrů (u ARPu broadcast, u IPv6 ND multicast), který končí až na control plane (tedy v CPU) všech připojených směrovačů, a o tom, že to může způsobovat provozní problémy, vědí třeba v AMS-IX svoje. Zmíněná funkcionalita tedy snižuje množství BUM provozu víceméně na polovinu. V českém prostředí se zatím budou moci provozovatelé sítí s touto technologií setkat a začít ji používat v rámci projektu FENIX.

IPv4 nás to samozřejmě zcela nezbaví. Ale můžeme ho mít zase o něco méně. A pak je tu samozřejmě ještě jeden aspekt – je to určitě krok k „out of the band“ inter-AS routingu, minimálně z pohledu IPv4-only sítí. Dost možná by dávalo smysl tímto směrem pokročit ještě dál, ale o tom snad někdy jindy.