TCP/IP-Grundlagen für Microsoft Windows
Kapitel 2 – Die Architektur des TCP/IP Protokollsatzes
Zusammenfassung Dieses Kapitel geht genauer auf die Einzelheiten der TCP/IP-Protokollfamilie (Transmission Control Protocol/Internet Protocol) ein und untersucht seine vier Schichten sowie die Kernprotokolle, die in diesen Schichten verwendet werden. Netzwerkadministratoren müssen die Kernprotokolle der verschiedenen Schichten und ihre Funktion verstehen, um nachvollziehen zu können, wie Netzwerkanwendungen arbeiten, wie Daten von einer Anwendung zu einer anderen gesendet werden und wie Sammlungen übertragener Daten zu interpretieren sind. In diesem Kapitel werden außerdem die beiden wichtigsten Anwendungsprogrammierschnittstellen (APIs) erläutert, auf die sich Netzwerkanwendungen für die Microsoft® Windows®-Betriebssysteme stützen, sowie das Benennungsschema der APIs. Auf dieser SeiteZiele dieses KapitelsNach der Lektüre dieses Kapitels werden Sie in der Lage sein, folgende Aufgaben auszuführen:
Die TCP/IP-ProtokollfamilieDie TCP/IP-Protokollfamilie entspricht dem als DARPA-Modell bekannten Vier-Schichten-Modell, dessen Name sich von der US-Regierungsbehörde herleitet, die TCP/IP ursprünglich entwickelt hat. Die vier Schichten des DARPA-Modells sind: Anwendungsschicht, Transportschicht, Internet-Schicht und Netzzugangsschicht. Jede Schicht des DARPA-Modells entspricht einer oder mehreren Schichten des siebenschichtigen OSI-Modells. Abbildung 2-1 zeigt die Architektur der TCP/IP-Protokollfamilie. Die TCP/IP-Protokollfamilie verfügt in der Internet-Schicht über zwei Protokollsätze:
Die NetzzugangsschichtDie Netzzugangsschicht (auch Netzwerkschnittstellenschicht genannt) sendet TCP/IP-Pakete in das Netzwerkmedium und empfängt TCP/IP-Pakete aus dem Netzwerkmedium. TCP/IP wurde so konzipiert, dass es unabhängig von der Netzwerkzugriffsmethode, dem Rahmenformat und dem Medium ist. Daher ermöglicht TCP/IP die Kommunikation zwischen Netzwerken unterschiedlichen Typs, wenn diese LAN-Technologien – etwa Ethernet und 802.11 Wireless-LAN – und WAN-Technologien – beispielsweise Frame-Relay und ATM (Asynchronous Transfer Mode) – verwenden. Dank dieser Unabhängigkeit von speziellen Netzwerktechnologien kann TCP/IP an neue Technologien angepasst werden. Die Netzzugangsschicht des DARPA-Modells umfasst die Sicherungs- und die Bitübertragungsschicht des OSI-Modells. Die Internet-Schicht des DARPA-Modells macht keinen Gebrauch von Sequenzierungs- und Bestätigungsdiensten, die möglicherweise in der Sicherungsschicht des OSI-Modells zur Verfügung stehen. Die Internet-Schicht geht vielmehr von einer unzuverlässigen Netzzugangsschicht aus und unterstellt, dass zuverlässige Kommunikation durch Sitzungseinrichtung sowie die Sequenzierung und Bestätigung von Paketen in der Verantwortung der Transport- oder der Anwendungsschicht liegen. Internet-SchichtDie Internet-Schicht ist verantwortlich für die Adressierung, die Sequenzierung und die Routingfunktionen. Die Internet-Schicht entspricht der Vermittlungsschicht des OSI-Modells. Die IPv4-Internet-Schicht verwendet folgende Kernprotokolle:
Weitere Informationen zu den Kernprotokollen der IPv4-Internet-Schicht finden Sie im Abschnitt "IPv4-Internet-Schicht" weiter hinten in diesem Kapitel. Die IPv6-Internet-Schicht verwendet folgende Kernprotokolle:
Weitere Informationen zu den Kernprotokollen der IPv6-Internet-Schicht finden Sie im Abschnitt "IPv6-Internet-Schicht" weiter hinten in diesem Kapitel. TransportschichtDie Transportschicht (auch Host-zu-Host-Transportschicht genannt) stellt Sitzungs- und Datagrammkommunikationsdienste für die Anwendungsschicht bereit. Die Transportschicht ist für dieselben Bereiche verantwortlich wie die OSI-Transportschicht. Die Kernprotokolle der Transportschicht sind TCP und UDP. TCP bietet einen verbindungsorientierten und verlässlichen 1:1-Kommunikationsdienst. TCP richtet Verbindungen ein, sequenziert und bestätigt die gesendeten Pakete und stellt die während der Übertragung verloren gegangenen Pakete wieder her. Im Unterschied zu TCP bietet UDP einen verbindungslosen, nicht verlässlichen 1:1- oder 1:n-Kommunikationsdienst. UDP wird dann verwendet, wenn nur geringe Mengen an Daten (die beispielsweise in ein Paket passen) zu übertragen sind, wenn ein Entwickler den mit TCP-Verbindungen verbundenen Aufwand vermeiden möchte oder wenn die Anwendungen bzw. die Protokolle der oberen Schichten eine verlässliche Zustellung garantieren. TCP und UDP sind sowohl mit IPv4- als auch IPv6-Internet-Schichten einsetzbar. Hinweis Die TCP/IP-Komponente von Windows enthält andere Versionen der TCP- und UDP-Protokolle als die Microsoft TCP/IP-Komponente der Version 6. Die Versionen der Microsoft TCP/IP-Komponente der Version 6 entsprechen funktional den mit dem Betriebssystem Microsoft Windows NT® 4.0 gelieferten Versionen und enthalten alle aktuellen Sicherheitsaktualisierungen. Die Existenz von zwei getrennten Protokollkomponenten mit jeweils eigenen Versionen von TCP und UDP wird Dual-Stack-Architektur genannt. Die ideale Architektur wird Dual-IP-Schicht genannt; dabei arbeiten die gleichen Versionen von TCP und UDP sowohl über IPv4 als auch über IPv6 (wie in Abbildung 2-1 gezeigt). Microsoft erwägt, für eine künftige Version der Windows-Betriebssysteme die Dual-IP-Schichtarchitektur für die TCP/IP-Protokollkomponenten zu verwenden. AnwendungsschichtDie Anwendungsschicht erlaubt Anwendungen, auf die Dienste der anderen Schichten zuzugreifen, und definiert die Protokolle, die Anwendungen zum Austausch von Daten verwenden. Die Anwendungsschicht enthält viele Protokolle, und es werden ständig weitere Protokolle entwickelt. Die bekanntesten Protokolle der Anwendungsschicht helfen Anwendern, Daten auszutauschen:
Zusätzlich helfen Ihnen folgende Protokolle der Anwendungsschicht, TCP/IP-Netzwerke zu verwenden und zu verwalten:
Windows Sockets und NetBIOS sind Beispiele von Schnittstellen der Anwendungsschicht für TCP/IP-Anwendungen. Weitere Informationen finden Sie weiter unten in diesem Kapitel unter "Anwendungsprogrammierschnittstellen". IPv4-Internet-SchichtDie IPv4-Internet-Schicht umfasst folgende Protokolle:
In den folgenden Abschnitten werden diese Protokolle detaillierter beschrieben. ARPWenn IP ein Paket in einem auf Broadcasts basierenden Netzwerk sendet, ermittelt das Protokoll ARP (Address Resolution Protocol) die MAC-Adresse (Media Access Control) der IP-Adresse des Knotens, an den das Paket weitergeleitet wird (ein solcher Knoten wird auch Folgeknoten oder Next-Hop genannt). Wie in RFC 826 definiert, verwendet ARP Broadcasts der MAC-Ebene, um den IPv4-Adressen des Folgeknotens die entsprechenden MAC-Adressen zuzuordnen. Basierend auf der IPv4-Zieladresse und der Routenfestlegung bestimmt IPv4 die IPv4-Adresse des Folgeknotens für die Weiterleitung des Pakets. IPv4 übergibt dann das IPv4-Paket, die IPv4-Adresse des Folgeknotens und dessen Schnittstelle an ARP. Entspricht die IPv4-Adresse des Folgeknotens für dieses Paket der IPv4-Adresse des Paketziels, liefert ARP das Paket direkt an das Ziel. Bei der direkten Lieferung muss ARP die IPv4-Zieladresse des Pakets in die entsprechende MAC-Adresse auflösen. Entspricht die IPv4-Adresse des Folgeknotens für dieses Paket nicht der IPv4-Zieladresse des Pakets, leitet ARP das Paket an einen Router weiter. Bei dieser indirekten Lieferung muss ARP die IPv4-Adresse des Routers in die entsprechende MAC-Adresse auflösen. Um die IPv4-Adresse des Folgeknotens eines Pakets in die entsprechende MAC-Adresse auflösen zu können, stützt sich ARP auf die Broadcast-Möglichkeiten von Netzwerken wie Ethernet oder 802.11 und sendet eine Broadcast-ARP-Anforderung aus. Daraufhin erhält der Sender eine ARP-Antwort mit der MAC-Adresse, die der IPv4-Adresse für den Folgeknoten des Pakets entspricht. ARP-CacheUm die Zahl der Broadcast-ARP-Anforderungen zu reduzieren, sehen viele Implementierungen des TCP/IP-Protokolls einen ARP-Cache vor, in dem in Form einer Tabelle die zuletzt aufgelösten IPv4-Adressen und die ihnen entsprechenden MAC-Adresse gespeichert werden. ARP überprüft diesen Cache, bevor eine ARP-Anforderung gesendet wird. Jede Schnittstelle hat ihren eigenen ARP-Cache. Abhängig von der Implementierung des Anbieters, kann der ARP-Cache folgende Eigenschaften aufweisen:
Auf einem Computer unter Windows können Sie sich den ARP-Cache ansehen, indem Sie an der Eingabeaufforderung arp -a eingeben. Mit dem Tool arp können Sie außerdem statische Einträge hinzufügen oder löschen. ARP-ArbeitsweiseWenn IPv4 als sendender Host oder als weitergebender Router ein Paket weiterleiten muss, dann sendet IPv4 dieses IPv4-Paket zusammen mit der IPv4-Adresse des Folgeknotens und der Schnittstelle des Folgeknotens an ARP. Unabhängig davon, ob eine direkte oder eine indirekte Zustellung erfolgt, führt ARP folgende Schritte durch:
Abbildung 2-2 zeigt diesen Vorgang. Internet-Protokoll Version 4 (IPv4)IPv4 ist ein Datagrammprotokoll und vor allem verantwortlich für die Adressierung und Weiterleitung von Paketen zwischen Hosts. IPv4 ist verbindungslos, was bedeutet, dass vor dem Datenaustausch keine Verbindung hergestellt wird, und es ist nicht verlässlich, was bedeutet, dass IPv4 die Zustellung der Pakete nicht garantiert. IPv4 versucht jedoch bei der Paketzustellung "sein Bestes". Ein IPv4-Paket kann verloren gehen, dupliziert werden, in der falschen Reihenfolge oder verzögert zugestellt werden. IPv4 versucht nicht, solche Fehler zu beheben. Ein Protokoll einer höheren Schicht, etwa TCP oder ein Anwendungsprotokoll, muss die zugestellten Pakete bestätigen und verlorene Pakete gegebenenfalls erneut anfordern. IPv4 ist im RFC 791 definiert. Ein IPv4-Paket besteht aus einem IPv4-Header und den IPv4-Nutzdaten. Die IPv4-Nutzdaten sind als Dateneinheit für ein Protokoll einer höheren Schicht organisiert, beispielsweise als TCP-Segment oder UDP-Nachricht. Abbildung 2-3 zeigt die Grundstruktur eines Pv4-Pakets. Tabelle 2-1 nennt und beschreibt die Schlüsselfelder im IPv4-Header.
Tabelle 2-1 Schlüsselfelder im IPv4-Header Fragmentierung und WiederzusammensetzungEmpfängt ein Router ein IPv4-Paket, das für das Netzwerksegment, an das es weitergeleitet werden soll, zu groß ist, dann zerteilt IPv4 auf dem Router das Paket in kleinere, für das Netzwerksegment, an das es weitergeleitet werden soll, passende Pakete. Wenn diese Pakete ihr Ziel erreichen, setzt IPv4 auf dem Zielhost die einzelnen Fragmente wieder zu dem ursprünglichen Datenpaket zusammen. Dieser Vorgang wird als Fragmentierung und Wiederzusammensetzung bezeichnet. Die Fragmentierung kann in Umgebungen erforderlich werden, in denen unterschiedliche Netzwerktechnologien eingesetzt werden, etwa Ethernet oder Token Ring. Fragmentierung und Wiederzusammensetzung funktioniert folgendermaßen:
Wenn der empfangende Host die Fragmente erhält, kann er anhand des ID-Feldes erkennen, welche Fragmente zusammengehören, und sie mithilfe des Fragmentoffsetfelds in der richtigen Reihenfolge wieder zu dem ursprünglichen IPv4-Nutzdatenpaket zusammensetzen. ICMP (Internet Control Message Protocol)Das im RFC 792 definierte ICMP meldet Fehler, wenn Pakete nicht zugestellt werden können, und hilft bei deren Beseitigung. Kann IPv4 zum Beispiel ein Paket nicht an den Zielhost liefern, dann sendet ICMP auf dem Router oder dem Zielhost an den sendenden Host die Nachricht, dass der Empfänger nicht erreicht werden konnte. Tabelle 2-2 nennt und beschreibt die am häufigsten vorkommenden ICMP-Nachrichten.
Tabelle 2-2 Häufig vorkommende ICMP-Nachrichten ICMP definiert eine Reihe von Nichterreichbarkeitsnachrichten. Tabelle 2-3 nennt und beschreibt die am häufigsten vorkommenden Nichterreichbarkeitsnachrichten.
Tabelle 2-3 Häufig vorkommende ICMP Nichterreichbarkeitsnachrichten ICMP macht aus IPv4 kein verlässliches Protokoll. ICMP versucht, Fehler zu melden und eine Reaktion auf bestimmte Bedingungen zu liefern. ICMP-Nachrichten werden als nichtbestätigte IPv4-Pakete weitergeleitet und sind selbst nicht zuverlässig. IGMP (Internet Group Management Protocol)Router und Hosts verwenden IGMP, um die Mitgliedschaften in IPv4-Multicastgruppen eines Subnetzes zu verwalten. Eine IPv4-Multicastgruppe, auch Hostgruppe genannt, besteht aus mehreren Hosts, die den an eine bestimmte IPv4-Multicastadresse gesendeten IPv4-Verkehr überwachen. Der IPv4-Multicastverkehr eines gegebenen Subnetzes wird an eine einzelne MAC-Adresse gesendet, jedoch von mehreren IPv4-Hosts empfangen und verarbeitet. Jedes Mitglied einer Hostgruppe erhält alle Pakete, die über eine bestimmte IPv4-Multicastadresse eintreffen. Damit ein Host IPv4-Multicastpakete erhält, muss eine Anwendung IPv4 darüber informieren, dass dieser Host solche Pakete von der angegebenen IPv4-Multicastadresse erhalten will. IPv4 informiert dann die Router der lokal angeschlossenen Subnetze, dass die an die angegebene IPv4-Multicastadresse gelieferten Multicastpakete empfangen werden sollen. IGMP ist das Protokoll, das Mitgliedsinformationen einer Hostgruppe registriert. IGMP-Nachrichten haben folgendes Format:
Damit IPv4-Multicasting in einem IPv4-Netzwerk routerübergreifend funktionieren kann, verwenden Router Multicastroutingprotokolle, um Informationen über Hostgruppen weiterzugeben. Jeder Router, der Multicastweiterleitung unterstützt, kann daraufhin entscheiden, wie er IPv4-Multicastverkehr weiterleitet. Windows Server 2003 und Windows XP unterstützen IGMP, IGMP Version 2 und IGMP Version 3, die in RFC 1112, RFC 2236 und RFC 3376 definiert sind. IPv6-Internet-SchichtIPv6 wird einmal die Protokolle der IPv6-Internet-Schicht des DARPA-Modells ersetzen. IPv6 ersetzt:
Softwareentwickler müssen die Protokolle der Transport- und der Anwendungsschicht nicht ändern, um deren Funktion mit einer IPv6-Internet-Schicht zu unterstützen, es sei denn, Adressen sind Teil der Nutzdaten oder Teil der Datenstrukturen, die von dem Protokoll verwaltet werden. So müssen Softwareentwickler beispielsweise sowohl TCP als auch UDP aktualisieren, damit eine neue Prüfsumme berechnet wird, und sie müssen RIP aktualisieren, damit auf IPv6 basierende Routeninformationen gesendet und empfangen werden können. Die IPv6-Internet-Schicht umfasst folgende Protokolle:
In den folgenden Abschnitten werden diese Protokolle eingehender erläutert. IPv6Wie IPv4 ist auch IPv6 ein verbindungsloses, nicht verlässliches Datagrammprotokoll, das vor allem verantwortlich ist für die Adressierung und Weiterleitung von Paketen zwischen Hosts. RFC 2460 definiert die IPv6-Paketstruktur. Ein IPv6-Paket besteht aus einem IPv6-Header und den IPv6-Nutzdaten. Die IPv6-Nutzdaten bestehen aus keinem oder mehreren IPv6-Erweiterungsheadern und einer Dateneinheit für ein Protokoll einer höheren Schicht, beispielsweise eine ICMPv6-Nachricht, ein TCP-Segment oder eine UDP-Nachricht. Abbildung 2-4 zeigt die Grundstruktur eines IPv6-Pakets. Tabelle 2-4 nennt und beschreibt die Schlüsselfelder im IPv6-Header.
Tabelle 2-4 Schlüsselfelder im IPv6-Header IPv6-ErweiterungsheaderIPv6-Nutzdaten können Null oder mehrere Erweiterungsheader unterschiedlicher Länge enthalten. Das Feld Nächster Header in einem IPv6-Header gibt den nächsten Erweiterungsheader an. Jeder Erweiterungsheader enthält wiederum das Feld Nächster Header, das den nächsten Erweiterungsheader angibt. Der letzte Erweiterungsheader gibt, wenn vorhanden, das Protokoll einer höheren Schicht an (etwa TCP, UDP oder ICMPv6), das die Dateneinheit für ein Protokoll einer höheren Schicht enthält. Der IPv6-Header und die Erweiterungsheader ersetzen den IPv4-Header und seine Fähigkeit, Optionen anzugeben. Das neue Format für Erweiterungsheader erlaubt es, IPv6 um die Unterstützung künftiger Anforderungen und Fähigkeiten zu ergänzen. Im Unterschied zu den Optionen im IPv4-Header kennen IPv6-Erweiterungsheader keine Größenbeschränkungen und können alle Erweiterungsdaten aufnehmen, die für die IPv6-Kommunikation benötigt werden. RFC 2460 definiert die folgenden IPv6-Erweiterungsheader, die alle IPv6-Knoten unterstützen müssen:
Typische IPv6-Pakete enthalten keine Erweiterungsheader. Sendende Hosts fügen einen oder mehrere Erweiterungsheader nur dann ein, wenn zwischengeschaltete Router oder der Zielknoten das Paket auf spezielle Weise behandeln müssen. Fragmentierung in IPv6Empfängt bei IPv4 ein Router ein Paket, das für das Netzwerksegment, an das es weitergeleitet werden soll, zu groß ist, dann zerteilt IPv4 auf dem Router das Paket in kleinere, für das Netzwerksegment, an das es weitergeleitet werden soll, passende Pakete. In IPv6 fragmentiert nur der sendende Host ein Paket. Ist ein IPv6-Paket zu groß, sendet der IPv6-Router die ICMPv6-Nachricht Zu großes Paket an den sendenden Host und verwirft das Paket. Ein sendender Host kann Pakete fragmentieren, die der Zielhost mithilfe des Fragmenterweiterungsheaders wieder zusammensetzen kann. ICMPv6 (Internet Control Message Protocol for IPv6)Wie IPv4 meldet auch IPv6 keine Fehler. Statt dessen verwendet IPv6 eine aktualisierte Version von ICMP für IPv4. Diese neue Version heißt ICMPv6 und erfüllt die von ICMP bekannten Funktionen für IPv4; sie meldet Fehler bei der Zustellung oder Weiterleitung von Daten und bietet einen einfachen Echodienst zur Problembehandlung. Das Protokoll ICMPv6 bietet außerdem eine Nachrichtenstruktur für ND- und MLD-Nachrichten. Tabelle 2-5 nennt und beschreibt die im RFC 2463 definierten ICMPv6-Nachrichten.
Tabelle 2-5 Häufig vorkommende ICMPv6-Nachrichten ICMPv6 definiert eine Reihe von Nichterreichbarkeitsnachrichten. Tabelle 2-6 nennt und beschreibt die am häufigsten vorkommenden Nichterreichbarkeitsnachrichten.
Tabelle 2-6 Häufig vorkommende ICMPv6-Nichterreichbarkeitsnachrichten ICMPv6 macht aus IPv6 kein zuverlässiges Protokoll. ICMPv6 versucht, Fehler zu melden und eine Reaktion auf bestimmte Bedingungen zu liefern. ICMPv6-Nachrichten werden als nichtbestätigte IPv6-Pakete weitergeleitet und sind selbst nicht verlässlich. ND (Neighbor Discovery)ND ist eine Folge von ICMPv6-Nachrichten und Prozessen, die die Beziehungen zwischen benachbarten Knoten festlegen. ND ersetzt ARP, die ICMPv4-Routersuche sowie die in IPv4 verwendete ICMP-Umleitung und stellt zusätzliche Funktionen bereit. Hosts verwenden ND für folgende Zwecke:
Router verwenden ND zu folgenden Zwecken:
Knoten (sowohl Hosts als auch Router) verwenden ND für folgende Zwecke:
Tabelle 2-7 nennt und beschreibt die im RFC 2461 beschriebenen ND-Prozesse.
Tabelle 2-7 Vorgänge zur Erkennung von Nachbarn Auflösung von AdressenDer Vorgang der Auflösung von IPv6-Adressen vollzieht sich durch Austausch von Nachbaraufforderungs- und Nachbaranwesenheitsnachrichten, um der IPv6-Folgeknotenadresse seiner korrespondierenden MAC-Adresse zuzuordnen. Der sendende Host schickt eine Nachbaraufforderung in Form einer Multicastnachricht an die passende Schnittstelle. Die Nachbaraufforderungsnachricht enthält die MAC-Adresse des sendenden Knotens. Wenn der Zielknoten die Nachbaraufforderungsnachricht erhält, aktualisiert er seinen Nachbarcache (der dem ARP-Cache entspricht) durch einen Eintrag mit der Quell- und der Mac-Adresse, die in der Nachbaraufforderungsnachricht enthalten sind. Dann sendet der Zielknoten eine Nachbaranwesenheitsnachricht in Form einer Multicastnachricht mit seiner MAC-Adresse an den Sender der Nachbaraufforderungsnachricht. Nach Empfang der Nachbaranwesenheitsnachricht vom Ziel aktualisiert der sendende Host seinen Nachbarcache durch einen Eintrag mit der in der Nachricht enthaltenen Mac-Adresse. Ab diesem Punkt können der sendende Host und das Ziel der Nachbaraufforderungsnachricht IPv6-Unicastdaten senden. Erkennung von RouternDie Erkennung von Routern ist der Vorgang, bei dem ein Host versucht, die Router eines lokalen Subnetzes zu ermitteln. Zusätzlich zur Konfiguration eines Standardrouters wird bei diesem Vorgang auch Folgendes konfiguriert:
Der Vorgang der IPv6-Routererkennung vollzieht sich folgendermaßen:
Automatische AdresskonfigurationEine äußerst vorteilhafte Eigenschaft von IPv6 ist seine Fähigkeit, sich mithilfe eines Adresskonfigurationsprotokolls wie DHCPv6 (Dynamic Host Configuration Protocol for IPv6) automatisch selbst zu konfigurieren. Standardmäßig kann ein IPv6-Host für jede Schnittstelle eine Adresse für die Verwendung im Subnetz konfigurieren. Mithilfe der Routererkennung kann ein Host außerdem die Adresse von Routern, zusätzliche Adressen und weitere Konfigurationsparameter ermitteln. Routeranwesenheitsnachrichten geben an, ob ein Adresskonfigurationsprotokoll verwendet werden sollte. RFC 2462 definiert die automatische Konfiguration von IPv6-Adressen. MLD (Multicast Listener Discovery)MLD ist das IPv6-Äquivalent von IGMP-Version 2 für IPv4. MLD ist ein Satz von zwischen Routern und Knoten ausgetauschten ICMPv6-Nachrichten, mit denen Router für jede angeschlossene Schnittstelle die IPv6-Multicastadressen ermitteln können, für die es verarbeitende Knoten gibt. Wie IGMPv2 ermittelt auch MLD nur die Multicastadressen, die wenigstens einen verarbeitenden Knoten haben, und nicht die Liste der Multicast verarbeitenden Knoten jeder Multicastadresse. RFC 2710 definiert MLD. Im Unterschied zu IGMPv2 verwendet MLD ICMPv6-Nachrichten statt eigene Nachrichten zu definieren. Die drei Typen von MLD-Nachrichten sind:
TCP (Transmission Control Protocol)TCP ist ein verlässlicher, verbindungsbasierter Kommunikationsdienst. Verbindungsbasiert bedeutet, dass eine Verbindung hergestellt werden muss, bevor Hosts Daten austauschen können. Verlässlichkeit wird ereicht, indem jedem übertragenen Segment eine Sequenznummer zugewiesen wird. Die beiden Knoten, die mittels TCP miteinander kommunizieren, bestätigen jeweils, dass sie Daten empfangen haben. Ein TCP-Segment ist die PDU (Protocol Data Unit), die aus einem TCP-Header und den TCP-Nutzdaten besteht, und auch einfach als Segment bezeichnet wird. Für jedes TCP-Segment, das Daten enthält, muss der empfangende Host eine Bestätigung (ACK, Acknowledgment) senden. Wird innerhalb des vorgegebenen Zeitraums keine Bestätigung empfangen, überträgt der sendende Host das TCP-Segment erneut. RFC 793 definiert TCP. Tabelle 2-8 nennt und beschreibt die Schlüsselfelder im TCP-Header.
Tabelle 2-8 Schlüsselfelder im TCP-Header TCP-Ports:Um TCP verwenden zu können, muss eine Anwendung die IP-Adresse und die TCP-Portnummer der Quell- und Zielanwendung bereit stellen. Ein Port stellt einen Ort für das Senden von Segmenten dar. Jeder Port wird durch eine eindeutige Nummer bezeichnet. TCP-Ports sind von UDP-Ports zu unterscheiden, auch wenn diese die gleiche Nummer verwenden. Portnummern unter 1024 sind sog. bekannte Nummern, die von der IANA (Assigned Numbers Authority) zugewiesen wurden. Tabelle 2-9 nennt einige dieser bekannten TCP-Ports.
Tabelle 2-9 Bekannte TCP-Ports Eine vollständige Liste der zugewiesenen TCP-Ports finden Sie unter http://www.iana.org/assignments/port-numbers (nur auf Englisch verfügbar). TCP-Drei-Wege-HandshakeEine TCP-Verbindung wird mittels Drei-Wege-Handshake initialisiert. Aufgabe des Drei-Wege-Handshake ist die Synchronisation der Sequenznummer und der Bestätigungsnummern auf beiden Seiten sowie die wechselseitige Bekanntgabe der TCP-Fenstergröße. Die folgenden Schritte beschreiben den Vorgang für die bekannte Situation, in der ein Clientcomputer einen Servercomputer kontaktiert.
TCP verwendet ein ähnliches Handshakeverfahren zur Beendigung der Verbindung. Dies garantiert, dass beide Seiten die Übertragung beendet haben und alle Daten empfangen wurden. UDP (User Datagram Protocol)UDP ist ein verbindungsloser Datagrammdienst, bei dem weder für die Zustellung der Datagramme noch für die korrekte Reihenfolge der gelieferten Pakete garantiert wird. UDP überträgt verloren gegangene Daten nicht ein weiteres Mal. Ein UDP-Paket besteht aus einem UDP-Header sowie den UDP-Nutzdaten und wird auch als Nachricht bezeichnet. RFC 768 definiert UDP. Anwendungen verwenden UDP, wenn sie keine Empfangsbestätigung der Daten brauchen und in der Regel jeweils nur kleine Datenmengen übertragen müssen. NetBIOS-Namensdienst, NetBIOS-Datagrammdienst und SNMP sind Beispiele für Dienste und Anwendungen, die UDP verwenden. Tabelle 2-10 nennt und beschreibt die Schlüsselfelder im UDP-Header.
Tabelle 2-10 Schlüsselfelder im UDP-Header UDP-PortsUm UDP verwenden zu können, muss eine Anwendung die IP-Adresse und die UDP-Portnummer der Quell- und Zielanwendung bereit stellen. Ein Port stellt einen Ort für das Senden von Nachrichten dar. Jeder Port wird durch eine eindeutige Nummer bezeichnet. UDP-Ports sind von TCP-Ports zu unterscheiden, auch wenn diese die gleiche Nummer verwenden. Wie bei TCP-Ports sind auch UDP-Portnummern unter 1024 bekannte Ports, die von der IANA zugewiesen wurden. Tabelle 2-11 nennt einige dieser bekannten UDP-Ports.
Tabelle 2-11 Bekannte UDP-Ports Eine vollständige Liste der zugewiesenen UDP-Ports finden Sie unter http://www.iana.org/assignments/port-numbers (nur auf Englisch verfügbar). Multiplexing und Demultiplexing von PaketenWenn ein Host ein IPv4- oder ein IPv6-Paket sendet, gibt er in diesem Paket auch Informationen weiter, mit deren Hilfe die im Paket enthaltenen Daten am Ziel der korrekten Anwendung übergeben werden können. Die Aufnahme von Bezeichnern, damit Daten an eine von mehreren Entitäten in den verschiedenen Schichten einer mehrschichtigen Architektur gesendet werden können, wird Multiplexing genannt. Die Multiplexinginformationen für IP-Pakete bezeichnen den Knoten des Netzwerks, das IP-Protokoll der höheren Schicht und für TCP und UDP den Port, der der Anwendung zugeordnet ist, für die die Daten bestimmt sind. Der Zielhost benutzt diese Bezeichner, um die Daten durch die einzelnen Schichten der richtigen Zielanwendung zu übergeben; dieser Vorgang wird Demultiplexing genannt. Das IP-Paket enthält außerdem Informationen, die für den Zielhost notwendig sind, um eine Antwort zu senden. IP enthält Multiplexinginformationen, um Folgendes zu erreichen:
TCP- und UDP-Ports können eine beliebige Nummer aus dem Bereich von 0 bis 65.535 verwenden. Portnummern für clientseitige Anwendungen werden in Regel auf eine entsprechende Anforderung hin dynamisch zugewiesen, während Portnummern für bekannte serverseitige Anwendungen von der IANA zugewiesen wurden. Die vollständige Liste bereits zugewiesener Portnummern finden Sie unter http://www.iana.org/assignments/port-numbers (nur auf Englisch verfügbar). All diese Daten stellen Multiplexinginformationen dar, mit denen erreicht wird, dass:
Wird ein Paket gesendet, werden diese Informationen auf folgende Weise verwendet:
Abbildung 2-5 zeigt als Beispiel eine DNS-Namensanforderung in einem IPv4-Paket mit der IP-Zieladresse 131.107.89.223, das dem DNS-Dienst übergeben wird (Demultiplexing). Anwendungsprogrammierschnittstellen (APIs)Windows-Netzwerkanwendungen verwenden zwei Anwendungsprogrammierschnittstellen (APIs), um unter Windows auf TCP/IP-Dienste zuzugreifen: Windows Sockets und NetBIOS. Abbildung 2-6 zeigt diese APIs und den möglichen Datenfluss bei ihrer Verwendung. Nachfolgend werden einige konzeptionelle Unterschiede zwischen der Windows Sockets-API und der NetBIOS-API aufgeführt:
Windows SocketsWindows Sockets ist eine allgemein verwendete, moderne API für Netzwerkanwendungen in Windows. Die zum Lieferumgang von Windows gehörigen TCP/IP-Dienste und Dienstprogramme sind Beispiele für Windows Sockets-Anwendungen. Windows Sockets stellt Dienste bereit, die es Anwendungen ermöglichen, bestimmte IP-Adressen und -Ports zu verwenden, Verbindungen zu einer bestimmten IP-Zieladresse und einem Zielport zu initialisieren und zu akzeptieren, Daten zu senden und zu empfangen und eine Verbindung zu schließen. Es gibt drei Typen von Sockets:
Ein Socket fungiert als Endpunkt für die Netzwerkkommunikation. Eine Anwendung erzeugt einen Stream- oder Datagrammsocket, indem sie drei Elemente angibt: die IP-Adresse des Hosts, der Typ des Dienstes (TCP für verbindungsorientierten und UDP für verbindungslosen Dienst) und den Port, den die Anwendung verwendet. Zwei Sockets, einen für jeden Endpunkt der Verbindung, bilden einen bidirektionalen Verbindungsweg. Für Low-Level-Sockets muss die Anwendung die gesamten IP-Nutzdaten angeben. NetBIOSNetBIOS ist eine ältere API, die Namensverwaltung sowie Datagramm- und Sitzungsdienste für NetBIOS-Anwendungen bietet. Eine Anwendung, die die NetBIOS-API für die Netzwerkkommunikation nutzt, kann mit jeder Protokollimplementierung laufen, die die NetBIOS-Schnittstelle unterstützt. Beispiele für Windows-Anwendungen und -Dienste, die NetBIOS verwenden, sind die gemeinsame Nutzung von Dateien und Druckern und der Computerbrowser-Dienst. NetBIOS definiert auch ein Protokoll, das in der OSI-Kommunikationsschicht funktioniert. Diese Schicht wird durch die darunter liegende Protokollimplementierung, etwa NetBIOS über TCP/IP (NetBT) implementiert; NetBT ist in den RFCs 1001 und 1002 definiert. Der NetBIOS-Namensdienst verwendet UDP-Port 137. Der NetBIOS-Datagrammdienst benutzt UDP-Port 138. Der NetBIOS-Sitzungsdienst verwendet TCP-Port 139. TCP/IP-Benennungsschemata in WindowsZwar arbeitet IP mit 32 Bit (IPv4) und 128 Bit (IPv6) langen Adressen für sendende und empfangende Hosts, doch können Computeranwender mit Namen besser als mit IP-Adressen umgehen und sich Namen auch einfacher merken. Wird ein Name als Alias für eine IP-Adresse verwendet, muss ein Mechanismus vorhanden sein, der IP-Adressen Namen zuweist, deren Eindeutigkeit sicherstellt und diese Namen wieder in den zugehörigen IP-Adressen zuordnet. Die TCP/IP-Komponenten von Windows verwenden jeweils eigene Mechanismen für die Zuweisung und Auflösung von Hostnamen (wie sie Windows Sockets-Anwendungen nutzen) und NetBIOS-Namen (wie sie NetBIOS-Anwendungen nutzen). HostnamenEin Hostname ist ein Alias, der einem IP-Knoten zugewiesen wurde, um ihn als TCP/IP-Host zu kennzeichnen. Der Hostname kann bis zu 255 Zeichen lang sein und Buchstaben und Ziffern sowie die Zeichen “-” und “.” enthalten. Einem Host können mehrere Hostnamen zugewiesen werden. Windows Sockets-Anwendungen, beispielsweise Internet Explorer und das Dienstprogramm Ping, können mit zwei Werten auf einen Zielhost verweisen: der IP-Adresse oder dem Hostnamen. Gibt der Anwender eine IP-Adresse an, wird keine Namensauflösung benötigt. Gibt der Anwender einen Hostnamen an, muss diesem Namen eine IP-Adresse zugeordnet werden, bevor die Kommunikation mit der Zielressource möglich ist. Hostnamen können verschiedene Formen annehmen. Die zwei gebräuchlichsten Formen sind der Spitzname und der voll qualifizierte Domänenname (Fully Qualified Domain Name, FQDN). Ein Spitzname ist ein Alias für eine IP-Adresse, den ein bestimmter Anwender zuweisen und benutzen kann. Ein FQDN ist ein strukturierter Name, beispielsweise www.microsoft.com, der den von DNS verwendeten Internet-Konventionen folgt. NetBIOS-NamenEin NetBIOS-Name ist ein 16 Byte langer Name, der eine NetBIOS-Anwendung im Netzwerk bezeichnet. Ein NetBIOS-Name ist entweder ein eindeutiger (exklusiver) Name oder ein (nicht exklusiver) Gruppename. Wenn eine NetBIOS-Anwendung mit einer bestimmten NetBIOS-Anwendung auf einem einzelnen Computer kommuniziert, werden eindeutige Namen verwendet. Wenn ein NetBIOS-Prozess mit mehreren NetBIOS-Anwendungen auf verschiedenen Computern kommuniziert, wird ein Gruppenname verwendet. Der NetBIOS-Name kennzeichnet Anwendungen in der Kommunikationsschicht des OSI-Modells. Der NetBIOS-Sitzungsdienst arbeitet beispielsweise über TCP-Port 139. Da alle NetBT-Sitzungsanforderungen an den TCP-Zielport 139 adressiert werden, müssen NetBIOS-Anwendungen den NetBIOS-Namen des Ziels verwenden, wenn sie eine NetBIOS-Sitzung einrichten. Ein Beispiel für die Verwendung eines NetBIOS-Namens ist die gemeinsame Nutzung von Dateien und Druckern auf einem Windows-Computer. Wenn Ihr Computer startet, registriert der Serverdienst einen eindeutigen NetBIOS-Namen, der von dem Namen Ihres Computers abgeleitet ist. Vom Serverdienst wird der 15 Zeichen lange Computername plus einem sechzehnten Zeichen mit dem Hexadezimalwert 0x20 verwendet. Ist der Computername kürzer als 15 Zeichen, wird er mit Leerzeichen auf die Länge von 15 Zeichen aufgefüllt. Andere Netzwerkdienste verwenden ebenfalls den Computernamen als Grundlage für ihre NetBIOS-Namen, wobei das sechzehnte Zeichen in der Regel dazu dient, den jeweiligen Dienst zu kennzeichnen. Wenn Sie unter Angabe des Computernamens eine Verbindung mit einem Computer mit Windows Server 2003 oder Windows XP zur gemeinsamen Nutzung von Dateien herstellen möchten, dann entspricht der Serverdienst des von Ihnen angegebenen Dateiservers einem bestimmten NetBIOS-Namen. Wenn Sie beispielsweise eine Verbindung zum Computer CORPSERVER herstellen, lautet der dem Serverdienst entsprechende NetBIOS-Name CORPSERVER <20>. (Beachten Sie, dass der Name mit Leerzeichen aufgefüllt wurde.) Bevor eine Verbindung zur gemeinsamen Nutzung von Dateien und Drucker hergestellt werden kann, muss eine TCP-Verbindung erzeugt werden. Damit eine TCP-Verbindung hergestellt werden kann, muss dem NetBIOS-Namen CORPSERVER <20> eine IPv4-Adress zugeordnet werden. Unter der NetBIOS-Namensauflösung versteht man den Vorgang der Zuordnung einer IPv4-Adresse zu einem NetBIOS-Namen. Zusammenfassung des KapitelsIn diesem Kapitel wurden folgende Schlüsselinformationen behandelt:
KapitelglossarAutomatische Adresskonfiguration – Der IPv6-ND-Vorgang der automatischen Konfiguration von IPv6-Adressen einer Schnittstelle. Adressauflösung – Der Vorgang, bei dem der IP-Folgeknotenadresse unter IPv4 mithilfe von ARP und unter IPv6 mithilfe von ND eine MAC-Adresse zugeordnet wird. Address Resolution Protocol (ARP) – Ein Protokoll, das mittels Broadcastnachrichten im lokalen Netzwerk einer IPv4-Adresse die zugehörige MAC-Adresse zuordnet. ARP – Siehe Address Resolution Protocol. ARP-Cache – Eine für jede Schnittstelle bestehende Tabelle mit dynamisch oder statisch aufgenommenen Einträgen mit IPv4-Adressen und den zugehörigen MAC-Adressen. ICMP – Siehe Internet Control Message Protocol. ICMPv6 – Internet Control Message Protocol für IPv6. IGMP – Siehe Internet Group Management Protocol. Internet Control Message Protocol (ICMP) – Ein Protokoll der IPv4-Internet-Schicht, das Fehler meldet und Möglichkeiten zur Fehlerbehandlung bietet. Internet Control Message Protocol für IPv6 (ICMPv6) – Ein Protokoll der IPv6-Internet-Schicht, das Fehler meldet, Möglichkeiten zur Fehlerbehandlung bietet und außerdem für ND- und MLD-Nachrichten verantwortlich ist. Internet Group Management Protocol (IGMP) – Ein Protokoll der IPv4-Internet-Schicht, das in einem Subnetz die Mitgliedschaft in Multicastgruppen verwaltet. Internet Protocol (IP) – Bei IPv4 ein routerfähiges Protokoll der IPv4-Internet-Schicht, das Pakete adressiert, verschickt, fragmentiert und wieder zusammenfügt. Wird auch als Oberbegriff zur Bezeichnung der IPv4- und IPv6-Protokollfamilie verwendet. IP – Siehe Internet Protocol. IPv4 – Die Internet-Schicht, die im Internet und in privaten Netzwerken breite Verwendung findet. Ein anderer Begriff für IP. IPv6 – Die neue Internet-Schicht, die einmal die vorhandene IPv4-Internet-Schicht ersetzen wird. MLD – Siehe Multicast Listener Discovery. Multicast Listener Discovery (MLD) – Ein Satz von drei ICMPv6-Nachrichten, die Hosts und Router verwenden, um in einem Subnetz die Mitgliedschaft in Multicastgruppen zu verwalten. Namensauflösung – Der Vorgang der Zuordnung eines Namens zu einer Adresse. ND – Siehe Neighbor Discovery. Nachbarcache – Ein für jeden IPv6-Knoten bestehender Cache, in dem die IPv6-Adresse eines Nachbarn und die ihr entsprechende MAC-Adresse gespeichert ist. Der Nachbarcache entspricht dem ARP-Cache von IPv4. Neighbor Discovery (ND, Nachbarerkennung) – ND ist eine Folge von ICMPv6-Nachrichten und Prozessen, die die Beziehungen zwischen benachbarten Knoten festlegen. ND ersetzt ARP, ICMP-Routererkennung und die ICMP-Umleitungsnachrichten von IPv4. Network Basic Input/Output System (NetBIOS) – Eine Standard-API für Anwendungen zur Verwaltung von NetBIOS-Namen und zum Zugriff auf NetBIOS-Datagramm- und Sitzungsdienste. NetBIOS – Siehe Network Basic Input/Output System. Routererkennung – Der Vorgang der Nachbarerkennung, bei dem ein Host die lokalen Router eines angeschlossenen Subnetzes ermittelt. TCP – Siehe Transmission Control Protocol. Transmission Control Protocol (TCP) – Ein verlässliches, verbindungsbasiertes Protokoll der Transportschicht, das über IP angesiedelt ist. UDP – Siehe User Datagram Protocol. User Datagram Protocol (UDP) – Ein verbindungsloses, nicht zuverlässiges Protokoll der Transportschicht, das oberhalb von IP angesiedelt ist. Windows Sockets – Eine allgemein verwendete Programmierschnittstelle (API), auf die sich Windows-Anwendungen stützen, um Daten mittels TCP/IP zu übertragen.
|
In diesem Beitrag
|
