zdroj: Lupa.cz

Každý, kdo se setká s tím, že chce mít své vlastní IP adresy, lhostejno zda čtyřkové nebo šestkové, se dříve či později setká s jedním zásadním omezením. Adresy se do DFZ, tedy lidově „veřejného Internetu“, oznamují po blocích. Pokud byste chtěli oznamovat jen jednu nebo malé množství IP adres, nikdo vám je nebude akceptovat a dokonce i váš tranzitní operátor vám decentně sdělí, že něco takového není úplně dobrý nápad.

Důvod je jednoduchý. Páteřní routery v Internetu neprovádějí svoji nejzásadnější funkci – přehazování IP packetů z jednoho rozhraní na jiné – v obyčejných procesorech (CPU), jaké znáte ze stolních počítačů a serverů, ale ve specializovaném hardware. Jak už jsem kdysi zmiňoval, v reálném světě je vždycky něco za něco, specializované vidle na přehazování packetů sice umějí těch packetů přehazovat opravdu mraky a s předem známým zpožděním, ale množství cílů, které dokáží obsloužit, není neomezené. Kdysi se naráželo na limit 256 000 cest, později se to zvedlo na milion, dnešní limit je 2–4 miliony známých prefixů. Nicméně IPv4 adres je celkem něco přes čtyři miliardy, o celkovém množství IPv6 adres raději nemluvě. Kdyby se měla v páteřních směrovačích vyskytovat každá jedna z nich, bylo by to současnými technologiemi nevyrobitelné, nezaplatitelné a dalších ne by tam bylo ještě daleko více.

Proto je všeobecně jakýmsi zvykovým právem uznáván reálný spodní limit pro velikost bloku IPv4 adres ve veřejném Internetu rozsah /24 neboli 255.255.255.0, čili 256 adres – neboli dnes už značně nesprávně jedno Céčko; u IPv6 pak vznikl konsensus na rozsahu /48, byť to žádné RFC explicitně nenařizuje (nicméně například RFC7454 zmiňuje jako objektivní fakt). Čas od času se objeví návrhy na akceptování prefixů menších, avšak odezvy ze strany provozovatelů sítí se takové iniciativy zatím nedočkaly a změna na obzoru rozhodně není. Cílem tohoto článku není vyvolat polemiku o tom, jestli je to tak dobře nebo špatně, je to obecně přijímáno jako fakt úplně stejně, jako že se střídá den a noc.

Avšak výjimky z tohoto pravidla existují. Prvním z nich je technika boje s DDoS útoky zvaná RTBH, route triggered blackholing. Je to nástroj primitivní a dnes už poněkud zastaralý, který oběti útoku zase tak moc nepomáhá, zatímco útočníkovi ještě pomůže dosáhnout svého záměru, ale bohužel jako varianta poslední linie obrany, přes existenci nástrojů výrazně účinnějších a sofistikovanějších, stále poptávaný. Funguje to tak, že svému poskytovateli IP tranzitu nebo peeringovému partnerovi (pokud s ním máte takovou dohodu) oznámíte specifickou cestu konkrétního cíle útoku (klidně i /32 u IPv4 nebo /128 u IPv6) se specifickou BGP komunitou, dokonce existuje i RFC7999, doporučující použití formátu „[ASN]:666“. Filtr u operátora potom obvykle vypadá tak, že nejprve kontroluje BGP komunity, pokud najde komunitu pro RTBH a prefix splňuje další předpoklady pro akceptaci, už není aplikován filtr hlídající nejmenší velikost akceptovaného prefixu.

Poměrně dlouhou dobu se o žádné jiné výjimce pro nejmenší velikost IP bloku příliš neuvažovalo. Ne že by se čas od času akceptace menších prefixů mezi různými autonomními systémy pod stejnou správou neobjevovaly, když kupříkladu dříve Dial Telecom, dnešní Quantcom, integroval do vlastní infrastruktury některé menší operátory při akvizicích, byla to celkem účelná dočasná pomůcka, nicméně veřejně a mezi různými autonomními systémy pod kontrolou různých firem se o takové možnosti dříve neuvažovalo. I to se ovšem pomalu mění.

Co to znamená? Ne, neznamená to, že vám operátor akceptuje vaši /28 nebo dokonce /32 a tuto vypropaguje do DFZ. To ani nemůže, žádná partnerská síť by to neakceptovala. Nicméně také to neznamená, že takový prefix musí nutně zahodit. Takzvané hyperspecifické prefixy přinášejí třetí možnost – operátor si takový prefix ponechá pouze ve své vlastní síti, tedy vypropaguje si jej jen vnitřně do všech svých páteřních zařízení. Neoznámí jej ani peeringovým partnerům, ani do IP tranzitu (má-li ho), dokonce ani svým zákazníkům zpravidla ne (byť u této možnosti se také mohou objevit odůvodnitelné výjimky). K čemu je to dobré, ptáte se? Inu, odpovědí je lepší řízení provozu. Představte si, že máte nějaké servery v datovém centru v Praze, nějaké v Brně a nějaké třeba ve Vídni, v každé lokalitě využíváte například IPv4 prefix o velikosti /27 a máte konektivitu od jednoho stejného dodavatele, který ve své síti podporuje hyperspecifické prefixy.

Máte jen jeden SVŮJ rozsah /24 a chcete zůstat nezávislí na cizích sítích. Pokud ze všech lokalit oznámíte ven tento rozsah /24 a nebudete mezi nimi mít žádné vnitřní propojení, tak se vám sice podařilo vytvořit hezký anycast, nicméně to ve většině reálných případů patrně nebude až tak docela vaším cílem. Oznámíte-li kromě této /24 ze všech lokalit i příslušné menší prefixy, ve zmíněném případě tedy pražskou /28 z Prahy, brněnskou /28 z Brna a vídeňskou /28 z Vídně, voilà, ono to funguje. Dokonce se to vidí, pokud si své ASN nefiltrujete na vstupu (k tomu je nutné například na zařízeních od Cisco Systems použít funkci allowas-in, u Juniper Networks pak „set routing-options autonomous-system XYZ loops“) i mezi sebou. Anebo pokud přijímáte namísto (nebo vedle) plných routovacích tabulek také default route, implicitní cestu (0.0.0.0/0 u IPv4 nebo 2000::/3 u IPv6). A stačí vám jen 1x /24, narozdíl od konvenční konfigurace, kde by bylo nutné ty /24 rozsahy mít tři. To je úspora asi 600 000 Kč.

Výše uvedený příklad je samozřejmě jen ten nejjednodušší možný. Další možnosti nasazení se nabízejí kupříkladu při migracích serverů, při optimalizování datových toků, lze je využít i při sofistikovanějších akcích pro boj s DDoS útoky, než je jen tupé RTBH apod. A budete-li chtít, najdete i další případy, kdy se vám hyperspecifické prefixy mohou hodně hodit.

Hyperspecifický prefix má tedy jedno specifikum – zůstává v síti vašeho upstream operátora. Máte-li takových operátorů více a od všech konektivitu ve všech svých datacentrech, bude to samozřejmě fungovat také. Jak zjistíte, že je váš operátor podporuje? Prostě se ho zeptejte...