Von Microsoft Windows 2000 TCP/IP unterstützte Internet RFCs
Bei RFCs (Requests for Comments) handelt es sich um eine Reihe von Berichten, Protokollvorschlägen und Protokollstandards, die einem ständigen Wandel unterliegen und von der Internetgemeinde verwendet werden. Per FTP können Sie RFCs unter einer der folgenden Adressen erhalten:
nis.nsf.net
nisc.jvnc.net
wuarchive.wustl.edu
src.doc.ic.ac.uk
normos.org
Tabelle 2 Die von dieser Version von Microsoft TCP/IP unterstützten RFCs
RFC
|
Titel
|
768
|
User Datagram Protocol (UDP)
|
783
|
Trivial File Transfer Protocol (TFTP)
|
791
|
Internet Protocol (IP)
|
792
|
Internet Control Message Protocol (ICMP)
|
793
|
Transmission Control Protocol (TCP)
|
816
|
Fehlereingrenzung und -behebung
|
826
|
Address Resolution Protocol (ARP)
|
854
|
Telnet-Protokoll (TELNET)
|
862
|
Echo-Protokoll (ECHO)
|
863
|
Discard-Protokoll (DISCARD)
|
864
|
Zeichengenerator-Protokoll (CHARGEN)
|
865
|
Zitat des Tages-Protokoll (QUOTE)
|
867
|
Daytime-Protokoll (DAYTIME)
|
894
|
IP über Ethernet
|
919, 922
|
IP Broadcastdatagramme (Senden mit Subnetzen)
|
950
|
Internet Standard-Prozedur zur Verwendung von Subnetzen
|
959
|
File Transfer Protocol (FTP)
|
1001, 1002
|
NetBIOS Service-Protokolle
|
1065, 1035, 1123, 1886
|
Domain Name System (DNS)
|
1042
|
Ein Standard für die Übertragung von IP-Datagrammen über IEEE 802-Netzwerke
|
1055
|
Übertragung von IP über serielle Leitungen (IP-SLIP)
|
1112
|
Internet Group Management Protocol (IGMP)
|
1122, 1123
|
Hostanforderungen (Kommunikation und Anwendungen)
|
1144
|
Komprimierung von TCP/IP-Headern für serielle Verbindungen mit geringen Geschwindigkeiten
|
1157
|
Simple Network Management Protocol (SNMP)
|
1179
|
Line Printer Daemon-Protokoll
|
1188
|
IP über FDDI
|
1191
|
Identifizierung der maximalen Übertragungseinheit des Pfades
|
1201
|
IP über ARCNET
|
RFC
|
Titel
|
1256
|
ICMP-Routersuche-Meldungen
|
1323
|
TCP-Erweiterungen für Hochleistung (siehe Registrierungsparameter TCP1323opts)
|
1332
|
PPP Internet Protocol Control Protocol (IPCP)
|
1518
|
Architektur für Zuteilung von IP-Adressen mit CIDR
|
1519
|
CIDR (Classless Inter-Domain Routing): Eine Strategie für die Zuweisung und Aggregation von Adressen
|
1534
|
Interoperation zwischen DHCP und BOOTP
|
1542
|
Erläuterungen und Erweiterungen zum Bootstrap-Protokoll
|
1552
|
PPP Internetwork Packet Exchange Control-Protokoll (IPXCP)
|
1661
|
Das Point-to-Point-Protokoll (PPP)
|
1662
|
PPP in HDLC-ähnlichem Framing
|
1748
|
IEEE 802.5 MIB mit SMIv2
|
1749
|
IEEE 802.5 Stationsquellrouting MIB mit SMIv2
|
1812
|
Voraussetzungen für IP-Router, Version 4
|
1828
|
IP-Authentifizierung mit Keyed MD5
|
1829
|
ESP DES-CBC-Transformation
|
1851
|
ESP Dreifach-DES-CBC-Transformation
|
1852
|
IP-Authentifizierung mit Keyed SHA
|
1886
|
DNS-Erweiterungen zur Unterstützung von IP-Version 6
|
1994
|
PPP Challenge Handshake Authentication-Protokoll (CHAP)
|
1995
|
Inkrementeller Zonentransfer in DNS
|
1996
|
Ein Mechanismus für die prompte DNS-Benachrichtigung über Veränderungen der Zonen
|
2018
|
TCP-Optionen für Selective Acknowledgments
|
2085
|
HMAC-MD5 IP-Authentifizierung mit Wiedergabeschutz
|
2104
|
HMAC: Keyed Hashing zur Meldungsauthentifizierung
|
2131
|
Dynamic Host Configuration-Protokoll
|
2136
|
Dynamische Aktualisierungen im Domain Name System (DNS UPDATE)
|
2181
|
Erläuterungen zur DNS-Spezifikation
|
2205
|
Resource ReSerVation Protocol (RSVP) – Version 1 Funktionale Spezifikation
|
2236
|
Internet Group Management-Protokoll, Version 2
|
2308
|
Negativer Cache für DNS-Abfragen (DNS NCACHE)
|
2401
|
Sicherheitsarchitektur für das Internetprotokoll
|
2401
|
Sicherheitsarchitektur für das Internetprotokoll
|
2402
|
IP-Authentifizierungsheader
|
2406
|
IP Encapsulating Security Payload (ESP)
|
2581
|
TCP-Überlastungssteuerung
|
Architekturmodell
Überblick
Die Microsoft TCP/IP-Produktfamilie enthält die eigentlichen Protokollelemente, Dienste und die Schnittstellen zwischen diesen. Die TDI (Transport Driver Interface) und die NDIS (Network Device Interface Specification) sind öffentlich und ihre Spezifikationen bei Microsoft erhältlich unter:1 http://www.microsoft.com (englischsprachig) und ftp://ftp.microsoft.com (englischsprachig). Darüber hinaus gibt es eine Reihe von höheren Schnittstellen, die für Benutzermodusanwendungen zur Verfügung stehen. Die gängigsten sind Windows Sockets, RPC (Remote Procedure Calls) und NetBIOS.
Abb. 1 Das Windows 2000 TCP/IP-Netzwerkmodell
Plug & Play
In Windows 2000 wird Plug & Play eingeführt. Plug & Play bietet die folgenden Möglichkeiten und Funktionen:
Automatische und dynamische Erkennung von installierter Hardware. Dies umfasst die ursprüngliche Systeminstallation, Erkennung statischer Hardwareveränderungen, die zwischen zwei Bootvorgängen eintreten können, und Reaktion auf Laufzeit-Hardwareereignisse, wie z. B. Andocken und Abdocken und das Einstecken oder Entfernen von Karten.
Optimale Hardwarekonfiguration als Ergebnis der automatischen und dynamischen Erkennung von Hardware, einschließlich dynamischer Hardwareaktivierung, Vermittlung bei Ressourcen, Laden der Gerätetreiber, Laufwerkbereitstellung usw.
Unterstützung bestimmter Busse und sonstiger Hardwarestandards, die die automatische und dynamische Erkennung von Hardware und eine optimale Hardwarekonfiguration ermöglichen, einschließlich Plug & Play ISA, PCI, PCMCIA, PC-Karte/Kartenbus, USB und 1394. Dazu gehört auch die Weitergabe von Standards und Beratung zur Funktionsweise von Standards.
Ein geordneter Plug & Play-Rahmen, in dem Autoren von Treibern operieren können. Dies umfasst die Infrastruktur, wie Geräteinformation (INF)-Schnittstellen, APIs, Kernelmodusmeldungen, exekutive Schnittstellen usw.
Mechanismen, die es Code und Anwendungen, die im Benutzermodus ausgeführt werden, ermöglichen, Änderungen an der Hardwareumgebung zu erkennen, so dass die entsprechenden Maßnahmen ergriffen werden können.
Ein Plug & Play-Vorgang erfordert keine Plug & Play-Hardware. Soweit möglich, beziehen sich die ersten beiden Punkte der Aufzählung oben auf ältere Hardware und auch auf Plug & Play-Hardware. In einigen Fällen ist eine richtige Aufzählung der älteren Geräte nicht möglich, da die Erkennungsmethoden destruktiv oder unangemessen zeitaufwändig sind.
Die Hauptauswirkung der Unterstützung von Plug & Play auf Protokollstapel besteht darin, dass Netzwerkschnittstellen jederzeit hinzukommen und wegfallen können. Der Windows 2000 TCP/IP-Stapel und die zugehörigen Komponenten wurden für die Unterstützung von Plug & Play angepasst.
Die NDIS-Schnittstelle und darunter
Die Networking-Protokolle von Microsoft verwenden die Network Device Interface Specification (NDIS), um mit den Netzwerkkartentreibern zu kommunizieren. Der größte Teil der Verbindungsschichtfunktionalität des OSI-Modells wurde in dem Protokollstapel implementiert. Das vereinfacht die Entwicklung der Netzwerkkartentreiber erheblich.
Spezifikation der Network Driver Interface (3.1 bis 5.0)
NDIS 3.1 unterstützt Basisdienste, die einem Protokollmodul das Senden von Rohdatenpaketen über ein Netzwerkgerät ermöglichen und demselben Modul ermöglichen, dass es über eingehende Pakete informiert wird, die von einem Netzwerkgerät empfangen werden.
NDIS 4.0 ergänzte NDIS 3.1 um die folgenden Funktionen:
Unterstützung von Out-of-Band-Daten (erforderlich für Broadcast-PC)
WirelessWAN Media Extension
Versenden und Empfangen von Paketen in Hochgeschwindigkeit (ein wesentlicher Leistungsgewinn)
Fast IrDA Media-Erweiterung
Media Sense (erforderlich für das Logo "Designed for Windows" in den Hardware Design Guides PC 97 und folgende). Der Microsoft Windows 2000 TCP/IP-Stapel verwendet Media Sense-Informationen. Eine Beschreibung hierzu finden Sie im Abschnitt "Automatische Clientkonfiguration" in diesem Whitepaper.
Filter für rein lokale Pakete (verhindert, dass Netzwerkmonitor die CPU auslastet).
Zahlreiche neue NIDS-Systemfunktionen (erforderlich für binäre Miniportkompatibilität bei Windows 95, Windows 98, Windows NT und Windows 2000).
NDIS 5.0 enthält die gesamte in NDIS 4.0 definierte Funktionalität mit den folgenden Erweiterungen:
NDIS-Energieverwaltung (erforderlich für die Netzwerk-Energieverwaltung und das Netzwerk-Wakeup)
Plug&Play (Windows 95 NDIS unterstützte bereits Plug & Play. Daher bezieht sich diese Veränderung nur auf Netzwerktreiber für Windows 2000.)
Unterstützung der Windows-Verwaltungsinstrumentation, welche die WBEM (Webbasiertes Enterprise Management)-kompatible Instrumentation von NDIS Miniports und ihren entsprechenden Adaptern bereitstellt.
Unterstützung für ein einheitliches INF-Format für alle Windows-Betriebssysteme. Das neue INF-Format basiert auf dem Windows 98 INF-Format.
Nicht serieller Miniport für mehr Leistung
Taskablademechanismen, wie TCP- und UDP-Prüfsumme und schnelle Paketweiterleitung
Broadcast Media-Erweiterung (wird benötigt für Broadcast Services für Windows)
Verbindungsorientiertes NDIS (erforderlich zur Unterstützung von ATM (Asynchronous Transfer Mode) , ADSL (Asymmetric Digital Subscriber Line) und der Verbindungsstreamingarchitektur des Windows-Treibermodells (Windows Driver Model–Connection Streaming Architecture, WDM-CSA)
Unterstützung von QoS
Fortgeschrittene Treiberunterstützung (erforderlich für Broadcast PC, Virtuelle LANs, Paketplanung für QoS und NDIS-Unterstützung der IEEE 1394-Netzwerkgeräte)
NDIS kann Netzwerkadapter herunterschalten (power down), wenn das System ein anderes Energieniveau anfordert. Diese Anforderung kann entweder vom System oder vom Benutzer ausgehen. Wenn der Benutzer den Computer beispielsweise in den Schlafmodus schalten möchte oder das System aufgrund der Inaktivität von Tastatur oder Maus ein anderes Energieniveau verlangt. Zusätzlich kann das Herausziehen des Netzwerkkabels dazu führen, dass die Abschaltung angefordert wird, wenn die Netzwerk-Schnittstellenkarte (NIC) diese Funktionalität unterstützt. In diesem Fall wartet das System eine konfigurierbare Frist, bevor die NIC abgeschaltet wird, da das Trennen das Ergebnis einer vorübergehenden Änderung an der Netzwerkverkabelung sein könnte und nicht das Trennen eines Kabels vom Netzwerkgerät selbst bedeuten muss.
Die Richtlinie der NDIS-Energieverwaltung basiert auf fehlender Netzwerkaktivität. Das bedeutet, dass alle darüberliegenden Netzwerkkomponenten der Anforderung zustimmen müssen, bevor die NIC abgeschaltet werden kann. Falls im Netzwerk irgendwelche aktiven Sitzungen oder geöffneten Dateien vorhanden sind, kann die Abschaltanforderung von einer oder allen der betroffenen Komponenten abgelehnt werden.
Der Computer kann auch aus einem niedrigeren Energiezustand aufgrund von Netzwerkereignissen aktiviert werden. Ein Wakeup-Signal kann ausgelöst werden von:
Erkennung einer Veränderung im Status der Netzwerkverbindung (z. B. Kabel wird wieder angeschlossen)
Empfang eines Netzwerk-Wakeup-Rahmens
Empfang eines Magic-Pakets. (Weitere Information finden Sie unter http://www.microsoft.com [englischsprachig].)
Bei der Initialisierung von Treibern fragt NDIS die Funktionen des Miniports ab, um festzustellen, ob er solche Dinge wie Magic Packet, Mustervergleich, oder Wakeups bei Änderungen der Verbindung unterstützt, und um den niedrigsten erforderlichen Energiezustand für jede Wakeup-Methode herauszufinden. Die Netzwerkprotokolle fragen dann die Miniportfunktionen ab. Zur Laufzeit legt das Protokoll die Wakeup-Richtlinie fest und verwendet dafür Objektkennungen (object identifiers, OIDs) wie Enable Wakeup, Set Packet Pattern und Remove Packet Pattern.
Gegenwärtig ist Microsoft TCP/IP der einzige Microsoft-Protokollstapel, der die Netzwerk-Energieverwaltung unterstützt. Es registriert die folgenden Paketmuster bei der Initialisierung des Miniports:
Directed IP-Paket
ARP-Broadcast für die IP-Adresse der Station
NetBIOS über TCP/IP-Übertragung für den zugewiesenen Computernamen der Workstation
NDIS-kompatible Treiber werden für eine Vielzahl von NICs von verschiedenen Anbietern angeboten. Die NDIS-Schnittstelle ermöglicht, dass mehrere Protokolltreiber verschiedener Typen eine Verbindung zu einem einzigen NIC-Treiber herstellen sowie dass ein einziges Protokoll eine Verbindung zu mehreren NIC-Treibern herstellt. Die NDIS-Spezifikation beschreibt den Multiplexing-Mechanismus, der hierfür erforderlich ist. Bindungen können über den Ordner Windows Netzwerkverbindungen eingesehen oder verändert werden.
Windows 2000 TCP/IP unterstützt:
Ethernet (und 802.3 SNAP)
FDDI
Token Ring (802.5)
ATM (LANE und CLIP)
ARCnet
Dedizierte WAN-Verbindungen (Wide Area Netzwork), wie DDS (Dataphone Digital Service) und T-Träger (Fraktionales T1, T1 und T3)
WAN-Wählverbindungen oder vermittelte Verbindungen über Standleitungen, wie analoges Telefon, ISDN und xDSL
Paketvermittelte WAN-Dienste, wie X.25, Frame Relay und ATM
Zu den Zielen für diese neuen Funktionen gehören:
Zunehmende Benutzerfreundlichkeit und Senkung der Anschaffungs- und Folgekosten (Total Cost of Ownership, TCO)
Leistungssteigerung
Ermöglichen neuer Medientypen, Dienste und Anwendungen
Mehr Flexibilität bei der Treiberarchitektur
Funktionalität der Verbindungsschicht
Die Funktionalität der Verbindungsschicht verteilt sich auf die Kombination Netzwerk-Schnittstellenkarte/Treiber und den Protokollstapeltreiber niedriger Ebene. Die Filter für die Kombination Netzwerkkarte/Treiber beruhen auf der MAC-Adresse (Media Access Control) des Ziels jedes Rahmens.
Normalerweise filtert die Hardware alle eingehenden Rahmen mit Ausnahme solcher aus, die eine der folgenden Zieladressen enthalten:
Die Adresse des Adapters
Die Einer-Broacastadresse (FF-FF-FF-FF-FF-FF)
Multicastadressen, an denen ein Protokolltreiber auf diesem Host sein Interesse angemeldet hat, unter Verwendung einer NDIS-Grundfunktion.
Da diese erste Filterentscheidung von der Hardware getroffen wird, verwirft die NIC alle Rahmen, die diese Filterkriterien nicht erfüllen, ohne dass sie von der CPU verarbeitet werden. Alle Rahmen (einschließlich Broadcasts), die den Hardwarefilter passieren, werden dann durch einen Hardwareinterrupt an den NIC-Treiber weitergeleitet.2 Der NIC-Treiber ist Software, die auf dem Computer ausgeführt wird, so dass alle Rahmen, die bis hierher gelangen, während einer gewissen Dauer von der CPU verarbeitet werden müssen. Der NIC-Treiber bringt den Rahmen von der Schnittstellenkarte in den Systemspeicher. Der Rahmen wird dann dem (den) entsprechend gebundenen Transporttreiber(n) gemeldet (an ihn (sie) weitergeleitet). Die NDIS 5.0-Spezifikation enthält weitere Angaben zu diesem Prozess.
Rahmen werden an alle gebundenen Transporttreiber in der Reihenfolge weitergeleitet, in der sie gebunden werden.
Wenn ein Paket ein Netzwerk oder eine Reihe von Netzwerken durchquert, ist die Quell-MAC-Adresse immer die der NIC, die es auf den Medien abgelegt hat und die Ziel-MAC-Adresse ist die der NIC, die das Paket von den Medien ziehen soll. Das bedeutet, dass in einem gerouteten Netzwerk die Quell- und Ziel-MAC-Adresse sich mit jedem Abschnitt durch ein Netzwerkschichtgerät (Router oder Layer 3-Schalter) ändern.
Maximale Übertragungseinheit (Maximum Transmission Unit, MTU)
Für jeden Medientyp gilt eine maximale Rahmengröße, die nicht überschritten werden darf. Die Verbindungsschicht ist für das Feststellen dieser maximalen Übertragungseinheit zuständig und meldet diese an die übergeordneten Protokolle. Der Protokollstapel kann die lokale maximale Übertragungseinheit bei den NDIS-Treibern abfragen. Die Kenntnis der maximalen Übertragungseinheit für eine Schnittstelle wird von Protokollen der oberen Schichten, wie TCP, verwendet, die die Paketgrößen für jedes Medium automatisch optimieren. Weitere Informationen dazu finden Sie in den Erläuterungen zur Ermittlung der maximalen Übertragungseinheit des TCP-Pfades (Automatic Path Maximum Transmission Unit, PMTU) im Abschnitt "TCP (Transmission Control Protocol)" dieses Whitepapers.
Wenn ein NIC-Treiber - wie z. B. ein ATM-Treiber - den LAN-Emulationsmodus verwendet, kann er melden, dass er eine maximale Übertragungseinheit hat, die höher als die für diesen Medientyp erwartete ist. Beispielsweise kann er Ethernet emulieren, aber eine maximale Übertragungseinheit von 9180 Bytes melden. Windows NT und Windows 2000 akzeptieren und verwenden die von dem Adapter gemeldete maximale Übertragungseinheit, selbst wenn sie die normale maximale Übertragungseinheit für einen bestimmten Medientyp überschreitet.
Manchmal ist die an den Protokollstapel gemeldete maximale Übertragungseinheit niedriger, als für einen bestimmten Medientyp zu erwarten wäre. Beispielsweise verringert die Verwendung des Standards 802.1p für QoS über Ethernet oft (dies ist hardwareabhängig) die gemeldete maximale Übertragungseinheit um 4 Bytes aufgrund von größeren Verbindungsschichtheadern.
Kern-Protokollstapelkomponenten und die TDI-Schnittstelle
Die Kern-Protokollstapelkomponenten sind diejenigen, die in Abbildung 1 zwischen der NDIS- und TDI-Schnittstelle dargestellt werden. Sie sind in dem Windows 2000-Treiber Tcpip.sys implementiert. Der Microsoft-Stapel ist über die TDI-Schnittstelle und die NDIS-Schnittstelle zugänglich. Die Schnittstelle Winsock2 stellt auch gewisse Unterstützung für direkten Zugriff auf den Protokollstapel bereit.
ARP (Address Resolution Protocol)
ARP übernimmt die Auflösung der IP-Adresse in die MAC-Adresse (Media Access Control) für ausgehende Pakete. Da jedes ausgehende IP-Datagramm in einen Rahmen eingeschlossen ist, müssen die Quell- und Ziel-MAC-Adressen hinzugefügt werden. Das Feststellen der Ziel-MAC-Adresse für jeden Rahmen ist die Aufgabe des ARP.
ARP vergleicht die Ziel-IP-Adresse jedes ausgehenden IP-Datagramms mit dem ARP-Cache für die NIC, über die der Rahmen gesendet wird. Falls es einen übereinstimmenden Eintrag gibt, wird die MAC-Adresse aus dem Cache abgerufen. Andernfalls sendet ARP ein ARP-Anforderungspaket an das lokale Subnetz und bittet den Inhaber der betreffenden IP-Adresse um Antwort mit seiner MAC-Adresse. Wenn ein Paket durch einen Router geht, löst ARP die MAC-Adresse für den Router des nächsten Abschnitts auf, nicht für den Host des endgültigen Ziels. Wenn eine ARP-Antwort erhalten wird, wird der ARP-Cache mit diesen neuen Informationen aktualisiert, die für die Ansprache des Pakets in der Verbindungsschicht verwendet werden.
|
