7. IPv6

1. 7. IPv6 • seit 1992 wird über eine Nachfolge Version von IP(v4) nachgedacht • Deering and Hinden. Internet Protocol Version 6 (IPv6) Specification, RFC 2460, 1998. • es gibt bereits einige „virtuelle“ Netze, die IPv6 verwenden • wichtigste Vorteile: • erweiterte Adressierungsmöglichkeiten • Vereinfachung des Headers • verbesserte Unterstützung für Optionen und Erweiterung • Kennzeichnung von Flüssen (flows) die auf besondere Art behandelt werden sollen • Optionen für die Authentifikation und Verschlüsselung von Paketen

2. 0 15 31 7 IPv4 Header version hlength type of service total length identification flags fragment offset time to live protocol header checksum source IP address destination IP address options (if any) data

3. 0 15 31 7 IPv6 Header version traffic class flow label payload length next header hop limit source IP address (128 bit) destination IP address (128 bit) extension headers (if any) data

4. IPv6 Header Vereinfachungen • Festes Format für den Header, keine Optionalen Elemente. Optionen werden in Form von Extension Headern an den IPv6 Header angehängt. Dies vereinfacht das Parsen von Paketen (soll in Hardware möglich sein). • Header Checksumme wurde entfernt, da der Schutz meist bereits auf Schicht 2 geleistet wird. Dadurch vermindert sich die Komplexität in den Routern. • Fragmentierung im Inneren des Netzes wurde entfernt. Nun kann Fragmentierung nur von Endsystemen durchgeführt werden. Dies erfordert Path-MTU discovery, oder die Verwendung von kleinen Paketen (minimale Path-MTU in IPv6 Netzen ist 1280 Bytes).

5. IPv6 Header - Klassische Felder • payload length (statt total length): die Größe des IP Paketes ohne den 40 Byte IPv6 Header • next header (statt protocol type): der auf den IPv6 Header folgende Header (z.B. ein spezieller extension header oder TCP) • hop limit (statt time-to-live): hier wird im Namen die tatsächliche Funktion des Feldes berücksichtigt

6. IPv6 Neue Felder • flow label: dient zur Identifikation von Flüssen mit besonderen Anforderungen - dies ist noch nicht vollständig für IPv6 spezifiziert • class: dieses Feld dient der Priorisierung von IP Paketen, auch hier wird noch experimentiert!

7. IPv6 Extension Headers • die Extension Headers ersetzen die Options von IPv4 • die Extension Header folgen auf den IP header: IPv6 Header next header= Routing Routing Header next header= Fragment Fragment Header next header= TCP Fragment TCP

8. 0 15 31 7 IPv6 Extension Headers: Routing Header next header hdr. ext. length routing type=0 segments left reserved address1 (128 bit) more addresses

9. IPv6 Extension Headers: Routing Header • next header: welcher Header kommt als nächstes (weiterer extension Header? TCP?) • hdr. ext. length: wie groß ist dieser extension header in 64 bit Vielfachen, ohne die ersten 64 bit • routing type: zur Zeit immer 0 • segments left: an welcher Position befinden wir uns, d.h. welche Adresse ist als nächstes an der Reihe • die Adressen von den Systemen, die durchlaufen werden sollen, der letzte Eintrag ist der des Zielsystems an dem das Paket ankommen soll

10. Routing Header - Behandlung • In einem System wird der Routing Header nur betrachtet, wenn die IP Adresse dieses Systems als Empfängeradresse im IP Header steht. • Gibt es keine weiteren Einträge im Routing Header (die Liste ist abgearbeitet) so ist das Paket am endgültigen Ziel angekommen. • Falls weitere Einträge vorhanden sind wird die Zieladresse im IP Header durch den nächsten Eintrag ersetzt und das Paket wird an diese Adresse geschickt.

11. 0 15 31 7 IPv6 Extension Headers: Fragmentation Header • fragment offset: Position des Fragmentes • identification: identifiziert das Paket zu dem das Fragment gehört • M: more fragments: 0 für das letzte Fragment eines Paketes, sonst 1 • IPv6 Fragmentierung wird ausschließlich von Endsystemen durchgeführt, d.h. Pakete die zu groß sind werden von Router automatisch so behandelt als wäre ein don’t fragment bit gesetzt. next header reserved fragment offset res M identification

12. Weitere IPv6 Extension Header • Destination Options Header: für die Übermittlung von Optionen vom Sender zum Empfänger. Bislang weitestgehend ungenutzt. • Hop-by-Hop Options Header: für die Übermittlung von Optionen von einem Knoten zum Nachbarknoten des Netzes. Ebenfalls weitestgehend ungenutzt. • Authentication Header: für die Authentifizierung von Paketen. Werden wir später genauer diskutieren.

13. ICMPv6 für IPv6 • A. Conta, S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 2463. 1998. • nicht länger benötigte Elemente wurden in ICMPv6 weggelassen • das Mitgliedschaftsprotokoll für Multicast (IGMP) wurde in ICMPv6 mit aufgenommen • die Pakete wurden an die neue Adressgröße angepasst

14. 0 15 31 7 ICMPv6 - Paketformat • type: ICMP Nachrichtentyp • code: Unterteilung der Typen • checksum: über eine pseudo IPv6 Header und das gesamte ICMP Paket IPv6 header type code checksum message body

15. ICMP Nachrichten Typen • Errors: • 1: Destination Unreachable • 2: Packet Too Big • 3: Time Exceeded • 4: Parameter Problem • Echo: • 128: Echo Request • 129 Echo Reply • Multicast Gruppenmitgliedschaft (130-132) • Autokonfiguration (133-137)

16. 0 15 31 7 ICMPv6 Errors IPv6 header type={1,2,3,4} code checksum parameter verursachendes Paket (maximale Gesamtgröße des ICMP Paketes ist 576 inklusive aller Header, dann wird das Paket abgeschnitten)

17. ICMPv6 Errors • Destination Unreachable: • no route to destination • communication with destination administratetively prohibited • address unreachable • port unreachable • Packet Too Big • Time Exceeded • hop limit exceeded in transit • fragment reassembly time exceeded • Parameter Problem • erroneous header field • unrecognized next header type • unrecognized IPv6 option

18. 0 15 31 7 Auswirkungen auf Höhere Schichten • Neuer Pseudoheader für die Berechnung der Checksummen (ICMP, TCP, UDP, ....) source IP address (128 bit) destination IP address (128 bit) payload length flow label next header beim next Header Feld werden alle extension Header ignoriert, hier steht also die ID für TCP/UDP/ICMP, etc.

19. Auswirkung auf Höhere Schichten • Domain Name Service: • neuer resource record: AAAA (code 28) für 128-bit IPv6 Adressen • für pointer-queries gibt es einen neuen top-level Knoten: IP6.INT (äquivalent zu in-addr.arpa) • für pointer queries wird die numerische IPv6 Adresse in eine Sequenz hexadezimaler Stellen zerlegt (je 4 bit), da es keine natürlichen Grenzen wie bei IPv4 gibt

20. IPv6 Designentscheidungen • Header Felder werden so definiert, dass jeder Wert sinnvoll ist • Beispiel: • payload-length in IPv6 gibt an wie groß der Payload ist, alle Werte sind gültig (auch 0 für keinen Payload) • in IPv4 gibt das total length Feld die Größe des ganzen Paketes an, d.h. inklusive header. Daher sind Werte kleiner als 20 ungültig • Vorteile des neuen Design: • eine Verzweigung weniger im Programmcode, daher besser für Pipelining und Optimierungen geeignet • weniger Komplexität und daher weniger Fehlermöglichkeiten

21. IPv6 Designentscheidungen • jedes Header Feld so klein wie möglich halten • z.B. hop-limit kann maximal 255 sein, dies ist kontrovers diskutiert worden! • z.B. Pakete können nur 64kbyte groß sein, auch dies ist kontrovers diskutiert worden (es gibt einen extension Header der größere Pakete ermöglicht) • Vorteil dieses Vorgehens: der Header bleibt klein und verursacht keinen übermäßigen Overhead • die einzige Ausnahme sind die Adressen, die als Kompromiss auf 128 bit ausgelegt wurden, obwohl wohl auch 64 bit gereicht hätten

22. IPv6 Designentscheidungen • Minimierung von redundanter Funktionalität: Funktionalität die an anderer Stelle des Protokollstacks durchgeführt werde sollte in IPv6 nicht verdoppelt werden • Beispiel: es gibt keine Checksumme mehr für den IPv6 Header • dies beschleunigt die Handhabung von Paketen in Routern • wird möglich, da i.d.R. auf Schicht 2 bereits eine Fehlererkennung durchgeführt wird • auch sichern nahezu alle Schicht 4 Protokolle den IPv6 Header mit Hilfe eines pseudo Headers in ihrer Checksumme • Dieses Vorgehen verschlankt den Protokollstack und beschleunigt die Bearbeitung von Paketen

23. IPv6 Adressierung - Adressgröße • Man ging 1991 davon aus, daß im Jahr 2000 alle 10 Milliarden Menschen auf der Erde eine Internetadresse benötigen • Dann hat man weiter nachgedacht und ist zu der Annahme gekommen daß jeder Mensch mehrere IP-Adressen benötigt (eine für sein Auto, eine für seinen Kühlschrank, eine für jede Glühbirne, etc.). Daraufhin ging man von 100 Internet Adresse pro Mensch aus, d.h. 1 Billion Adressen = 10 hoch 12. • Dann wollte man nicht auf einen Sicherheitspuffer verzichten und hat IPv6 Adressen so gestaltet, daß 10 hoch 15 Endgeräte über 10 hoch 12 Sub-Netze verbunden werden können.

24. IPv6 Adressierung • ein System in IPv6 kann wie in IPv4 mehrere IP Adressen besitzen (z.B. wenn es an mehrere Sub-Netzte angeschlossen ist • es gibt drei Kategorien der Adressierung: • unicast für Punkt zu Punkt Verbindungen • multicast für die Adressierung von Empfängergruppen • anycast zur Adressierung einer Gruppe aus welcher genau ein System das Paket erhält

25. IPv6 Adressierung • Notation von IPv6 Adressen: • FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 • Unsignifikante 0en dürfen in jeder einzelnen 16 Bit Einheit weggelassen werden 0012 wir also zu 12 • eine Kette von Einheiten, die 0 sind darf mittels :: zusammengefasst werden: • 1080:0:0:0:8:800:200C:417A wird zu • 1080::8:800:200C:417A • nur ein :: ist erlaubt • beim Expandieren werden an die Stelle von :: so viele 0 Einheiten eingefügt, bis die Adresse wieder die richtige Länge hat • IPv4 Adressen sind ein Sub-Set von IPv6 Adressen, bei denen die ersten 96 bit null sind, sie werden wie folgt geschrieben: • ::134.155.48.96

26. IPv6 Adressierung • Präfixe in IPv6: • werden wie in IPv4 (Net-ID, Sub-Net ID) für das Routing benötigt • haben variable Länge • werden mit folgender Notation bezeichnet: • FEDC:BA98:7600::/40 • die unsignifikanten Bits eines Präfix sollten auf 0 gesetzt und mit :: abgekürzt werden

27. IPv6 Adressierung • der IPv6 Adressraum wird wir folgt aufgeteilt: • Präfix 0000 0001: Reserved for NSAP Allocation • Präfix 0000 001: Reserved for IPX Allocation • Präfix 010: Aggregatable Global Unicast Addresses • Präfix 100: Reserved for Geographic-based Unicast Addresses • Präfix 1111 1110 10: Link Local Use Addresses • Präfix 1111 1110 11: Site Local Use Addresses • Präfix 1111 1111: Multicast Addresses • der Rest des Adressraumes steht noch zur Verfügung (>70%) um weitere Adresstypen zu ermöglichen

28. Aggregatable Global Unicast Addresses • man hat in IPv4 (schmerzhaft) gelernt, wie wichtig es ist Adressen aggregieren zu können (s. CIDR) um eine Explosion der Routing Tabellen zu vermeiden • daher werden in IPv6 die „normalen“ unicast Adressen so aufgebaut, daß sie gut aggregierbar sind: 001 TLA 13 Bit NLA 32 Bit SLA 16 Bit Interface IP 64 Bit TLA: Top Level Aggregator NLA: Next Level Aggregator SLA: Site Local Aggregator Interface: Identifikation des Interfaces eines Rechners

29. Aggregatable Global Unicast Addresses • Top Level Aggregator: • Dies sind die Knoten in der default-freien Zone, im Backbone des Internet, in welchem die Router keinen default Eintrag in der Routing Tabelle haben dürfen. • Insbesondere ist jeder TLA in jeder Routing Tabelle in der default-freien Zone vorhanden. • Daher gibt es auch nur maximal 8192 TLAs. • TLAs werden i.d.R. nach einer Kombination von großen Providern und regionalen Gesichtspunkten zugeordnet, z.B. könnte T-Online in Europa (fiktives Beispiel!) eine TLA IP erhalten. • Ein TLA kann auch einfach ein Konten in der default-freien Zone sein, an dem mehrere Netzwerke miteinander Verbunden sind.

30. Aggregatable Global Unicast Addresses • Next Level Aggregator: • Hier kann die Verantwortlichkeit weiter delegiert werden, z.B. T-Online Deutschland, etc. • Die 32 Bit können nach Belieben weiter aufgeteilt werden um weitere Hierarchiebenen für die Aggregation zu schaffen. • So könnten die ersten 16 Bit genutzt werden um für T-Online in Europa nach Ländern zu unterscheiden und dann die nächsten 16 Bit um in den Ländern nach Regionen zu unterscheiden.

31. Aggregatable Global Unicast Addresses • Site Local Aggregator und Interface ID: • Site Local Aggregator IDs bezeichnen i.d.R. Links einer Site, also z.B. das Ethernet für L15,16. • Eine Interface ID bezeichnet ein Netzwerkinterface eines Rechners, diese ID kann z.B. aus der ID der Ethernetkarte gewonnen werden, in dem 16 null Bits an geeigneter Position eingefügt werden. • Site Local Aggregator IDs und die Interface IDs sind unabhängig vom Rest der IP Adresse, wird z.B. der Provider gewechselt, bleiben SLA ID und Interface ID konstant.

32. Spezialadressen • unspecified address (16 null Bytes): als Absendeadresse einer Station die noch nicht eingerichtet wurde. Wird auch als Platzhalter verwendet wenn eine Adresse benötigt wird, aber keine da ist • loopback address (0:0:0:0:0:0:0:1) • IPv4 address (::u.v.w.x) • site local address (1111 1110 11/10): Adressen die nur innerhalb einer Site verwendet werden und nie ins Internet geroutet werden. Normalerweise wählt man die Adressen so, daß die letzten 80 Bit wie bei einer aggregatable global unicast address zugeordnet werden (SLA + Interface ID). Dann kann man später die Systeme schnell ins Internet einbinden.

33. Spezialadressen • link local addresses (1111 1110 10): diese Adressen sind nur auf einem Sub-Netz gültig und werden nie von Routern Weitergeleitet. Man strukturiert sie so, daß die letzten 64 bit die Interface ID beinhalten um die Adresse schnell in eine Aggregatable Global Unicast Address umwandeln zu können

34. IPv6 Exterior Gateway Routing • entweder mit BGP-4 (+IPv6 Erweiterung hierzu), • oder mit dem ISO (ISO Standard 10747) Inter-Domain Routing Protocol (IDRP) • Hauptunterschiede BGP-4/IDRP: • BGP tauscht Nachrichten über TCP aus, IDRP direkt über IPv6 • BGP ist für das Routen einer Adressfamilie gedacht (z.B. IPv4 oder IPv6) während IDRP für mehrere Adressfamilien gleichzeitig verwendet werden kann • BGP benutzt Autonome System IDs, IDRP identifiziert domains anhand von Adresspräfixen variabler Länge

35. Unterschiede BGP-4 vs. IDRP • TCP vs. kein TCP • BGP wählte TCP, da dies das Protokoll vereinfacht • aber, wenn eine Nachricht verloren geht, dann sorgt TCP für eine Übertragungswiederholung, diese kann aufgrund von congestion control erheblich verzögert werden • während dieser Verzögerungszeit kann sich die Routing Information bereits wieder geändert haben und eine Übertragungswiederholung daher sinnlos sein • IDRP stellt daher die Zuverlässige Übertragung von Nachrichten selber sicher und ist somit effizienter aber auch komplexer

36. Unterschiede BGP-4 vs. IDRP • Adressformat: • in BGP-4: length (1 Byte) + prefix (variabel) • in IDRP: address family (2 Byte) + address length (2 Byte) + address information (variabel) • address information: length (1 Byte) + Prefix (variabel) • durch dieses Format ist IDRP für mehrere Adressfamilien gleichzeitig verwendbar

37. Unterschiede BGP-4 vs. IDRP • Autonome System ID vs. Präfix variabler Länge • in BGP werden Autonome System IDs verwendet um zu identifizieren, durch welche Netze eine Route führt, dies wird benötigt um Schleifen zu vermeiden und politisches Routing zu ermöglichen • bei IDRP wird statt einer Autonomen System ID ein variabler Adresspräfix verwendet (z.B. FEDC::/16) • da die Autonome Systeme ID auf 16 Bit beschränkt ist, kann ein BGP-4 Engpass entstehen, dies ist in IDRP nicht der Fall • Autonome System IDs müssen von der IANA explizit vergeben werden, Adresspräfixe sind durch die IPv6 Adressen bereits bekannt • bei der Aggregation von Routen in BGP müssen die IDs aller Autonomen Systeme mitübertragen werden, dies kann zu einem signifikanten Overhead führen, bei IDRP ist dies nicht notwendig, da die Adresspräfixe sich in natürlicher Weise aggregieren lassen

38. IDRP – Beispiel (Frei Erfunden!) Router der default freien Zone. Routing Einträge zu 20FE::/16, 200F:10::/32 und 200F:1000::/24 T-Online Europe TLA-ID: F Präfix: 200F::/16 Central African Exchange TLA-ID: FE Präfix: 20FE::/16 hier können weitere Router dazwischen liegen T-Online Deutschland NLA-ID (1. Hälfte/16 Bit): 10 Präfix: 200F:10::/32 T-Online Frankreich NLA-ID (1. Hälfte/8 Bit): 10 Präfix: 200F:1000::/24 Router der untersten Ebene. Routing Einträge zu allen Sub-Netzen in 20FE:10:FF00::/48, und eine default Route zu T-Online Startup GMBH NLA-ID (2. Hälfte/16 Bit): FF00 Präfix: 200F:10:FF00::/48

39. IPv6 Interior Gateway Routing • OSPF für IPv6 • eigene link state Datenbank für IPv6 (wird nicht kombiniert mit der von IPv4, wenn eine vorhanden ist) • Adressfelder werden auf die 128 bit Adressen von IPv6 angepasst • RIP für IPv6 • Adressfelder werden auf die 128 bit Adressen von IPv6 angepasst • ansonsten analog zu RIP-2

40. IPv6 Plug and Play • Autokonfiguration • Adressvergabe • Adressauflösung und Nachbarerkennung • Abbilden der Schicht 2 Adresse auf eine IPv6 Adresse und umgekehrt • Automatisiertes Erkennen von Routern • Optimieren der Route von einem Endsystem zum ersten Router

41. IPv6 Autokonfiguration • Autokonfiguration: • Automatische Vergabe von Adressen • Automatisierte Eintragung ins DNS • IPv6 soll auch von nicht-Spezialisten verwendet werden, z.B. um ein Heimnetz aufzubauen, es sollte daher möglichst automatisierbar sein. • Durch Provider-abhängige Adressen ist es notwendig, dass eine eine Renumerierung automatisiert vorgenommen werden kann. • Autokonfiguration wird in IPv6 mit Hilfe von ICMPv6 realisiert

42. Bestimmung einer Link Local Address • Sobald ein Interface initialisiert ist kann ein Host eine Link Local Address für dieses Interface bestimmen. • Dazu wird der wohlbekannte Präfix für Link Local Adresses (FE80:0:0:0/64) um ein ein eindeutiges 64-Bit Token erweitert welches i.d.R. aus der Schicht 2 Adresse der Netzwerkkarte abgeleitet wird. • Das Token kann auch auf andere Weise erstellt werden, solange „garantiert“ ist, daß es in dem Subnetz eindeutig ist. • Zum Beispiel kann eines zufällig ausgewählt werden, da eine Kollision so unwahrscheinlich ist gilt dies als „garantiert“. (sehr interessante Einstellung!!!). • Link Local Addresses lösen das Problem von autonomen Netzen, die nicht an das Internet angeschlossen werden sollen und die nur aus einem Sub-Netz bestehen. Für alle anderen Netze müssen weitere Schritte erfolgen.

43. Autokonfiguration • Zustandslos: die Adressen werden von den Endsystemen selbst konstruiert, mit Hilfe von Informationen die sie von einem der direkt am selben Sub-Netz angeschlossenen Router erhalten. • Zustandsbehaftet: die Adressen werden von einem zentralen Server vergeben. Dies nennt man zustandsbehaftet, da der Server einen Zustand halten muss (z.B., welche Adressen er bereits vergeben hat)

44. Zustandslose Autokonfiguration • Eine Solicitation Nachricht wird auf die All Routers Multicast Gruppe (FF02::2) geschickt. Dabei wird die eigene Link Local Adress als Absender verwendet. Außerdem beinhaltet die Solicitation Nachricht die Schicht 2 Adresse des Absenders. • Als Antwort schicken die Router auf diesem Subnetz eine Router Advertisement Nachricht. Diese beinhaltet die folgenden Informationen: • Managed Address Configuration Bit: 0 wenn Stationen zustandslose Autokonfiguration vornehmen dürfen, 1 wenn ein Server für Zustandsbehaftete Autokonfiguration kontaktiert werden muss (s. später). • Other Configuration Bit: 0 wenn bei der zustandslosen Autokonfiguration ein Server für Parameter angefragt werden muss, 1 wenn diese Informationen an diese Nachricht angehängt sind • Prefix Information Option: der Präfix mit dem aus dem Token eine global gültige IPv6 Adresse wird.

45. Zustandslose Autokonfiguration • Adressen haben nur eine beschränkte Lebensdauer, diese wird in der Router Advertisement Nachricht mitübertragen: • Valid Lifetime: nach dieser Zeit darf die Adresse nicht mehr verwendet werden. • Preferred Lifetime (<Valid Lifetime): nach dieser Zeit sollte die Adresse nicht mehr für den Aufbau von Verbindungen verwendet werden. • Router Advertisement Nachrichten werden periodisch auf der All Nodes Multicast Gruppe übertragen und frischen damit die beiden Werte wieder auf. Einen Timeout gibt es nur wenn der Präfix tatsächlich geändert wurde. • Entdecken von Duplikaten: da man nie ausschließen kann, dass das selbe Token zweimal in einem Subnetz vorkommt (Konfigurationsfehler) wird nach der zustandslosen Autokonfiguration eine spezielle Nachricht an die neue Adresse geschickt, kommt nach einer Sekunde keine Antwort gilt die neue Adresse als gültig.

46. Zustandsbehaftete Autokonfiguration • Die zustandsbehaftete Autokonfiguration von IPv6 erfolgt mit Hilfe einer IPv6 Version des Dynamic Host Configuration Protocol (DHCP). Dieses gibt es auch für IPv4. • Probleme: • Wie lernt man als DHCP Client die Adresse eines DHCP Servers? • Wie kann man mit diesem kommunizieren, obwohl man noch keine gültige Adresse hat? • Wie werden diese beiden Probleme gelöst, wenn es nur einen zentralen DHCP Server für eine Site geben soll?

47. DHCP für IPv6 • Der erste Schritt ist das Suchen nach einem DHCP Server. • Dazu wird auf die all DHCP Servers multicast Adresse (FF02::1:2) eine Solicitation Nachricht verschickt: • Protokoll: UDP. • Absenderadresse: die Link Local Address des Absenders. • Diese Link-Local Address steht auch noch einmal in der Solicitation Nachricht selber.

48. DHCP für IPv6 • Damit nicht in jedem Sub-Netzwerk ein DHCP Server vorhanden sein muss gibt es in jedem Sub-Netz ohne DHCP Server sogenannte DHCP Relay Agents (kurz DHCP Relays). • Diese sind notwendig, da die Link Local Address des Absenders einer Solicitation Nachricht nur in diesen einen Subnetz gültig ist. • Wenn in einem Sub-Netz keine DHCP Server sondern nur ein DHCP Relay vorhanden ist, dann leitet das DHCP Relay die Solicitation Nachricht an einen DHCP Server weiter. Bei der weitergeleiteten Nachricht ist nun das DHCP Relay der Absender. Zusätzlich trägt das DHCP Relay seine Adresse in die Nachricht ein.

49. DHCP für IPv6 • Ein DHCP Server antwortet auf eine Solicitation Nachricht mit einer Advertise Nachricht. • Diese beinhaltet die Adressen des Servers und – sofern vorhanden – des DHCP Relays. Weiterhin können bereits erste Konfigurationsparameter in der Advertise Nachricht enthalten sein. • Wenn ein DHCP Relay involviert ist wird die Advertise Nachricht an das Relay geschickt, welches es dann an den DHCP Client im eigenen Sub-Netz weiterleitet. Ansonsten befinden sich DHCP Client und Server im selben Sub-Netz und der Server kann dem Client direkt antworten • Der DHCP Client wählt unter allen Advertise Nachrichten einen Server (und, falls notwendig ein DHCP Relay) aus, den er für seine Autokonfiguration verwenden möchte. Alle anderenwerden ignoriert.

50. DHCP für IPv6 • Der Client fragt von dem ausgewählten Server die Autokonfigurationsdaten mit Hilfe einer Request Nachricht nach. • Request Nachrichten werden direkt an den Server/DHCP Relay geschickt und nicht per multicast versandt. • Die Request Nachricht beinhaltet die Adresse des Servers, eines eventuell verwendeten DHCP Relays und die Link Local Address des Client.