Už ve svém předloňském článku jsem zmiňoval teoretickou možnost potenciálního využití IPv4 adres třídy E v Internetu a upozorňoval jsem i na problematické aspekty takového nápadu.

Protože však nikdy neodhalíte, kolik problémů s prosazením nějaké konkrétní myšlenky bude, dokud to sami nevyzkoušíte, rozhodli jsme se to udělat. Vybrali jsme si prefix přiměřené velikosti z tohoto rozsahu, z nějakého důvodu se mi zalíbil právě rozsah 242.242.0.0/16 a tento prefix jsme z jednoho ASN patřících Quantcomu začali oznamovat do DFZ, nebo, chcete-li to v běžné lidské řeči, do veřejného Internetu. Cílem bylo odhalit, kolik systémů v Internetu odmítne přijmout samotný prefix, kolik jich sice naimportuje prefix do RIB, ale tento se již neuplatní ve FIB (čili lidskou řečí kolik zařízení ten prefix sice bude mít v routovací tabulce, ale packet směrovaný na cíl v 242.242/16 přesto zahodí).

Třída E IPv4 adres je stále považována za experimentální, oficiální status je Reserved for future use. Původně byl zamýšlen pro, vedle unicastu a multicastu, jakýsi mytický třetí druh routingu, který teprve čeká na své vynalezení – a kterého se evidentně nikdy nedočkáme. Supernet 240/4 nemá žádného oficiálního vlastníka, žádný RIR je vám ani nikomu jinému nepřidělí, ale to zároveň znamená, že ony adresy nikomu nepatří. Nelze o ně tedy nikoho připravit. Situace je tak trochu podobná prvotnímu záboru nikým nevlastněné půdy. Na druhou stranu, nikdo negarantuje, že se takový prefix bude veřejným Internetem skutečně šířit a že packet dojde, kam má. Stejně tak si takový prefix může zabrat i kdokoli další a případným sporem se také žádný RIR zabývat nebude. Nikdo vám nenadeleguje reverzní zóny, na RPKI klíče je v této divočině také třeba zapomenout.

Nicméně žádné RFC ani žádný jiný globálně platný dokument zároveň explicitně nezakazuje takový prefix do Internetu oznámit a samotný Internet a protokoly v něm ostatně jako experiment také původně vznikly. Pro úplnost uvedu, že v rámci pracovních skupin IETF existuje nová verze draft-schoen-intarea-unicast-240, který se návrhem povolit tento rozsah zabývá.

Nedávno se v NANOG mailing listu ovšem objevil velmi odvážný návrh, jak levně přijít k většímu bloku IPv4 adres – a sice právě alokace produkčních adres z rozsahu třídy E, tj. z 240/4. Celá ta debata se pak zvrhla v celkem podařenou absurdní komedii, ale to je vedlejší. Podstatné je, že jsem si řekl, že by bylo přece jenom zajímavé tohle vyzkoušet a zjistit, kolik problémů s tím opravdu reálně ten, kdo to navrhl, bude mít.

Je evidentní, že ve většině případů zafunguje anti-BOGON/anti-martian ochrana a filtrování podle RIR listů. Ta zabrání úspěšně tomu, aby se prefix začal masově směrovat ven. Pokud síť využívá například filtrování poskytované Team Cymru nebo si generuje prefix listy z RIPE databáze, je zřejmé, že test nebude úspěšný. Dostat však prefixy z rozsahu 240/4 do RIPE DB nebo naopak pryč z Team Cymru BOGON listu však představuje jen administrativní opatření, nikoli technický problém, což znamená, že pokud by se komunita kolem IETF a RIR usnesla příděly pro jednotlivé RIR vytvořit, celá tato organizační bariéra by odpadla sama.

Tam náš experiment ovšem nemířil. Nás zajímalo, jaké další konkrétní reálné technické bariéry brání routování rozsahu 240/4 v DFZ. Zde už to celé závisí na autorech operačních systémů serverů, klientských stanic a síťových zařízení a rozhodně nelze říci, že tam bariéry nejsou.

Ostatně, těch bariér je hned několik druhů. Ta první, to jsou bariéry snadno odstranitelné administrátory konkrétních sítí. Sem patří kupříkladu explicitní potřeba vyjmutí konkrétního rozsahu 240.0.0.0/4 z vnitřního předpřipraveného seznamu martian prefixů autorem operačního systému předmětného směrovače. To jde udělat buď snadno, rychle a bezvýpadkově (například Juniper JunOS a jeho „set routing-options martians …“) nebo nesnadno a s nutným rebootem routeru (například Arista, zde však záleží na konkrétním modelu, někde to reálně možné není).

$ ping 242.242.1.1
PING 242.242.1.1 (242.242.1.1): 56 data bytes
64 bytes from 242.242.1.1: icmp_seq=0 ttl=62 time=1.567 ms
64 bytes from 242.242.1.1: icmp_seq=1 ttl=62 time=1.766 ms
64 bytes from 242.242.1.1: icmp_seq=2 ttl=62 time=1.748 ms
64 bytes from 242.242.1.1: icmp_seq=3 ttl=62 time=1.849 ms
64 bytes from 242.242.1.1: icmp_seq=4 ttl=62 time=1.692 ms
64 bytes from 242.242.1.1: icmp_seq=5 ttl=62 time=1.779 ms
^C
--- 242.242.1.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.567/1.734/1.849/0.088 ms$ traceroute 242.242.1.1
traceroute to 242.242.1.1 (242.242.1.1), 64 hops max, 52 byte packets
 1  router.lan (192.168.100.1)  1.122 ms  1.002 ms  1.486 ms
 2  82.113.37.191 (82.113.37.191)  1.954 ms  1.494 ms  1.482 ms
 3  cz-prg-p1sit-hunge-0-2-0-0.quantcom.cz (82.119.246.109)  1.739 ms  1.104 ms  1.926 ms
 4  cz-prg-bbr4-et-5-0-0.quantcom.cz (82.119.246.197)  1.872 ms  1.934 ms  1.891 ms
 5  242.242.1.1 (242.242.1.1)  1.849 ms  1.711 ms  1.868 ms

Jan 16 18:57:46.183 CET: %BGP-3-MARTIAN_IP: 100.71.50.10: Martian prefix 242.242.0.0/16 in withdraw

c:\>ping 242.242.1.1

Pinging 242.242.1.1 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.