Technische Grundlagen des Internets

Jedes Netzwerk braucht Gemeinsamkeiten. Die (einzige!) Gemeinsamkeit im Internet ist die Art der Datenübertragung, das so genannte Protokoll. Im Internet wird das so genannte TCP/IP (Transfer Control Protocol/Internet Protocol) verwendet.

Jeder Rechner auf der ganzen Welt braucht eine eindeutige Adresse, um im Internet erkannt zu werden, die so genannte IP-Adresse. (Diese Adresse wird vom Internet Protocol IP genutzt). In der derzeit gültigen Version 4 des Internet Protokolls ist die IP-Adresse eine 32-stellige Binärzahl, also etwa:

11011001.01010011.11001111.00010001

Meist fasst man 8 Binärstellen (bits) zu einem Byte zusammen, dessen Wert man berechnet. Die "Kurzschreibweise" der oben angeführten IP-Adresse würde daher zum Beispiel lauten:

217.83.207.17

Diese Adressen werden von der Internet Number Association (IANE) vergeben.

Man hat also mit einer solchen 32 bit-Adresse insgesamt 2³² = 4 294 967 296 Möglichkeiten (also mehr als 4 Milliarden), einen PC unverwechselbar zu adressieren. Man sollte meinen, dass diese große Anzahl für alle PCs der Welt ausreicht. Leider ist das nicht so!

Diese Adressen sind nämlich in zwei Teile geteilt:

Der erste Teil ist die Netzwerk-Adresse. Da das Internet aus vielen miteinander verbundenen lokalen Netzen (LAN) besteht, ist es sinnvoll, jedem LAN eine eindeutige Adresse zuzuweisen.

Der zweite Teil gibt die Adresse der einzelnen Rechner im Netz an (Host-Adresse). Dieser Teil wird durch das lokale Netzwerkmanagement frei vergeben.

Man hat nun verschiedene Größenklassen von Netzwerken festgelegt:

Class-A-Netze: Adresse beginnt mit einer binären 0, 7 bit für Netzwerk-Adresse, 24 bit für Host-Adresse. Damit gibt es weltweit 127 derartige Netzwerke, ein Class-A-Netz kann bis zu 16 Mio. Teilnehmer haben. Alle derartigen Netzadressen sind bereits belegt.

IP-Adressen von Class-A-Netzen:

0.0.0.0 bis 127.255.255.255

Class-B-Netze: Adresse beginnt mit der binären Ziffernkombination 10, 14 bit für Netzwerk-Adresse, 16 bit für Host-Adresse. Damit gibt es weltweit 16384 derartige Netzwerke, ein Class-B-Netz kann bis zu 65536 Teilnehmer haben. Alle derartigen Netzadressen sind bereits belegt.

IP-Adressen von Class-B-Netzen:

128.0.0.0 bis 191.255.255.255

Class-C-Netze: Adresse beginnt mit der binären Ziffernkombination 110, 21 bit für Netzwerk-Adresse, 8 bit für Host-Adresse. Damit gibt es weltweit 2 Mio. derartige Netzwerke, ein Class-C-Netz kann bis zu 256 Teilnehmer haben. Neu zugeteilte Netzadressen sind heute immer vom Typ C. Es ist abzusehen, dass bereits in Kürze alle derartigen Adressen vergeben sein werden. Man arbeitet daher an einem neuen Standard (Version 6 des Internet Protokolls, IPv6 oder IPng für „new generation“), der statt einer Adresslänge von 32 bit eine Länge von 128 bit haben soll. Um die Kompatibilität zu gewährleisten, wird die alte Adresse in der neuen Adresse "enthalten sein".

IP-Adressen von Class-C-Netzen:

192.0.0.0 bis 223.255.255.255

Class D-Netze haben einen speziellen Anwendungsbereich (Multicast-Anwendungen) und haben für Internet keine Bedeutung.

Laut RFC 1918 sind für „private“ Netze folgende IP-Bereiche gestattet (Rechner mit diesen IP-Adressen dürfen keinen direkten Internet-Verkehr haben, d.h. mit dem Internet nur über Proxy-Server in Kontakt treten; sie werden nicht geroutet!):

10.0.0.0 – 10.255.255.255

172.16.0.0 – 172.31.255.255

192.168.0.0 – 192.168.255.255

Für einen Anwender sind derartige Zahlenkombinationen schwer zu merken. Es werden daher statt dieser Zahlendarstellung symbolische Namen verwendet.

So gibt es etwa einen Server mit dem Namen

noe.wifi.at

Diesem Servernamen entspricht eine eindeutige IP-Adresse. Dabei setzt sich der Name aus Teilen zusammen, die eine Hierarchie angeben: Das Teilnetzwerk "noe" (fachchinesisch bezeichnet man ein solches Teilnetz als Domäne, englisch domain) ist ein Teil des Netzwerks "wifi", dieses wiederum ein Teil des Netzwerks "at" (für Österreich). Das "at"-Netzwerk ist ein Teil der Domäne "the world" (die aber nie angegeben zu werden braucht).

Die Länderkennung ist ein Beispiel für eine Top Level Domain (TLD); so werden die „Haupt-Domänen“ bezeichnet, die entweder einem Land oder einer „Kategorie“ entsprechen.

Die Zuordnung IP-Adressen zu logischen Namen muss von einem eigenen Rechner durchgeführt werden, dem Domain Name System-Server (DNS-Server). Wenn nun ein Anwender einen Server noe.wifi.at anwählt, so "fragt" die Station zunächst beim DNS-Server des Anwenders (der meist beim Provider steht), ob er die IP-Adresse von noe.wifi.at kennt. Das wird nicht der Fall sein. In diesem Fall hat der DNS-Server die IP-Adresse des nächstliegenden DNS-Servers gespeichert und fragt bei diesem an, ob er die IP-Adresse kennt. Das geht so lang, bis ein DNS-Server erfolgreich ist, die IP-Adresse wird übermittelt, die Datenübertragung kann beginnen.

Das Internet ist also ein so genanntes Teilstrecken-Netzwerk; es genügt, wenn jeder Internet-Knotenrechner mit einem weiteren Knoten verbunden ist. Die physikalische Datenübertragung wird über äußerst leistungsfähige Kabel, so genannte „Backbones“ realisiert.

Eine Karte, die die europäische Struktur der Backbones zeigt, findet man unter

www.ebone.net/structure/backbone.html.

Die zentrale Verwaltung der Domain-Namen mit den Top-Level-Domains .com, .net, .org und .int obliegt der InterNIC, einer Kooperation aus dem kommerziellen Unternehmen NSI (Network Solutions Inc.), der Telefongesellschaft AT&T sowie der US National Science Foundation. Bisher wurden die angegebenen Domains ausschließlich von der NSI im Auftrag der InterNIC verwaltet. Die jährliche „Miete“ eines Domännamens kostet ca. 50 US-$. Die Domain-Verwaltung soll jedoch bis 2001 von der NSI an die nichtkommerzielle Organisation ICANN (International Corporation for Assigned Names and Numbers) übergeben werden. Die Datenbank der NSI ist unter www.networksolutions.com/cgi-bin/whois/whois zu finden.

Die IANA (Internet Assigned Numbers Authority, www.iana.org) verwaltet die IP-Adressen.

Einen IP-Adressen-Index findet man unter ipindex.dragonstar.net.

Die ISPA (Internet Service Provider Association Austria – www.ispa.at) ist die Vereinigung der österreichischen Internet Service Provider, quasi eine „Dachorganisation“. Die NIC.AT GmbH, ein Unternehmen der ISPA, ist mit der Verwaltung und Vergabe der Domänennamen mit dem Top Level Domain „.at“ beauftragt (www.nic.at). Registrierungen und Online-Abfragen von at-Domainen sind unter www.namen.at möglich.

Dabei gibt es zum Beispiel als Länder-Top Level Domain (ISO-Norm 3166):

at . Austria (Österreich)

de Deutschland

jp Japan

us USA (fehlt meist)

Zusätzlich zu den landesspezifischen Erweiterungen gab es folgende Kennzeichnungen, die ursprünglich nur US-amerikanischen Einrichtungen vorbehalten waren:

com company (Firma)

gov government (Regierung) – US

edu education (Universitäten) – US

mil military (Militär) – US

int internationale Organisation

org organization (gemeinnützige Organisation)

net Provider

Nun werden die Adressen von 28 lizenzierten Firmen vergeben. Diese Firmen werden im CORE (Council of Registrars) zusammengefasst. Die neuen TLDs lauten:

firm Firmen und Unternehmen

arts Kunst und Kultur

info Informationsservices

rec Unterhaltung und Freizeit

web WWW-Aktivitäten

store Warenangebote

nom Restkategorie

MAC-Adresse = weltweit eindeutige Seriennummer, mit der jede Ethernet-Karte identifiziert wird

wird vom Hersteller fest eingebrannt

Unter TCP/IP besitzt jeder Rechner eine ARP (Address-Resolution-Protocol)-Tabelle, in der die Abbildung der IP-Adressen des lokalen Sub-Netzes auf die MAC-Adresse erfolgt.

Falls MAC-Adresse eines Rechners im Sub-Netz nicht bekannt, wird sie durch Rundfrage (broadcast) ermittelt. Rechner mit der gewünschten MAC-Adresse antwortet.

Besondere IP-Adressen

a) Netzwerkmasken

Netzwerkmasken unterscheiden sich in der Länge des Netzwerk- (alle Bit-Stellen auf 1) und Hostanteils (alle Bitstellen auf 0)

abhängig von der Netzwerkklasse

1.Byte 2.Byte 3.Byte 4.Byte

Class A 255 0 0 0

Class B 255 255 0 0

Class C 255 255 255 0

Netzwerkmasken stellen einen Filter dar, an dem Rechner entscheiden können, ob sie sich im selben (logischen) Netz befinden

b) Netzwerkadressen

die Netzwerkadresse eines Rechners ergibt sich, indem man die IP-Adresse mit der Netzwerkmaske bitweise UND-verknüpft

generell gilt, daß bei Netzwerkadressen alle Bitstellen des Hostanteils 0 sind

Beispiel

Class C 131 130 34 6 IP-Adresse

AND 255 255 255 0 Class C-Netzwerkmaske

= 131 130 34 0 Netzwerkadresse

nur Rechner mit der gleichen Netzwerkadresse befinden sich im gleichen logischen Netzwerk

c) Broadcast-Adresse

Die Broadcast-Adresse ergibt sich aus der IP-Adresse, bei der alle Bitstellen des Hostanteils auf 1 gesetzt sind. Sie bietet die Möglichkeit, Datenpakete an alle Rechner eines logischen Netzwerkes zu senden. Sie wird ermittelt, indem die Netzwerkadresse mit der invertierten Netzwerkmaske bitweise ODER-verknüpft wird.

Beispiel

Class C 255 255 255 0 Class C-Netzwerkmaske

0 0 0 255 invertierte Netzwerkmaske

OR 131 130 34 0 Class C-Netzwerkadresse

= 131 130 34 255

d) Loopback-Adresse

Die Class-A-Netzwerkadresse 127 ist weltweit reserviert für das sogenannte local loopback

dient zu Testzwecken der Netzwerkschnittstelle des eigenen Rechners.

Die IP-Adresse 127.0.0.1 ist standardmäßig dem Loopback-Interface jedes Rechners zugeordnet

alle an diese Adresse geschickten Datenpakete werden nicht nach außen ins Netzwerk gesendet, sondern an der Netzwerkschnittstelle reflektiert.

Die Datenpakete erscheinen, als kämen sie aus einem angeschlossenem Netzwerk

Rechenbeispiele zum Subnetting (Quelle: http://www.zyxel.de/support):

Auf der Hardwareseite wird die gesamte Kommunikation immer über die MAC Adresse abgewickelt. Diese Methode ist zwar recht schnell, jedoch lassen sich so nur schwer logische Zusammenschlüsse von einzelnen Computern bilden.

Beispiel:

Ein Unternehmen besteht aus drei Abteilungen mit jeweils fünf Computern. Daher ergeben sich 15 MAC Adressen unternehmensweit. Nun ist es in dieser Größenordnung kein Problem, eine Liste mit allen MAC Adressen und deren Standorten zu führen.

Was aber, wenn eine Nachricht nur an die Rechner der Abteilung Buchhaltung geschickt werden soll? Diese Nachricht müsste nun an jeden einzelnen Computer der betreffenden Abteilung einzeln geschickt werden.

Nun stellt man sich diese Aufgabe in einem Unternehmen mit zig hundert Computern vor !!

Aus diesem Grund musste zusätzlich zur realen Adressierung eine Methode entwickelt werden, um Computer in logische Gruppen organisieren zu können. Dies wird mit TCP/IP realisiert.

Den Aufbau eine TCP/IP Adresse kann man sich ungefähr wie eine Postanschrift vorstellen:

Land -> Ort -> Strasse -> Gebäude -> Familie -> Person

Die derzeitige Schreibweise bei IP-Adressen wird „Dotted Decimal" genannt. In dieser Form besteht eine Adresse aus zwei Zahlenblöcken mit jeweils vier Gruppen. Der erste Block ist die eigentliche Adresse, der zweite die Subnetzmaske.

Beispiel:

Adresse
192.168.100.1

Subnetzmaske
255.255.255.0

Um TCP/IP Adressen verstehen zu können, muß man sich vor Augen halten, daß die „reale" Schreibweise von Adressen in binärer Form erfolgt (4 Oktetts a 8 Bit).

192
11000000

168
10101000

100
01100100

1
00000001

Gerechnet wird dann wie folgt:

	128	64	32	16	8	4	2	1
192	1	1	0	0	0	0	0	0
168	1	0	1	0	1	0	0	0
100	0	1	1	0	0	1	0	0
1	0	0	0	0	0	0	0	1
	x	x	x	x	x	x	x	x
255	1	1	1	1	1	1	1	1

192	=	11000000	=	128	+	64
168	=	10101000	=	128	+	32	+	8
100	=	01100100	=	64	+	32	+	4
1	=	00000001	=	1

Daraus ergibt sich auch der Maximalwert von 255

255 = 11111111 = 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1

Gleiches gilt auch für die Subnetzmaske:

255
11111111

0
00000000

Erst durch die Subnetzmaske ist eine Zusammenfassung von TCP/IP Adressen in logische Gruppen möglich. Dazu muß man wissen, daß es in jeder Gruppe (Subnetz) zwei spezielle Adressen gibt:

Subnetzadresse (die erste Adresse eines Subnetzes)
Diese Adresse ist die Oberadresse für das gesamte Subnetz

Broadcast (die letzte Adresse eines Subnetzes)
Unter dieser Adresse werden Rundmeldungen an alle ausgetauscht

Um nun die Berechnung von Subnetzen zu verstehen, sehen wir uns das obige Beispiel auf der binären Ebene an:

Gegebene Hostadresse: 192.168.100.1 /24

Berechnung der Subnetzadresse:

Die Hostadresse wird mit der Subnetzmaske logisch UND verknüpft:

Hostadresse	192.168.100.1	11000000	10101000	01100100	00000001
UND
Maske	255.255.255.0	11111111	11111111	11111111	00000000
Subnetz	192.168.100.0	11000000	10101000	01100100	00000000

Berechnung der Broadcastadresse:

Die Subnetzadresse wird mit der invertierten Subnetzmaske logisch ODER verknüpft:

Subnetz	192.168.100.0	11000000	10101000	01100100	00000000
ODER
Maske	0.0.0.255	00000000	00000000	00000000	11111111
Broadcast	192.168.100.255	11000000	10101000	01100100	11111111

Daraus ergibt sich:

Subnetzadresse:	192.168.100.0
Broadcast:	192.168.100.255
Adressbereich:	192.168.100.1 bis 192.168.100.254

Hier gibt es nur ein Subnetz. Im folgenden Beispiel sind es schon zwei:

Gegebene Hostadresse: 192.168.100.1 /25

Berechnung der Subnetzadresse 0:

Die Hostadresse wird mit der Subnetzmaske logisch UND verknüpft:

Hostadresse	192.168.100.1	11000000	10101000	01100100	00000001
UND
Maske	255.255.255.128	11111111	11111111	11111111	10000000
Subnetz	192.168.100.0	11000000	10101000	01100100	00000000

Berechnung der Broadcastadresse 0:

Die Subnetzadresse wird mit der invertierten Subnetzmaske logisch ODER verknüpft:

Subnetz	192.168.100.0	11000000	10101000	01100100	00000000
ODER
Maske	0.0.0.127	00000000	00000000	00000000	01111111
Broadcast	192.168.100.127	11000000	10101000	01100100	01111111

Berechnung der Subnetzadresse 1:

Die Hostadresse wird mit der Subnetzmaske logisch UND verknüpft:

Hostadresse	192.168.100.129	11000000	10101000	01100100	10000001
UND
Maske	255.255.255.128	11111111	11111111	11111111	10000000
Subnetz	192.168.100.128	11000000	10101000	01100100	10000000

Berechnung der Broadcastadresse 1:

Die Subnetzadresse wird mit der invertierten Subnetzmaske logisch ODER verknüpft:

Subnetz	192.168.100.128	11000000	10101000	01100100	10000000
ODER
Maske	0.0.0.127	00000000	00000000	00000000	01111111
Broadcast	192.168.100.255	11000000	10101000	01100100	11111111

Daraus ergibt sich:

Subnetzadresse 0:	192.168.100.0
Broadcast 0:	192.168.100.127
Adressbereich 0:	192.168.100.1 bis 192.168.100.126

Subnetzadresse 1:	192.168.100.128
Broadcast 1:	192.168.100.255
Adressbereich 1:	192.168.100.129 bis 192.168.100.254

Mögliche Subnetzmasken und ihre verschiedenen Schreibweisen sind:

Subnetzmaske		# Bit Subnetting	# Subnetze	# Hosts / Netz
255.0.0.0	/8	0	0	16777214
255.128.0.0	/9	1	2	8388606
255.192.0.0	/10	2	4	4194302
255.224.0.0	/11	3	8	2097150
255.240.0.0	/12	4	16	1048574
255.248.0.0	/13	5	32	524186
255.252.0.0	/14	6	64	262142
255.254.0.0	/15	7	128	131070
255.255.0.0	/16	8	256	65536
255.255.128.0	/17	9	512	32766
255.255.192.0	/18	10	1024	16382
255.255.224.0	/19	11	2048	8190
255.255.240.0	/20	12	4096	4094
255.255.248.0	/21	13	8192	2046
255.255.252.0	/22	14	16384	1022
255.255.254.0	/23	15	32786	510
255.255.255.0	/24	16	65536	254
255.255.255.128	/25	17	131072	126
255.255.255.192	/26	18	262144	62
255.255.255.224	/27	19	524288	30
255.255.255.240	/28	20	1048576	14
255.255.255.248	/29	21	2097152	6
255.255.255.252	/30	22	4194304	2

Adressklassen

Class A: 1.0.0.0 - 127.0.0.0

Netzwerkanteil:	7 Bit im 1. Byte (1 Bit festgelegt Wenige Class A Netze
Hostanteil:	2. Bis 4. Byte (insgesamt 24 Bit) Pro Class A Netz sehr viele Hosts
Class A:	Sehr geringe Anzahl von Netzwerken mit einer sehr großen Anzahl von Hosts/Netzwerk

Class B: 128.0.0.0 - 191.255.0.0

Netzwerkanteil:	6 Bit im 1. Byte (2 Bit festgelegt) & 8 Bit im 2. Byte (insgesamt 14 Bit Netzwerkanteil) Mittlere Anzahl von Class B Netzen
Hostanteil:	3. & 4. Byte (insgesamt 16 Bit) Pro Class B Netz mittlere Anzahl von Hosts
Class B:	Mittlere Anzahl von Netzwerken mit einer mittleren Anzahl von Hosts/Netzwerk

Class C: 192.0.0.0 - 223.255.255.0

Netzwerkanteil:	5 Bit im 1. Byte (3 Bit festgelegt) & jeweils 8 Bit im 2. & 3. Byte (insgesamt 21 Bit)
Hostanteil:	nur 4. Byte (gesamt 8 Bit) Pro Class C Netz nur geringe Anzahl an Hosts
Class C:	Sehr grosse Anzahl von Netzwerken mit einer geringen Anzahl von Hosts/Netzwerk

Zusammenfassung:

CLASS	Netzwerk Anteil	# Netze	Hostanteil	# Hosts/Netz
A	1 Bit + 7 Bit	128	24 Bit	16.777.214
B	2 Bit + 14 Bit	16.864	16 Bit	65.534
C	3 Bit + 21 Bit	2.097.152	8 Bit	253

Private Adressen

Da jede Adresse individuell sein MUß, gleichzeitig aber auch eine gewisse Flexibilität bei der Adressvergabe vorhanden sein soll, wurden innerhalb der einzelnen Adressklassen Bereiche geschaffen, die dem privaten Gebrauch vorbehalten sind. Diese Adressen dürfen innerhalb z.B. Eines Firmennetzes ohne jegliche Registrierung frei vergeben werden. Natürlich dürfen diese Adressen innerhalb eines Netzes nicht doppelt vorkommen, jedoch können so unterschiedliche Nete mit den gleichen Adressen entstehen. Aus diesem Grund muß sichergestellt sein, daß diese Adressen niemals nach aussen (ins Internet) propagiert werden (dies kann z.B. durch NAT - Network Adress Translation verhindert werden).

Private Bereiche:

Class A:	10.0.0.0	255.0.0.0
Class B:	172.16.0.0	255.240.0.0
Class C:	192.168.0.0	255.255.255.0

Ports

Auf TCP/IP basieren viele verschiedene Dienste wie Mail, News, DNS, etc. Um nun diese Dienste innerhalb der Protokollfamilie TCP/IP voneinander abzugrenzen, werden diese Dienste den sogenannten Ports zugewiesen. Ein Port ist nichts anderes als eine zusätzliche Kennung zur IP-Adresse. Derzeit sind rund 65.000 Ports bekannt, welche sich auf verschiedene Bereich aufteilen.

Well known Ports:	0	-	1023
Registered Ports:	1024	-	49151
Dynamic and/or privat Ports:	49152	-	65535

Eine komplette Liste aller Ports, und so ziemlich die gesamte Dokumentation zu allem was Netzwerke und Protokolle betrifft, findet sich unter „http://www.iana.com".

ARP

ARP (Adress Resolution Protocol) beschreibt die Kommunikation zwischen Hosts auf Basis von Layer 2 (MAC Adressen). Die eigentliche Kommunikation zwischen Hosts basiert, unabhängig von den höheren Protokollen wie TCP/IP, IPX etc. immer auf Basis der MAC-Adressen. Das bedeutet, wenn ein Host ein Datenpaket an einen anderen schickt, dann sieht es für den Benutzer zwar so aus, als wenn das paket an eine bestimmte IP-Adresse gerichtet ist, in Wirklichkeit jedoch kennt der Netzwerktreiber, ähnlich wie bei DNS, die Zuordnung zwischen ihm bekannten MAC-Adressen und den zugeordneten IP-Adressen. Diese Vergleichstabelle nennt man auch ARP-Cache. Diese Einträge unterliegen einem Alterungsprozess (Aging). Da jedes Datenpaket als Absender nicht nur die IP-Adresse sondern auch die entsprechende MAC-Adresse enthält, lernen so die Hosts im Laufe der Zeit alle zuordnungen zwischen MAC- und IP-Adresse. Wird nun eine Adresse eine bestimmte Zeit nicht angesprochen, "altert" ihr Eintrag und rutscht in der tabelle nach unten, bis er schliesslich ganz aus der tabelle entfernt wird. Dieses "Aging" dient dazu, die Tabelle möglichst kurz zu halten, und so die Suchzeiten zu minimieren. Soll nun ein Paket an eine IP-Adresse geschickt werden, deren MAC-Adresse nicht bekannt ist, stellt der sendene Host einen ARP-Request mit folgendem Inhalt: "Antwort erbeten von IP-Adresse xxx.xxx.xxx.xxx". Wenn die gerufene Station darauf antwortet, übermittelt sie ja nicht nur ihre IP-Adresse, sondern auch ihre MAC-Adresse. Somit sind alle notwendigen Angaben zusammen und der Transport des Paketes kann stattfinden.

Den umgekehrten Weg, MAC-Adresse bekannt, IP-Adresse gesucht, definiert RARP (Reverse Adress Resolution Protocol).

RARP

Oftmals ergibt sich die Problematik, z.B. ein Notebook in verschiedenen Netzen betreiben zu müssen. Dadurch wird es notwendig, Netzwerkparameter wie IP-Adresse, Gateway, etc. nach dem Start des Systems neu einstellen zu müssen. Meist ist dann ein Neustart erforderlich. Wesentlich einfacher und effektiver wäre es, das System selbst die Einbindung ins Netzwerk und damit sämtliche Parameter, vornehmen zu lassen.

Die erste und einfachste Alternative zur Lösung dieses Problems, das Reverse Adress Resolution- oder RARP-Protokoll, bietet Computersystemen die Möglichkeit, sich eine IP-Adresse zuteilen zu lassen, wenn ein Computer über keine Möglichkeiten verfügt, seine IP-Adresse lokal zu speichern, z.B. auf einer Festplatte. Im einzelnen wendet sich dabei ein Rechner mittels eines Broadcasts auf sein Subnetz an einen sogenannten RARP-Server und teilt ihm seine Hardwareadresse mit, für die der Server die zugeordnete IP-Adresse kennt. Der Server teilt daraufhin dem Rechner seine IP-Adresse mit. Die Übertragung der Informationen erfolgt über die physikalische Netzverbindung. Bei der Verwendung von Ethernet beispielweise hat eine RARP-Anfrage den Standard-Vorspann, Ethernet-Quell- und Ziel-Adressen und Pakettyp-Felder am Beginn des Ethernet-Pakets. Der Datenteil enthält dann die 28-Oktett-RARP-Nachricht. RARP hat drei schwerwiegende Nachteile: Als erstes setzt es den direkten Zugriff auf die Netz-Hardware voraus. Diese Tatsache macht es einem Anwendungsprogrammierer schwer bzw. unmöglich, ein Serverprogramm zu erstellen. Zweitens benötigt RARP den direkten Austausch von Paketen zwischen einer Clientmaschine und dem Rechner, der die Rolle des Servers übernimmt. Der Server kann aber dem Client als einzige Information die 4-Oktett-IP-Adresse mitteilen. Und drittens verhindert die Tatsache, daß RARP die Hardware-Adresse eines Rechners zu dessen Identifizierung benutzt, den Einsatz von RARP in Netzen, die Hardwareadressen dynamisch vergeben

BOOTP

Als Ausweg aus dieser Problemlage unter RARP wurde das Bootstrap- oder BOOTP-Protokoll entwickelt. Wie RARP setzt BOOTP ein Client-Server-artiges Konzept voraus und benötigt nur ein einzelnes Paket, um die Konfigurationsinformation zu übermitteln. Dabei erfährt ein konfigurationswilliger Host von einem BOOTP-Server seine IP-Adresse, die Adresse eines Routers und eines File Servers sowie firmenspezifische Parameter, die der Host für das Booten benötig. Dies funktioniert folgendermaßen: Ein konfigurationswilliges Computersystem sendet einen sogenannten BOOTREQUEST als Broadcast an einen oder mehrere BOOTP-Server. Als Transportprotokoll wird das User Datagram Protocol verwendet. Der BOOTP-Server antwortet mit einem BOOTREPLY, in dem er dem Client eine IP-Adresse und andere Parameter für die Netzkonfiguration vermittelt, die es aus einer Konfigurationsdatei ausliest. Diese Datei wird von den Netzbetreibern erstellt. Falls BOOTP-Server und BOOTP-Client sich nicht auf dem selben Subnetz befinden, leitet ein sogenannter Relay Agent den Broadcast auf die gewünschten Subnetze weiter.

DHCP

Mit der Entwicklung von mobilen Systemen wie Systemen mit drahtloser Übertragung oder Laptops mit Netzanschluß ergibt sich das Problem, daß BOOTP zu statisch für die Konfiguration dieser Systeme ist. Die Ursache liegt darin, daß BOOTP nur gestattet, Konfigurationsinformationen einem Hostsystem statisch zuzuordnen. Außerdem muß bei BOOTP der Netzadministrator für jeden Host die Konfigurationsinformationen einzeln in einem Konfigurations-File des BOOTP-Servers niederlegen. Dadurch ist BOOTP nicht in der Lage, einzelne Rechner dynamisch mit einer Konfiguration zu versorgen. Große Probleme bekommt man mit BOOTP vor allem dann, wenn Rechner sehr flexibel in unterschiedlichen Netzen eingesetzt werden oder wenn weniger freie IP-Adressen vorhanden sind als Interessenten für eine IP-Adresse. Einen Ausweg aus dieser Problemlage bietet das sogenannte Dynamic Host Configuration Protocol, kurz DHCP genannt. DHCP wird heute schon in vielen Bereichen zur Konfiguration von IP-Systemen eingesetzt und eignet sich vor allem auch gut zur Konfiguration mobiler Systeme. DHCP erweitert das BOOTP-Protokoll, indem es einem Rechner oder IP-System die Möglichkeit bietet, seine IP-Adresse schnell und dynamisch zu erhalten. Um einen sogenannten DHCP-Server in die Lage zu versetzen, IP-Systeme dynamisch mit IP-Adressen zu versorgen, muß ein Netzadministrator ihm einen Satz IP-Adressen zur Verfügung stellen. Über diese IP-Adressen muß der DHCP-Server frei verfügen können, d.h., sie dürfen nicht von anderen Systemen im Netz belegt sein. Wenn nun ein Rechner, der sogenannte DHCP-Client, in das Netz eintritt, nimmt er mit dem DHCP-Server Kontakt auf]]. Der Server wählt eine seiner freien Adressen aus und vermittelt sie dem neuen Rechner. Dabei unterstützt DHCP auch BOOTP-Anfragen. Bei DHCP gibt es dabei drei Arten der Adreßvergabe]:

Bei der manuellen Vergabe von IP-Adressen werden diese wie beim BOOTP-Protokoll von einem Administrator vergeben.
Beim automatischen Vergabeverfahren bekommt ein neu hinzugekommener Rechner vom Server automatisch eine permanente IP-Adresse zugeteilt.
Beim dynamischen Vergabeverfahren bekommt der neu Hinzugekommene wie beim automatischen Verfahren eine IP-Adresse, jedoch nur für eine beschränkte Zeit, die sogenannte Leasezeit. Dabei wird der Begriff Lease auch als Bezeichnung für die Erlaubnis verwendet, die Netzressourcen zu nutzen, welche der DHCP-Server zugänglich macht.

Bei der Vergabe von Adressen ist zu beachten, daß ein System, welches mehrere IP-Adressen benötigt, für jede Adresse eine eigene Adressenanfrage unter DHCP starten muß.

DNS

Das Prokoll , oder besser die Protokollfamilie TCP/IP, benötigt zur Adressierung die erwähnten IP-Adressen. Nun ist es für den Anwender unmöglich, alle benötigten Adressen in der numerischen Form zu behalten. Es wäre doch wesentlich einfachen, statt "ping 192.168.100.1" sagen zu können "ping fileserver". Damit dieses möglich wird, muß zwischen dem eigentlichen Befehl "ping" und der Anwendung desselben auf eine Adresse eine weitere Zwischenstufe geschaltet werden: DNS (Domain Name Service). Diese Protokoll macht nichts anderes, als einem "realen" Namen eine dem Protokoll TCP/IP verständliche Adresse zuzuweisen. Dazu stellt der IP-Stack des jeweiligen Betriebssystems einen sogenannten DNS-Request über den Port 53 an den ihm bekannten DNS-Server. Falls dieser in der Lage ist, den Request zu beantworten, wird die IP-Adresse zurück gegeben. Falls nicht, wird je nach Konfiguration des DNS-Servers von diesem der Request an seine ihm vorgeschalteten Server weitergeleitet, oder aber, der Request wird als nicht auflösbar beantwortet.

Die Reihenfolge eines DNS-Requests wird hier ersichtlich:

Hier wird auch ersichtlich, warum dem Betriebssystem sowohl ein DNS als auch ein Gateway bekannt sein muß. Der DNS-Request wird an die Adresse des DNS gestellt, der eigentliche Befehl aber über die des Gateways. Die Datei HOSTS ist Bestandteil aller Betriebssysteme mit TCP/IP Protokollstack. Diese ersetzt einen remote DNS, falls dieser nicht, oder während des Bootens, noch nicht, verfügbar ist. Wie eindeutig zu ersehen ist, wird die Datei HOSTS immer zuerst befragt. D.h. wenn dort eine entsprechende Namensauflösung vorgenommen werden kann, wird diese Antwort an den Protokoll-Stack übergeben, unabhängig davon, ob die gelieferte IP-Adresse richtig ist.

Format der HOSTS-Datei

#IP-Adresse	#realer Name	#Kommentare
127.0.0.1	localhost
192.168.100.1	fileserver	#kurze Bezeichnung
192.168.100.1	fileserver.home_domaine.de	#lange Bezeichnung inkl. Domaine

WICHTIG: Die zu verwendenden Kommentarzeichen sind vom Betriebssystem abhängig.

Datenübertragung im Internet

Bei der Datenübertragung im Internet laufen viele Vorgänge ab, von denen der Anwender nichts merkt. So werden im Internet nicht ganze Dateien übertragen, sondern sogenannte „Pakete“, auch „IP-Datagramme“ genannt.

Damit ein Paket auch beim Empfänger ankommt, müssen eine Reihe von Informationen mit diesem Paket mitgeschickt werden.

Da die Datenübertragung in jedem Netzwerk sehr komplex ist, teilt man das Problem in Teilprobleme auf. Man unterscheidet sogenannte „Schichten“, die bestimmte Aufgaben erfüllen; im Internet könnte man folgende Schichten unterscheiden:

Application (Anwendung): Benutzerebene (Surfen über WWW, FTP, ...)
Transportschicht: Transport der Meldungen (verlässlich, ...)
Netzwerkschicht: Adressierung, Verwaltung
Network Interface: Daten auf das Medium (Kabel) bringen bzw. vom Medium (abholen)
Hardware: Lichtwellenleiter, Kupferkabel

Jede Schicht (Teilfunktion) wird durch ein sogenanntes Protokoll realisiert; in der Praxis gibt es spezielle Treiber, die die Aufgaben von Protokollen übernehmen (in Windows gibt es etwa die TCP/IP-Treiber).

Man hat für alle Netzwerke ein einheitliches Schichtenmodell entworfen, das ISO/OSI-7-Schicht-Referenzmodell. In der folgenden Abbildung sehen Sie, welche Protokolle im Internet welche Aufgaben erfüllen:

Jede Schicht fügt spezielle Adress- und Protokollinformationen (sogenannte „Header“) zu den eigentlichen Daten hinzu. Dadurch wird das Datenpaket immer größer. Beim Empfänger durchläuft das Datenpaket die Protokolle in umgekehrter Reihenfolge, wobei die Daten dabei sozusagen „ausgepackt“ werden.

Protokolle niederer Schichten (Schichten 1, 2)

ARP, Address Resolution Protocol:

Dieses Protokoll setzt IP-Adressen in MAC-Adressen um (Media Access Control). Die meisten Netzwerke sind Ethernet-Netze; in diesen Netzen besitzt jeder Rechner (eigentlich: die Netzwerkkarte jedes Rechners) eine weltweit eindeutige Adresse, die sogenannte MAC-Adresse. Das ARP ordnet daher jeder IP-Adresse die korrekte Netzwerkkarte zu.

DHCP, Dynamic Host Configuration Protocol:

Dieses Protokoll dient dazu, um Rechner im Netz bereits beim Booten konfigurieren zu können. So kann zum Beispiel jedem Rechner automatisch eine IP-Adresse zugewiesen werden.

PPP, Point to Point Protocol:

Ermöglicht die Verbindung zweier Computer über eine serielle Leitung – wird heute immer bei Modemverbindungen zum Internet-Server verwendet. Das Protokoll arbeitet mit IP zusammen und bildet zusätzlich Prüfsummen zur Fehlerkontrolle. (Ein älteres Protokoll mit derselben Aufgabe war das SLIP = Serial Line Internet Protocol, welches heute aber nicht mehr verwendet wird).

Das Internet Protocol (IP) – Schicht 3

Wir haben bereits erwähnt, dass jedes Protokoll spezielle Informationen (den sogenannten Header) zu den eigentlichen Daten hinzufügt.

Hauptaufgaben des IP-Protokolls:

Adressierung von Netzknoten
Routing (Wegesuche im Netz)
Zerlegung des Datenstroms in Pakete; ein IP-Datenpaket kann maximal 65536 Bytes groß sein.

Wir wollen hier den IP-Header etwas genauer betrachten. Zuerst sollen an dieser Stelle das Aussehen und die Bedeutung der einzelnen Header-Elemente beschrieben werden.

Abbildung: Der IP-Header

$\begin{figure} \begin{center} \leavevmode\epsfbox{pictures/ip-header.ps}\end{center}\end{figure}$

Die ersten vier Bits stellen das Feld Ver dar (siehe Abbildung). Sie sind für die Version des IP-Protokolls bestimmt, welches das zu sendende Datagramm zusammenstellt. Bei der Benutzung von IPv4 enthält dieses Feld den Wert vier.

Die nächsten vier Bit, die das Feld HLen repräsentieren, enthalten die aktuelle Header-Länge. Dabei werden aber nicht die Bytes, sondern die Doppel-Worte (4 Byte) gezählt. Bei einem IP-Standard-Header sollte hier eine fünf stehen. Dieser Standard-Header findet bei der Übertragung normaler Nutzdaten Anwendung. Er umfaßt immer 5 Doppel-Worte = 20 Byte.

Danach folgt das Feld TOS, Type of Service. Es enthält u.a. Informationen, welcher Art die zu transportierenden Daten sind und welche Qualität die Art der Übertragung besitzen soll.

Das Feld Total Length im IP-Header kennzeichnet die totale Länge eines Datagramms einschließlich Header. Da dieses Feld nur eine 16-Bit-Zahl enthalten kann, ist auch die Größe eines IP-Datagramms auf maximal 2¹⁶ - 1 = 65535 Byte beschränkt. Ein größeres Datagramm kann durch IP nicht vermittelt werden.

Auf die Bedeutung der Felder Identification, Flags und Fragment Offset wird später näher eingegangen. Sie werden benötigt, um eine Datagramm-Übermittlung auch über Netzverbindungen zu garantieren, die die maximale Größe eines IP-Datagramms nicht transportieren können.

Im Feld TTL wird die Lebenszeit, Time To Live, eines Datagramms verwaltet. Es dient zur Vorbeugung, daß ein Datagramm im Netz nicht ,“ewig herumirrt“. Beim Verschicken des Datagramms wird durch den Sender eine Zahl in dieses Feld eingesetzt, die die Lebenszeit dieses Datagramms in Sekunden repräsentieren soll. Da aber ein anderer Host nicht weiß, wann dieses Datagramm erzeugt wurde und im Header auch keine Information über die Erzeugung vorhanden ist, repräsentiert diese Zahl in der Praxis etwas anderes. Sie gibt an, wieviele Router dieses Datagramm passieren darf, um den Empfänger zu erreichen. Dazu ist es notwendig, daß jeder benutzte Router den Wert dieses Feld um 1 erniedrigt. Ist irgendwann einmal der Wert des Feldes TTL gleich Null, dann wird es von dem Router, der es gerade bearbeitet, verworfen, und er sendet eine Fehlermeldung zurück an den Sender.

Das Feld Protocol wird von IP benutzt, um auf der Seite des Senders das Protokoll zu vermerken, welches die Dienste von IP in Anspruch nimmt. Auf der Seite des Empfängers dient es IP dazu, das Datagramm genau an dieses Protokoll zur weiteren Bearbeitung weiterzuleiten.

Das Feld Header Checksum beinhaltet eine Prüfsumme. Sie dient zum Erkennen von Verfälschungen bei der Übertragung des Datagramms. Allerdings wird sie nur über die Daten des IP-Headers selbst gebildet. Die zu transportierenden Daten werden nicht berücksichtigt. Soll über diesen Daten auch eine Prüfsumme zur Fehlererkennung gebildet werden, muß das ein anderes Protokoll oder die Anwendung selbst übernehmen, die die Dienste von IP in Anspruch nimmt. Die Überprüfung ist einfach zu vollziehen. Der das Datagramm bearbeitende Host, das kann auch ein Router sein, extrahiert den Wert aus dem Feld Header Checksum des Datagramms und berechnet diesen neu. Gleichen sich die beiden Werte nicht, wird IP dieses Datagramm verwerfen und eine Fehlermeldung an den Sender schicken. Ansonsten wird das Datagramm an den Empfänger zugestellt. Der Algorithmus zur Erstellung dieser Prüfsumme ist recht simpel. Der Wert dieser Prüfsumme stellt das Einerkomplement der Einerkomplementsumme des Headers dar. Dabei werden die Daten in Einheiten von 16 Bit zerteilt und addiert. Zur Berechnung wird der Header vollständig ausgefüllt. Das Feld Header Checksum wird vor der Berechnung mit Null initialisiert. Als Eingabe des Algorithmus bei einem Standard-Header dienen dann diese so vorbereiteten 20 Byte = 10 Worte. Das ermittelte Ergebnis wird zuletzt in das Feld Header Checksum übertragen. Der Grund, nur über den IP-Header eine Prüfsumme zu bilden, liegt darin begründet, daß diese Berechnung auf jedem Router durchgeführt werden muß. Dieses Verfahren stellt gegenüber der Berechnung über alle Daten eine erhebliche Beschleunigung der Vermittlung dar.

Zur Adressierung des Datagramms werden unbedingt die zwei Felder Source IP Address (Quell-Adresse) und Destination IP Address (Ziel-Adresse) benötigt. Die Ziel-Adresse dient zur Adressierung des Empfängers. Das Eintragen einer Quell-Adresse wird einmal zur etwaigen Erzeugung von Fehlermeldungen benötigt und außerdem dient sie dem Empfänger zur Identifizierung des Senders.

Im Feld Data können alle möglichen Nutzdaten transportiert werden.

Die Felder IP Options und Padding hängen direkt miteinander zusammen. Da der IP-Header immer Vielfache von Doppel-Worten enthalten muß, die Optionen aber verschieden lang sein können, wird das Padding zur Auffüllung genutzt, um wieder ein volles Doppel-Wort zu erhalten. Wird durch IP festgestellt, daß der Wert im Feld HLen größer als 5 ist, muß der Header Optionen enthalten. An Hand dieser Header-Länge ist auch ersichtlich, wo die Optionen enden und von wo ab eventuell Daten im Datagramm enthalten sind. Die Bedeutung der Optionen werden u.a. im RFC 791 beschrieben.

Abbildung: Das Feld TOS des IP-Headers

$\begin{figure} \begin{center} \leavevmode\epsfbox{pictures/ip-tos.ps}\end{center}\end{figure}$

Die Abbildung zeigt den Aufbau des Feld TOS. Die drei Bits des Feldes Precedence kennzeichnen die Art des Datagramms. Sie können einen Wert zwischen 0 und 7 annehmen. Der Wert 0 wird bei einem Datagramm eingesetzt, welches normale Nutzdaten transportiert. Der Wert 7 wird für Datagramme zur Netzwerk-Steuerung verwendet. Näheres dazu ist im RFC 791 zu erfahren. Die Felder D, T und R legen fest, welcher Qualität die Art der Übertragung des Datagramms sein soll. Feld D macht dabei eine Aussage über die Schnelligkeit, Feld T über den Durchsatz und Feld R über die Verfügbarkeit der Übertragung. Setzt z.B. ein Sender das Bit in Feld D in einem Datagramm, verlangt er, daß dieses so schnell wie möglich an den Empfänger übermittelt wird.

Der Header muß grundsätzlich in der Netzwerk-Byte-Ordnung (network byte order) verschickt werden. Diese Ordnung wird auch Big Endian genannt.

Das Transfer/Transmission Control Protocol (TCP) – Schicht 4

Das TCP ist ein verbindungsorientiertes Protokoll; es bildet die Verbindung zwischen IP und Anwendung.

Aufgaben:

garantiert den sicheren Transport von Daten im Netz
gewährleistet, daß kein Datenpaket verlorengeht und daß alle Pakete in der richtigen Reihenfolge ankommen

Merkmale:

vollduplex, bidirektionale (virtuelle) Verbindung
Benutzer sieht Datenstrom, keine Pakete
Zustellung der Information der entsprechenden Anwendung
geregelter Verbindungsauf-/abbau

Der TCP-Header: Natürlich fügt auch das TCP-Protokoll spezielle Daten hinzu – wieder in Form eines Headers – der wie folgt aufgebaut ist:

· Sender/Empfänger-Port (je 16 B): Endpunkte der Verbindung

· Sequ./Quitt.nummer (32 B): Synchronisation der Daten

· Datenabstand (4 B): Länge des Headers in 32 B

· Flags (6 B): Aktionen (Aufbau, Ende, ...)

· Fenstergröße (16 B): Größe des verfügbaren Empfängerbuffers (bei 0 Stop des Senders)

· Prüfsumme (16 B): Korrektheit des Headers

· Urgent-Zeiger (16 B): zur Verarbeitung von wichtigen Daten

· Optionen (24 B), Füllzeichen (6 B)

Protokolle höherer Schichten – Schichten 5, 6, 7

Diese Protokolle sind sozusagen die gemeinsame „Sprache“ zwischen Serversoftware und Clientsoftware. Jedem Internet-Dienst ist ein solches Protokoll zugeordnet:

HTTP = Hypertext Transfer Protocol: Surfen im WWW
FTP = File Transfer Protocol: Upload und Download von Dateien
SMTP = Simple Mail Transfer Protocol: Protokoll zum Senden von Mails (funktioniert nur, wenn Online!)
POP3 = Post Office Protocol, version 3: Protokoll zum Abholen von Mails (mit User- und Passwortabfrage)
NNTP = Network News Transfer Protocol: Protokoll zum Arbeiten mit Newsgroups
Telnet: Sitzung auf einem Remote Server (Terminal-Modus)

usw.

Well Known Port Numbers (RFC 1340): Fast immer laufen auf einem Internet-Server mehrere Dienste, etwa FTP, Archie, WWW etc. Um die einzelnen Dienste unterscheiden zu können, wurde jedem Dienst eine spezielle Kennung, die sogenannte „Port Number“, zugewiesen. Um internationale Einheitlichkeit zu gewährleisten, wurden die „gut bekannten“ Port Numbers im RFC 1340 (Request for Comment, „Bitte um Kommentar“, de facto eine „Internet-Norm“) zusammengestellt.

Ein Auszug folgt hier:

   ftp-data        20/tcp    File Transfer [Default Data]

   ftp             21/tcp    File Transfer [Control]

   telnet          23/tcp    Telnet

                   24/tcp    any private mail system

   smtp            25/tcp    Simple Mail Transfer

                   35/tcp    any private printer server

   time            37/tcp    Time

   rlp             39/tcp    Resource Locatio Protocol

   graphics        41/tcp    Graphics

   nameserver      42/tcp    Host Name Server

   nicname         43/tcp    Who Is

   domain          53/tcp    Domain Name Server

   xns-auth        56/tcp    XNS Authentication

   tftp            69/tcp    Trivial File Transfer

   gopher          70/tcp    Gopher

   finger          79/tcp    Finger

   www             80/tcp    World Wide Web HTTP

   hosts2-ns       81/tcp    HOSTS2 Name Server

   xfer            82/tcp    XFER Utility

   kerberos        88/tcp    Kerberos

   su-mit-tg       89/tcp    SU/MIT Telnet Gateway

   rtelnet        107/tcp    Remote Telnet Service

   pop2           109/tcp    Post Office Protocol - Version 2

   pop3           110/tcp    Post Office Protocol - Version 3

   auth           113/tcp    Authentication Service

   audionews      114/tcp    Audio News Multicast

   sftp           115/tcp    Simple File Transfer Protocol

   uucp-path      117/tcp    UUCP Path Service

   sqlserv        118/tcp    SQL Services

   nntp           119/tcp    Network News Transfer Protocol

   statsrv        133/tcp    Statistics Service

   netbios-ns     137/tcp    NETBIOS Name Service

   netbios-dgm    138/tcp    NETBIOS Datagram Service

   netbios-ssn    139/tcp    NETBIOS Session Service

   imap2          143/tcp    Interim Mail Access Protocol v2

   sqlsrv         156/tcp    SQL Service

   pcmail-srv     158/tcp    PCMail Server

   irc            194/tcp    Internet Relay Chat Protocol

   ipx            213/tcp    IPX

   imap3          220/tcp    Interactive Mail Access Protocol v3

   conference     531/tcp    chat

   netnews        532/tcp    readnews

   netwall        533/tcp    for emergency broadcasts

   uucp           540/tcp    uucpd

Wenn nötig, ist die Portnummer auch anzugeben (mit einem Doppelpunkt nach der eigentlichen Adresse). Ein Beispiel ist der bekannte Ö3-Chat:

Die Syntax in der URL-Zeile lautet allgemein:

Servertyp://servername.domain.tld:portnumber

Serverinstallation

1. Schritt:

NT-Server installieren; kein Domänencontroller, sondern „alleinstehender Server“!

CD-Key 040-0033861

2. Schritt:

Windows NT Service Pack 3 installieren

3. Schritt:

Microsoft Internet Explorer 4.0 installieren

4. Schritt:

NT 4 Option Pack installieren

Lizenzvertrag annehmen.

Man kann auch die Standard-Variante installieren; wesentlich sind jedoch die Komponenten „Microsoft Script Debugger“ und „IIS 4“. Empfehlung: Installieren Sie die Frontpage-Servererweiterungen NICHT! Sie sind nur äußerst schwer wieder entfernbar und können das System destabilisieren!

Bei den Standardverzeichnissen am besten vorläufig nichts ändern:

Details zur Serverinstallation im WIFI St. Pölten – Internet-Lehrgang

Beachten Sie bitte: Die angegebenen Lizenzen und Lizenznummern wurden vom WIFI ausschließlich für Schulungszwecke angekauft und dürfen daher außerhalb der Kursumgebung keinesfalls verwendet werden!

1. Herstellen der Verbindung zu den Novell Netware-Druckern:

Um die Druckservices des Novell Netware-Servers WIFI nutzen zu können, muss der Gateway-Service und Client für Netware-Netzwerke installiert werden.

Dazu rufen Sie die Eigenschaften der Netzwerkumgebung auf, wählen die Karteikarte „Dienste“ und klicken dann auf die Schaltfläche „Hinzufügen“:

Klicken Sie dann auf OK, um den Dienst hinzuzufügen. Die Karteikarte „Dienste“ hat nun folgendes Aussehen:

Funktionskontrolle: In der Netzwerkumgebung sehen Sie jetzt auch den WIFI-Server bzw. unter dem Eintrag „Gesamtes Netzwerk“ sehen Sie auch Netware-kompatible Netzwerke.

Nun können Sie den im Lehrsaal befindlichen Netzwerkdrucker installieren!

2. Herstellung der Anbindung ans Internet:

Um die Anbindung an den WIFI-internen Internet-Linux-Server zu erhalten, sind folgende Einträge notwendig:

Klicken Sie in den Eigenschaften der Netzwerkumgebung auf die Karteikarte „Protokolle“ und wählen Sie das TCP/IP-Protokoll aus.

Klicken Sie dann auf die Schaltfläche „Eigenschaften“ und stellen Sie folgendes ein:

Der Internet-Server-Administrator des WIFI hat auf dem Linux-Server ein Routing für folgenden Adressbereich eingetragen:

192.168.201.100

192.168.201.101

....

192.168.201.115

Als Gateway dient die Adresse

192.168.201.1

Nun fehlt noch ein Eintrag für den Domain Name Server. Klicken Sie dazu auf die Karteikarte „DNS“. Dort klicken Sie auf „Hinzufügen“ und tragen die Adresse des DNS-Servers ein.

(Anmwerkung: Im WIFI sind zwei DNS-Server definiert:

194.96.13.3 und

194.96.13.4 )

Dann fahren Sie den Rechner wieder hoch und probieren aus, ob Sie den eben installierten WIFI-Gateway nützen können, um im Internet zu surfen!

3. Office-Installation (Word, Access):

CD-Key für Office 97: 0401-0990811

Starten Sie den NT-Explorer und wählen Sie [Extras]-[Netzlaufwerk verbinden]:

Verbinden Sie sich zur Ressource \\WIFI2\\SW_Tank:

Sie können jetzt auf die im Netzwerk befindlichen Ressourcen zugreifen, unter anderem auf die CDs von Office 97 und Office 2000.

Domain Name Service (DNS): Zuordnen von Computernamen zu IP-Adressen

(a) über einen DNS-Server

(b) dynamisch:

DHCP-Server nötig (DHCP = dynamic host configuration protocol)

(c) Statisch (machen wir im Kurs):

Datei HOSTS im Verzeichnis

\WINNT\SYSTEM32\DRIVERS\ETC

bearbeiten mit Editor.

# This is a sample HOSTS file used by Microsoft TCP/IP for Windows NT.

# This file contains the mappings of IP addresses to host names. Each

# entry should be kept on an individual line. The IP address should

# be placed in the first column followed by the corresponding host name.

# The IP address and the host name should be separated by at least one

# space.

# Additionally, comments (such as these) may be inserted on individual

# lines or following the machine name denoted by a '#' symbol.

# For example:

# 102.54.94.97 rhino.acme.com # source server

# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost

192.168.0.1 ilg.at

Diese Datei ordnet jeder IP-Adresse einen DNS-Namen (“friendly name”) zu.

Im selben Verzeichnis befindet sich auch die LMHOSTS-Datei, die die Zuordnung von IP-Adressen zu NetBIOS-Namen regelt (NetBIOS-Namen werden als “PC-ID” von Win NT standardmäßig verwendet).

Wichtig: Jeder PC im Intranet muss dieselbe HOSTS-Datei bekommen, da sonst der Server nicht mit dem friendly name angesprochen werden kann. (Also: Datei auf jeden PC im Netz kopieren!!!)

Diagnose- und Konfigurationsprogramme

1. PING:

Versucht, 4 IP-Pakete an einen Host-Rechner zu senden. Zweck: Überprüfung der Funktionsfähigkeit von Netzwerkverbindungen.

C:\WINDOWS>ping 10.0.0.6

Ping wird ausgeführt für 10.0.0.6 mit 32 Bytes Daten:

Antwort von 10.0.0.6: Bytes=32 Zeit<10ms TTL=128

Ping-Statistik für 10.0.0.6:

Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),

Ca. Zeitangaben in Millisek.:

Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

2. IPCONFIG:

Gibt Informationen über die Windows IP-Konfiguration aus.

Parameter: /ALL gibt auch Informationen über die MAC-Adresse aus.

Beispiel 1: Ausgabe ohne Parameter /ALL

Windows 98 IP-Konfiguration

0 Ethernet Adapter :

IP-Adresse. . . . . . . . . : 0.0.0.0

Subnet Mask . . . . . . . . : 0.0.0.0

Standard-Gateway . . . . . . :

1 Ethernet Adapter :

IP-Adresse. . . . . . . . . : 10.0.0.6

Subnet Mask . . . . . . . . : 255.0.0.0

Standard-Gateway . . . . . . : 193.170.244.18

Beispiel 2: Ausgabe mit Parameter /ALL

Windows 98 IP-Konfiguration

Hostname . . . . . . . . . : KKTN.noe.wifi.at

DNS-Server . . . . . . . . : 194.96.13.3

194.96.13.5

Knotentyp . . . . . . . . . : Broadcast

NetBIOS-Bereichs-ID . . . . :

IP-Routing aktiviert. . . . : Nein

WINS-Proxy aktiviert. . . . : Nein

NetBIOS-Aufl”sung mit DNS . : Nein

0 Ethernet Adapter :

Beschreibung. . . . . . . . : PPP Adapter.

Physische Adresse . . . . . : 44-45-53-54-00-00

DHCP aktiviert. . . . . . . : Ja

IP-Adresse. . . . . . . . . : 0.0.0.0

Subnet Mask . . . . . . . . : 0.0.0.0

Standard-Gateway . . . . . . :

DHCP-Server . . . . . . . . : 255.255.255.255

Erster WINS-Server . . . . :

Zweiter WINS-Server . . . :

Gültig seit. . . . . . . :

Gültig bis . . . . . . . :

1 Ethernet Adapter :

Beschreibung. . . . . . . . : PPP Adapter.

Physische Adresse . . . . . : 44-45-53-54-00-01

DHCP aktiviert. . . . . . . : Ja

IP-Adresse. . . . . . . . . : 0.0.0.0

Subnet Mask . . . . . . . . : 0.0.0.0

Standard-Gateway . . . . . . :

DHCP-Server . . . . . . . . : 255.255.255.255

Erster WINS-Server . . . . :

Zweiter WINS-Server . . . :

Gültig seit. . . . . . . :

Gültig bis . . . . . . . :

2 Ethernet Adapter :

Beschreibung. . . . . . . . : Novell 2000 Adapter.

Physische Adresse . . . . . : 00-00-E8-2F-15-FA

DHCP aktiviert. . . . . . . : Ja

IP-Adresse. . . . . . . . . : 194.96.13.190

Subnet Mask . . . . . . . . : 255.255.255.0

Standard-Gateway . . . . . . : 194.96.13.1

DHCP-Server . . . . . . . . : 194.96.13.8

Erster WINS-Server . . . . :

Zweiter WINS-Server . . . :

Gültig seit. . . . . . . : 09.05.00 09:35:26

Gültig bis . . . . . . . : 09.05.00 09:45:26

3. WINIPCFG:

Am besten über [Start] – [Ausführen] aufrufen.

4. TRACERT:

Zeigt die Route eines IP-Pakets an.

Syntax: TRACERT [-d] [-h Abschnitte max] [-j Host-Liste] [-w Timeout] Zielname

Options:

-d Adressen nicht zu Hostnamen auswerten.

-h Abschnitte max Max. Anzahl an Abschnitten bei Zielsuche.

-j Host-Liste "Loose Source Route" gemäß Host-Liste.

-w Timeout Timeout in Millisekunden für eine Antwort.

Beispiel:

Route-Verfolgung zu www.yahoo.akadns.net [216.32.74.52]

über maximal 30 Abschnitte:

1 2 ms 3 ms 3 ms vianet-stpolten-gw01.via.at [194.96.211.18]

2 5 ms 5 ms 6 ms vianet-stpolten-gw00.via.at [194.96.211.17]

3 16 ms 32 ms 12 ms vianet-head-gw04.via.at [194.96.210.5]

4 22 ms 23 ms 14 ms atlas-atm4-1-0-460.uta.at [195.70.250.101]

5 22 ms 15 ms 16 ms kronos-atm9-0-0-597.uta.at 212.152.192.245]

6 31 ms 32 ms 29 ms 164.128.33.89

7 31 ms 32 ms 37 ms i79zhh-035-FastEthernet6-1-0.ip-plus.net [164.128.36.67]

8 120 ms 186 ms 126 ms i00ny-015-Pos0-0-0.ip-plus.net [164.128.35.118]

9 537 ms 120 ms 121 ms exodus-nyc.ip-plus.net [164.128.236.46]

10 121 ms 154 ms 136 ms bbr02.g3-0.jrcy01.exodus.net [209.67.45.254]

11 129 ms 127 ms 135 ms bbr01-p5-0.stng01.exodus.net [209.185.9.98]

12 130 ms 129 ms 162 ms dcr03-g9-0.stng01.exodus.net [216.33.96.145]

13 129 ms 131 ms 178 ms 216.33.98.18

14 128 ms 134 ms 173 ms 216.35.210.122

15 136 ms 132 ms 128 ms www.yahoo.akadns.net [216.32.74.52]

Route-Verfolgung beendet.

5. ARP (Adress Resolution Protocol):

Ändert und zeigt die Übersetzungstabellen für IP-Adressen/physische

Adressen an, die vom ARP (Address Resolution Protocol) verwendet werden.

Parameter:

ARP -s IP_Adr Eth_Adr [Schnittst]

ARP -d IP_Adr [Schnittst]

ARP -a [IP_Adr] [-N Schnittst]

-a Zeigt aktuelle ARP-Einträge durch Abfrage der Protokoll-

daten an. Falls IP_Adr angegeben wurde, werden die IP- und

physische Adresse für den angegebenen Computer angezeigt.

Wenn mehr als eine Netzwerkschnittstelle ARP verwendet,

werden die Einträge für jede ARP-Tabelle angezeigt.

-g Gleiche Funktion wie -a.

IP_Adr Gibt eine Internet-Adresse an.

-N Schnittst Zeigt die ARP-Einträge für die angegebene Netzwerk-

schnittstelle an.

-d Löscht den durch IP_Adr angegebenen Host-Eintrag.

-s Fügt einen Host-Eintrag hinzu und ordnet die Internet-Adresse

der physischen Adresse zu. Die physische Adresse

wird durch

6 hexadezimale, durch Bindestrich getrennte Bytes angegeben.

Der Eintrag ist permanent.

Eth_Adr Gibt eine physische Adresse (Ethernet-Adresse) an.

Schnittst Gibt, falls vorhanden, die Internet-Adresse der Schnittstelle

an, deren Übersetzungstabelle geändert werden soll.

Sonst wird die erste geeignete Schnittstelle verwendet.

Beispiel:

> arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Fügt einen statischen Eintrag

hinzu.

> arp -a .... Zeigt die Arp-Tabelle an.

6. NETSTAT

Zeigt bestehende Netzwerkverbindungen an.

Beispiel für netstat:

C:\WIN98>netstat

Aktive Verbindungen

Proto Lokale Adresse Remote-Adresse Status

TCP nr:1026 I406:nbsession ESTABLISHED

TCP nr:1037 www.browser.at:80 ESTABLISHED

TCP nr:1045 WWWIFI:80 ESTABLISHED

7. ROUTE

Manipulation und Anzeige der Routingtabelle des Betriebssystems.

Beispiel für route:

C:\WIN98>route print

Aktive Routen:

Netzwerkadresse Subnet Mask Gateway-Adresse Schnittstelle Anzahl

0.0.0.0 0.0.0.0 192.168.2.100 192.168.2.104 1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

192.168.2.0 255.255.255.0 192.168.2.104 192.168.2.104 1

192.168.2.104 255.255.255.255 127.0.0.1 127.0.0.1 1

192.168.2.255 255.255.255.255 192.168.2.104 192.168.2.104 1

224.0.0.0 224.0.0.0 192.168.2.104 192.168.2.104 1

255.255.255.255 255.255.255.255 192.168.2.104 0.0.0.0 1

C:\WIN98>

Der Internet Information Server

Wählen Sie Start – Programme – Windows NT 4.0 Option Pack – Microsoft Internet Information Server – Internet-Dienstmanager.

Es wird die Microsoft Management Konsole (MMC.EXE) aufgerufen. Die MMC ist ein allgemeines Werkzeug zur Verwaltung von Serverdiensten; sie wird in Windows 2000 zu einem zentralen Administrationstool.

Die Konsole kann mit sogenannten “Snap-Ins” für verschiedene Administrationsaufgaben konfiguriert werden (Menü [Konsole]-[Snap-In hinzufügen/löschen] bzw. Strg-M); die Einstellungen werden in Konfigurationsdateien gespeichert.

Ruft man den Internet-Dienstmanager auf, so wird bereits eine vorkonfigurierte Einstellung (Datei IIS.MSC) aufgerufen, die die Administration der Internet-Serverdienste stark vereinfacht.

FTP-Server einrichten und testen

FTP von der Serverseite aus gesehen – Einrichten und Konfigurieren des FTP-Dienstes im Internet Information Server:

Schritt 1:

Es ist oft sinnvoll, einen Webauftritt eines Kunden über eine eigene IP-Adresse zu realisieren. Dazu muss es aber möglich sein, der Netzwerkkarte des Webservers mehrere IP-Adressen zuzuweisen. Dies realisiert man in den erweiterten TCP/IP-Einstellungen:

Start - Einstellungen - Systemsteuerung - Netzwerk - Protokolle - TCP/IP-Protokoll - Optionen - Hinzufügen - IP-Adresse eingeben

Nicht vergessen: auch in der HOSTS-Datei eintragen!

Schritt 2:

Im Explorer (inetpub) root-Verzeichnis anlegen.

In diesem Beispiel:

C:\INetPub\Kunde1_101

Schritt 3:

Klicken Sie mit der rechten Maustaste auf den Servernamen (in der Abbildung etwa *nt701) und wählen Sie aus dem Kontextmenü [Neu]-[FTP-Site].

Schritt 4:

Start - Programme - Verwaltung (allgemein) - Benutzermanager für Domänen

Benutzer - Neu - Ausfüllen - Einstellungen vornehmen - Hinzufügen

Richtlinien - Benutzerrechte - lokale anmeldung wählen - Hinzufügen –

Benutzer anzeigen - auswählen - ok

Schritt 5:

Start - Programme - NT Éxplorer - Kundenverzeichnis auswählen - rechte Maustaste - Eigenschaften - Sicherheit - Berechtigungen

„Berechtigungen für existierende Dateien ersetzen“ auswählen:

Einstellungen vornehmen

Schritt 6

Management Konsole – Kontextmenü des FTP-Dienstes des neuen Kunden auswählen - Eigenschaften - Sicherheitskonten – „Nur anonyme Verbindungen erlauben“ deaktivieren

FTP von der Anwenderseite aus gesehen – FTP-Server testen:

Mit FTP können Sie Dateien von Ihrem Rechner auf einen entfernten Server übertragen (Upload) oder von einem entfernten Server Dateien auf Ihren Rechner laden (Download).

Der FTP-Dienst ist auf verschiedene Art und Weise nutzbar:

a) FTP-Programme:

Beispiele:

WS-FTP
FTPVoyager
CuteFTP

Es soll hier das Programm WS-FTP95 kurz erläutert werden:

1. Starten Sie das Programm WS-FTP95

2. Legen Sie ein Profil mit folgenden Einträgen an (Klicken Sie auf die Schaltfläche „New“):

3. Mit "OK" verbinden Sie sich zum PIAKREMS-FTP-Server: Links sehen Sie die Verzeichnis-/Laufwerksstruktur Ihres eigenen Rechners, rechts sehen Sie die Verzeichnisstruktur des FTP-Servers, mit dem Sie verbunden sind.

4. Mit den Pfeilen in der Mitte können Sie markierte Dateien von Ihrer Festplatte (links) auf den Server (rechts) kopieren oder umgekehrt!

b) Manuelle FTP-Sitzung:

Aufruf:

ftp Servername

FTP-Befehle:

! delete literal prompt send

? debug ls put status

append dir mdelete pwd trace

ascii disconnect mdir quit type

bell get mget quote user

binary glob mkdir recv verbose

bye hash mls remotehelp

cd help mput rename

close lcd open rmdir

dir remote Verzeichnis auflisten

cd, lcd Verzeichnis wechseln, remote / local

pwd aktuelles Verzeichnis

get, mget Datei/en von remote nach local kopieren

put, mput Datei/en von local nach remote kopieren

binary auf binären Transfer (Programme, Images, ...) umschalten

prompt Bestätigung abschalten

user als Benutzer einloggen

open, close Verbindung öffnen / schließen

? Hilfe anzeigen

quit, bye Programm beenden

Beispiel für eine manuelle FTP-Sitzung (Benutzereingaben sind fett dargestellt):

C:\WIN98>ftp off97.noe.wifi.at

Verbindung mit off97.noe.wifi.at.

220 wifi2 Microsoft FTP Service (Version 3.0).

Benutzer (off97.noe.wifi.at:(none)): user401

331 Password required for user401.

Kennwort:****

230-Herzlich Willkommen am Wifi Ftp-Server !

230 User user401 logged in.

Ftp> dir

200 PORT command successful.

150 Opening ASCII mode data connection for /bin/ls.

d--------- 1 owner group 0 Aug 19 1999 kids

d--------- 1 owner group 0 Feb 17 1998 kktn

---------- 1 owner group 0 Aug 18 1999 test.txt

---------- 1 owner group 0 Aug 19 1999 test3.txt

226 Transfer complete.

Ftp: 269 Bytes empfangen in 0.16Sekunden 1.68KB/Sek.

Ftp> get test.txt

200 PORT command successful.

150 Opening ASCII mode data connection for test.txt(0 bytes).

226 Transfer complete.

Ftp> put xxx.htm

200 PORT command successful.

150 Opening ASCII mode data connection for xxx.htm.

226 Transfer complete.

Ftp: 1777 Bytes gesendet in 0.00Sekunden 1777000.00KB/Sek.

Ftp> pwd

257 "/" is current directory.

Ftp> quit

221 Auf Wiedersehen !

Wenn Sie als anonymer FTP-Nutzer arbeiten wollen, so geben Sie als Benutzername anonymous an, als Kennwort Ihre eigene E-Mail-Adresse. (Es ist kein Passwort nötig, allerdings verlangen die Regeln der Netiquette eine derartige – freiwillige! – Identifizierung.)

c) FTP über den Browser:

Auch über Browser-Software ist eingeschränkter FTP-Betrieb möglich: Während Downloads problemlos möglich sind, können Uploads nicht durchgeführt werden!

Wichtig: Sollten Sie für den FTP-Server einen Benutzernamen und ein Kennwort eingeben müssen, dann wählen Sie bitte folgende Syntax für die Adresszeile des Browsers:

ftp://Benutzername:Kennwort@ftpserver.at

(Anmerkung: Das Passwort in der obigen Abbildung wurde abgedeckt bzw. verändert.)

Der WWW-Dienst im IIS

Zunächst legt man für den Kunden einen virtuellen Webserver (Website) an:

„Handeln“ mit Websites

Besitzt man mehrere IP-Adressen, so kann man damit „handeln“, d.h. der Webseite eines Kunden eine eigene IP-Adresse zuweisen.

Dafür gibt es mehrere Varianten:

a) Zuordnung in der HOSTS-Datei:

192.168.2.229 501_k1.ilg.edu

192.168.2.229 501_k2.ilg.edu

b) Host-Header-Name im IIS:

Dem Kunden wird zunächst eine eigene Seite mit eigener IP-Adresse zugewiesen.

Klick auf „Erweitert“ liefert die Möglichkeit, dieser Seite einen oder mehrere „Host-Header-Namen“ zuzuweisen.

Es ist also denkbar, ein und dieselbe Webseite mit mehreren Domain-Namen aufzurufen. (Ältere Browser unterstützen diese Funktion allerdings nicht!)

Schutz von Kindern und Jugendlichen durch RSACi-Filter und PICS-Labels

Quellen:

www.w3.org/PICS

www.rsac.org oder www.icra.org

RSACi = Recreational Software Advisory Council for the Internet

Das RSACi-System ist ein Filtersystem für jugendgefährdende Inhalte im Web, das von der ICRA (Internet Content Rating Association) verwaltet wird. Ziel dieses Systems ist die Gewährleistung der „Redefreiheit“ im Internet einerseits, der Schutz von Kindern und Jugendlichen vor gefährlichen oder anstößigen Inhalten andererseits.

Das RSACi-System ist im Internet Explorer integriert. Eltern können – gesichert durch ein Supervisor-Kennwort – den Level bestimmen, der angezeigt werden soll.

Für jeden RSACi-Label gibt es vier Sicherheitsstufen:

	Gewalt	Nacktheit	Sex	Sprache
Level 4	Vergewaltigungen oder willkürliche, brutale Gewaltakte	provozierende Nacktaufnahmen, von vorn fotografiert	Sexualverbrechen oder brutale, deutliche sexuelle Vorgänge	Rohe, vulgäre Sprache, freizügige sexuelle Anspielungen
Level 3	Aggressive Gewalt oder Töten von Menschen	Vollständige Nacktheit, von vorn fotografiert	Sexuelle Vorgänge	Deftige, vulgäre oder hasserfüllte Sprechweise; obszöne Kraftausdrücke
Level 2	Zerstörung realistischer Objekte	Teilweise Nacktheit	Sexuelle Berührungen im bekleideten Zustand	Kraftausdrücke; nicht sexuell bezogene anatomische Anspielungen
Level 1	Verletzen von Menschen	Aufreizende Bekleidung	Leidenschaftliche Küsse	Schwache Kraftausdrücke, milde Ausdrücke für Körperfunktionen
Level 0	Keine der obigen oder im Zusammenhang mit Sport	Keine der obigen	Keine der obigen oder “unschuldige” Küsse; Romantik	Keine der obigen

ICRA at a glance

The Internet Content Rating Association is an international, independent, non-profit organization with offices in Washington, D.C, USA and Brighton, UK, that empowers the public, especially parents, to make informed decisions about electronic media by means of an open, objective, content advisory system. The RSACi system managed by ICRA provides consumers with information about the level of sex, nudity, violence, offensive language (vulgar or hate-motivated) in Web sites. To date, RSACi has been integrated into Microsoft's browser, Internet Explorer, and MicroSystem's Cyber Patrol Software. CompuServe (US and Europe) has also committed to rate all its content with the RSACi system.

Rating The Web

Our aim in creating RSACi (RSAC on the Internet) was to provide a simple, yet effective rating system for web sites which both protected children and protected the rights of free speech of everyone who publishes on the World Wide Web.

Parental Controls

We also designed a system based on the tried and tested content advisory system used for computer games and one which could be simply understood and set by parents at either the browser level (eg. Microsoft's Internet Explorer 3.0x) or blocking device (eg. CyberPatrol). We urge parents, educators and other interested individuals to SET THE LEVELS at the growing number of browsers and software devices that are designed to read the RSACi labels.

Content Providers

Another essential part of this highly ambitious task, is to encourage internet content providers of all kinds to use our voluntary, self-disclosure rating system. There are a number of compelling reasons why a provider or web master would rate with RSACi, not least that it sends a clear signal to governments around the world, that the World Wide Web is willing to self-regulate, rather than have the heavy hand of government legislation decide what is or is not acceptable.

Commercial Web Sites

Commercial sites, with little or no objectionable material will want to rate. When a parent sets the levels for their child, they will also be offered an option that says, "Do not go to unrated sites". Most sites want the maximum number of visits to justify advertising or other related commercial activity. It would make good marketing sense for all commercial sites to rate whether or not they have any content that could be described as harmful.

Protecting Free Speech

RSACi has been an enthusiastic member of a number of initiatives that would support the protection of free speech on the Web. We work closely with PICS, the Platform for Internet Content Selection, based at MIT. This standard format provides us the means by which our rating system can be read by browsers and selection software around the world.

Setting The Levels

Please have a look at the table below. It gives you, at a glance, the four categories of the RSACi system with the five levels and their descriptors. It is these levels that parents and other interested individuals will set at their browser or blocking device.

Further Information On Definitions

Definitions for RSACi Language Questions

Definitions for RSACi Nudity Questions

Definitions for RSACi Sex Questions

Definitions for RSACi Violence Questions

· PICS Rating Vocabularies in XML/RDF (W3C NOTE 27 March 2000)

· Statement on Using PICS Well (1 June 1998)

· PICS Signed Labels (DSig) 1.0 Specification (27 May 1998)

· PICS Reference Code (2/98)

· PICSRules Language for Writing Filtering Rules; a W3C Recommendation (12/97)

· Letter from Tim Berners-Lee to GILC about PICSRules. Tim Berners-Lee (12/97)

· PICS and Intellectual Freedom FAQ. Paul Resnick. Updated filtering section to include brief discussion of PICSRules. (updated 1/97)

· PICSRules and Free Speech. Joseph Reagle. General comments and Joseph's responses to posts on the fight-censorship mailing list. (12/97)

· Free Java implementation of parsers for PICS labels, services, and rules, evaluator for PICSRules (12/97)

· DSIG 1.0 specification for signing PICS labels; a W3C Proposed Recommendation (12/97)

· SurfWatch available in PICS format. The PICS Application Incubator at The University of Michigan School of Information has created a PICS label bureau to distribute SurfWatch labels. (12/97)

· IBM's PICS-compliant proxy server released (12/97)

· Net Shepherd and Alta Vista offer filtered Internet search (11/97)

Information for the Media

Press inquiries about PICS should be directed to any of the following people:

· Josef Dietl, W3C Communications, +33.4.92.38.79.72

Technical inquiries to:

· W3C PICS expert, (pics-ask@w3.org)

· Ralph R. Swick, (swick@w3.org), W3C metadata lead. + 1.617.253.2613

Inquiries about public policy issues surrounding content regulation may also be directed to

· Joseph Reagle (reagle@w3.org), W3C Policy Analyst. + 1.617.253.2613

· Danny Weitzner, (djweitzner@w3.org), W3C Technology and Society Domain Leader. + 1.617.253.2613

What others are saying about PICS

Governments

· European Commission Report (follow-on document of 20 March, 1997)

· Australian Broadcast Authority report on its investigation into on-line services

· European Parliament Green Paper: the Protection of Minors and Human Dignity in Audiovisual and Information Services

· European Union Communication on illegal and harmful content on the Internet

· Report of European Commission Working party on illegal and harmful content on the internet

· Working Party Report

· European Commission Forum for Exchange of Information on Internet Best Practices

Media

· PICS Walks Fine Line on Net Filtering

· Good Clean PICS: The most effective censorship technology the Net has ever seen may already be installed on your desktop (Simson Garfinkel in HotWired: February 1997)

· College Hill interview with Joseph Reagle, W3C staff member

Individuals and Organizations

· EFF's Draft Policy on public interest principles for online filtration, ratings, and labeling systems. Suggested guidelines for responsible use of labeling and filtering.

· The Internet Filter Assessment Project. A group of librarians with mixed feelings about filtering examined several products in detail and discussed the issues facing libraries.

· ACLU White Paper Critical of Labeling and Filtering

· PICS-Aware Proxy System vs. Proxy Server Filters. Wayne Salamonsen and Roland Yeo, proceedings of INET '97.

· Metadata, PICS and Quality. Chris Armstrong. Ariadne magazine, May 1997.

· Rating the Net. Jonathan Weinberg. in Hasting Communications and Entertainment Law Journal, Vol. 19, No. 2, p. 453-482. (A balanced but critical academic's look at rating systems and their legal and social impact.)

· The Net Labeling Delusion (anti-PICS web site in Australia)

· Fight-censorship mailing lists (Declan McCullagh's moderated and unmoderated lists; occasional discussion of PICS and related technologies).

__________

PICS Technical Specifications

Completed Specifications for PICS-1.1

These are official W3C recommendations. They are stable.

1. Service descriptions: Specifies the format for describing a rating service's vocabulary and scales; analogous to a database schema.

2. Label format and distribution: Specifies the format of labels and methods for distributing both self-labels and third-party labels.

3. PICSRules: Specifies an interchange format for filtering preferences, so that preferences can be easily installed or sent to search engines.

These are proposed W3C recommendations. They may still change.

4. PICS Signed Labels (DSig) 1.0 Specification: Specifies the syntax and semantics of digital signatures in PICS labels.

Special Supplements to the Specifications

These are not official W3C recommendations, but they do represent a consensus of the PICS working group.

5. Default and Override Labels: Specifies what a user agent (e.g., filtering software) should do when multiple labels are available from the same service; Also suggests where filtering agents should look for self-labels if they do not arrive in or along-with a document.

Resources for Developers of Software and Labeling Services

There is a low-volume mailing list, pics-interest@w3.org for developers and potential developers of PICS related products and services. To join this list, send email to pics-ask@w3.org and say why you're interested in joining.

Resources for Software Developers

The technical specifications above are the most important resource for developers. In addition:

· Free Java implementation of parsers for PICS labels, services, and rules, evaluator for PICSRules

· PICSLE, the PICS Label Editor, also written in Java, provided courtesy of IBM T.J. Watson Research Center.

· IBM's PICS-compliant proxy server makes it easy to set up a label bureau against which you can test clients.

· Protocol extensions. These are extensions that people have defined using the extension mechanisms provided in the technical specifications.

· Hints to implementors

· Various tools and free technical advice available from the PICS Application Incubator project at the University of Michigan School of Information.

· W3C's Amaya browser will soon have PICS client features integrated, against which you will be able to test PICS-compatible server products. Please check back.

Resources for Labeling Service Developers

To start a new labeling service, you will need to take the following steps:

1. Decide who will assign labels.

· Web site operators who self-label and/or

· A panel of raters that you recruit and/or

· A computer program that analyzes the contents of materials and assigns labels

2. Decide the labeling vocabulary and criteria

3. Express the labeling vocabulary and criteria according to the format specified in the technical specification. You can create this file from scratch, or you can fill out web forms at the PICS Application Incubator and the file will be created for you.

4. Create the labels

5. Arrange for distribution of your labels

· Give your labels to someone else who is running a PICS label bureau and/or

· Run your own PICS label bureau and/or

· Convince web site operators to distribute the labels for their own pages, either by putting them into HTML META tags or sending them along with web pages.

The PICS Application Incubator project at the University of Michigan School of Information will provide a limited amount of free technical consulting to organizations that are considering establishing new labeling services.

Lists of PICS-compatible products and services.

Technology Inventory. Lorrie Cranor and Paul Resnick. This inventory was first distributed at the December 1997 Internet On-line summit: Focus on Children. The on-line version was updated until the summer of 1999. It also lists some products and services that are not PICS-compatible.

The following resource lists are being maintained by members of the PICS developers' community. Contact the maintainer of each individual list with additional links. The maintainers have all agreed to be fast and fair in maintaining these lists (please send any unresolved complaints to pics-ask@w3.org).

· Client software that reads PICS labels.

· HTTP servers that distribute labels along with documents.

· Proxy servers that perform filtering based on PICSRules.

· Label bureaus: HTTP servers that distribute third-party PICS labels through the PICS label bureau query protocol.

· Rating services

· more information "for families and caregivers" from GetNetWise

Innovative Uses of PICS Labels

The most common uses of PICS labels have been in filtering products that block access to certain materials based on labels associated with those materials. The technology inventory, however, identifies a range of other actions that can be taken based on labels: suggest, search, inform, monitor/log, and warn.

· Inform: med-PICS; a collaboration for critical appraisal of medical information on the Internet

· Search: Net Shepherd and Alta Vista offer filtered Internet search

· Inform: Alexa Internet displays PICS labels visually, but does not block access based on those labels.

· Inform: The Test-a-URL feature created by the PICS Application Incubator lets you see what labels have been assigned to any URL by several different rating services. (A similar test-a-URL feature is available for other, non PICS-based services.)

Hints for Web Site Authors Who Want to Self-Label

Many authors and web site operators offer materials that they realize will not be appropriate for all audiences. We encourage them to label their materials to make it easier for filtering software to block access. As an added inducement to labeling, we note that some future applications may use labels for searching as well as filtering. Thus, labeling your site will make it easier both for some audiences to avoid your site or documents and for others to find you.

PICS is able to remain value-neutral by refusing to endorse any particular labeling vocabulary. As a web site operator, you will not have that luxury. You'll want to adopt one or more of the rating vocabularies that other sites are using. You may want to use one of the self-rating vocabularies.

Once you have created a label, you will need to distribute it along with your document(s). PICS has defined several ways to do that. The recommended method, if your HTTP server allows it, is to insert an extra header in the HTTP header stream that precedes the contents of documents that are sent to web browsers. The correct format, as documented in the specifications, is to include the two headers, Protocol and PICS-Label:

HTTP/1.0 200 OK
Date: Thu, 30 Jun 1995 17:51:47 GMT
Last-modified: Thursday, 29-Jun-95 17:51:47 GMT
Protocol: {PICS-1.1 {headers PICS-Label}}
PICS-Label:
(PICS-1.1 "http://www.gcf.org/v2.5" labels
on "1994.11.05T08:15-0500"
exp "1995.12.31T23:59-0000"
for "http://www.greatdocs.com/foo.html"
by "George Sanderson, Jr."
ratings (suds 0.5 density 0 color/hue 1))
Content-type: text/html

...contents of foo.html...

The server can send these headers even if the browser has not specifically request them.

The next best method is to run a label bureau at a specific location on your server, as specified in a supplement to the PICS specs, distributing labels only for documents on your server.

If neither of these methods is not available to you, a simpler but more limited method is to embed labels in HTML documents using a META tag. With this method, you will be able to send labels only with HTML documents, not with images, video, or anything else. You may also find it cumbersome to insert the labels into every HTML document. Some browsers, notably Microsoft's Internet Explorer versions 3 and 4, will download the root document for your web server and look for a generic label there. For example, if no labels were embedded in the HTML for this web page (they are), Internet Explorer would look for a generic label embedded in the page at http://www.w3.org/ (generic labels can be found there). Be sure to read the supplement for information on when specific labels override generic labels and when they don't.

The following is a an example of the right way to embed a PICS label in an HTML document:

RIGHT!

<head>

<META http-equiv="PICS-Label" content='

(PICS-1.1 "http://www.gcf.org/v2.5"

labels on "1994.11.05T08:15-0500"

until "1995.12.31T23:59-0000"

for "http://w3.org/PICS/Overview.html"

ratings (suds 0.5 density 0 color/hue 1))

</head>

...contents of document here...

SSL und HTTPS

Der Microsoft Certificate Server (SSL und HTTPS)

Grundlagen der Kryptographie:

Die Sicherheit der Datenübertragung über das Internet lässt sich deutlich erhöhen, wenn die Dateien nicht im Klartext übertragen werden, sondern durch Verschlüsselungsalgorithmen unlesbar gemacht werden.

(Quelle: Microsoft Hilfe)

Man unterscheidet zwei Gruppen von Verschlüsselungsverfahren:

· Symmetrische Verfahren: Hier wird derselbe Schlüssel zur Ver- und Entschlüsselung verwendet.

· Asymmetrische Verfahren: Hier werden zwei verschiedene Schlüssel verwendet, ein „öffentlicher Schlüssel“ (public key) und ein „privater Schlüssel“ (private key).

(Quelle: Microsoft Hilfe)

Der MS Certificate Server ist im MS Option Pack für Windows NT 4.0 enthalten, wird aber standardmäßig nicht mitinstalliert. Er muss entweder nachinstalliert werden, oder wurde bereits mit der Vollinstallation des Option Packs mitinstalliert.

Der MS Certificate Server erzeugt Zertifikate im X.509-Format.

Bei der Installation des Zertifikatsservers wird ein “Notar” installiert, der selbst Zertifikate ausstellen kann. Ein solcher “Notar” (Zertifizierungsinstanz, englisch Certificate Agency, CA) benötigt selbst nur ein sogenanntes Basiszertifikat. Solche Zertifikate gelten als “absolut vertrauenswürdig” und werden durch keine weitere Instanz bestätigt. Basiszertifikate haben international natürlich nur dann Gewicht, wenn die Organisation einen hohen Bekanntheitsgrad bzw. ein hohes Vetrauen des Publikums genießt.

Möchte man eine Seite international gültig zertifizieren lassen, so gibt es dazu anerkannte Zertifizierungsinstitute:

· http://www.verisign.com

Ab jetzt ist es möglich, Schlüssel zu erstellen, die vom eben installierten Zertifikatsserver “signiert” werden können.

Das Eigenzertifikat wird im angegebenen Freigabeordner (hier: C:\cert) abgelegt:

Überprüfen der Schlüsselkonfiguration:

C:\>certutil -dump

Eintrag 0:

Name: 'WIFI'

Organisationseinheit: 'EDV'

Organisation: 'WIFI Niederoesterreich'

Ort: 'St. Poelten'

Bundesland: 'Niederoesterreich'

Land: 'AT'

Konfiguration: 'I1\WIFI'

Austauschzertifikat: 'I1_WIFI_Exchange.crt'

Signaturzertifikat: 'I1_WIFI.crt'

Beschreibung: 'Test-Instanz'

Erstellen eines eigenen Schlüssels:

Der nächste Schritt ist die Erstellung eines eigenen Schlüsselpaares. Der Schlüssel muss natürlich von einer Zertifizierungsinstitution bestätigt werden. Wir könnten die Anforderung entweder an Verisign schicken oder von unserem eigenen Zertifizierungsserver bestätigen lassen.

Rufen Sie dazu von der Microsoft Management-Konsole aus den Schlüssel-Manager auf:

Klicken Sie den abzusichernden Dienst (im allgemeinen: WWW) mit der rechten Maustaste an und wählen Sie [Neuen Schlüssel erstellen...]

Wir haben nun folgende Situation: Es wurde ein Schlüssel erstellt, der bereits zur Bestätigung der Zertifizierungsinstanz ist. Gleichzeitig wurde der Schlüssel in einer Zertifizierungsanforderungsdatei gespeichert, in unserem Fall c:\101ilg.txt.

Diese Datei sieht folgendermaßen aus:

Als nächster Schritt wird die Anforderung an der Zertifikatsserver geschickt (wir verwenden unseren eigenen), der eine Bestätigung (digitale Signatur) durchführen soll. Dafür gibt es vorinstallierte Hilfsprogramme, aufrufbar unter http://IP-Adresse/certsrv:

Kennwort eingeben (dasselbe wie bei der Erzeugung des Schlüssels)

Nun ist der Schlüssel vollständig und kann verwendet werden.

Absichern eines Verzeichnisses durch SSL:

Vorbereitung: Erstellen Sie ein Verzeichnis unterhalb eines virtuellen Servers eines Kunden. Legen Sie eine HTML-Datei in dieses Verzeichnis.

Im folgenden Beispiel wurde unterhalb des virtuellen WWW-Servers Kunde1_i1_WWW ein Verzeichnis verz angelegt, das eine Datei ssltest.htm enthält.

Rufen Sie die Eigenschaften des abzusichernden Verzeichnisses im IIS (MMC) auf, dann wählen Sie die Karteikarte “Verzeichnissicherheit”. Dort klicken Sie im Abschnitt “Sichere Kommunikation” auf die Schaltfläche “Bearbeiten...”:

Nun muss noch eine Portnummer für die SSL-Kommunikation vergeben werden, wir verwenden 443:

Tests:

Eingabe von http://.../ssltest.htm schlägt fehl.

Erst durch das Protokoll https://... ist eine Anzeige der Datei möglich.

Arbeitsplan

Certificate Server

HTTPS - Secure socket layer

Schritt 3.0

· Certificate Server von Option Disk installieren

· CA-Zertifikat (Basiszertifikat, Sitezertifikat) erstellen

· Name der Zertifizierungsinstanz: Elektronischer Notar x; "x" steht für den Computernamen, z.B. 701

· Im Anforderungsformular für das CA-Zertifikat dürfen keine Beistriche verwendet werden. Beistriche werden als Feldende interpretiert und es wird eine ungültige Anforderung ohne Fehlerwarnung erstellt.

· Überprüfen der Konfigurationsinformation: CertUtil -dump; Gibt den Inhalt der Datei CertSrv.txt aus.

· Browserinstallation des CA-Zertifikats

· IE5.0: Extras, Internetoptionen, Inhalt, Zertifikate, Vertrauenswürdige Stammzertifizierungsstellen.

· Hinweise auf Registryeinträge

· HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineKeys

· HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates

· HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\SecurityProviders

· Ordner für Konfigurationsdateien: c:\mscf

· cacerts.htm: Liste der Zertifikate der Zertifizierungsinstanz

· Internetdienstmanager

· Schlüsselmanager

· WWW: Rechtsklick - Neuen Schlüssel erstellen

· Anforderung als Datei speichern, die an eine Instanz gesendet wird: c:\Certs\NewKeyReq.txt. z.B. 701.ilg.edu.req.txt

· Schlüsselname: Computername und key, z.B. 701key

· Bei allgemeinem Namen IP-Adresse oder freindly Name angeben

· c:\certs: certreq newkeyrq.txt neqkeyaw, z.B. 701.ilg.edu.aw

· Schlüsselmanager: Schlüsselzertifikat intallieren

· Verzeichnis mit Verzeichnissicherheit einrichten; Registerkarte "Verzeichnissicherheit", Beim Zugriff auf diese Ressource sicheren Channel verlangen; mit HTTPS anwählen

· Versuche

· CA-Zertifikat ist nicht (im Browser) installiert: "Das Sicherheitszertifikat wurde von einer Firma ausgestellt, die Sie nicht als vertrauenswürdig eingestuft haben. Untersuchen Sie das Zertifikat, um festzustellen, ob Sie der ausstellenden Institution vertrauen möchten.

· Schloßsymbol in Statuszeile als Zeichen für sichere Kommunikation.

Angaben bei "Allgemeiner Name" stimmt nicht mit Namen bei DNS-Suchvorgang überein. Meldung "Der auf dem Sicherheitszertifikat angegebene Name stimmt nicht mit dem Namen der Site überein".