Na jednu ethernetovou adresu padne 32 multicastových. IETF sepsal, proč to vadí
Když si dvě zařízení na lodi nebo v hale vyberou multicastovou skupinu, můžou skončit na téže ethernetové adrese – připadá jich na ni dvaatřicet. Síťová karta je pak nerozliší a hardwarový filtr přestane fungovat. IETF v červenci vydal popis problému, ne jeho řešení.
Skupina autorů z firem Garmin, lispers.net a Futurewei vydala v červenci 2026 dokument RFC 10019. Nezavádí žádný protokol a ani se o to nesnaží: je to soupis toho, proč automatické přidělování multicastových adres v malých sítích nefunguje, a seznam požadavků na řešení, které teprve má vzniknout. Kategorie dokumentu je informativní, nikoli standardizační.
Dvaatřicet adres na jedno místo
Jádro potíže je stará vlastnost ethernetu. Když se má IPv4 multicastová adresa přeložit na ethernetovou, použije se z ní jen spodních 23 bitů – popisuje to oddíl 6.4 dokumentu RFC 1112 z roku 1989. Adresa má přitom 32 bitů a první čtyři jsou pevná předpona, takže na výběr zbývá 28 bitů. Rozdíl mezi 28 a 23 znamená, že na jednu ethernetovou adresu připadá až 32 různých multicastových adres IP.
Následky RFC 10019 dělí na tři. První se týká síťové karty: když se aplikace přihlásí k odběru skupiny, karta se nastaví tak, aby propouštěla jen její provoz. Sdílejí-li dvě skupiny tutéž ethernetovou adresu, karta je od sebe nepozná a nechtěný provoz musí odfiltrovat až operační systém – tedy softwarem, s odpovídající zátěží procesoru.
Druhý následek se týká přepínačů, které sledují přihlášky k odběru (IGMP a MLD snooping podle RFC 4541). Když dvě skupiny padnou na tutéž ethernetovou adresu, přepínač pošle data i tam, kde o ně nikdo nestál. Dokument upozorňuje, že to bolí zvlášť tam, kde na pomalé lince visí zařízení, které dostane proud dat určený někomu jinému.
Třetí je vnitřní stavba některých přepínačů. Uvádějí si adresy v tabulce s pevně velkými přihrádkami; když se do jedné přihrádky trefí víc adres, než se vejde, další záznamy se zahodí. Přeposílání pak přestane fungovat úplně. RFC se u toho odvolává na konkrétní patent, nikoli na obecnou úvahu.
Proč to sepsali lidé od lodí
První autor je z Garminu a v poděkování stojí americká asociace pro lodní elektroniku. Není to náhoda: lodní síť je učebnicový případ prostředí, které dokument popisuje. Na jedné podsíti visí čidla teploty nebo hladiny za pár stovek vedle radaru, sonaru a kamer, propojuje je obyčejný ethernetový přepínač a nikdo tam nekonfiguruje adresy ručně.
Levné přepínače navíc neumějí adresovat zdrojově (SSM), protože jejich tabulka zná jen cílové ethernetové adresy. Každý datový proud proto dostane vlastní multicastovou adresu IP a o doručování rozhoduje právě sledování přihlášek. Tím se ale celá stavba opře o to, co je popsané výš – a kolize adres jí podrazí nohy.
Dokument sám dodává, že lodě jsou jen názorný příklad. Táž omezení platí pro průmyslovou automatizaci, menší audiovizuální rozvody a nahodile poskládané sítě čidel.
Co už existuje a proč to nestačí
Protokol na dynamické přidělování multicastových adres vznikl už dávno – RFC 2730 z roku 1999 popisuje MADCAP. Staví ale na serveru, který adresy rozdává, a to je přesně to, co v prostředí bez konfigurace není k mání. Dokumenty RFC 3306 a RFC 4489 řeší přidělování adres IPv6 přímo na koncových zařízeních, kolizím na ethernetové vrstvě však nepředcházejí.
U IPv6 je situace o něco lepší, protože rámec z RFC 3307 s kolizemi počítá. I tam ale autoři vidí mezeru: oba popsané způsoby dynamického přidělování – serverem i samotným zařízením – sahají do téhož rozsahu, takže se navzájem nevylučují.
Nabízelo se řešení, které by problém u IPv4 odstranilo úplně: vyhradit 32 rozsahů tak, aby se jejich ethernetové obrazy nepřekrývaly. Autoři ho zamítli s odůvodněním, že RFC 5771 nové přidělování multicastového prostoru IPv4 nedoporučuje – je ho málo. Doporučení pro nové návrhy proto zní jinak a je stručné: použít IPv6.
Co má řešení umět
Požadavky, které dokument vypisuje, pokrývají čtyři oblasti: jak zařízení najdou, že tu nějaké přidělování běží, jak si adresu vezmou, jak poznají a vyřeší střet s jiným zařízením a jak se adresa po čase vrátí zpátky. Řešení má být decentralizované a nenáročné, protože poběží i na čidlech, která nemají výkon nazbyt.
Co v dokumentu není, je samotný protokol. RFC 10019 popisuje zadání, ne hotovou věc – a mezi tím, že si obor sepíše požadavky, a tím, že se objeví implementace v přepínačích a čidlech, bývá u síťových norem několik let.
Zdroje
- RFC 10019: Zeroconf Multicast Address Allocation Problem Statement and Requirements, IETF, červenec 2026
- RFC 1112: Host Extensions for IP Multicasting, oddíl 6.4, IETF, srpen 1989
- RFC 5771: IANA Guidelines for IPv4 Multicast Address Assignments, IETF, březen 2010
