N05 Der ganze Rest.pptx - Tamdhu www root

Rechnernetze Sommer 2014 Rechnernetze ... der ganze Rest! UDP (c) Peter Sturm, Uni Trier 1 Rechnernetze Sommer 2014 UDP •  UDP = User Datagram Protocol –  End-­‐to-­‐End-­‐Version von IP (Portnummer) •  Best-­‐Effort –  Nachrichtenverluste –  Keine Ordnung –  Keine Flußkontrolle Source port UDP length DesYnaYon port UDP checksum •  8 Byte Header •  Maximale Datagramm-­‐Länge: 64 Kbyte inkl. Header •  UDP-­‐MulYcast möglich –  Angabe einer MulYcast-­‐IP-­‐Adresse als Empfänger –  Meist von Sysadmins ausgeschaltet TCP (c) Peter Sturm, Uni Trier 2 Rechnernetze Sommer 2014 Transmission Control Protocol (TCP) •  Reliable Stream – 
– 
– 
– 
– 
VerbindungsorienYert Voll-­‐Duplex Keine Nachrichtenverluste Reihenfolge-­‐erhaltend Wegfall der Paketgrenzen •  Arbeitspferd des Internets •  VielfälYge Anforderungen –  Ausnutzung der Speicherfähigkeit des Mediums –  Schnelle ReakYon bei interakYven Verbindungen –  Flußkontrolle (Sliding-­‐Window) Quicungsbetrieb •  Gründe –  ReakYon auf Nachrichtenverluste –  Erkennen von NetzparYYonen –  Erkennen von Ausfällen •  Empfänger •  KommunikaYonssystem Sender Empfänger Timeout setzen Timeout ACK –  Flußkontrolle •  langsame Empfänger •  Grundlage Timeout –  PosiYve Quicung (Implizite Wiederholung) –  NegaYve Quicung (Explizite Anforderung) Sender Empfänger Receive + Timeout setzen Timeout NACK •  Nachteil: Schlechte Auslastung des Mediums bei hoher Latenz (c) Peter Sturm, Uni Trier 3 Rechnernetze Sommer 2014 Speicherfähigkeit des Mediums •  Raumsonde Voyager 2 Abstand zur Erde (April 2013): 18481 Millionen Kilometer Roundtrip-­‐Zeit: 34h, 13min, 48s Annahme 100 Mbit pro Sekunde: 1.4 Tbyte Speicherkapazität KonYnuierliches Senden • 
Nachrichten nummerieren • 
Sender verwaltet Liste der noch nicht quiierten Nachrichten –  Empfänger kann durch Senden von NACK fehlende Nachrichten nachträglich anfordern Sender NACK 2,3 ACK 1-­‐5 (c) Peter Sturm, Uni Trier Empfänger 1 2 3 4 5 6 2 3 7 • 
Empfänger verwaltet Liste der empfangenen Nachrichten –  Sender kann durch Empfang von ACK erfolgreich übermicelte Nachrichten aus der Liste enjernen • 
SelekYve Wiederholung • 
Go-­‐Back-­‐N • 
Probleme – 
– 
– 
– 
Komplexe Protokolle Hoher Pufferbedarf Schlechtes Hochlastverhalten Sender paßt sich dem Tempo des Empfängers nicht an 4 Rechnernetze Sommer 2014 Flußkontrolle: Sliding-­‐Window-­‐Protokolle •  Ziele –  Tempo von Sender und Empfänger anpassen –  Speicherkapazität des Mediums opYmal nutzen •  Sender verwaltet Fenster von maximal n unquiierten Nachrichten – 
– 
– 
– 
Sender kann Empfänger um maximal n Nachrichten vorauslaufen Innerhalb des Fensters Quicungsbetrieb analog konYnuierlichem Senden Bei n austehenden Quicungen Blockade des Senders Wahl von n hängt u.a. von der Speicherkapazität ab Fenster n=4 11 10 9 8 7 6 5 Nicht Gesendet 4 3 2 1 Quiiert TCP hl source port desYnaYon port Sequence numbers flags Window size checksum Urgent pointer •  TCP = Transmission Control Protocol •  Reliable Stream –  VerbindungsorienYert –  Flußkontrolle (Sliding-­‐Window) –  Duplex •  Segmente –  Maximale Datenmenge die in einem Schric übertragen wird –  Maximale Segmentgröße (MSS) „handeln“ Sender und Empfänger aus (c) Peter Sturm, Uni Trier 5 Rechnernetze Sommer 2014 TCP Header Source Port (16 Bit) DesYnaYon Port (16 Bit) Sequence Number (32 Bit) Acknowledgement Number (32 Bit) Header Length Flags TCP Checksum (16 Bit) Window Size (16 Bit) Urgent Pointer (16 Bit) FIN SYN RST PSH ACK URG OpYonen (falls vorhanden) Bestandteile •  Portnummer Sender/Empfänger •  Sequence Number –  Laufende Nummer des ersten Datenbytes in der Nachricht –  Vorschlag bei Ausau der Verbindung •  Acknowledgement Number –  Laufende Number des Datenbytes, das Sender als nächstes erwartet •  Header Length –  Länge in Einheiten von 4 Byte (max. 60 Byte Header) •  Window Size –  Aktuelle Fenstergröße •  Checksum –  Prüfsumme über TCP-­‐Header und Daten •  Urgent Pointer –  Zeigt auf das letzte “dringende” Datenbyte im Paket (c) Peter Sturm, Uni Trier 6 Rechnernetze Sommer 2014 Die Flags •  URG –  Urgent Pointer im Header ist gülYg •  ACK –  Acknowledgement Number ist gülYg •  PSH –  Daten schnellstmöglich an Anwendung weitergeben •  RST –  Verbindungen zurücksetzen •  SYN –  Sequenznummer beim Verbindungsausau synchronisieren •  FIN –  Sender beendet Datenübertragung All Flags on •  RFC 1025 [J.B. Postel, 1987, “TCP and IP Bake Off”] calls a segment with the maximum combinaYon of allowable flag bits turned on at once (SYN, URG, PSH, FIN, and 1 byte of data) a Kamikaze packet. It’s also known as a nastygram, Christmas tree packet, and lamp test segment •  Es gab TCP/IP-­‐Protokollstacks, die bei einem Kamikaze Packet einfach abgestürzt sind und das Betriebssystem gleich mitgerissen haben. (c) Peter Sturm, Uni Trier 7 Rechnernetze Sommer 2014 Beispiel für eine TCP-­‐Verbindung 11:42:03.483508 IP localhost.50484 > localhost.50244: S 4033456674:4033456674(0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 387601565 0,sackOK,eol> 11:42:03.483560 IP localhost.50244 > localhost.50484: S 2074141348:2074141348(0) ack 4033456675 win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 387601565 387601565,sackOK,eol> 11:42:03.483573 IP localhost.50484 > localhost.50244: . ack 1 win 65535 <nop,nop,timestamp 387601565 387601565> 11:42:03.483585 IP localhost.50244 > localhost.50484: . ack 1 win 65535 <nop,nop,timestamp 387601565 387601565> 11:42:03.483621 IP localhost.50484 > localhost.50244: P 1:101(100) ack 1 win 65535 <nop,nop,timestamp 387601565 387601565> 11:42:03.483636 IP localhost.50244 > localhost.50484: . ack 101 win 65535 <nop,nop,timestamp 387601565 387601565> … 11:42:06.484445 IP localhost.50484 > localhost.50244: P 301:401(100) ack 1 win 65535 <nop,nop,timestamp 387601595 387601585> 11:42:06.484537 IP localhost.50244 > localhost.50484: . ack 401 win 65535 <nop,nop,timestamp 387601595 387601595> 11:42:07.484721 IP localhost.50484 > localhost.50244: F 401:401(0) ack 1 win 65535 <nop,nop,timestamp 387601605 387601595> 11:42:07.484813 IP localhost.50244 > localhost.50484: . ack 402 win 65535 <nop,nop,timestamp 387601605 387601605> 11:42:07.484838 IP localhost.50484 > localhost.50244: . ack 1 win 65535 <nop,nop,timestamp 387601605 387601605> OpYons Kind •  End of opYon (kind = 0) 0 •  No operaYon (kind = 1) –  Padding auf Vielfaches von 4 Byte 1 •  Maximum segment size (kind = 2) 2 len 4 3 len 3 4 len 10 (c) Peter Sturm, Uni Trier MSS •  Window scale factor (kind = 3) •  Timestamp (kind = 4) sc Timestamp Value Timestamp Reply 8 Rechnernetze Sommer 2014 OpYonen in einer TCP-­‐Verbindung 11:42:03.483508 IP localhost.50484 > localhost.50244: S 4033456674:4033456674(0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 387601565 0,sackOK,eol> 11:42:03.483560 IP localhost.50244 > localhost.50484: S 2074141348:2074141348(0) ack 4033456675 win 65535 <mss 16344,nop,wscale 3,nop,nop,timestamp 387601565 387601565,sackOK,eol> 11:42:03.483573 IP localhost.50484 > localhost.50244: . ack 1 win 65535 <nop,nop,timestamp 387601565 387601565> 11:42:03.483585 IP localhost.50244 > localhost.50484: . ack 1 win 65535 <nop,nop,timestamp 387601565 387601565> 11:42:03.483621 IP localhost.50484 > localhost.50244: P 1:101(100) ack 1 win 65535 <nop,nop,timestamp 387601565 387601565> 11:42:03.483636 IP localhost.50244 > localhost.50484: . ack 101 win 65535 <nop,nop,timestamp 387601565 387601565> … 11:42:06.484445 IP localhost.50484 > localhost.50244: P 301:401(100) ack 1 win 65535 <nop,nop,timestamp 387601595 387601585> 11:42:06.484537 IP localhost.50244 > localhost.50484: . ack 401 win 65535 <nop,nop,timestamp 387601595 387601595> 11:42:07.484721 IP localhost.50484 > localhost.50244: F 401:401(0) ack 1 win 65535 <nop,nop,timestamp 387601605 387601595> 11:42:07.484813 IP localhost.50244 > localhost.50484: . ack 402 win 65535 <nop,nop,timestamp 387601605 387601605> 11:42:07.484838 IP localhost.50484 > localhost.50244: . ack 1 win 65535 <nop,nop,timestamp 387601605 387601605> Verbindungsausau Client IniYal Sequence Number Server SYN, ISN Client (acYve open) SYN, ISN Server ACK ISN Client + 1 (passive open) ACK, ISN Server + 1 3 Way Handshake (c) Peter Sturm, Uni Trier 9 Rechnernetze Sommer 2014 Timeout beim Verbindungsausau 12:35:02.643496 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 387633313 0,sackOK,eol> 12:35:03.614692 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 387633322 0,sackOK,eol> 12:35:04.616383 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 387633332 0,sackOK,eol> 12:35:05.617975 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> 12:35:06.619513 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> 12:35:07.621131 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> 12:35:09.624411 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> 12:35:13.630349 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> 12:35:21.643850 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> 12:35:37.668238 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> 12:36:09.714995 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826(0) win 65535 <mss 1460,sackOK,eol> Verbindungsabbau Client Server FIN Half Close ACK FIN ACK (c) Peter Sturm, Uni Trier 10 Rechnernetze Sommer 2014 DNS Mapping Names to IP Addresses What‘s the addre
ss of www.uni-­‐trier.d
e 136.199.199.105 Name Service Client 136.199.51.201 (c) Peter Sturm, Uni Trier Name Service Server 136.199.54.116 11 Rechnernetze Sommer 2014 Übersicht DNS •  Domain Name Service •  Hierarchischer Namensraum: balvenie.uni-­‐trier.de •  TransformaYon –  Domain Name → IP-­‐Adresse (Lookup) –  IP-­‐Adresse → Domain Name (Reverse Lookup) •  UNIX-­‐API –  gethostbyname() –  gethostbyaddr() •  IETF-­‐Standard –  RFC 1034 (Konzepte) –  RFC 1035 (ImplemenYerungsdetails) •  Gängige ImplemenYerung –  Berkeley Internet Name Domain Server (BIND) OrganisaYon der DNS-­‐Server •  Hierarchische Struktur named •  Ausfallsicherheit –  Primary Name Server –  Secondaries named named •  AdministraYve Einheiten –  Zone named named named (c) Peter Sturm, Uni Trier named named 12 Rechnernetze Sommer 2014 Domain Name Service Root Server TLD Server TLD Server TLD Server Domain Server Domain Server Domain Server Domain Server Domain Server Domain Server … … … … … … Root Servers (c) Peter Sturm, Uni Trier 13 Rechnernetze Sommer 2014 Root-­‐Server Record DNS Server Hierarchy Root Server TLD DE Your Provider TLD COM uni-­‐trier.de google.com Your host (c) Peter Sturm, Uni Trier 14 Rechnernetze Sommer 2014 Recursive Querying Root Server maps.google.com? maps.google.com? 209.85.148.103! TLD DE TLD COM 209.85.148.103! 209.85.148.103! google.com Your Provider maps.google.com? maps.google.com? 209.85.148.103! Your host Example: Query for maps.google.com IteraYve Querying Root Server maps.google.com? TLD DE .COM Server maps.google.com? TLD COM google.com Server IteraPve Queries Your Provider maps.google.com? 209.85.149.102 google.com maps.google.com? 209.85.149.102 Recursive Query (c) Peter Sturm, Uni Trier Your host Example: Query for maps.google.com 15 Rechnernetze Sommer 2014 Einträge •  Ca. 20 verschiedene Eintragsformen –  Viele nicht mehr gülYg •  Gängige „Record“-­‐Einträge – 
– 
– 
– 
– 
– 
– 
A: IPv4-­‐Adresse AAAA: IPv6-­‐Adresse NS: NS-­‐Server CNAME: Kanonischer Name PTR: Pointer-­‐Record HINFO: Host-­‐InformaYon MX: Mail Exchange Record •  Pointer-­‐Query –  Gegeben IP-­‐Adresse; Gesucht: Kanonischer Name –  in-­‐addr.arpa Domain DNS Records •  Resource Record (RR) Name Value Type TTL Hostname IPv4 Address A TTL Hostname IPv6 Address AAAA TTL Domain AuthoritaYve Name Server NS TTL Alias Name Canonical Name CNAME TTL Domain Name of Mail Server MX TTL •  Record Types (c) Peter Sturm, Uni Trier 16 Rechnernetze Sommer 2014 Example DNS Records •  Resource Record (RR) Name Value Type TTL www-­‐neu.uni-­‐trier.de 136.199.199.105 A 7200 www-­‐neu.uni-­‐trier.de 2001:0db8:85a3:3d … AAAA 7200 uni-­‐trier.de dns.uni-­‐trier.de NS 7200 www.uni-­‐trier.de www-­‐neu.uni-­‐trier.de CNAME 7200 uni-­‐trier.de rzmail.uni-­‐trier.de MX 7200 •  Record Types DNS Messages 16 TransacYon ID Number of quesYons 16 16 Number of authority records Flags Number of answer records 16 16 16 Number of addiYonal records QuesYons Answer records Authority records AddiYonal records (c) Peter Sturm, Uni Trier 17 Rechnernetze Sommer 2014 DNS Query DN
S u
Po ses U
rt 5 DP
3 DNS Response Non-­‐authoritaPve reply AuthoritaPve nameservers (c) Peter Sturm, Uni Trier 18 Rechnernetze Sommer 2014 Die Client-­‐Seite Internet / Intranet ? Desktop Ausgangspunkt •  Unterschiedlichste Anschlußtechnologien – 
– 
– 
– 
– 
AkusYk-­‐Koppler Modem ISDN A-­‐DSL / S-­‐DSL … •  Meist nur “Physical Layer” (Ebene 1) vorhanden –  TCP/IP erwartet “Data Link Layer” (Ebene 2) •  Endanwender kein Netzadministrator –  AutomaYsmen bei der KonfiguraYon (c) Peter Sturm, Uni Trier 19 Rechnernetze Sommer 2014 SLIP, PPP, PPPOE BrückenfunkYon Ebenen 5 bis 7 Transportebene (UDP und TCP) IP SLIP oder PPP Physical Layer (c) Peter Sturm, Uni Trier 20 Rechnernetze Sommer 2014 SLIP •  Serial Line Internet Protocol •  Aus der Not geboren, als Rechner über serielle Leitungen miteinander vernetzt wurden •  Minimaler FunkYonsumfang –  Framing eines IP-­‐Datagramms Framing IP Datagramm SLIP End Character 0xc0 IP Datagramm 0xc0 •  Escaping für 0xc0 im IP-­‐Datagramm –  Aus 0xc0 wird 0xdb 0xdc –  Aus 0xdb wird 0xdb 0xdb (c) Peter Sturm, Uni Trier 21 Rechnernetze Sommer 2014 Probleme •  Keine standardisierte MTU –  üblich sind 1006 Byte •  Keine Fehlererkennung und –korrektur –  eigentlich üblich auf Ebene 2 –  Mehraufwand in höheren Ebenen •  Keine Kontrollmöglichkeiten •  Keine Typerkennung –  Mischen verschiedener Ebene-­‐3-­‐Protokolle unmöglich •  Adreßerkennung –  IP-­‐Adresse des Gegenüber kann nicht direkt ermicelt werden •  Keine Datenkompression •  Weder Sicherheit noch Schutz –  Keine Möglichkeit der AuthenYfizierung –  Keine Paketverschlüsselung PPP •  Point-­‐to-­‐Point Protokoll •  IETF-­‐Standard für Überbrückung der Ebene 2 –  RFC 1171 (1990) •  Technische Wurzeln –  ISO HDLC (High-­‐Level Data Link Control) von IBM –  Basiert wiederum auf SLDC (Synchronous Data Link Control) •  Großer Leistungsumfang (c) Peter Sturm, Uni Trier 22 Rechnernetze Sommer 2014 Komponenten •  EncapsulaYon Method –  Framing der IP-­‐Datagramme •  Link Control Protocol (LCP) –  Ausau, Unterhalt und Abbau der Verbindung –  Aushandeln der nutzbaren Link-­‐EigenschaÄen •  Network Control Protocols (NCPs) –  “Ebene 3”-­‐spezifische Kapselungsaspekte –  Gängige Beispiele •  IPCP für IP •  IPXCP für IPX (Novell Networks) •  ATCP für AppleTalk FunkYonsumfang •  Besseres Rahmen von IP-­‐Datagrammen •  Unterstützung für viele “Physical Layer” –  Synchron / Asynchron –  Halb-­‐ und Vollduplex •  Kontrollmöglichkeiten –  Aushandeln von Link-­‐EigenschaÄen –  Link-­‐Test •  Protocol MulYplexing •  Datenkompression •  AuthenYfizierung, Verschlüsselung (c) Peter Sturm, Uni Trier 23 Rechnernetze Sommer 2014 Link-­‐Zustände -­‐ Link Dead Physical Link Link Establishment Link TerminaYon LCP Link AuthenYcaYon AuthenYcated LCP Link Network Layer Protocol AuthenYcated LCP + NCPs Link Open AuthenYfizierung •  Password AuthenYcaYon Protocol (PAP) –  2-­‐Wege –  Name und Passwort im Klartext •  Challenge-­‐Handshake AuthenYcaYon Protocol (CHAP) –  3-­‐Wege –  Challenge •  Text –  Response •  Verschlüsselter Text •  Server verschlüsselt auch und vergleicht Server IniYator nge Challe
Respon
se ailure s or F
Succes
(c) Peter Sturm, Uni Trier 24 Rechnernetze Sommer 2014 PPPoE Internet Ethernet •  Point-­‐to-­‐Point Protocol over Ethernet •  Klingt seltsam? –  Ethernet hat “Data Link Layer” –  PPPoE realisiert “Data Link Layer” •  Primärer Nutzen –  AuthenYfizierung bei Ethernet-­‐basiertem Modemzugang DHCP (c) Peter Sturm, Uni Trier 25 Rechnernetze Sommer 2014 Netzwerk-­‐KonfiguraYon •  TCP/IP-­‐KonfiguraYon – 
– 
– 
– 
– 
– 
Eigene IP-­‐Adresse Netz/Subnetzmaske IP-­‐Adresse Default-­‐Router IP-­‐Adresse DNS-­‐Server MTU TTL-­‐Wert Manuelle KonfiguraYon •  Manuelle Festlegung der relevanten InformaYonen •  In überschaubaren Netzen möglich •  Probleme –  Remote AdministraYon erschwert –  Mobile Geräte –  Diskless Clients (c) Peter Sturm, Uni Trier 26 Rechnernetze Sommer 2014 Ziele •  AutomaYsierte KonfiguraYon •  Zentrale Speicherung aller KonfiguraYonsdaten •  Dynamische Zuteilung –  Mobile Geräte –  Sporadisch angeschaltete Geräte •  Teilen von IP-­‐Adressen –  Bessere Nutzung des IPv4-­‐Adreßraums (c) Peter Sturm, Uni Trier 27 Rechnernetze Sommer 2014 Dynamic Host ConfiguraYon Protocol (DHCP) •  Vorgänger –  RARP: Nur IP-­‐Adresse –  BOOTP •  DHCP ist Erweiterung von BOOTP –  RFC 1451, Oktober 1993 •  BOOTP + Vergabe temporärer IP-­‐Adressen Varianten der Adressvergabe •  Client erfragt seine IP-­‐Adresse •  Manuelle Zuordnung –  Netzwerkadministrator ordnet feste IP-­‐Adresse zu –  Immerhin Vorteil der zentralen Speicherung •  Dynamische Zuordnung – 
– 
– 
– 
Client “leiht” sich IP-­‐Adresse aus (DHCP Lease) Zeitlich begrenzt Renew vor Ablauf Ursprung IP-­‐Adresse •  Feste Vorgabe (vgl. Manuell) •  Aus Adress-­‐Pool DHCP Config DHCP Server Client (c) Peter Sturm, Uni Trier 28 Rechnernetze Sommer 2014 NAT Hilfe! Wir haben keine Adressen mehr! •  Ungenutzte IP-­‐Adreßbereiche werden wieder eingefordert •  Infrastruktur –  Classless Inter Domain RouYng (CIDR) –  Variabler Netzanteil –  Bündelung von “Class C”-­‐Netzen •  Dynamische IP-­‐Adressen –  Jede “Einwahl” liefert neue IP-­‐Adresse •  Network Address TranslaYon (NAT) (c) Peter Sturm, Uni Trier 29 Rechnernetze Sommer 2014 Network Address TranslaYon (NAT) From (136.199.54.243,4010) To (199.42.240.180,80) 192.168.42.1 Gateway 136.199.54.243 Host 192.168.42.10 From (192.168.42.10,2033) To (199.42.240.180,80) Via 192.168.42.1 Port 4010 Host 192.168.42.77 Bemerkungen •  VariaYonen –  Festes Host-­‐Mapping •  1 Externe Adresse pro interne Adresse –  Dynamisches Host-­‐Mapping •  Wahl einer IP-­‐Adresse aus einem Pool bei Bedarf –  Festes Host-­‐Mapping, Dynamisches Port-­‐Mapping •  Normalfall: IP des Gateways für alle inneren Rechner •  z.B. Internet ConnecYon Sharing bei Windows –  Dynamische Host-­‐ und Port-­‐Mapping •  Manche Protokolle becen IP-­‐Adressen in den Nutzdaten ein –  z.B. Äp •  Auch aus Schutzgründen sinnvoll –  Externer Verkehr muß über Gateway –  Innere Struktur bleibt verborgen (c) Peter Sturm, Uni Trier 30 Rechnernetze Sommer 2014 NACHBARSCHAFT Netzwerkumgebung •  “Zero ConfiguraYon” für normale Endanwender –  Keine technischen Detailkenntnisse vorhanden •  Inhalte –  Benachbarte “freundliche” Rechner einbinden –  Zugang zu Druckern, CD/DVD-­‐Brennern, … •  OS-­‐Spezifische Lösungsansätze –  Mac OS X: Bonjour –  Windows-­‐Umfeld: UPnP •  Standardisierungsversuche der IETF (c) Peter Sturm, Uni Trier 31