Vorbemerkung: Auf dieser Seite soll nur ein kurzer Einblick stattfinden. Für das komplette Gebiet gibt es umfangreiche Literatur.
IP-Adressen teilen sich in Netzwerk- und Host-Adresse / -Adressteil auf. Bevor Netzwerkmasken eingeführt wurden, gab es die Einteilung in Klassen.
In "klassischen" TCP/IP-Netzwerken teilt man den IP-Adressbereich in 3 bzw. 5 Klassen auf:
|
---|
126 Subnetze mit je 16777214 Hosts
|
---|
16384 Subnetze mit je 65534 Hosts
|
---|
2097152 Subnetze mit je 254 Hosts
Die beiden folgenden Klassen sind spezielle Klassen und tauchen in vielen Lehrbüchern nicht auf:
Besondere Adressen:
"Private Netzwerke"
Die Internet Engineering Task Force (IETF) hat in "weiser" Voraussicht drei (bzw. vier) Adress-Bereiche für die private Nutzung festgelegt, die durch die IANA (Internet Assigned Numbers Authority) reserviert sind. Für diese Adress-Bereiche ist festgelegt, dass sie im Internet nicht geroutet werden (siehe RFC1917). Das bedeutet, dass selbst bei direkter Anbindung eines Rechners mit solch einer Adresse seine IP-Pakete nicht vom Provider weitergeleitet werden. (Trotzdem ist eine solche Anbindung aus Sicherheitsgründen nicht zu empfehlen)
Damit ein Internet-Zugriff erfolgen kann müssen durch NAT (Network Address Translation) im Router diese Adressen in "öffentliche" umgewandelt werden.
Einige Provider nutzen private Adressen ebenfalls für ihre eigenen Zwecke, um Kosten zu sparen (Nutzung weniger öffentlicher IP-Adressen durch Verwendung von Masquerading / NAT).
Je nach Komplexität des Netzwerkes kann man einen der folgenden Adressbereiche nutzen:
Wer genau aufgepasst und mitgezählt hat, wird bemerkt haben, dass ein paar Hosts / Adressen "fehlen".
Der Grund liegt in speziellen reservierten Adressen / Adressbereichen.
Das Klassenkonzept hat den Nachteil, das es für die Praxis zu starr ist.
Der Netzwerkadministrator sollte selbst festlegen können, wieviele Bits auf den Netzwerk- bzw. Host-Anteil entfallen sollen. Aus diesem Grund wurden (Sub-)Netzwerkmasken eingeführt. Dadurch können kleinere (Teil-)Netze verwirklicht werden.
Eine Netzwerkmaske legt fest, welche Bits für das Netz und welche für die Hosts genutzt werden. Die Netzwerkklassen werden in derselben Notation geschrieben wie die Adressen. Jedes Bit, das in der Maske gesetzt ist definiert das korrespondierende Bit des Subnetz-Anteils in der Adresse.
Die Standard-Subnetzmasken sind so definiert, dass sie genau ein Subnetz im Adressraum abdecken:
|
---|
Mit Hilfe der IP-Adresse und der Subnetz-Maske lassen sich die Netzwerk- und die Broadcast-Adresse berechnen.
Logische UND-Verknüpfung der IP-Adresse mit der Subnetz-Maske = IP-Adresse des Netzwerks,
Logische ODER-Verknüpfung der IP-Adresse mit der (bit)negierten Subnetz-Maske = Broadcast-Adresse des Netzwerks.
Beispiel:
|
---|
Je nach Subnetz können weitere "Einsen" an die Subnetzmaske angehängt werden (zur Vereinfachung der Administration des Netzwerks empfohlen, jedoch kein "Muss" - siehe dazu auch RFC950).
Daraus ergeben sich dann folgende möglichen IP-Subnetzmasken:
|
---|
Dieses Verfahren wird auch als Subnetting bezeichnet.
Beispiel "29Bit extended-network-prefix":
|
---|
Als das "Subnetting" im RFC950 definiert wurde, war die Nutzung der sogenannten "all-0's" und "all-1's" Subnets nicht gestattet, da die bisherigen Router ("classful router") auf solche Situation unkontrolliert (verwirrt) reagierten. Heutige Router können gleichzeitig "classful" (RIP-1-Protokoll) und "classless" (BGP-4-Protokoll) arbeiten.
Beispiel "all-0's":
|
---|
Für den Router wären das SubNet 197.23.6.0/28 und das Netzwerk 197.23.6.0/24 identisch (197.23.6.0), was der Router nicht voneinander trennen könnte ohne Kenntnis der Prefix-Länge oder Netzwerk-Maske.
Beispiel "all-1's":
|
---|
Hier würde die gleiche Broadcast-Adresse (197.23.6.255) sowohl für das gesamte Netzwerk 197.23.6.0/24 als auch für das Subnetz 197.23.6.240 benutzt werden, was z.B. auch zu einem stärkerem (und ungewollten) Netzwerk-Traffic im gesamten Netz führen würde.
Die Einführung der IP-Adressklassen hat natürlich auch Nachteile. Falls z.B. ein (kleiner) Provider (nur) 70.000 Adressen benötigt, würde er schon ein Klasse-A-Netz oder zwei Klasse-B-Netze benötigen. In beiden Fällen würden aber unzählige IP-Adressen (ca. 16 Millionen bzw. 60.000) unbenutzt bleiben. Man könnte das Ganze natürlich auch mit 276 Klasse-C-Netzen lösen (und nur 104 unbenutzten IP-Adressen), aber der Verwaltungsaufwand wäre enorm.
Selbst so große Provider wie T-Online oder AOL sucht man unter den Klasse-A-Besitzern vergebens, weniger als die Hälfte ist vergeben worden!
Da die Klassen eingeführt wurden, um das Routing zu vereinfachen, ist durch die enorm gestiegene Rechenleistung moderner Rechner ein allgemeineres Konzept - das des klassenlosen Inter-Domän-Routings (CIDR - Classless Interdomain Routing - auch Supernetting genannt, siehe RFC1518 bis RFC1520) - möglich.
Da noch nicht alle Router umgestellt worden sind, ist hierbei auf eine gewisse Abwärtskompatibilität geachtet worden.
Bei CIDR werden die IP-Adressen nicht mehr in Klassen eingeteilt, sondern bekommen eine beliebige Anzahl an Präfix-Bits zugeordnet. Ein Klasse-A-Netz hat demzufolge 8 Präfix-Bis, ein Klasse-B-Netz 16 Bit und ein Klasse-C-Netz 24 Bit.
Da die Länge der Präfix-Bits aber beliebig sein darf, wäre für das obige Beispiel eine Präfix-Länge von 15 Bits das Optimum darstellt. Dadurch sind für die Hosts 17 Bit adressierbar, was 217=131072 Host entspricht.
Statt der Schreibweise "201.136.222.177/255.255.255.0" aus dem Beispiel weiter oben, schreibt man nun "201.136.222.177/24", d.h. hinter die IP-Adresse wird die Anzahl der Präfix-Bits gehängt.
Es sind also auch Netzwerkadressen wie 217.25.173.0/23 möglich, wobei nicht im Präfix enthaltene Teile (also Nullen) weggelassen werden können: 217.25.173/23 .
Beispiele:
|
---|
Jedes dieser zusammenhängenden Adress-Blöcke mit dem Prefix "/19" enthält 2(32-19) = 213 = 8192 Host-Adressen.
Diese Netze können auch weiterhin auf eine traditionelle Klasse A-, B- oder C-Netzwerknummer abgebildet werden.
CIDR Adress-Blöcke:
|
---|
Zusätzlich werden die verbliebenen Klasse C Adressen restriktiver und strukturierter vergeben (RFC 1519).
Die Welt ist dabei in vier Zonen, von denen jede einen Teil des verbliebenen Klasse C Adressraums erhält, aufgeteilt:
|
---|
Jede der Zonen erhält dadurch in etwa 32 Millionen Adressen zugewiesen. Vorteil bei diesem Vorgehen ist, dass die 32 Millionen Adressen einer Region im Prinzip zu einem Eintrag in den Routing-Tabellen komprimiert worden sind. Der Vorteil der dadurch entsteht ist, dass z.B. jeder Router, der eine Adresse außerhalb seiner Region zugesandt bekommt schneller das Ziel bestimmen kann, da er nicht mehr so viele komplizierte Routing-Tabellen vorhalten muss...
Das oben angesprochene Internet-Protokoll Version 4 (IPv4) stößt langsam an seine Grenzen, nicht nur betreffs des knapper werdenden Adressraums, sondern auch der fehlenden Echtzeit-Datenübertragungs-Unterstützung (z.B. für "richtige" Multimediaanwendungen benötigt) wegen.
Bereits seit geraumer Zeit (seit 1990) beschäftigt sich das IETF mit der Entwicklung eines neuen IP-Protokolls.
Dabei sollten vor allem folgende Ziele umgesetzt werden:
Statt bisher 32 Bit hat IPv6 nun 128 Bit für die Adressen (2128 sind mehr als 3,4*1038 Adressen).
Eine Adresse in IPv6-Notation wird in 8 Komponenten zu je 16 Bit dargestellt:
2C47:0:0:0:0:7:54:17AF wäre also eine gültige Adresse. Es existiert auch hier eine abkürzende Schreibweise, auch hier werden die Nullen weggelassen:
2C47:::::7:54:17AF.
Wie man sieht, kommt man hier ohne DNS und ähnlichen Maßnahmen kaum noch aus.
Es existiert auch eine Mischform aus IPv6- und IPv4-Adressen, um den Wechsel auf IPv6 zu erleichtern. Router, die sowohl IPv6 als auch IPv4 verstehen, bekommen eine IPv4 kompatible IPv6-Adresse, bei der die ersten 6 Komponenten "Null" sind und so dargestellt werden:
0:0:0:0:0:0:32.154.222.87 bzw. verkürzt ::32.154.222.87 .
Alte IPv4-Adressen werden wie folgt in das IPv6-Adressschema integriert:
201.136.222.177 => ::FFFF:201.136.222.177 , d.h. die sechste Komponente enthält den Wert "FFFF".
In der Übergangszeit werden die IPv6-Pakete dann über die alten IPv4-Protokolle "getunnelt", wo noch keine IPv6-fähigen Routen existieren.
Durch den massiven Widerstand der Internet Service Provider kann die Einführung des neuen Protokolls (hohe Investitionskosten) aber noch eine ganze Zeit auf sich warten lassen.
In privaten Netzen (insbesondere Linux-Netzen) ist es aber schon ab und zu anzutreffen.
© 2003 by | |
|