Zusammenfassung

  • RFC 3361 gab DHCPv4-Option 120 zwei ausschließliche Codierungen: eine bevorzugte Liste von DNS-Namen oder eine geordnete IPv4-Liste für lokale SIP-Ausgangsproxys.
  • Der Name konnte Transport, Port, Instanz und Ersatzwahl an DNS delegieren; Adressen hielten eine Hostreihenfolge fest. Keine gültige Lease bewies die spätere SIP-Transaktion oder den vollständigen Anrufpfad.

Frühe Konfiguration wirkt leicht wie ein vollständiges Ergebnis. Ein Endgerät erhält seine DHCP-Lease und darin einen lokalen SIP-Proxy. Doch zwischen dieser Startkoordinate und einer Verbindung liegen Namensauflösung, Transport, Transaktionszustand, weitere Proxys, Sitzungsverhandlung und Medienverkehr.

RFC 3361 erschien im August 2002 auf dem Standards Track und definierte DHCPv4-Option 120. In manchen Netzen konnte ein SIP-Client ein Ziel aus der URI direkt erreichen. In anderen, etwa hinter Firewalls, benötigte er einen lokalen Server für ausgehende Anforderungen. DHCP war eine von mehreren Auffindungsmethoden; manuelle Konfiguration blieb möglich.

Nach Code und Länge folgte ein Codierungsbyte. Null bedeutete eine Folge von Domainnamen, eins eine oder mehrere binäre IPv4-Adressen. Jede Implementierung musste beide Formen beherrschen, obwohl das Dokument Namen vorzog.

Die beiden Formen transportierten nicht nur unterschiedliche Schreibweisen. Ein Domainname führte in das Verfahren aus RFC 3263. NAPTR konnte verfügbare Transporte bekannt machen, SRV Instanzen, Ports, Prioritäten und Gewichte bestimmen, A oder AAAA schließlich Adressen liefern. Der Client schnitt dieses Angebot mit eigenen Fähigkeiten und Richtlinien. Ein Name delegierte Auswahl an einen veränderlichen Dienstgraphen.

Die IPv4-Liste trug weniger Kontext. Adressen standen in Präferenzreihenfolge, doch Option 120 enthielt keinen NAPTR-Dienst, keinen SRV-Port, keine Priorität, kein Gewicht und keine Transportbeschreibung. Sie fror Kandidaten in die DHCP-Konfiguration ein. Änderungen mussten dort verteilt werden.

Damit verschob die Form die Änderungsmacht. DNS-Verwalter konnten Instanzen oder Reihenfolgen ohne neue Lease bewegen. Eine Literal-Liste gab dem DHCP-Verwalter mehr direkte Kontrolle. Clientversion, Cache, Transportfähigkeit, Richtlinie und aktuelle Proxygesundheit blieben außerhalb beider Hände.

Auch mehrere Namen hatten eine begrenzte Bedeutung. Sie sollten verschiedene NAPTR-Domains, etwa unterschiedliche Anbieter, vertreten und nicht mehrere A-Einträge einer Domain ersetzen. Der Client versuchte sie in Listenfolge und wechselte erst bei Kontaktfehler, fehlendem gemeinsamen Transport oder lokaler Sperre.

Mehrere Ordnungen lagen übereinander. DHCP ordnete Anbieter-Domains, NAPTR Transportdienste, SRV Instanzen nach Priorität und Gewicht. Auflösung gab Adressen, Clientfähigkeit entfernte ungeeignete Kandidaten. Der schließlich sichtbare Host war das komprimierte Ergebnis mehrerer Steuerungsflächen.

RFC 3263 setzte außerdem eine Grenze für Veränderung. Nach erfolgreichem Kontakt für eine SIP-Transaktion mussten Wiederholungen, CANCEL und ACK zu einer Nicht-2xx-Endantwort denselben Server erreichen. Vorher durfte die Suche dynamisch sein; danach schützte Bindung den entstandenen Zustand.

Das Codierungsbyte machte eine semantische Gefahr sichtbar. Ein DHCP-Server durfte Namen und Adressen nicht in derselben Nachricht mischen, auch nicht als zwei Vorkommen von Option 120. DHCP fügt wiederholte Optionen vor der Verarbeitung zusammen. Zwei lokal gültige Fragmente mit verschiedenen Grammatiken ergäben ein falsch verstandenes Gesamtobjekt.

RFC 3396 präzisierte später die Reihenfolge der Verkettung und das Aufteilen langer DHCPv4-Optionen. Sie hielt zugleich fest, dass viele eingesetzte Agenten solche Teile nicht wieder zusammensetzten. Ein Sender konnte normgerecht teilen und auf einen Empfänger treffen, der den Wert nicht rekonstruierte.

RFC 3361 verlangte genau diesen Mechanismus, wenn die Namensliste eine Option überschritt. Noch vor einer DNS-Anfrage hing eine lange Liste von Fragmentreihenfolge und Implementierung ab. Der Nachweis vollständiger Übertragung war kein Nachweis gleicher Interpretation.

RFC 3319 wählte im folgenden Jahr für DHCPv6 zwei getrennte Optionscodes, einen für Namen und einen für IPv6-Adressen. DHCPv6 hatte keinen Mangel an Codes und konnte das Codierungsbyte vermeiden. Das machte die Optionen kürzer, einfacher und besser ausgerichtet und erlaubte getrennte Anfragen. Knappheit in einem Register war zuvor als Komplexität in jede IPv4-Nachricht gewandert.

Die Namen verwendeten RFC-1035-Label und DNS-Kompression, auch mit Blick auf künftige internationalisierte Namen. Darunter wirkten SRV aus RFC 2782 und NAPTR aus RFC 3403. Die kleine Option blieb klein, weil sie auf größere, unabhängig gepflegte Mechanismen verweisen konnte.

Indirektion vergrößerte Flexibilität und Vertrauen zugleich. RFC 3361 warnte, veränderte oder eingeschleuste DHCP-Antworten könnten den Client zu einem fremden SIP-Server lenken, Anforderungen abfangen oder Dienst verweigern. Namen für TLS-basierte SIP-Server konnten ausgelassen werden. Die Lease trug kein Gespräch, entschied aber über das erste Signalisierungstor und unsichtbare Alternativen.

Das heutige IANA-Register führt Code 120 weiterhin. Diese Zeile belegt die koordinierte Zuordnung, nicht aktuelle Verteilung, Implementierung, Verwendung oder Erreichbarkeit eines Proxys.

Auch eine beobachtete Lease hat engen Beweiswert. Sie zeigt Bytes und Form. Sie zeigt nicht, ob DNS antwortete, Transporte zusammenpassten, die Verbindung aufging, der Proxy eine Transaktion annahm, spätere Hops funktionierten, die Sitzung zustande kam oder Medien flossen.

Darum sind Belege zu trennen. Für DHCP: Server, Relay, Rohbytes, Form, Reihenfolge und Laufzeit. Für Namen: NAPTR, SRV, A/AAAA, TTL und gefilterte Wahl. Für Adressen: Versuch, Port und Transport. Danach getrennt Proxykontakt, SIP-Antwort, Folgerouting, Sitzungsbeschreibung und Medien.

Zwei Texte von Lu Heng dienen offengelegt als analytische Perspektiven. „Minimum Initial Specification“ erklärt den Wert einer engen gemeinsamen Option, die Anbieterbetrieb, DNS-Regeln und Einführung lokal belässt. „Reality Layers“ trennt registrierten Code, gelieferte Konfiguration, aufgelösten Dienst, laufende Implementierung und Anrufergebnis. Das sind redaktionelle Lesarten, keine Behauptungen über Urheberschaft oder Absicht von RFC 3361.

Option 120 schuf einen Treffpunkt, keinen Ankunftsbeleg. Ihr Byte entschied, ob spätere Wahl an ein lebendes Namenssystem ging oder teilweise in einer Adressreihe erstarrte. Die Lease nannte den Anfang; für den weiteren Pfad waren weitere Belege nötig.

Quellen