Adressierung in TCP/IP-Netzen

Neben der MAC-Adresse bedarf es in komplexen Netzwerken einer erweiterten Form der Identifikation, um Netzwerkpakete verwaltungstechnisch effizient adressieren zu können. Unter Verwendung des TCP/IP-Protokolls bedient man sich einer IP-Adresse und eines Ports, um eine eindeutige Adresse zu bilden. Damit eine praktikable Zuordnung von IP-Adressen zu einem bestimmten Subnetz möglich wird, unterteilt die Subnetzmaske jede IP-Adresse in zwei Bereiche (Netzwerk-ID und Rechner-ID), was die Konfiguration von Netzwerkkomponenten stark vereinfacht. Schlussendlich fungiert das default Gateway als Router und somit als Verbindungsglied zwischen mehreren Subnetzen, während ein DNS-Dienst für die Umsetzung von Domain Namen zuständig ist. Der Artikel versucht, die Zusammenhänge zu verdeutlichen.

Leicht erklärt

MAC-Adresse

Jede Netzwerkkarte (kurz NIC genannt) hat eine eindeutige abrufbare Seriennummer, welche man MAC-Adresse, LAN-ID, NIC-Nummer, physikalische Adresse, Airport-ID oder Ethernet-ID nennt. Sie setzt sich zusammen aus einer Hersteller-ID und einer angrenzenden laufenden Nummer. Dadurch lässt sich jede Netzwerkkarte weltweit eindeutig identifizieren.

fBZpdb THX that's a great answer!

MAC-Filter

Mithilfe eines MAC-Filters ist es möglich, ausschließlich ausgewählten Netzwerkkarten den Fernzugriff auf ein System zu erlauben. Allerdings weisen Ethickerds darauf hin, dass ein aktivierter MAC-Filter noch lange kein Garant für ein geschlossenes Netz ist. So ist es leicht möglich, die MAC-Adresse seiner eigenen Netzwerkkarte zu ändern. Das Verfahren nennt sich MAC-Spoofing.

Dennoch ist ein Filter für MAC-Adressen eines Accesspoints durchaus sinnvoll, da er eine zusätzliche Barriere für Skriptkiddies darstellt.

Warum bedarf es neben der MAC-Adresse einer anderen Adressierung?

Für größere Netze benötigt man eine Möglichkeit, bereits anhand von bestimmten Eigenschaften der Adressen ermitteln zu können, zu welchem Teilnetz ein Paket gehört. Die Rede ist von so genannten Subnetzen. Die MAC-Adresse ist aufgrund ihres Aufbaus aber nicht für eine Unterteilung in Subnetze geeignet.

Zudem gesellt sich ein weiteres Manko der MAC-Adresse: Man könnte zwar einen Rechner Adressieren, aber in der Adresse nicht angeben, für welches Programm des Rechners das Paket bestimmt ist.

Die Lösung bieten höhere Kommunikationsprotokolle, die über die MAC-Adresse gelegt werden. Ein Netzwerkpaket wird also bildlich gesehen mehrfach verpackt. Auf der äußeren Verpackung befindet sich die gewohnte MAC-Adresse, die das Ethernet benutzt, um das Paket an den Adressaten oder eine für den Adressaten zuständige Netzwerkkomponente zu übergeben. Dort wird das Paket ausgepackt, wodurch die darunter liegende Verpackung mit den erweiterten Adressdaten der höheren Protokolle zum Vorschein kommen und ausgewertet werden.

Die Verwendung der MAC-Adresse lässt sich mit dem internen Adressierungsschema einer Poststelle vergleichen, die jedes ihrer Objekte anhand einer Identifikationsnummer verwaltet. Das hat den Vorteil, dass sich der Postbote (Ethernet) lediglich mit diesem einfachen Adressierungsschema auskennen muss. Die höheren Protokolle interessieren ihn nicht. Es ist für ihn beispielsweise irrelevant, für welches Programm des Computers das Paket bestimmt ist. Er muss das Paket schließlich nur dem Computer übergeben. Es liegt nun bei dem Computer, das Paket auszupacken und die dadurch sichtbaren Zusatzinformationen der höheren Protokolle entsprechend auszuwerten.

Die Mac-Adresse dient dem Ethernet also als niederschichtigste Adressierung eines Teilnehmers in einem Netzwerk. So kann man ein und dasselbe Ethernet für die zeitgleiche Übertragung von Paketen nutzen, die auf unterschiedliche höhere Adressierungsprotokolle zurückgreifen (wie z.B. TCP/IP, IPX/SPX, etc.). Neben dem Empfänger muss allerdings auch die Poststelle (Router) das verwendete höhere Protokoll kennen. Erreicht ein Paket auf seinem Weg über mehrere Subnetze den Router, so analysiert er die höheren Adressierungsprotokolle, um dem Paket die MAC-Adresse des Objektes mitgeben zu können, an das der Postbote das Paket übergeben soll.

Die MAC-Adresse des ursprünglichen Absenders wird nicht über ein Subnetz hinweg übertragen. Niemand aus dem Internet kann somit die wahre MAC-Adresse des Kommunikationspartners sehen, da ihm während der Verbindung lediglich die MAC-Adresse des letzten Routers übermittelt wird, über den das Paket geleitet wurde (über ihn muss das Paket schließlich wieder zurückgeschickt werden).

IP-Adresse

Um Netzwerkkarten in komplexen Netzwerken verwalten zu können, wird unter Verwendung des IP-Protokolls eine so genannte IP-Adresse über jede Netzwerkkarte gelegt. Sie ist vergleichbar mit einer Hausadresse, die eine Straßennummer und eine Hausnummer enthält. Nur über die Adresse weiß die Post, zu welchem Haus (zu welcher Netzwerkkarte) die Pakete geliefert werden sollen.

Beispiel einer 32-Bit IP-Adresse:  192.168.1.23 

Welcher Teil der IP-Adresse sinnbildlich die Straßennummer repräsentiert (Netzwerk-ID), und welcher Teil die Hausnummer darstellt (Rechner-ID), wird durch die Subnetzmaske definiert.

Jeder Ziffernblock einer IP-Adresse (Block1 . Block2 . Block3 . Block4) kann theoretisch einen Wert von 0 bis 255 annehmen. Einer IP-Adresse sollte man aber nur Werte zwischen 1 bis 254 zuweisen, da die Werte 0 und 255 eine besondere Bedeutung haben. Auch sollte man in seinem eigenen Netzwerk einen IP-Adressbereich verwenden, der für private (also nicht öffentliche) Netzwerke vorgesehen ist. Das gilt zumindest dann, wenn man das eigene Netzwerk irgendwann einmal mit dem Internet verbinden möchte (z.B. per DSL-Router).

Port

Der Port, auch Anschlussnummer genannt, gehört in einem TCP/IP-Netz zum TCP- und UDP-Protokoll, welches über das IP-Protokoll gelegt wird. Er funktioniert sinnbildlich gesehen wie ein Namensschild an einem Hauseingang. Der Hauseingang (die Netzwerkkarte) hat eine Adresse (die IP-Adresse). Über die zusätzlich angegebene Port-Nummer weiß das Betriebssystem, für welches Programm „im Haus“ das Netzwerkpaket bestimmt ist.

Beispieladresse mit Portangabe (hier http-Port 80):   192.168.1.23:80

Hinweise:

• Diese Konstellation (Angabe der IP Adresse und des Ports, getrennt durch einen Doppelpunkt) nennt man Socket.

• Unter den technischen Details wird auf ein weit verbreitetes Missverständnis bezüglich der Rückgabeports hingewiesen.

Subnetzmaske

Damit Netzwerkkomponenten, die mehrere Subnetze miteinander verbinden, ihre Arbeit verrichten können, müssen sie wissen, welche Netzwerkpakete zu welchem Netz gehören. Um dies zu realisieren, hat man nach einem Weg gesucht, wie man die Netzwerkzugehörigkeit anhand der IP-Adresse erkennen kann. So wurde festgelegt, dass die ersten Ziffern der IP-Adresse den Namen des Netzwerkes bilden, während der zweite Teil der Zahl die eindeutige ID eines Rechners (genauer einer Netzwerkkarte) in diesem Netzwerk umfasst.

Die Subnetzmaske, auch Netzmaske genannt, legt fest, welcher Bereich der IP-Adresse zum Netzwerkbereich gehört. Der Rest der IP-Adresse bildet den Rechnerbereich, welchen man auch Hostbereich nennt.

Somit ist sichergestellt, dass keine IP-Adresse aus dem einen Subnetz einen Adresskonflikt mit einer IP-Adresse eines anderen Subnetzes auslöst. Zudem müssen die Netzwerkkomponenten nun lediglich die Netzwerknamen aus der IP-Adresse ermitteln, um die Netzwerkpakete dem jeweiligen Subnetz zuordnen zu können. Auf diese Weise lassen sich Regeln für Netzwerkkomponenten ganz einfach formulieren.

Ein Beispiel

Eine typische IP-Adresse wäre beispielsweise:  192.168.1.23:80

Eine Subnetzmaske von „255.255.255.0“ bestimmt nun, dass die ersten drei Byte (also die ersten drei Ziffernblöcke) komplett den Netzwerkbereich bilden. Bildlich gesehen handelt es sich hierbei also um die 192.168.1'te Straße (Netzwerk-ID), Hausnummer 23 (Rechner-ID), Raum 80 (Portnummer). Hätte man in dem Netz eine Subnetzmaske von "255.255.0.0" festgelegt, so würde die Straßennummer 192.168 lauten und die Hausnummer wäre nun 1.23

Je größer die Subnetzmaske ist, umso weniger Rechner lassen sich pro Subnetz erfassen (bei 255.255.255.0 sind es „nur“ 254 Rechner pro Subnetz, was in der Regel aber ausreichen sollte; bei 255.255.0.0 sind es immerhin schon 64.516 mögliche Rechner pro Subnetz). Und je kleiner die Subnetzmaske ist, desto weniger Subnetze lassen sich definieren.

Das „default Gateway“ der TCP/IP-Konfiguration

Bei der TCP/IP-Konfiguration einer Netzwerkkarte wird auch ein so genanntes „default Gateway“ angegeben. Laut Definition nimmt ein Gateway die Konvertierung eines Protokolls in ein anderes vor (beispielsweise IPX nach IP). Auch eine Dienstbasierte Umsetzung ist hier möglich (z.B. eMail zu SMS oder eMail zu Fax, etc.). Das „default Gateway“ allerdings leitet lediglich alle nicht zu einem Subnetz gehörenden Netzwerkanfragen in ein anderes Subnetz weiter. Damit übernimmt es schlicht die Funktionen eines Routers. Router sind jedoch keine Gateways.

Warum also widerspricht das „default Gateway“ der Gatewaydefinition? Als die allgemeine Verbreitung von TCP/IP noch in den Kinderschuhen steckte, war man nicht selten gezwungen, Netzwerke unterschiedlichen Typs miteinander zu verbinden und damit zwangsläufig deren Protokolle zu konvertieren. Denn TCP/IP wurde mit Protokollen wie DECnet, SNA und Novells IPX/SPX konfrontiert. Der Begriff „default Gateway“ sollte dem Administrator verdeutlichen, dass er hier ein Gateway eintragen kann. Allerdings „kann“ heißt nicht „muss“, denn was dort tatsächlich eingesetzt wird, hängt von der jeweiligen Netzwerkarchitektur ab.

Mit der Vorherrschaft des TCP/IP-Protokolls zog der Router immer öfter an die Stelle des Gateways. Mittlerweile gibt es in diesem Segment kaum noch Gateways, da die Netze fast ausschließlich über das TCP/IP-Protokoll kommunizieren. Eine Protokollumsetzung ist also nicht mehr erforderlich, weshalb die Bezeichnung „default Router“ heutzutage treffender wäre.

DNS

Wie oben bereits erwähnt, wird in einem TCP/IP-Netz jede Netzwerkkarte über eine eindeutige IP-Adresse adressiert. IP-Adressen sind jedoch nicht zwangsläufig beständig, da sich spätestens bei einem Umzug in ein anderes Subnetz die eigene IP-Adresse oder die des Kommunikationspartners ändert. Wird die IP-Adressen dynamisch vergeben, wechselt sie gar bei jedem Neustart der Geräte. Wie aber lässt sich unter diesen Umständen die Adresse des Kommunikationspartners ausfindig machen?

Ein weiteres Problem einer solchen Adressierung liegt darin, dass sich Menschen die Zahlen der IP-Adressen nur schlecht einprägen können.

Als Lösung für beide Probleme hat man sich darauf geeinigt, den Rechnern zusätzlich einen sprechenden Namen (Domain Namen) zu geben. Er wird symbolisch über die IP-Adresse gelegt („PC_von_Hinz“=192.168.1.1 / „PC_von_Kunz“= 192.168.1.2 / etc.). Eine entsprechende Liste kann automatisch aktualisiert werden, sobald sich die zum jeweiligen Domain Namen gehörende IP-Adresse ändert.

Der DNS (Domain Name Service, auch Domain Name System genannt) ist für die Umsetzung der Domain Namen in die IP-Adresse zuständig. Das DNS-Verfahren wird durch eine verteilte Datenbank realisiert.

Die Arbeit des DNS-Dienstes ist vergleichbar mit einem Telefonbuch, in dem zu jedem Rechnernamen die IP-Adresse steht. Auf diese Weise kann vor jeder Netzwerkanfrage an einen Domain Namen automatisch die dazu gehörende IP-Adresse ermittelt werden. Denn erst mit der IP-Adresse des Rechners lässt sich der Rechner protokollspezifisch richtig adressieren.

ping „PC_von_Hinz“ -> ping stellt eine Anfrage an den DNS-Dienst -> ping 192.168.1.1 ausführen

Diese Umsetzung geschieht für den Anwender transparent, sodass er in der Regel davon nichts bemerkt. Für ihn sieht es so aus, als hätten die Rechner tatsächlich sprechende Namen.

Technische Details

Die technischen Daten der eigenen Netzwerkkarte abfragen

Windows NT4 / 2000 / 2003 / XP

Unter diesen Betriebssystemen kann man eine DOS-Konsole öffnen und dort ipconfig /all eingeben, um die MAC- und IP-Adresse, die Subnetzmaske, das default Gateway und den DNS-Server der eigenen Netzwerkkarte abzurufen.

Windows 95 / 98 / ME

Hier muss in der DOS-Konsole winipcfg eingegeben werden, um die Einstellungen zu erfragen.

Anfrage- und Rückgabe-Port

Ein Internetdienst, welcher z.B. Webseiten bereitstellt, wird durch ein Programm realisiert, welches auf dem jeweiligen Internetserver läuft. Bei dem Programm handelt es sich um einen Netzwerkdienst (auch Service oder Daemon genannt) der an einem bestimmten Port lauscht. So bindet sich z.B. ein http-Dienst an den Port 80, über den er Anfragen eines beliebigen Clients entgegennimmt.

Wenn es um Portregeln geht, gibt es ein weit verbreitetes Missverständnis: Auf das Beispiel bezogen, läuft auf dem Client ein beliebiger Internetbrowser, der seine Anfrage an den Server:Port80 stellt. Entgegen dem, was oftmals vermutet wird, bindet sich der Internetbrowser jedoch nicht ebenfalls an den Port 80 des PCs, um die Antwortpakete entgegenzunehmen. Sobald mehrere Internetbrowser auf dem PC gestartet werden, würde das auch nicht mehr funktionieren, da sich so mehrere Prozesse ein und denselben Rückgabeport teilen müssten. Welchem Prozess aber sollte das Betriebssystem die dort eingehenden Netzwerkpakete übergeben? Eine eindeutige Zuordnung wäre so nicht möglich.

Deshalb bindet sich jeder gestartete Browserprozess an einen anderen dynamisch erzeugten Rückgabeport, welcher in einem Bereich zwischen 1024 und 65535 liegt. So startet der Browser seine Anfrage an den Server:Port80 und teilt ihm gleichzeitig mit, dass die Antwort zurück an die IP-Adresse des PCs auf Port xyz zu schicken ist (xyz=Rückgabeport des jeweiligen Browserprozesses). Genau genommen erhält sogar jede autonome Netzwerkanfrage (also auch Anfragen aus weiteren Fenstern des Browsers) seinen eigenen Rückgabeport, selbst wenn sie zu ein und demselben Prozess gehören. Auf diese Weise bleibt die Zuordnung der Antwortpakete jederzeit eindeutig.

Bezogen auf eine Firewall bedeutet dies, dass man die Übermittlung der Antwortpakete nicht unterbinden kann, indem man eingehende Pakete auf Port 80 blockiert. Werden hingegen ausgehende Pakete unterbunden, die sich an den Port 80 richten, wodurch keine http-Anfrage mehr möglich ist und so ein Zugriff der internen Rechner auf Webseiten unterbunden wird.

Sessionports

Oftmals nutzen Netzwerkdienste ihren Standardport lediglich für die Eröffnung einer neuen Sitzung. Der Client stellt also seine erste Anfrage an den Standardport des Dienstes. Im Antwortpaket teilt der kontaktierte Netzwerkdienst dem Client dann mit, auf welchem Port die weiteren Anfragen zu stellen sind. Jede Sitzung erhält so ihre eigene Portnummer auf dem Server. Auf diese Weise lassen sich die einzelnen Sitzungen innerhalb des Dienstprogramms besser verwalten.

Werte, die einem Byte der IP-Adresse nicht zugewiesen werden sollten

Jeder Ziffernblock einer IP-Adresse ist ein Byte groß und kann somit einen Wert von 0 bis 255 annehmen. Da jedoch die 0 innerhalb eines Netzwerkplans als Identifikation für ein komplettes Subnetz benutzt wird, sollte man es vermeiden, einem kompletten Byte einer real existierenden IP-Adressen den Wert 0 zuzuweisen. Zudem ist der Wert 255 protokollintern für Broadcast reserviert, weshalb man keinem Byte der IP-Adresse diesen Wert zuweisen darf.

Komplizierter wird es, wenn sich die letzten Bits einer Subnetzmaske nicht auf das komplette Byte erstrecken (siehe Tabelle: alle Netzmasken außer CIDR /24, /16 und /8). Auch hier darf die IP-Adresse bezogen auf dieses Byte nicht den höchst möglichen Wert annehmen, da dieser Wert einer directed Broadcast-Adresse entspricht. Nur ist der höchst mögliche Wert hier kleiner als 255. Alle gültigen Werte lassen sich der Tabelle entnehmen.

Adressbereiche für private Netzwerke

Um kompatibel mit dem Internet zu sein, sollte man in einem privaten Netz die IP-Adressen 192.168.x.x verwenden (x = Werte zwischen 1 bis 254), da dieser Bereich offiziell für private Netzwerke freigegeben ist. Die für diesen Adressbereich empfohlene Subnetzmaske lautet 255.255.255.0. Zumindest sollte sie aber keinesfalls kleiner als 255.248.0.0 sein.

Der private IP-Bereich soll verdeutlichen, dass in diesem Adressbereich kein Internetserver registriert wurde, welcher mit einem Rechner aus dem privaten Netz einen Adresskonflikt auslösen könnte. Denn wird das private Netzwerk mit dem Internet verbunden und gäbe es dieselbe IP-Adresse eines internen Rechners auch im Internet, so wäre nicht klar, an welchen der beiden Rechner die Netzwerkpakete geschickt werden sollen. Theoretisch würde eine Anfrage eines Rechners aus dem privaten Netz auf diese IP-Adresse einen IP-Adresskonflikt produzieren. Um so etwas zu vermeiden, werden keine IP-Anfragen zum default Gateway geleitet, die auf das eigene Subnetz passen. Das default Gateway würde ohnehin keine Anfragen weiterreichen, bei der die IP-Adresse des Zielrechners in das Netz des Quellrechners passt. Das hat wiederum zur Folge, dass alle Internetserver, deren IP-Adressen in die Subnetzadresse des eigenen Netzes passen, aus diesem Subnetz heraus nicht zu erreichen sind. Deshalb gibt es den Bereich, der für private Netzwerke reserviert wurde. Nur wenn man ihn verwendet, kann man einen solchen Konflikt sicher ausschließen.

Alternativ zum oben genannten Adressbereich existieren auch weitere, für den privaten Gebrauch reservierte Adressbereiche: 172.16.x.x bis 172.31.x.x (empfohlene Subnetzmaske: 255.255.0.0; sie sollte auf keinen Fall kleiner sein, wenn der komplette Adressbereiche beansprucht wird) und 10.x.x.x (empfohlene Subnetzmaske: 255.0.0.0; sie sollte auf keinen Fall kleiner als 254.0.0.0 sein).

Einem populären Missverständnis zufolge, werden die privaten Adressbereiche nicht geroutet. Das ist allerdings nicht richtig. Innerhalb des privaten Netzes lassen sich damit natürlich Subnetze einrichten, welche die internen Router auch miteinander verbinden können. Allerdings werden sämtliche interne Anfragen an diese IP-Adressen nicht an das Internet weitergereicht. Das erscheint konsequent, denn man wird im Internet keinen Server finden, dessen IP-Adresse zu der Adresse aus einem privaten Adressbereichs passt.

Grundsätzliche Regeln für die Subnetzmaske

• Innerhalb eines Subnetzes müssen die Subnetzmasken auf allen PCs und Servern, die direkt miteinander kommunizieren wollen, identisch sein. Der Grund ist folgender: Anhand der eigenen IP-Adresse und der Subnetzmaske kann jeder Rechner im Netz ermitteln, wie der Netzwerkname seines Subnetzes lautet. Geht eine Anfrage an eine IP-Adresse, welche zu einem anderen Subnetz gehört, so merkt das der Rechner nun und schickt die Anfrage direkt zu seinem "default Gateway" (Router), welcher die Anforderung weiterreicht. Das ist auch der einzige Grund, warum man die Subnetzmaske nicht nur auf den Netzwerkkomponenten, sondern auch auf jedem Client bekannt geben muss.
  
  Die Subnetzmaske des Rechners definiert also, welche Adressen direkt ansprechbar sind. Sind die Masken inkonsistent, so gibt es schlicht Kommunikationsprobleme, da die Adressierung in eine der beiden Richtungen nicht mehr funktioniert (der Rechner mit der größeren Subnetzmaske nimmt dann an, dass sein Gegenpart in einem anderen Netzsegment steht und leitet die Anfrage an sein "default Gateway" weiter).
  
  Hinweis: Auf einem physikalischen Netzwerk können durchaus unterschiedliche logische Netzwerke (mit unterschiedlichem Netzwerk-Adressteil) aufgesetzt und gleichzeitig verwendet werden. Dies wird unter anderem eingesetzt, wenn später das Netzwerk wirklich aufgeteilt werden soll oder wenn früher getrennte Netze physikalisch zusammengefasst wurden. In diesem Fall könnten durchaus unterschiedliche Subnetzmasken zum Einsatz kommen. Hierbei handelt es sich jedoch um vollkommen unterschiedliche Subnetze, die sich zur Kommunikation nur zufällig ein und dasselbe Kabel teilen (will einer dieser Rechner Kontakt zu einem Rechner aus dem anderen Subnetz aufnehmen, so benötigt er dafür einen Router, obgleich sie dieselbe physikalische Leitung nutzen; daher gibt es durchaus Router, die nur über ein einzigen physikalischen Netzwerkanschluss verfügen).

• Eine Subnetzmaske darf keine Lücken aufweisen. Sie muss also von links nach rechts bündig sein, d.h. wenn das nächste rechte Feld beschrieben wird (also ungleich 0 ist), so muss das davor liegende linke Feld mit 255 gefüllt sein (gültig: 255.128.0.0 und 255.255.255.0, etc. / ungültig: 128.255.0.0 oder 255.0.255.0, etc.). Die letzte Ziffer, welche ungleich 0 ist, darf wiederum nur eine der folgenden Werte einnehmen: 128, 192, 224, 240, 248, 252, 254 oder 255. Ist der Wert ungleich 255, so gestaltet es sich etwas aufwendiger, den Netzwerk-/Host-Teil der IP-Adresse zu ermitteln.

• Wenn mehrere Netzwerke miteinander verbunden werden sollen, so ist dies einfacher, wenn die Subnetzmasken der Netzwerke gleich sind. Das ist aber nicht zwingend erforderlich.

Netzklassen

Die Verwendung von Netzklassen ist veraltet und wurde entwickelt, lange bevor es die Subnetzmaske gab. Damals bediente man sich eines anderen Mechanismus, um die Länge der Netzwerk-ID einer 32-Bit IP-Adresse zu definieren. Dafür wurden laut Konvention RFC 990 die IP-Adressen in bestimmte Adressbereiche unterteilt, wobei jeder dieser Bereiche für eine bestimmte Länge der Netzwerk-ID stand. Die Bereiche nannte man Klassen.

So mussten beispielsweise bei einer IP-Adresse aus einem Klasse C Netz die ersten hochwertigen Bits mit 1 1 0 belegt sein. Mit anderen Worten konnte man anhand der IP-Adressen 192.x.x.x bis 223.x.x.x erkennen, dass sie zu einem Klasse C Netz gehören. Und laut Konvention erstreckte sich die Netzwerk-ID in einem Klasse C Netz auf die ersten drei Ziffernblöcke der IP-Adresse (also auf die ersten drei Byte).

Bezeichnung	Class-ID-Bits aus dem ersten Byte der IP-Adresse	Daraus ergibt sich ein Adressbereich von	bis	Der Adressbereich definiert den folgenden Bereich der Netzwerk-ID (NID) in den IP-Adressen
Klasse A	0xxxxxxx	0.x.x.x	127.x.x.x	NID.x.x.x
Klasse B	10xxxxxx	128.x.x.x	191.x.x.x	NID.NID.x.x
Klasse C	110xxxxx	192.x.x.x	223.x.x.x	NID.NID.NID.x
Klasse D (Sonderklasse für Multicast-Adressen)	1110xxxx	224.x.x.x	239.x.x.x	NID.NID.NID.x
Klasse E (Reserviert)	1111xxxx	240.x.x.x	255.x.x.x	NID.NID.NID.x

Dank dieses Systems erkannten alle Netzwerkkomponenten bereits anhand der verwendeten IP-Adressen, welche Unterteilung zwischen der Netzwerk-ID und Rechner-ID in ihrem Netz verwendet wurde. Und das ohne sie wie heute durch die Bekanntgabe der Subnetzmaske entsprechend konfigurieren zu müssen. Allerdings haben die Entwickler dieses zweifellos genialen Adressierungsschemas nicht mit der Erfolgsgeschichte des Internet und dem heutigen IP-Adressenbedarf gerechnet.

Eine andere Methode sollte helfen, den Teil der Netzwerk-ID viel feiner als mit den Netzklassen üblich zu bestimmen. So wurde 1985 die Subnetzmaske eingeführt. Sie realisierte zunächst eine weitere Strukturierung des Netzwerk-ID-Bereichs innerhalb des eigenen Netzes. Die Netzklassen waren praktisch nur noch im Internet präsent. Allerdings mussten damals alle Subnetze im gesamten privaten Netz dieselbe Subnetzmaske verwenden. 1987 wurde auch diese Beschränkung aufgehoben.

Bereits zu jener Zeit störte es niemanden, wenn man in seinem privaten Netz eine Subnetzmaske angegeben hat, die zu einem Klasse-B-Netz kompatibel ist (also 255.255.0.0), dort aber Adressen verwendet wurden, welche laut Konvention eigentlich zu einem Klasse C Netz gehörten. Allerdings gab es einige alte Router, welche sich auf diese Konvention verlassen haben und dann von einer Subnetzmaske 255.255.255.0 ausgegangen sind. Diese Geräte konnte man in einem solchen Netz nicht mehr verwenden. Da seit Ende der 1980er nur noch Router produziert werden, bei denen man die Subnetzmaske von Hand konfigurieren kann, gibt es das Problem heute nicht mehr.

1993 hat man sich auch im Internet von den Netzklassen gänzlich verabschiedet. Auf diese Weise war man nun in der Lage, bisherige Klasse-A-Netzwerke in kleinere Subnetze aufzugliedern, wodurch ein riesiger Pool von weiteren IP-Adressen zur Verfügung stand.

So kann eine Organisation (z.B. ein Internetprovider), die einen IP-Adressblock zugewiesen bekommen hat, diesen nun intern nach ihren eigenen Bedürfnissen aufteilen. Damit die Organisation nach außen den gesamten IP-Adressblock propagieren kann, mussten deren Router allerdings zu einem autonomen Netzwerk zusammengefasst werden. Das lässt sich am besten mit der dem Verschicken eines Paketes per Post vergleichen: Wird dort eine Adresse angegeben, so gelangt es erst zum Verteilzentrum des angegebenen Ortes. Das Verteilzentrum „propagiert“ also alle Postleitzahlen des Ortes und kümmert sich dann intern um die Weiterleitung. Denn da man erst hier genau weiß wie die Aufteilung der Adressen tatsächlich aussieht, kann das Paket auch nur von hier aus intern auf den richtigen Weg zum Ziel geschickt werden.

Tabelle: Subnetzmaske / Adressierbare Rechner

Es gibt im Internet zahlreiche Bespiele dafür, wie man die Netzwerk- und Rechner-ID ermitteln kann, indem die einzelnen Bits der IP-Adresse aufgeschlüsselt werden. Demgegenüber wird hier versucht, diese Aufgabe mithilfe einer Tabelle zu lösen:

Subnetzmaske	CIDR-Schreibweise	FB-Wert	theoretische Anzahl der Rechner pro Subnetz	tatsächliche max. Rechneranzahl, wenn die 0 für das komplette Byte und die 255 bzw. die directed Broadcast-Adresse keinem Rechner (oder besser keiner Netzwerkkarte) zugewiesen wird	mögliche Netzwerk-ID (NID)	mögliche Rechner-ID (RID)	IP-Adresse
255.255.255.254	/31	2	2	1	[1 bis 254].[1 bis 254].[1 bis 254].[1 bis 254]	[0]	IP-Adresse=NID
255.255.255.252	/30	4	4	3	[1 bis 254].[1 bis 254].[1 bis 254].[128, 64, 32, 16, 8, 4 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 2 wenn last NID > 0, sonst 1 bis 2]	NID.NID.NID.[NID RID]
255.255.255.248	/29	8	8	7	[1 bis 254].[1 bis 254].[1 bis 254].[128, 64, 32, 16, 8 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 6 wenn last NID > 0, sonst 1 bis 6]	NID.NID.NID.[NID RID]
255.255.255.240	/28	16	16	15	[1 bis 254].[1 bis 254].[1 bis 254].[128, 64, 32, 16 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 14 wenn last NID > 0, sonst 1 bis 14]	NID.NID.NID.[NID RID]
255.255.255.224	/27	32	32	31	[1 bis 254].[1 bis 254].[1 bis 254].[128, 64, 32 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 30 wenn last NID > 0, sonst 1 bis 30]	NID.NID.NID.[NID RID]
255.255.255.192	/26	64	64	63	[1 bis 254].[1 bis 254].[1 bis 254].[128, 64 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 62 wenn last NID > 0, sonst 1 bis 62]	NID.NID.NID.[NID RID]
255.255.255.128	/25	128	128	127	[1 bis 254].[1 bis 254].[1 bis 254].[128 und 0 können verwendet werden]	[0 bis 126 wenn last NID > 0, sonst 1 bis 126]	NID.NID.NID.[NID RID]
255.255.255.0	/24	-	256	254	[1 bis 254].[1 bis 254].[1 bis 254]	.[1 bis 254]	NID.NID.NID.RID
255.255.254.0	/23	2	512 (2 x 256)	508 (2 x 254)	[1 bis 254].[1 bis 254].[128, 64, 32, 16, 8, 4, 2 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 1 wenn last NID > 0, sonst 1].[1 bis 254]	NID.NID.[NID first RID].RID
255.255.252.0	/22	4	1024 (4 x 256)	1016 (4 x 254)	[1 bis 254].[1 bis 254].[128, 64, 32, 16, 8, 4 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 3 wenn last NID > 0, sonst 1 bis 3].[1 bis 254]	NID.NID.[NID first RID].RID
255.255.248.0	/21	8	2048 (8 x 256)	2032 (8 x 254)	[1 bis 254].[1 bis 254].[128, 64, 32, 16, 8 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 7 wenn last NID > 0, sonst 1 bis 7].[1 bis 254]	NID.NID.[NID first RID].RID
255.255.240.0	/20	16	4096 (16 x 256)	4064 (16 x 254)	[1 bis 254].[1 bis 254].[128, 64, 32, 16 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 15 wenn last NID > 0, sonst 1 bis 15].[1 bis 254]	NID.NID.[NID first RID].RID
255.255.224.0	/19	32	8192 (32 x 256)	8128 (32 x 254)	[1 bis 254].[1 bis 254].[128, 64, 32 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 31 wenn last NID > 0, sonst 1 bis 31].[1 bis 254]	NID.NID.[NID first RID].RID
255.255.192.0	/18	64	16384 (64 x 256)	16256 (64 x 254)	[1 bis 254].[1 bis 254].[128, 64 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 63 wenn last NID > 0, sonst 1 bis 63].[1 bis 254]	NID.NID.[NID first RID].RID
255.255.128.0	/17	128	32768 (128 x 256)	32512 (128 x 254)	[1 bis 254].[1 bis 254].[128 und 0 können verwendet werden]	[0 bis 127 wenn last NID > 0, sonst 1 bis 127].[1 bis 254]	NID.NID.[NID first RID].RID
255.255.0.0	/16	-	65536 (256 x 256)	64516 (254 x 254)	[1 bis 254].[1 bis 254]	.[1 bis 254].[1 bis 254]	NID.NID.RID.RID
255.254.0.0	/15	2	131072 (2 x 65536)	129032 (2 x 64512)	[1 bis 254].[128, 64, 32, 16, 8, 4, 2 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 1 wenn last NID > 0, sonst 1].[1 bis 254].[1 bis 254]	NID.[NID first RID].RID.RID
255.252.0.0	/14	4	262144 (4 x 65536)	258064 (4 x 64512)	[1 bis 254].[128, 64, 32, 16, 8, 4 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 3 wenn last NID > 0, sonst 1 bis 3].[1 bis 254].[1 bis 254]	NID.[NID first RID].RID.RID
255.248.0.0	/13	8	524288 (8 x 65536)	516128 (8 x 64512)	[1 bis 254].[128, 64, 32, 16, 8 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 7 wenn last NID > 0, sonst 1 bis 7].[1 bis 254].[1 bis 254]	NID.[NID first RID].RID.RID
255.240.0.0	/12	16	1048576 (16 x 65536)	1032256 (16 x 64512)	[1 bis 254].[128, 64, 32, 16 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 15 wenn last NID > 0, sonst 1 bis 15].[1 bis 254].[1 bis 254]	NID.[NID first RID].RID.RID
255.224.0.0	/11	32	2097152 (32 x 65536)	2064512 (32 x 64512)	[1 bis 254].[128, 64, 32 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 31 wenn last NID > 0, sonst 1 bis 31].[1 bis 254].[1 bis 254]	NID.[NID first RID].RID.RID
255.192.0.0	/10	64	4194304 (64 x 65536)	4129024 (64 x 64512)	[1 bis 254].[128, 64 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 63 wenn last NID > 0, sonst 1 bis 63].[1 bis 254].[1 bis 254]	NID.[NID first RID].RID.RID
255.128.0.0	/9	128	8388608 (128 x 65536)	8258048 (128 x 64512)	[1 bis 254].[128 und 0 können verwendet werden]	[0 bis 127 wenn last NID > 0, sonst 1 bis 127].[1 bis 254].[1 bis 254]	NID.[NID first RID].RID.RID
255.0.0.0	/8	-	16777216 (256 x 65536)	16386048 (254 x 64512)	[1 bis 254]	.[1 bis 254].[1 bis 254].[1 bis 254]	NID.RID.RID.RID
254.0.0.0	/7	2	33554432 (2 x 16777216)	32772096 (2 x 16387064)	[128, 64, 32, 16, 8, 4, 2 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 1 wenn NID > 0, sonst 1].[1 bis 254].[1 bis 254].[1 bis 254]	[NID RID].RID.RID.RID
252.0.0.0	/6	4	67108864 (4 x 16777216)	65544192 (4 x 16386048)	[128, 64, 32, 16, 8, 4 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 3 wenn NID > 0, sonst 1 bis 3].[1 bis 254].[1 bis 254].[1 bis 254]	[NID RID].RID.RID.RID
248.0.0.0	/5	8	134217728 (8 x 16777216)	131088384 (8 x 16386048)	[128, 64, 32, 16, 8 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 7 wenn NID > 0, sonst 1 bis 7].[1 bis 254].[1 bis 254].[1 bis 254]	NID.[NID RID].RID.RID.RID
240.0.0.0	/4	16	268435456 (16 x 16777216)	262176768 (16 x 16386048)	[128, 64, 32, 16 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 15 wenn NID > 0, sonst 1 bis 15].[1 bis 254].[1 bis 254].[1 bis 254]	NID.[NID RID].RID.RID.RID
224.0.0.0	/3	32	536870912 (32 x 16777216)	524353536 (32 x 16386048)	[128, 64, 32 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 31 wenn last NID > 0, sonst 1 bis 31].[1 bis 254].[1 bis 254].[1 bis 254]	NID.[NID RID].RID.RID.RID
192.0.0.0	/2	64	1073741824 (64 x 16777216)	1048707072 (64 x 16386048)	[128, 64 und 0 können verwendet und auch miteinander addiert werden]	[0 bis 63 wenn last NID > 0, sonst 1 bis 63].[1 bis 254].[1 bis 254].[1 bis 254]	NID.[NID RID].RID.RID.RID
128.0.0.0	/1	128	2147483648 (128 x 16777216)	2097414144 (128 x 16386048)	[128 und 0 können verwendet werden]	[0 bis 127 wenn NID > 0, sonst 1 bis 127].[1 bis 254].[1 bis 254].[1 bis 254]	NID.[NID RID].RID.RID.RID

Ein Beispiel für den Umgang mit der Tabelle

Es wird eine Subnetzmaske von 255.255.248.0 und eine Netzwerk-ID von 10.10.88 verwendet. Die 88 wurde anhand der Addition beliebiger Werte aus der Tabelle gebildet, die zu einer gültigen Netzwerk-ID der benutzen Subnetzmaske passen (128, 64, 32, 16, 8 und 0 können zugewiesen bzw. miteinander addiert werden; in diesem Beispiel wurde 64 + 16 + 8 = 88 verwendet).

Die Rechner-ID in einem 255.255.248’er Subnetz kann laut Tabelle im ersten Byte 0 bis 7 betragen, da das letzte Byte der Netzwerk-ID ungleich 0 ist (sonst wäre nur ein Wert zwischen 1 bis 7 zu empfehlen, da die 0 innerhalb eines Netzwerkplans als ID für ein komplettes Subnetz verwendet wird, weshalb man davon absehen sollte, einem kompletten Byte der IP-Adresse den Wert 0 zuzuweisen).

Die IP-Adresse der Rechner wird nun gebildet, indem man die 88 mit dem Wert aus der ersten Ziffer (also dem ersten Byte) der Rechner-ID addiert. Ein Rechner mit der ID 5.123 erhält somit in diesem Subnetz die IP-Adresse 10.10.(88 + 5).123, also 10.10.93.123. Wenn man diese IP-Adresse in einem Dokument festhalten möchte, so gibt man zudem den passenden CIDR-Wert aus der Tabelle mit an, damit der Leser daraus die Subnetzadresse ermitteln kann:

10.10.93.123/21

Wie aber kann man die Netzwerk-ID anhand dieser Angaben zurückrechnen? Hierfür nimmt man den zur CIDR-Angabe gehörenden FB-Wert aus der dritten Spalte der Tabelle (hier 8; als Hinweis: das entspricht 2 ^ 3, da es drei Bits im letzen Byte der Netzwerk-ID gibt, die nicht zur Netzwerk-ID gehören). Aus dem Bereich der Netzwerk-ID nimmt man nun die letzte Ziffer (hier x.x.93.x) und teilt diese durch den FB-Wert. Dann rechnet man das Ergebnis ohne den Nachkommateil wieder zurück. Bezogen auf dieses Beispiel wäre dass:

93 / 8 = 11,625
11 * 8 = 88

Die Netzwerk-ID lautet demnach 10.10.88. Nimmt man nun

93 - 88 = 5

so erhält man den gesuchten Teil der Rechner-ID: 5.123

siehe auch

• DNS

Weblinks (externe Links)

• wikipedia liefert eine ausführliche, technische Erklärung zur MAC-Adresse
• weitere Infos zur IP-Adresse sind bei wikipedia zu finden.
• wikipedia bietet auch eine gute technische Erklärung zum Netzwerk-Port
• zudem lassen sich weitreichende Informationen zur Subnetzmaske bei wikipedia finden