Unterthema: Lehrmeister - Klassifizierung von IP-Adressen
Bei der Konfiguration des TCP/IP-Protokolls stolpert man unter Windows NT über eine Registerseite im Konfigurationsdialog, die schon manchem Administrator Rätsel aufgegeben hat: IP-Weiterleitung aktivieren beziehungsweise in der englischen Version Enable IP Forwarding. Die Online-Hilfe bringt leider auch nicht viel: Sie weist lapidar darauf hin, daß diese Option aktiviert sein muß, wenn der entsprechende Host als Router fungieren soll. Alles klar?
Sogar in der ersten Version von Windows 95 konnte man aufgrund eines Fehlers in der Protokoll-Implementation Routing betreiben. Steht Enable Routing in der Registry unter \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\ auf dem Wert 1, geht es auch mit dem kleinen Microsoft-System. Erst spätere Versionen von Windows 95 oder 98 verhinderten das vollständig.
Selbst wenn man weiß, daß man einen Router benötigt, um IP-Teilnetze miteinander zu verbinden, bleibt immer noch die Frage offen, ob es unter Windows tatsächlich reicht, einfach diesen Schalter zu aktivieren. Und was passiert mit dem Internet-Zugang? IP-Forwarding heißt noch lange nicht, daß damit auch die Clients im LAN über den Router ins Internet gelangen.
Soll nun ein Paket an einen Rechner gehen, dessen IP-Adresse sich auch im Netzwerkteil von der eigenen unterscheidet, kann TCP/IP dies nicht direkt gewährleisten. Der Protokoll-Stack schickt das Paket daher an den Router (unter Windows meist Default Gateway genannt), der für die Weiterleitung zuständig ist. Ein Router hat mindestens zwei Netzwerk-Schnittstellen, über die er an verschiedene IP-Teilnetze angeschlossen ist. Kommt ein Paket herein, das für das Netz bestimmt ist, an das der Router mit dem zweiten Interface verbunden ist, kann er das Paket mit den normalen Methoden (arp) direkt zustellen. Andernfalls leitet er es ebenfalls an den nächsten Router weiter, wo sich der Prozeß wiederholt - und das so lange, bis endlich das Netz erreicht ist, in dem sich der Zielrechner befindet (siehe Grafik auf Seite 215).
Unter Routing versteht man also die zielgerichtete Zustellung eines Datenpakets von einem Host zu einem anderen in unterschiedlichen logischen Netzwerken. Das Paket soll dabei den kürzesten Weg nehmen und der IP-Stack, so die Idee, diese optimale Route vom Sender zum fernen Empfänger nach Möglichkeit auch noch selbst bestimmen.
Hier verbietet sich der Einsatz von Broadcast-Methoden. Befänden sich beispielsweise alle Hosts im Internet in einem logischen Netzwerk, in dem jeder Rechner mittels Broadcasts den Empfänger für ein Datenpaket finden muß, wäre die gesamte Infrastruktur bereits überlastet, bevor das erste Datenpaket überhaupt auf die Reise gegangen ist.
Derartige Netzverbünde müssen also in kleine logische Einheiten zerlegt werden; das verwendete Protokoll muß, um Effizienz zu gewährleisten, den Organisations-Overhead beim Datenverkehr zwischen diesen logischen Einheiten so gering wie möglich halten. Das IP-Protokoll selbst und die diversen auf diesem Protokoll basierenden Dienste berücksichtigen genau diese Anforderungen [3, 4].
Aber nicht nur das Internet ist über unterschiedliche IP-Subnetze strukturiert - jedes LAN, das eine gewisse Komplexität erreicht, läßt sich durch die Aufteilung in kleinere Teilnetze überschaubar halten. Die Anzahl der Routing-Stationen, die ein Datenpaket vom Absender zum Empfänger benötigt, nennt man Hop. Müßte ein Router in seinen Routing-Tabellen nun jeweils die vollständigen Wege führen, also alle Zwischenstationen kennen, kämen hier schnell gigantische Datenmengen zusammen. Um dies zu vermeiden, kennt ein Router immer nur die jeweils nächstgelegene Station auf dem Routing-Weg.
Der Router leitet das Paket weiter, indem er es gewissermaßen mit einem weiteren Umschlag versieht, auf dem die Adresse des nächstgelegenen Routers auf dem gewünschten Weg verzeichnet ist. Dieser Adressat entfernt den Umschlag, analysiert die Zieladresse, überprüft die eigenen Routing-Tabellen, um die nächste Station im Routing-Prozeß zu ermitteln, und reicht das Paket nach dem gleichen Prinzip weiter.
Jeder Router führt sogenannte statische und dynamische Routen in seinen internen Tabellen. Statische Routen gibt der Administrator mit dem Befehl route beziehungsweise über den entsprechenden Konfigurationsdialog für das TCP/IP-Protokoll vor. Im einfachsten Fall wird lediglich eine Default-Route für jeden Host konfiguriert. Unter NT muß man dem System nach der Aktivierung von IP-Forwarding mit dem Kommando route alle notwendigen Informationen bekanntgeben, und zwar im Format:
route -p ADD <Zieladresse> MASK <Subnetz-Maske> <Gateway-Adresse>Das Kommando ADD bewirkt, daß der NT-Router die Route hinzufügt. Der Parameter -p kennzeichnet die Route als persistent - sie steht also auch nach einem Neustart des Systems sofort wieder zur Verfügung.
Ein Router und auch jeder beliebige Host kennen immer nur den jeweils nächstliegenden Routing-Hop. Alles weitere liegt dann in den Händen der nächsten Station. Entsprechend sind in einer Routing-Anweisung zwei Angaben notwendig: das gewünschte Ziel der Route und der nächste Hop.
Die drei Route-Typen (Default-, Netzwerk- und Host-Routen) unterscheiden sich in der Art des Routing-Zieles. Bei einer Netzwerk-Route wird ein logisches Netzwerk als Ziel angegeben, etwa 162.168.10.0. Die Null im letzten Oktett steht für das gesamte logische Netz 192.168.10 mit allen darin befindlichen Hosts. Eine solche Route gilt demnach für alle Hosts eines gesamten logischen Netzwerks. Bei einer Host-Route ist das Ziel ein spezifischer Host. Host-Routen sind beispielsweise dann sinnvoll, wenn das Routing-Ziel ein PPP-Interface oder aber ein einzelner Host hinter einer semipermanenten Verbindung ist - das Weiterleiten der Daten erfolgt in diesem Fall über eine Punkt-zu-Punkt-Verbindung.
Am wenigsten spezifisch ist die Default-Route. Pro Host darf es nur eine solche Standard-Route geben. Wann immer für einen Routing-Vorgang keine Host- oder Netzwerk-Route in den Routing-Tabellen existiert, kommt die Default-Route zum Tragen. Das Datenpaket gelangt dann an den in der Default-Anweisung angegebenen Router - in der Hoffnung, dieser verfügt über spezifischere Informationen. Default-Routen sind immer dann notwendig, wenn ein Netzwerk oder auch ein einzelner Host in einem Netzverbund operieren, dessen Organisation nicht im Detail bekannt ist. Das einfachste Beispiel ist der Anschluß eines LAN ans Internet: Alle Pakete, die nicht an Hosts im internen Netz adressiert sind, muß der Router ins Internet weiterleiten.
route -p ADD 0.0.0.0 MASK 0.0.0.0 192.168.168.100Um in größeren Netzverbünden die Angabe von unnötig vielen Routen zu vermeiden, können Router mit einer Art Eigenintelligenz ausgestattet sein. Sogenannte Routing-Protokolle [4] ermöglichen es, daß die Router sich gegenseitig über mögliche Wege informieren. Bei NT handelt es sich dabei um ein separates Modul, das man über die Seite Dienste der Netzwerkeinstellungen einrichten kann. Das System kommt damit in den Genuß des Routing Information Protocol (RIP), einem von der IETF (Internet Engineering Task Force) standardisierten Protokoll.
RIP versetzt einen Router in die Lage, dynamisch mit benachbarten Routern Informationen über die möglichen Wege auszutauschen. Ein Router kann dadurch beispielsweise seine eigene IP-Adresse bekanntgeben und Angaben darüber machen, zu welchen Netzen er Wege kennt. Andere Router speichern diese Informationen in ihren Tabellen und benutzen sie dann, wenn sie Pakete an die so als erreichbar gekennzeichneten Netze weiterleiten sollen.
In großen Netzverbünden wie dem Internet sind die dynamischen Routen nach diesem Modell Standard. Die Router gleichen ihre Informationen fortlaufend miteinander ab; dabei gilt das Prinzip Good news travel fast, bad news travel slow. Sobald also ein RIP-Router eine neue Route findet, wird er diese Information zusammen mit der ermittelten Anzahl an notwendigen Hops bis zum Ziel an seine nächstliegenden Partner übermitteln. Fällt eine Route aus, wird diese Information erst mit einer gewissen Verzögerung publik gemacht - man geht davon aus, daß es sich nur um eine temporäre Störung handelt.
Da immer nur die benachbarten Router miteinander sprechen, bleibt der dadurch verursachte Datenverkehr überschaubar; dennoch können diese Router in einem Netzverbund immer den optimalen Weg zu einem Adressaten bestimmen. Zudem erreicht man damit ein gewisses Maß an Fehlertoleranz: Fällt eine Route aus, ermitteln die noch funktionierenden Router einen neuen, wenn auch vielleicht längeren Weg zum Ziel, ohne daß die Anwendung oder der Benutzer davon etwas bemerkt.
Ob in einem auf TCP/IP basierenden LAN RIP eingesetzt werden soll oder nicht, hängt sowohl von der Größe und Komplexität des LAN als auch von Sicherheitsüberlegungen ab. Nicht immer ist es erwünscht, daß sich ein IP-Paket von einem beliebigen Host im LAN-Verbund gewissermaßen selbständig den Weg zu einem beliebigen anderen Host in diesem Verbund suchen kann. Soll ein Teilnetz (beispielsweise eine bestimmte Abteilung) nur mit einem oder einigen anderen Teilnetzen kommunizieren können, verbietet sich der Einsatz von RIP. Hier sind lediglich statische Netzwerk-Routen zu setzen.
In der Regel reichen bei einfacheren LANs mit zwei oder drei Teilnetzen statische Routen völlig aus. Erst wenn die Installation komplexer wird (siehe Grafik auf dieser Seite), führt eigentlich auch unter NT kein Weg mehr an RIP vorbei. Denn diverse Teilnetze, über Telefonleitungen verbundene Installationen und zusätzliche Internet-Anschlüsse machen die manuelle Verwaltung der Routing-Tabellen zu einem Alptraum. Schnell hat man eine falsche Route gesetzt oder kommt beim Ausfall eines Weges nicht mit der Aktualisierung der Tabellen nach - mit dem Ergebnis, daß einzelne Rechner und ganze Teilnetze nicht erreichbar sind.
Dies von Hand mit den Bordmitteln von Windows zu konfigurieren kann aber zu einer größeren Staatsaktion ausarten - vor allem, wenn zusätzlich etwa noch Dial-in für einzelne Clients möglich sein soll und verschiedene lokale IP-Subnetze aktiv sind. Glücklicherweise hatte Microsoft vor einiger Zeit ein Einsehen und brachte den sogenannten Routing und Remote Access Service (RRAS) heraus [1], der kostenlos zu haben ist.
Bei RRAS handelt es sich im Prinzip um eine Aktualisierung des gewohnten Remote Access Service (RAS) des NT Server. Microsoft hat zudem mehrere Komponenten zusammengefaßt und stellt für sie eine einheitliche Verwaltungsoberfläche (RRAS Admin) zur Verfügung. Zu den einzelnen Modulen gehören neben RAS-Server und -Client die Routing-Software und das Routing-Protokoll RIP sowie der DHCP-Relay-Agent, mit dem Informationen eines DHCP-Servers aus einem anderen Teilnetz im lokalen IP-Subnetz erreichbar sind.
Um es deutlich zu sagen: Wirklich notwendig ist der Download und die Installation dieses immerhin 5,7 MB großen Pakets nicht. Obwohl RRAS von Microsoft auch als Performance Update bezeichnet wurde, konnten wir keine spürbaren Performance-Steigerungen verzeichnen. Immerhin bringt das Update einige Erweiterungen des RAS-Services, die in Umgebungen mit NetWare beziehungsweise IPX/SPX von Interesse sind. Entscheidend ist aber die spürbare Vereinfachung des Umgangs mit der Router-Software und RAS sowie die einfache Möglichkeit, Dial-on-Demand einzurichten.
Bevor man die Installation von RRAS startet, müssen eventuell bereits installierte Komponenten, die in dem Update integriert sind, entfernt sein. Das Installationsprogramm weist beim Setup zwar darauf hin, daß schon vorhandene RAS-Konfigurationen verlorengehen würden - dies war in unseren Versuchen aber nicht der Fall. Nach der Installation des Updates waren schon vorhandene Routing- und RAS-Einträge weiter verfügbar. Um sicherzugehen, sollte man allerdings die entsprechenden Konfigurationsdaten sichern - indem man sie abschreibt. Außerdem ist für RRAS inzwischen mindestens das NT-Service-Pack 3 notwendig - das laut RRAS-Anleitung nach der Einrichtung von RRAS seltsamerweise nochmals aufgespielt werden muß. Daran sollte man sich aber auch halten - die NT-Maschine arbeitet sonst nicht mehr stabil. Schon eine seltsame Vorgehensweise, daß ein Produkt zwar ein Service-Pack kennt, aber offensichtlich trotzdem einige Dateien mit älteren Versionen überschreibt ...
Schon bei der Installation besteht die Auswahlmöglichkeit, ob die Unterstützung für LAN-Routing und/oder On-Demand-Dial-up-Routing aktiv sein soll. Deaktiviert man das LAN-Routing, fungiert die NT-Maschine nicht mehr als normaler IP-Router, sondern nur noch als Einwahlserver für PPP-/RAS-Clients. Der Verbindungsaufbau ins Internet bleibt zudem möglich. Schaltet man On-Demand-Dial-up-Routing an, fungiert die NT-Maschine nur als Router zwischen LAN und Internet und baut die Verbindung selbständig auf, sobald Datenpakete anliegen, die nicht für das LAN bestimmt sind. Sobald alle drei Optionen (Router, RAS und On-Demand-Dial-up) aktiv sind, stellt der NT-Rechner einen vollwertigen Router dar, der gleichzeitig Dial-in ermöglicht und Verbindungen zum Internet oder über Weitverkehrsleitungen zu anderen LANs herstellen kann.
Voraussetzung dafür ist, daß ein entsprechendes Gerät (Modem, ISDN-Adapter oder ähnliches) unter Modems in den Systemeinstellungen konfiguriert ist. Im Ordner LAN and Demand Dial Interfaces kann man anschließend eine entsprechende RAS-Schnittstelle hinzufügen, die auf eines der eingerichteten Modems zugreift. Hier sind dann beispielsweise auch entsprechende Angaben über Telefonnummer oder Login-Informationen (im Menüpunkt Credentials des RAS-Interfaces) möglich.
Das einzige, was für den Internet-Zugang eines einzelnen IP-Teilnetzes dann noch fehlt, ist eine statische Default-Route über die RAS-Schnittstelle zum Router des Internet-Providers. Sie trägt man im Ordner IP-Routing/Static Routes ein - eine kleine Dialog-Box erwartet die Angabe von IP-Adresse und Subnetzmaske (für die Default-Route in beiden Fällen 0.0.0.0) sowie die Auswahl der Schnittstelle aus einer List-Box. Das war´s im Prinzip schon: Auf den Clients fügt man noch die NT-Maschine mit RRAS als Default-Gateway hinzu. Zusätzlich lassen sich natürlich weitere statische Routen für eventuelle lokale IP-Subnetze eintragen oder das dynamische Routing über RIP aktivieren.
Eines nimmt dem Administrator allerdings auch RRAS nicht ab: Man muß nach wie vor von Hand auf der Registerseite Routing im Einstellungsdialog des TCP/IP-Protokolls die Option IP-Weiterleitung aktivieren - sonst tut sich gar nichts.
Windows für Workgroups wie auch der OS/2-LAN-Server von IBM verwendeten ursprünglich NetBEUI (NetBIOS Enhanced User Interface) auf Ebene des Transport-Layers. Dabei handelt es sich jedoch um ein nicht-routebares Protokoll, das vorwiegend auf Broadcast-Mechanismen beruht. Die Realisierung von Fernanbindungen an solche Netzwerke war komplex, und entsprechende Installationen hatten häufig mit Performance-Engpässen zu kämpfen.
Eine Lösung für dieses Problem bietet TcpBEUI (von Microsoft NBT, NetBIOS over TCP/IP, genannt), eine Net-BIOS-Schnittstelle, die auf TCP/IP als Transportmedium aufsetzt. Ohne dies groß anzukündigen, hat Microsoft TcpBEUI vor einiger Zeit zum Standard erhoben - Windows 95 benutzte zwar standardmäßig immer noch NetBEUI, NT und Windows 98 dagegen setzen dieses Protokoll nur auf Wunsch ein und installieren TCP/IP als Standard.
De facto kann man sich gar nicht dagegen wehren, ein TcpBEUI-Netz zu fahren, sobald TCP/IP auf Windows NT installiert ist. Microsoft benutzt im Gegensatz zu IBM bei OS/2 diesen Begriff allerdings nicht, obwohl er die offizielle Bezeichnung des Standards der IETF für den Transport von NetBIOS-Daten über TCP/IP ist. Unter Windows richtet das System neben den Transport-Protokollen automatisch die NetBIOS-Schnittstelle ein, die nicht weiter konfigurierbar ist. Findet sie ein installiertes TCP/IP, verwendet sie es als Transport-Medium. Im Unterschied zu NetBEUI, das in der Regel keine weitere Konfiguration erfordert, ist für ein TcpBEUI-Netz natürlich eine funktionierende IP-Infrastruktur notwendig.
Gerade für den Internet-Zugang eines LAN macht NetBIOS allerdings einige Probleme. TCP/IP stellt die verschiedenen Dienste (etwa http für das Web oder ftp für den Dateitransfer) über sogenannte Port-Nummern bereit. Soll ein Datenpaket beispielsweise an einen Web-Server auf einem bestimmten Rechner gehen, schickt der Protokoll-Stack es nicht nur an die IP-Adresse der Maschine, sondern fügt noch die Information über den gewünschten Dienst als Port-Nummer hinzu (im Fall des Web-Servers die Port-Nummer 80).
In der Regel ist es nun aber gar nicht erwünscht, daß NetBIOS-Datenverkehr ins Internet gelangt - da er aber für den Protokoll-Stack wie ein normales IP-Paket aussieht, gibt es erst einmal keine Möglichkeit, dies zu verhindern. Viele, die ein LAN unter Windows ans Internet gebracht haben, wunderten sich ziemlich über ständige Verbindungsaufbauten und explodierende Telefonrechnungen.
Abhilfe schafft hier nur das Filtern der Ports, die für NetBIOS reserviert sind (137, 138 und 139). Der Routing and Remote Access Service von NT erlaubt glücklicherweise die Paketfilterung - man kann auf Adreß- und Port-Basis angeben, ob RRAS Pakete weiterleiten oder komplett verwerfen soll. Konfigurieren lassen sich die Filter über Configure Interface für jede einzelne Schnittstelle im Ordner IP-Routing/Summary des RRAS-Managers. Natürlich darf man die NetBIOS-Ports nicht auf der Netzwerkkarte ausfiltern - der NT-Router wäre sonst nicht mehr über das normale Windows-Netz ansprechbar. Wer dies allerdings sowieso nicht benötigt, kann so von vornherein verhindern, daß der Router NetBIOS-Pakete über das LAN-Interface akzeptiert.
Für den normalen Internet-Zugang sind für die WAN-Schnittstelle im RRAS Output-Filter einzurichten. Für jeden der drei NetBIOS-Ports ist dabei eine eigene Filterregel notwendig, da RRAS keine Port-Bereiche akzeptiert. Außerdem sollte man sowohl für TCP wie UDP entsprechende Regeln bereitstellen - insgesamt sind also sechs Filter notwendig, um den Verbindungsaufbau durch NetBIOS-Pakete zu verhindern.
Die Sache hat allerdings zwei ganz große Haken. Der erste: RRAS arbeitet nur mit der Server-Version von NT. Und die hat nun nicht jeder, der ein Windows-Netzwerk betreibt, einfach so herumstehen. Vor allem kleinere Firmen und Heimanwender arbeiten oft mit Peer-to-Peer-Netzen auf Basis von Windows 9x oder NT Workstation und dürften kaum bereit sein, die Hardware- sowie Software-Kosten für eine NT-Server-Installation zu bestreiten, um ein LAN ins Internet zu bringen.
Der zweite große Haken an RRAS: Der Router beherrscht keine Network Address Translation (NAT) [5]. Für die Verbindung lokaler IP-Teilnetze spielt das keine Rolle - wohl aber für den Zugang zum Internet. In der Regel benutzt man für ein LAN sogenannte private IP-Adressen (siehe Kasten `Lehrmeister´), die im Prinzip keine Kommunikation in öffentlichen Netzen wie dem Internet ermöglichen und damit auch eine eingeschränkte Sicherheit gegen Angriffe von außen bieten. Ein Router mit NAT setzt nun diese privaten auf eine oder mehrere öffentliche IP-Adressen um, leitet die Daten ins Internet und gibt die Antworten wieder an den Rechner im LAN zurück, von dem die ursprüngliche Anforderung kam.
Ohne Network Address Translation ist man darauf angewiesen, das gesamte Netz mit öffentlichen IP-Adressen auszustatten. Diese muß man beantragen (www.iana.org) und bezahlen - ein Weg, der sich nur für größere Installationen lohnt und für Heimanwender wohl kaum in Frage kommt. Wer nicht gleich zu Linux als Router und NAT-Gateway [6] wechseln oder sich auf einen Proxy-Server als Internet-Vermittler [7] beschränken will, steht aber auch mit Windows nicht im Regen.
Sowohl für Windows 9x wie für NT (Workstation oder Server) existiert mit NAT32 [2] ein Software-Router mit Network Address Translation. Prinzipiell gedacht ist NAT32 vor allem für das Anbinden eines LAN ans Internet, kann aber auch normale Routing-Funktionen übernehmen. Das Programm ist Shareware; die Registrierung kostet 47 US-Dollar. Die nicht-registrierte Version arbeitet 60 Minuten; reicht das zum Ausprobieren nicht, muß man sie manuell neu starten.
Die Interfaces sucht es sich automatisch aus der Netzwerk- beziehungsweise DFÜ-Konfiguration heraus. Wer nur ein einzelnes IP-Subnetz ins Internet bringen will, ist nach der Auswahl der entsprechenden Optionen schon fertig - die Routen setzt NAT32 automatisch, auch für die Network Address Translation ist keine Konfiguration notwendig.
Soll ein Anwender direkt am Router arbeiten, so gehen eventuelle Anfragen nicht über NAT32 ins Internet. Dies stellt allerdings kein Manko dar: Über die Dial-up-Verbindung des DFÜ-Netzwerks (Win9x) oder RAS (NT) bekommt das DFÜ-Interface schließlich eine öffentliche Adresse vom Provider zugewiesen, so daß auf der Maschine mit NAT32 weder Routing noch Address Translation notwendig ist. Die Clients im LAN bekommen wie bei RRAS auch die Adresse der NAT32-Maschine als Default-Gateway mitgeteilt - fertig.
NAT32 kann zudem noch einiges mehr. Unter anderem enthält es einen vollwertigen Telnet-Daemon für Windows, mit dem sich sogar kleinere Chats zwischen einem Anwender auf einem Client und auf dem Router realisieren lassen. Das Programm selbst sieht recht spartanisch aus - ruft man es auf, erhält man ein kleines Fenster, das erst einmal den Status der konfigurierten Schnittstellen ausgibt, während der eigentliche Router im Hintergrund seine Arbeit verrichtet.
In dem NAT32-Fenster steht ein Kommando-Prompt zur Verfügung, das eine Vielzahl von Befehlen zuläßt, die der Konfiguration oder Informationsanzeige dienen. Die Befehle realisieren einiges unter Windows, was ein Unix-Administrator an Kommandos zur Konfiguration und Fehleranalyse im Netzwerk gewohnt ist, unter den Microsoft-Systemen aber bislang schmerzlich vermißt hat.
Nicht nur für Heimanwender und kleinere Netze dürfte NAT eine prima Alternative zu RRAS sein, schaut man sich die doch recht hohen Einstiegskosten für den dafür notwendigen NT-Server an. Ob man NAT32 aber unbedingt auf einer Windows-9x-Maschine einsetzen sollte, ist eine andere Frage - für einen Router, von dem unter Umständen das Funktionieren des lokalen Netzes abhängt, erscheinen uns die kleinen Windows-Systeme doch weniger geeignet. (jk)
[2] Routing und Network Address Translation für Windows 95, 98 und NT: http://www.nat32.com
[3] Jürgen Kuri, Wenn der Postmann zweimal klingelt, Namen und Adressen im TCP/IP-Netzwerk und im Internet, c't 12/96, S. 334
[4] Jürgen Kuri, Da geht´s lang!, Routing, oder: wie die Daten im Internet ihren Weg finden, c't 6/97, S. 380
[5] Jürgen Kuri, Gruppenreise ins Internet, Gemeinsamer Internet-Zugang durch das LAN, c't 17/98, S. 118
[6] Jürgen Kuri, Oliver Diedrich, Reiseleiter, Linux vermittelt den Internet-Zugang fürs LAN, c't 21/98, S. 288
[7] Jürgen Kuri, Wechselspiel, Internet-Zugang fürs LAN mit dem Proxy-Server Sambar, c't 5/99, S. 264
Die 32 Bit große IP-Adresse (dargestellt in vier Oktetten) ist in zwei Teile zerlegt, die netid (Adresse des logischen Netzwerks) und die hostid (Adresse des Hosts innerhalb des logischen Netzwerks). Die einzelnen Klassen von Adressen unterscheiden sich in der Anzahl der Oktette, die auf netid und hostid entfallen. Die Zuordnung einer Adresse zu einer bestimmten Klasse erfolgt über den Anfang einer IP-Adresse. Abhängig von dem dort angegebenen Wert wird eine bestimmte Anzahl der folgenden Bits als netid, der verbleibende Rest als hostid gewertet. Dieselbe Aussage ist auch über die Subnetzmaske möglich: Die Bits einer IP-Adresse, die zur netid gehören, kennzeichnet die Subnetzmaske entsprechend mit dem Wert 1, die zur hostid gehörenden Bits mit dem Wert 0.
Class A: Anfangsbitfolge 0, Bitanzahl netid 7, Bitanzahl hostid 24, Subnetzmaske 255.0.0.0, IP-Adreßbereich 1.0.0.0 bis 126.255.255.255, reservierte Adressen für private LANs 10.0.0.0 bis 10.255.255.255 (eine vollständige Class-A-Adresse), die IP-Adresse 127.x.x.x ist reserviert für das Loopback-Interface.
Class B: Anfangsbitfolge 10, Bitanzahl netid 14, Bitanzahl hostid 16, Subnetzmaske 255.255.0.0, IP-Adreßbereich 128.0.0.0 bis 191.255.255.255, reservierte Adressen für private LANs 172.16.0.0 bis 172.31.255.255 (16 fortlaufende Class-B-Adressen).
Class C: Anfangsbitfolge 11, Bitanzahl netid 22, Bitanzahl hostid 8, Subnetzmaske 255.255.255.0, IP-Adreßbereich 192.0.0.0 bis 223.255.255.255, reservierte IP-Adressen für private LANs 192.168.0.0 bis 192.168.255.255 (256 fortlaufende Class-C-Adressen).
In jeder Netzklasse sind, wie bei den einzelnen Netzklassen angegeben, bestimmte Bereiche für den Gebrauch in privaten Netzen bestimmt - sie werden vom Network Information Center (NIC) nicht für die Verwendung in öffentlichen Netzen vergeben. Setzt man sie in einem LAN ein, muß eigentlich sichergestellt sein, daß die betreffenden Systeme vom Internet abgeschottet sind - in der Regel transportieren öffentliche Netze Datenpakete mit solchen Adressen allerdings sowieso nicht weiter. Adressen, die über 223.255.255.255 liegen, sind für die Klassen D (Multicast) und E (momentan nicht benutzt) reserviert.
Mit Hilfe sogenannter Subnetzmasken (subnet masks) kann man die hostid zur Bildung feinerer organisatorischer Einheiten nochmals unterteilen. Eine solche Maske besteht ebenfalls aus 32 Bit und wird wie eine IP-Adresse dezimal in vier durch Punkte getrennte Oktette geschrieben.
Bei einer Class-B-Adresse entfallen die ersten 16 Bit auf die netid, die verbleibenden 16 Bit auf die hostid. In einem logischen Netz dieses Adreßtyps lassen sich demnach 65 536 Hosts adressieren. Mit Hilfe einer Subnetzmaske kann man nun innerhalb dieses Netzes weitere logische Netze bilden. Die Subnetz-Maske 255.255.255.0 (abweichend zur normalen Subnetzmaske eines Class-B-Netzes von 255.255.0.0) beispielsweise sagt bei einem solchen Class-B-Netz aus, daß lediglich das letzte Oktett der Adresse tatsächlich auf die hostid entfällt. Das dritte Oktett läßt sich nun zur Erweiterung der netid verwenden. Die Hosts mit den Adressen 128.10.1.1 und 128.10.2.1 können sich dann nicht mehr direkt miteinander unterhalten. Denn es handelt sich durch die geänderte Subnetzmaske nicht mehr um die Hosts 1.1 beziehungsweise 2.1 im logischen Netz 128.10, sondern jeweils um Host 1, einmal im Netz 128.10.1, im anderen Fall im Netz 128.10.2.