Příběh prefixu 242.242.0.0/16 – 2. díl

Po zveřejnění, že propagujeme prefix 242.242/16, přišlo několik zajímavých tipů, co všechno by dávalo smysl vyzkoušet. Začali jsme s RIPE Atlasem a hledali sondy, které jsou schopny úspěšné komunikace právě s „naší“ adresou 242.242.1.1. Takových jsme pár nalezli, ale bylo jich do deseti kusů. Ani zdaleka všechny provozované sondy v našem vlastním ASN nebo u našich zákazníků se mezi ně nedostaly, byla jich přibližně polovina.

Pak jsme objevili sondy připojené k úplně jiným ASN, které se tam dokázaly dostat také. Mnoho jich sice nebylo, ale existovaly. Nejvzdálenější takovou RIPE Atlas sondu jsme našli v ruské Čitě, což je město pár set kilometrů za Bajkalem, poblíž hranice s Čínou, vzdušnou čarou asi 6500 km daleko, zhruba stejně jako z Prahy do New Yorku. Takový objev byl, jakkoli jsme si byli vědomi toho, že je to v zásadě jen důsledek tristního zabezpečení routingového ekosystému jako celku, celkem povzbuzující.

Dalším krokem tedy bylo zkusit opingat přímo z IP adresy 242.242.1.1 celý IPv4 adresní prostor, čili více než 4.2 miliardy adres (0.0.0.0/0). To jsme udělali a od 184496 IP adres jsme dokonce dostali odpověď. To je asi 0.005 %. Zajímavé bylo rozložení těch odpovědí, byly tam sítě z celé řady různých zemí, už bylo zmíněno Rusko, pak také USA, Vietnam, Spojené Arabské Emiráty, Rumunsko a dlouhá řada dalších, ČR a Slovensko samozřejmě nevyjímaje. Za zmínku stojí také dostupnost veřejného DNS resolveru Quad9 (9.9.9.9), který nám začátkem dubna celkem ochotně odpovídal:

$ dig -b 242.242.1.1 @9.9.9.9 isc.org AAAA

; <<>> DiG 9.16.27-Debian <<>> -b 242.242.1.1 @9.9.9.9 isc.org AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22090
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;isc.org.            IN    AAAA

;; ANSWER SECTION:
isc.org.        300    IN    AAAA    2001:500:6b:2::28

;; Query time: 172 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Apr 03 15:00:21 CEST 2024
;; MSG SIZE  rcvd: 64

Nicméně jedna vlaštovka jaro nedělá a 0.005 % není mnoho. Jistě, mnoho zařízení filtruje icmp echo, ale i kdyby tedy skutečné množství systémů v Internetu, které s 242.242.1.1 mohou úspěšně komunikovat, bylo čtyřnásobné, pořád jsou to jen 0.02 %.Pokud by někoho zajímalo, kolik času zabere opingání celého adresního prostoru IPv4, tak s gigabitovou linkou vyhrazenou jen pro tento účel se to dá zvládnout asi za 18 hodin.

Následoval ještě pokus navázat z adresy 242.242.1.1 spojení na port tcp/80, zde už byly výsledky horší, protokolem HTTP odpovědělo jen necelých 25000 unikátních IPv4 adres.Jak vidno, pro možnost použití rozsahu 240/4 jako jakýchkoli jiných veřejných IPv4 adres ve veřejném Internetu by tedy bylo nutné udělat ještě mnohé.

Druhá varianta, tedy masivní nasazení IPv6, má oproti 240/4 jednu zásadní výhodu. Podporují ji už jak RIR, tak všichni výrobci síťového hardware a v neposlední řadě i všichni producenti operačních systémů a drtivé většiny aplikací, Microsoft nějakým zázrakem nevyjímaje. Samozřejmě tato omezení nikterak nelimitují použití adres třídy E v privátních sítích obdobně, jako adresní rozsahy specifikované v RFC 1918 (tedy 10/8, 172.16/12 a 192.168/16), případně v RFC 6598 (100.64/10), pokud jde o komunikaci čistě mezi systémy, které tyto adresy podporují. 

Existují ještě další nevyužívané rozsahy

Prefix 240/4 ovšem není tím jediným, kam se dá ještě sáhnout. První na řadě je rozsah 0/8 (za předpokladu vynechání adresy 0.0.0.0/32), na který existuje poměrně čerstvý draft (čili je docela dobře možné, že vedle experimentu s 242.242.0.0/16 otestujeme někdy v budoucnu ještě propagaci kupříkladu prefixu 0.2.4.0/22).

Další na řadě je 127/8 (s vynecháním 127.0.0.0/16) a dá se očekávat, že se zanedlouho objeví (celkem oprávněná) myšlenka, zda náhodou alokace 224/4 pro multicast není zbytečně moc velká a zda by z ní také nešly vyškrábat nějaké další unicastové veřejné adresní rozsahy. Vlastně nikoli, očekávat to netřeba. Už se objevila. Paradoxně právě myšlenka s převedením části multicastových rozsahů do globálně směrovatelného unicastu je po technické stránce realizovatelná nejsnáze.

Ovšem samotný fakt, že něco je technicky možné, ještě neznamená, že bude dávat rozumný smysl to udělat, což je zhruba poselství bodu 2.3 v RFC1925, zmiňujícího se o tom, že s dostatečným tahem mohou i prasata docela dobře létat, ale že to má jistá úskalí. Příkladem něčeho takového z reálného světa budiž třeba elektrická parní lokomotiva.

Ilustrační fotografie, zdroj: Wikimedia Commons

Takže proč to vlastně nedělat?

Jednoduchá odpověď zní: protože už teď existuje dost adres, na které se mnoho uživatelů zatím nemůže dostat. Říkáme jim IPv6. K 3.4× 10³⁸ pro ně nedostupných IPv6 adres tedy přibydou ještě další, přičemž zásahy do existujících implementací TCP/IP stacků různých operačních systémů by si vyžádaly, kromě změny v alokaci pro multicast čili 224/4, téměř všechny. S rozsahy 0/8 nebo 127/8 si totiž neporadí ani drtivá většina těch systémů a zařízení, které 240/4 celkem bravurně zvládají – a to vše jen proto, abychom získali jenom přibližně 300 milionů adres (tedy 3× 10⁸, na první pohled hodně, ale srovnáte-li to s výše uvedeným číslem 3.4× 10³⁸, tak to druhé je o 30 nul delší), čili přibližně 1.2 milionu IPv4 rozsahů /24.

V tomto kontextu patrně ještě stojí za zmínku, že už i patrně největší uživatel IPv4 adres z rozsahu 240/4 ve své vnitřní infrastruktuře, Amazon AWS, už nyní také raději masivně nasazuje IPv6. Shrneme-li si to, za cenu rozsahem podobného úsilí (a dokonce s většími bariérami, absence podpory ve Windows je naprosto zásadním handicapem), jako si vyžaduje globální implementace IPv6, můžeme získat přibližně kvintilionkrát méně adres. A nelze odhlédnout od faktu, že u IPv6 už velká část práce byla odvedena.