EMZETT.Broadcast
Kurz: Eine Übertragung von einem Sender an alle Geräte in einem Netzwerksegment gleichzeitig, ohne einzelne Empfänger anzusprechen.
Genauer: ARP-Anfragen sind ein klassisches Broadcast-Beispiel: “Wer hat diese IP?” wird an alle im lokalen Netz geschickt, weil noch nicht bekannt ist, wer antworten wird. Broadcast-Traffic verursacht in großen Netzen spürbare Last, weshalb Netzwerke oft in kleinere Segmente unterteilt werden, um Broadcast-Domänen klein zu halten.
Im Detail
Adressierung: Subnetz-Broadcast vs. limitierter Broadcast
Technisch adressiert ein Broadcast im lokalen Netz eine spezielle Broadcast-Adresse — bei IPv4 gibt es dabei zwei Varianten. Der “gerichtete” (subnet-directed) Broadcast nutzt die höchste Adresse eines Subnetzes (z. B. 192.168.1.255 in einem /24-Netz) und lässt sich theoretisch sogar über Router-Grenzen hinweg an ein bestimmtes entferntes Subnetz adressieren. Der “limitierte” Broadcast nutzt dagegen die feste Adresse 255.255.255.255, die IMMER nur das lokale Segment erreicht und von Routern nie weitergeleitet wird. Auf MAC-Adressen-Ebene (Schicht 2) entspricht beiden die Adresse FF:FF:FF:FF:FF:FF. Jedes Gerät im Segment ist verpflichtet, an diese Adresse gerichtete Frames zu verarbeiten, im Gegensatz zu normalen Unicast-Frames, die nur das eigentliche Zielgerät überhaupt an die höheren Netzwerkschichten weiterreicht.
Typische Broadcast-Anwendungen
Neben ARP nutzen z. B. auch DHCP-Anfragen Broadcast: Ein neues Gerät ohne IP-Adresse kann noch niemanden gezielt ansprechen, deshalb schreit es per Broadcast “Ich brauche eine IP-Adresse!” ins Netz, und ein DHCP-Server antwortet. Auch Wake-on-LAN (das Aufwecken eines heruntergefahrenen Rechners übers Netzwerk) funktioniert klassisch per Broadcast: Das “Magic Packet” wird an die Broadcast-Adresse geschickt, damit es auch dann ankommt, wenn die genaue aktuelle IP-Adresse des Zielrechners nicht bekannt ist.
Broadcast Storms
Genau dieses Prinzip — jedes Gerät muss jede Broadcast-Nachricht verarbeiten, auch wenn sie es gar nicht betrifft — ist der Grund, warum Broadcast-Traffic in großen, flachen Netzen zum echten Problem werden kann (“Broadcast Storm”): Jedes zusätzliche Gerät erhöht die Grundlast für alle anderen, und bestimmte Fehlkonfigurationen (z. B. eine versehentliche Netzwerkschleife ohne funktionierendes Spanning Tree Protocol, siehe Bridge) können dazu führen, dass sich Broadcast-Frames selbst verstärkend im Kreis vervielfältigen, bis das gesamte Netzsegment binnen Sekunden praktisch handlungsunfähig wird. In der Praxis ist ein plötzlicher, unerklärlicher Totalausfall eines Netzwerksegments ohne erkennbare Ursache oft ein Indiz für genau dieses Phänomen.
Sicherheitsrisiko: Smurf-Angriff
Der gerichtete Broadcast war historisch auch Grundlage des “Smurf-Angriffs”: Ein Angreifer verschickt ICMP-Echo-Requests (siehe Ping) mit gefälschter Absenderadresse (der Adresse des eigentlichen Opfers) an die Broadcast-Adresse eines fremden Netzes — alle Geräte in diesem Netz antworten daraufhin gleichzeitig an das vermeintliche Opfer, das mit einer Flut an Antworten überschwemmt wird (Denial of Service durch Verstärkung). Aus genau diesem Grund blockieren moderne Router und Firewalls standardmäßig eingehende gerichtete Broadcasts von außen.
Eindämmung und IPv6-Ablösung
Moderne Netzwerke begrenzen Broadcast-Domänen deshalb aktiv durch VLANs und Routing-Grenzen — ein Router leitet Broadcast-Traffic grundsätzlich nicht zwischen unterschiedlichen Netzen weiter, wodurch jedes VLAN seine eigene, kleinere Broadcast-Domäne bildet und Probleme lokal begrenzt bleiben. IPv6 hat Broadcast als Konzept komplett abgeschafft und durch gezielteres Multicast ersetzt — eine bewusste Design-Entscheidung, um genau diese Skalierungs- und Sicherheitsprobleme großer Netze von vornherein zu vermeiden, da Multicast-Nachrichten nur die Geräte erreichen, die sich aktiv für die jeweilige Multicast-Gruppe interessiert haben.