Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 2te Vorlesung Lehrstuhl für...

Lehrstuhl für Kommunikationssysteme - Systeme II 1

Systeme II – 2te Vorlesung

Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät

Universität Freiburg2009


Mailingliste zur Vorlesung Einrichtung einer Mailing-Liste “[email protected]...”

Ankündigungen zur Vorlesung Bei Bedarf Nachfragen/Diskussion zu Vorlesungsthemen Hinweise etc.

Verwaltet von Phillip Chlap (Hiwi am Lehrstuhl), der sich auch um Vorlesungsaufzeichnungen und Materialien kümmert

Ein- und Austragungen von der Liste bitte über ihn regeln

Vorlesung Systeme II – Organisatorisches


Theoretische Übungen Ausgabe der Blätter in den folgenden Veranstaltungen

22.04. (Bitte ein Blatt ergreifen oder Online herunterladen) 06.05. 20.05. 27.05. 10.06. 24.06. 08.07.

Zwischendrin praktische Übungsblätter in den Übungen

Bearbeitung der Blätter ist nicht verpflichtend, ebensowenig wie der Besuch der praktischen Übungen

Vorlesung Systeme II – Organisatorisches


Inhalt der Vorlesung

IP auf der Vermittlungsschicht IP Header

Fragmentierung

TTL

Ziel und Quelladressen

...

IP-Adressräume Sub / supernetting

Datagramm-Zustellung Routing-Tabelle


Intro - Motivation

‣ Basisprotokoll des Internets / Grundlage seines Erfolgs• Bietet notwendigen Service Diensten in höheren Schichten an

• Überbrückt transparent verschiedene physikalische Netze


Internet Protocol

‣ Schichtenmodelle und Implementierung


Intro - Schichtenmodelle

‣ Wiederholung: Schichtenmodelle, Protokolle und Anwendungen


Intro - Universaldienst

‣ IP (internet protocol) entspricht OSI-Layer 3 (Vermittlungs-schicht)

‣ Universeller Service zum Verbinden verschiedener Netze benötigt


Intro - Universaldienst

‣ Letzte Veranstaltung: Verschiedene Weitverkehrsnetze

‣ Hinzu kommen: Endanwender via DSL, Kabel, UMTS, ISDN, Modem, GPRS ...

‣ Local Area Netzwerke (LAN, heutzutage typischerweise Ethernet – spätere Vorlesung) in unterschiedlichen Größen:

• Zu Hause mit unter zehn Maschinen

• Große Organisationen mit vielen Tausend, ...


Intro – Universaldienst

‣ Netzwerkabstraktion• Unabhängig von physikalischer Hardware

• Ausschliesslich in Software implementiert

• Bestandteil des OS oder Applikation, die unter OS läuft

‣ Aufgaben folgend aus Vermittlungsschicht• Nachrichtentransport ohne Interpretation bzw. Prüfung der

Semantik

• Zuweisung von logischen Quell- und Ziel-Adressen

• Steuerung des Kommunikations-Subnetzes

• Routing - Paketweiterleitung


Internet Protocol

‣ Warum IP?‣ IP ist im Wesentlichen ein Vermittlungsschichtprotokoll‣ Lokale Netzwerke können nicht nur über Hubs, Switches oder

Bridges verknüpft werden• Ethernet-Hubs: Kollisionen nehmen überhand (später genauer)• Switches:

- Routen-Information durch Beobachtung der Daten ineffizient- Broadcast aller Nachrichten schafft Probleme

• Es gibt über 10 Mio. lokale Netzwerke im Internet...

‣ Zur Beförderung von Paketen in großen Netzwerken braucht man Routeninformationen• Wie baut man diese auf?• Wie leitet man Pakete weiter?


Internet Protocol

‣ Definition eines einheitlichen Adressierungsschemas, das Hardware/Software-unabhängig ist

‣ Bereitstellung eines Datagrammaustauschs zwischen Netzen

‣ Hosts – im IP Sprech: Endsysteme

‣ Router in mehr als einem Teilnetz, leiten Vermittlungsschicht- datagramme zwischen ihnen weiter

‣ Router implementieren Routing-Protokolle zum Füllen ihrer Routing-Tabellen

‣ Hilfsprotokolle (wie bspw. ARP und ICMP für IP – spätere Vor- lesungen) können benötigt werden


Internet Protocol

‣ Der IP Layer stellt damit eine Ende-zu-Ende Zustellung von Paketen sicher

‣ Dabei konsistente Datagrammabstraktion• Best-effort Zustellung

• Keine Fehlererkennung in den Daten (Payload)

• Konsistente Maximalgröße der Datagramme

• Konsistentes globales Adressierungsschema

• Sollte in der Lage sein, sich an verschiedene Paketgrößen auf dem Gesamtpfad anpassen können

‣ Implementierung der geforderten Features im IP-Header


Internet Protocol – Header

Protokoll-Header beinhaltet: Versionsfeld

Quell- und Zieladressen

Längenfelder (Header, Optionen und Daten)

Header Checksumme

Fragmentierungssteuerung

TTL und TOS Info

Wobei TOS Info normalerweise ignoriert wird Sehr leicht auf dem Weg zu ändern (warum beachten?)

Problem: Konsistente Sicht auf Prioritäten

Wie sollen die am Übergang zwischen Autonomen Systemen (letzte Vorlesung) gehandhabt werden?



Versionsfeld (4 für Standard IP, 5 STII, 6 nächste Generation IP) und IP Header-Länge haben jeweils 4 Byte

IP Header normalerweise 20 Byte groß, kann mit Optionen größer werden

Längenfeld benötigt, um zu wissen, wann der nächste Header im Paket folgt



IP Optionen können bis zu 40 Byte groß werden Feld für die Paketgesamtlänge ist 16 bit groß, woraus eine

maximale Paketlänge von 64kbyte nicht überschritten werden darf

Das Minimum liegt bei 20 Byte (nur der IP Header selbst)

Die MTU von üblichen physikalischen Netzen ist deutlich kleiner, z.B. 1500 Byte beim Ethernet

Es gibt ein 16 bit Identifikationsfeld für IP-Fragmente Wird für jedes Paket (ob gebraucht oder nicht) vom Sender des

Datagramms eingetragen

Man kann nicht wissen, ob Fragmentierung irgendwann nochmal auftritt


Internet Protocol – Fragmentierung

IP hat die Aufgabe der Datagrammanpassung IP Datagramme können nicht größe als 64 kByte sein

(Beschränkung durch Größenfeld im Header)

Layer 2 Protokolle melden initiale MTU

Linux loopback 16384 Byte Ethernet Frames können max. 1500 Byte (aufgehoben für

Gigabit-Ethernet) ATM kann 48 Byte Langsame Modem/GPRS-PPP Verbindungen könnten

bspw. 296 Byte als MTU melden In der praktischen Übung mal mit ifconfig oder ip nachsehen



Fragmentierung und Wieder-Zusammenbau Alle Verbindungsschichts-Datagramme werden in mehrere

Sicherungsschichts-Einheiten umgebaut, die kleiner/gleich zur MTU sind

Weitere Fragmentierung kann auftreten

Manchmal deshalb geschickter schon in der Quelle eine kleinere MTU einzutragen, um spätere Fragmentierung zu vermeiden (typische Situation im LAN zuhause wegen DSL/PPPoE)



Zusammenbau der Datagramme erst im Ziel(!) und nicht schon irgendwo zwischendurch

Jedes Fragment verhält sich als autonomes, vollständiges und damit routebares IP-Datagramm

Nicht im Router zusammengebaut:

Damit können sie unterschiedliche Wege durchs Netz nehmen

Reduzieren Komplexität in Router-Hard/Software Werden durch das Tripel aus Quelle, Ziel und Fragment-ID

unterschieden


Internet Protocol – Header/Fragmentierung

IP-Fragmentfelder Initiale Zerteilung der Ursprungsmessage kann noch nicht klein

genug sein für ein spezielles Teilsegment

Bei auftretender Fragmentierung wird die ID in jedes IP-Fragment kopiert

Inhalt des 16 bit Felds wird vom Sender erzeugt Verschiedene OS nutzen verschiedene Schemata zur

Generierung der ID

So kann man maskierte Hosts durch ihre Fragment-IDs unterscheiden, da die Zähler jeder Maschine unterschiedliche Werte haben (z.B. Traffic-abhängig)

Private Netze können so unbewusst Informationen liefern



IP-Fragmentierung - weitere Felder: Flags für Fragmentierungssteuerung

MF: More fragments (folgen)

DF: dont fragment (Einige Protocol Implementierungen wie DHCP in Boot-ROMs können Pakete nicht wieder zusammenbauen)

Feature kann für MTU Path Discovery genutzt werden (Erhöhen der Paketgröße bis keine ICMP Fehlermeldung mehr kommt)

Fragmentation Offset



IP-Fragmentierung - weitere Felder: Offset bezieht sich auf das Originaldatagramm

Feld ist Null, wenn keine Fragmentierung genutzt wurde

Warum Offset und nicht Fragmentnummern? Falls weitere Fragmentierung benötigt wird – Fragmentierung

von Fragmenten

Fehlertolerant bei vertauschter Reihenfolge beim Empfang und bei Duplizierung



Probleme durch Fragmentierung: Verlust von einem oder mehr Fragmenten impliziert den Verlust

des gesamten Originaldatagramms

IP ist “best effort” und hat damit keine Wieder-Übertragung bei Verlust, muss erst ein Time-Out auftreten, damit Verlust klar wird

Kann Interessant für DoS Angriffe sein (Crash von Maschinen oder deren IP-Stack, Einschleusen von Fragmenten, ...)

Fragmentierungskonzept wurde deshalb mit IPv6 komplett geändert



Weitere Header-Felder TTL mit 8 bit (Max. Netzwerkdurchmesser von 256 Routern)

Sorgt für das “Verschwinden” von unzustellbaren, kreisgerouteten Paketen aus dem Netz

-1 bei jedem Router-Hop (bei jeder vergangenen Sekunde)



Weitere Header-Felder Protocol mit 8 bit

Wohin soll das Paket nach weiter oben im Stack (Transport-schicht) weitergereicht werden?

Typische Kennungen:

TCP – 6 (spätere Vorlesung) UDP – 17 (spätere Vorlesung) ICMP – 1 (IP Status-Protokoll für bestimmte Meldungen) IGMP – 2 (Multicast, spätere Vorlesung) IP – 4 (warum – IP-in-IP-Szenarien)

Weitere siehe beispielsweise /etc/protocols in der praktischen Übung



Weitere Header-Felder Header Checksum – Überprüfung der Integrität des Headers

Warum nicht gleich des gesamten Pakets?

Nicht Aufgabe der Vermittlungsschicht Aufwand – muss beim Routerdurchlauf erneut erzeugt

werden (warum?) Fragmentierung



Adressen als wichtig(st)e Header-Information Zwei 32 bit Felder für Quell- und Zieladressen

Für Routing-Entscheidungen wird nur die Binärform verwendet – die Dezimaldarstellung mit Punkten ist lediglich für menschliche Lesbarkeit



Programme und Betriebssystems übersetzen IP-Adressen deshalb automatisch zwischen den beiden Repräsentationen

IP-Adressen sind/waren topologisch sensitiv Host-Interfaces im selben Netzwerk haben dasselbe Prefix

Prefix wird durch ISP oder lokale Netzwerkadmins zugeteilt, wobei sie 32-bit global eindeutig sein müssen (mit bestimmten Einschränkungen)


Internet Protocol – Header/Adressen

IP-Adressen sind damit (virtuell) in Netzwerk- und Host-Teil aufgespalten



Frühe Standards definierten für diese Aufteilungen ursprünglich fünf Adressklassen

A, B, C, D and E

IP-Adresseen sollten selbsterklärend sein, sie sollten Informationen zur Netzwerkstruktur enthalten – ist aber Geschichte

In dieser Darstellung besteht eine IP aus bestimmten Mustern von höherwertigen Bits, welche die Klasse repräsentierten, gefolgt von einem Netzwerk und Host Anteil

Rechner im selben Netzwerk besitzen ein gemeinsames Prefix und müssen ein eindeutiges Suffix haben


Internet Protocol – Adressklassen



Klasse A: (high order bits: 0) Große Organisationen, wenige Netze (127), gewaltige Zahl von

Hosts (16.7 Millionen, völlig unrealistisch)

Adressbereich in Dezimaldarstellung 0.0.0.0 – 127.255.255.255

Class B: (high order bits: 10) Mittelgroße Organisationen und Firmen, wie beispielsweise die

Universitäten in Deutschland, es gibt einige Netze (16,384 – viel zu wenige) und eine größere Zahl von Hosts (65,536)

Adressebereich 128.0.0.0 – 191.255.255.255

Class C: (high order bits: 110) Kleine Organisationen und Firmen, ziemlich viele Netze

(2,097,152) mit einer kleinen Zahl von Maschinen pro Netz



Klasse C reicht von 192.0.0.0 bis 223.255.255.255

Class D: (high order bits: 1110) Multicast-Adresses, definiert aber kaum wirklich genutzt –

deutlich anders als A – C (spätere Vorlesung)

Adresse range 224.0.0.0 – 239.255.255.255

Class E: (high order bits: 1111) Für experimentelle Nutzung reserviert

Adresse range 240.0.0.0 – 255.255.255.255

Theoretischer Adressraum mit 4,294,967,296 sieht üppig aus, aber jetzige Erdbevölkerung schon größer

Zudem im Internet nur 1.X.Y.Z bis 223.X.Y.Z (mit weiteren Lücken) nutzbar

http://X.Y.Z/



Weitere Spezialadressen sind nicht direkt nutzbar: 0.0.0.0 definiert die sogenannte default route or ist die

spezielle Startadresse eines Hosts, der nach einer dynamisch vergebenen IP fragt

255.255.255.255 ist die lokale broadcast Adresse (und die damit auch die Zieladresse in Paketen von Hosts, die DHCP machen)

127.0.0.0 ist ein sehr großer Bereich für die spezielle loop back network Adresse (wo man eigentlich immer nur genau eine, typischerweise die 127.0.0.1 braucht)

Diese Adresse findet man auf jeder Maschine mit IP für Applikationen, die IP nutzen ohne dafür die Maschine selbst zu verlassen



Spezialadressen, die nur eingeschränkt nutzbar sind: Adressen für private Nutzung – Viele Organizationen nutzen IP,

aber mit eingeschränktem/abgeschotteten Zugriff

10.0.0.0 – 10.255.255.255 (im Klasse A Bereich) 172.16.0.0 – 172.31.255.255 (16 Klasse B Netze) 192.168.0.0 – 192.168.255.255 (65,536 Klasse C)

So hat das Universitäts-WLAN primär 10.X.Y.Z Adressen, über die dann eine “echte” IP via VPN bezogen wird (alles andere wäre Verschwendung und gegen das Konzept)

Pakete mit Adressen aus diesen Bereichen sollten auf Internet Routern verworfen werden

http://X.Y.Z/



Für Adressierung ganzer Subnetze oder die Ansprache aller Hosts in einem gegeben LAN (hängt aber von den Fähigkeiten der darunterliegenden phys. Netze ab) wurden ebenfalls spezielle IP-Adressen definiert

Netzwerk Nummer ist die kleinste IP-Adresse in einem gegebenen (Sub)Netzwerk, sie adressiert nicht eine Maschine und darf daher nicht an einen Host vergeben werden. Man findet sie in den Routingtabellen (Ende dieser Vorlesung)

Broadcast Adresse ist die größtmögliche IP in einem Netzwerk. Nicht für einen einzelnen Host – an diese Adresse kann man alle Hosts in einem Subnetz mit einem einzigen Paket erreichen (kommt auf das drunterliegende phys. Netz an)



Wenn man nun die Beispiel Klasse B Adresse 172.31.5.200 nimmt:

Dieser Host ist ein Mitglied im Netzwerk mit der Netzwerk Nummer 172.31.0.0 und einer Broadcast Adresse 172.31.255.255

Andere Zuordnungen möglich, denn

Netzwerke mit einer sehr großen Zahl von Hosts lassen sich in Subnetze für bessere Administration und Berücksichtigung der physikalischen Netzwerktopologien (zu diesen mehr in der Vorlesung zu Schichten 1 & 2) aufteilen



Das Beispiel Klasse B Netzwerk 172.16 mit 65536 Host IP Adressen, erlaubt z.B. die Aufteilung in 256 Subnetze mit 256 Hosts (minus Netz- und Broadcast-Adresse) falls an der Byte-Grenze unterteilt

Jedoch: Die resultierenden 256 “Klasse C Netzwerke” haben dasselbe “high order bit” Muser, wie das originale Klasse B Netzwerk


Internet Protocol – Subnetze

Die Zahl der Klasse B Netzwerke war deutlich zu wenig (Deutschland alleine hat schon mehr als 100 Universitäten und Fach/Hochschulen und würde alleine schon mindestens 100 Klasse B Netzwerke der vorhandenen 16,384 verbraten)

... und es gibt keinen wirklichen Bedarf für Klasse A Netzwerke (IBM, HP, ... hatten mal eines – im RFC nachlesen)

Es gibt Bedarf für größere Netzwerke als Klasse C, die jedoch deutlich kleiner als B sind

Die Adress”verschwendung” war zu Beginn groß, so dass der Bedarf nach IPv6 Mitte der 1990er sehr hoch schien

Aber erstmal wurde das Konzept von Sub- und Supernetzen eingeführt



“Supernetting” bedeutet die Aneinanderhängung von Adressräumen zu größeren mit genau einer gemeinsamen Netzwerk- und Broadcast-Adresse

Damit IP Adressen nicht mehr selbsterklärend Zur Info auf die Spanne von Adressen wurden Netzmasken

definiert: “1” markiert den Prefix Teil IP (Netzwerk) “0” den Suffixteil einer IP (Host)



Die Netzmaske von 255.255.0.0 markiert gerade die Größe eines Klasse B Netzwerks, 255.0.0.0 steht für Größen der Klasse A und 255.255.255.0 für C

Netzmaskes lassen sich durch die Zahl der “1” in der Netzmaske abkürzen: Klasse A: 8, B: 16, C: 24

Bei der Zusammenfassung von zwei Klasse C Netzwerken in ein größeres, ergibt das aus:

Netzwerk 192.168.10.0 mit Broadcast 192.168.10.255 &

Netzwerk 192.168.11.0 mit Broadcast 192.168.11.255

Ein kombiniertes Netz: Netzwerk 192.168.10.0 mit Broadcast 192.168.11.255 und

Netzmaske 255.255.254.0



Aufteilung der Netzmaske in Prefix und Suffix passiert am Übergang zwischen “1” und “0”

Beispielsweise steht “1111 1111.1111 1111.1 000 0000.0000 0000” für die Netzmaske 255.255.128.0 (vielfach sieht man auch die Abkürzung zu 17, Zahl der “1” in der Maske)

Wenn wir das Netzwerk 132.230.0.0/255.255.0.0 in zwei Subnetze aufteilen wollen:

132.230.0.0 – 132.230.127.255 132.230.128.0 – 132.230.255.255



Theoretisch könnte man das Netzwerk auch anders teilen: 1111 1111.1111 1111.0000 0000.0000 0001 ist die Netzmaske

255.255.0.1 und man erhält zwei Subnetze, eines mit geraden Zahlen (im letzten Octet der IP Adresse) und eines mit den ungeraden IP Adressen

Das Management von Netzwerken in dieser Weise ist jedoch ziemlich riskant und hängt von der Implementierung des IP-Stacks ab – ausprobieren :)



Generell gilt Netzwerk können zur größeren zusammengefasst und große geteilt werden:

Aufteilung bedeutet addieren einer “1” zur Netzmaske (verlängern des Prefix und Verkürzung des Suffix)

Zusammenfassung von Netzwerken durch Entfernen einer “1” von der Netzmaske und Hinzufügen einer “0” stattdessen

Deshalb gibts derzeit (noch) einige Blöcke von Klasse C Netzwerken zur Verteilung, was den Drang nach IP v6 erstmal etwas reduziert(e)



Nachteil: Zusätzliche Information ist benötigt und Router brauchen mehr

Speicher, um sich die Netzmasken in Kombination mit den Netzwerknamen zu merken

Vorteil: Routing-Tabellen können durch geeignete Aggregation von

Routen vereinfacht werden

Damit alle Informationen (Header) und Konzepte (Adressierung) vorhanden, um sich über die Routing-Funktionalität von IP zu unterhalten

Einsatz von Tabellen mit Zielnetzen (Routing Tables)


Internet Protocol – Routing

IP-Routing-Tabelle Enthält für Ziel (Destination) die Adresse des nächsten

Rechners (Router oft auch als Gateway bezeichnet)

Destination kann einen Rechner oder ganze Sub-nets beschreiben

Einträge sind nach Netzmaske sortiert (von oben nach unten mit sinkender Zahl an “1” für Prefix)

Zusätzlich wird am unteren Ende der Tabelle ein Default-Gateway angegeben (Netzmaske 0.0.0.0)



Packet Forwarding Auch Packet Routing genannt (früher)

IP-Paket (Datagramm) enthält Start-IP-Adresse und Ziel-IP-Adresse im Header:

Ist Ziel-IP-Adresse = eigene Rechneradresse dann Nachricht ausgeliefert

Ist Ziel-IP-Adresse in Routing-Tabelle dann leite Paket zum angegeben Gateway

Ist Ziel-IP-Subnetz in Routing-Tabelle dann leite Paket zum angegeben Gateway

Ansonsten leite zum Default-Gateway Darauf hin sich mal die Routing-Tabelle im eigenen Rechner

ansehen



Im Router kommt die bereits angesprochene TTL zum Tragen:

Behandlung eines Pakets

Verringere TTL (Time to Live) um 1 Falls TTL ≠ 0 dann Packet-Forwarding aufgrund der

Routing-Tabelle Falls TTL = 0 oder bei Problemen in Packet-Forwarding: Lösche Paket Falls Paket ist kein ICMP-Paket dann Sende spezielles IP/ICMP-Paket mit

Start= aktuelle IP-Adresse und Ziel = alte Start-IP-Adresse


Ende der zweiten VorlesungEnde der zweiten Vorlesung

Nächste Vorlesung am Montag an diesem Ort, gleiche Zeit: Weiter zu IP/Routing

Alle relevanten Informationen auf der Webseite zur Vorlesung: http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

Mailingliste wird in der Zwischenzeit aufgesetzt und eine erste Info-Mail verschickt ...

Zu lesen: Kapitel zu IP, Header und Routing in der angegebenen Literatur!

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 2te Vorlesung Lehrstuhl für...

Documents

Transcript of Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 2te Vorlesung Lehrstuhl für...