Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RADIUS-Neuauthentifizierung als Alternative zu RADIUS-CoA für DHCP-Abonnenten

RADIUS Change of Authorization (CoA)-Nachrichten, die in RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) spezifiziert sind, werden verwendet, um Client-Services zu aktivieren oder zu deaktivieren und bestimmte Merkmale der Client-Sitzung zu ändern, ohne den Client abzumelden, wodurch eine Unterbrechung des Abonnenten vermieden wird. Unter bestimmten Umständen kann es vorzuziehen, die erneute Authentifizierung des Anwenders als Methode zu verwenden, um die Client-Sitzungsservices und -merkmale ohne Unterbrechung zu ändern.

Die folgenden Kundenbereitstellungsmodi erfordern beispielsweise Änderungen der Attribute während der Lebensdauer einer Sitzung.

  • Privatkunden: Privatkunden können die Servicepläne während des gesamten Lebenszyklus einer Sitzung ändern, indem sie den Online-Service auswählen oder direkt beim Anbieter anrufen. Die Änderung des Serviceplans wird an den lokalen DHCP-Server weitergegeben, indem der Wert der DHCP-Client-Agent-Remote-ID geändert wird. Die Agent Remote-ID wird in Option 82, Unteroption 2, für DHCPv4-Clients und in Option 37 für DHCPv6-Clients übermittelt.

    Wenn eine erneute Authentifizierung konfiguriert ist, wird die Änderung des Serviceplans erkannt und führt zu einer erneuten Authentifizierung. der neue Serviceplan und alle geänderten Attribute werden vom RADIUS-Server zurückgegeben und für den Anwender implementiert.

  • Geschäftskunden: Geschäftskunden benötigen häufig Änderungen der Attribute (insbesondere gerahmte Routen) während einer bestimmten Sitzung. Die gewünschte Änderung der Attribute wird nicht durch eine Änderung der Servicepläne initiiert.

    Wenn eine erneute Authentifizierung konfiguriert ist, löst die Aushandlung der Lease-Verlängerung eine erneute Authentifizierung aus. Alle Änderungen an Attributen oder Services werden in der Access-Accept-Nachricht vom RADIUS-Server bereitgestellt und für den Abonnenten implementiert.

Zwei Alternativen zur erneuten Authentifizierung können beide viel mehr Sitzungsmerkmale ändern, als dies mit einer erneuten Authentifizierung möglich ist. CoA fordert Änderungen der Merkmale an, ohne den Abonnenten zu stören. Das Abmelden des Abonnenten und dann wieder eins kann viele weitere Sitzungseigenschaften ändern, ist jedoch offensichtlich störend.

Vorteile einer erneuten Authentifizierung

  • Aktualisieren oder ändern Sie die Attribute und Servicepläne der Anwendersitzung, ohne eine CoA-Anfrage zu verwenden.

  • Simplifizieren Sie die Aktivierung von Services, die sich aus häufig von Anwendern initiierten Änderungen ergeben.

  • Aktivieren Sie die erneute Authentifizierung pro Familie in Dual-Stack-Konfigurationen mit einer Sitzung.

  • Steuern Sie die erneute Authentifizierung über eine CLI-Konfiguration oder eine RADIUS-VSA.

Funktionalität

Die erneute Authentifizierung wird sowohl für DHCPv4 als auch für DHCPv6 unterstützt. Sie kann ausgelöst werden, wenn der lokale DHCP-Server eine Erneuerungs-, Rebind-, Erkennungs- oder Aufforderungsnachricht von einem DHCP-Client empfängt. Die Erkennungs- und Werbenachrichten unterstützen die erneute Authentifizierung ab Junos OS Version 18.1R1. Die Unterstützung für Erkennungs- und Werbenachrichten bedeutet, dass Authentication es authentication ermöglicht, wenn ein CPE mit einem gebundenen Client neu gestartet wird und der Client eine dieser Nachrichten sendet, um die Sitzung wieder zu starten.

Das Verhalten der erneuten Authentifizierung wird wie folgt ermittelt:

  • Die reauthenticate lease-renewal Anweisung gibt an, dass eine erneute Authentifizierung ausgelöst wird, wenn eine der vier unterstützten Nachrichten empfangen wird.

  • Die reauthenticate remote-id-mismatch Anweisung gibt an, dass eine erneute Authentifizierung nur ausgelöst wird, wenn die empfangene Nachricht eine Änderung des Wertes der Remote-Agent-ID des DHCP-Clients enthält. Der Attributwert enthält den Namen des Abonnenten-Serviceplans, sodass eine Änderung des Werts eine Änderung des Diensts für den Abonnenten bedeutet.

  • Die VSA von Juniper Networks reauthentication-on-renew (26-206) löst bei Erhalt einer der vier Nachrichten eine erneute Authentifizierung aus, wenn sie in der Access-Accept-Nachricht vom RADIUS-Server für den Anwender bei der Anmeldung mit dem Wert 1 zurückgegeben wird. Ein Wert von 0 deaktiviert die erneute Authentifizierung. Der VSA-Wert wird immer dann in der Sitzungsdatenbank gespeichert, wenn er empfangen wird. Nachdem diese VSA die erneute Authentifizierung aktiviert hat, wird sie bei jedem erneuten Authentifizierungsversuch überprüft. Wenn sich der Wert auf 0 geändert hat, also wenn ein späterer Zugriff die VSA mit dem Wert 0 zurückgegeben hat, wird der Prozess der erneuten Authentifizierung für diesen Abonnenten beendet.

    Die CLI-Konfiguration (reauthenticate Anweisung) und das Verhalten "Reauthenticate-On-Renew" sind additiv. Das Deaktivieren der erneuten Authentifizierung mit der VSA wirkt sich nur aus, wenn die reauthenticate Anweisung nicht konfiguriert ist. Wenn die reauthenticate Anweisung mit einer der beiden Optionen konfiguriert ist, überschreibt sie den VSA-Wert 0. Wenn keine CLI-Konfiguration vorhanden ist, kann die VSA selbst eine erneute Authentifizierung ermöglichen.

Der Erneuteauthentifizierungsprozess ist fast identisch mit dem ursprünglichen Authentifizierungsprozess. Wenn eine erneute Authentifizierung ausgelöst wird, übermittelt der jdhcpd-Prozess auf dem lokalen Server eine Authentifizierungsanforderung an authd, die wiederum eine Access-Request-Nachricht an den RADIUS-Server übermittelt, um eine zweite Authentifizierung anzufordern.

Hinweis:

Die Erneuteauthentifizierungsanforderung schlägt für eine andere Authentifizierungsreihenfolge als radius oder . none Der authentifizierte Prozess gibt eine negative Bestätigung (NAK) für jede solche Anforderung zurück.

Diese Zugriffsanfrage enthält RADIUS-Status- und Klassenattribute, die in der ursprünglichen Access-Accept-Nachricht zurückgegeben wurden. Diese Attribute ermöglichen es dem RADIUS-Server, die Anforderung zur erneuten Authentifizierung von Anmeldeanfragen (Authentifizierung) zu unterscheiden.

Der RADIUS-Server gibt eine Access-Accept-Nachricht an die Authentifizierung mit neuen Attributen für den Abonnenten zurück. Der authentifizierte Prozess sendet eine Bestätigung (ACK) mit den Änderungen an jdhcpd, das ein DHCP-Angebot mit geänderten Attributen an den DHCP-Client sendet. Die DHCP-Aushandlung wird wie üblich fortgesetzt, wie in Abbildung 1 dargestellt, und die Abonnentensitzung wird mit den neuen Attributwerten fortgesetzt. Wenn die erneute Authentifizierung eine Änderung des Serviceplans umfasst, gibt der RADIUS-Server den neuen Plan mit anderen geänderten Attributen zurück, wenn er die Anforderung akzeptiert, wie in Abbildung 2 dargestellt. Wenn das CPE, das den DHCP-Client hostet, während des Änderungsprozesses eines Serviceplans neu gestartet wird, wird die erneute Authentifizierung mit dem neuen Plan ohne Unterbrechung des Service unterstützt.

Wenn der RADIUS-Server eine Anfrage für eine erneute Authentifizierung ablehnt oder ein Zeitabweichungs-Out ausgibt, sendet die Authentifizierung einen NAK an jdhcpd, der den enthaltenen Fehlercode überprüft. Wenn der Fehlercode ein Timeout angibt, sendet jdhcpd einen ACK an den DHCP-Client, und die Abonnentensitzung wird mit den ursprünglichen Attributen und dem ursprünglichen Dienst verwaltet. Für jeden anderen Fehlercode sendet jdhcpd einen DHCPv4 NAK oder DHCPv6 REPLY (mit dem Lebenszeitwert auf 0) als logischen NAK, initiiert die Abonnentenanmeldung und löscht den Abonnenten aus der Sitzungsdatenbank.

Tabelle 1 beschreibt, wie authd Anfragen verarbeitet, wenn ein anderer Anforderungstyp für denselben Abonnenten bereits ausgeführt wird.

Tabelle 1: Verarbeitung mehrerer Anforderungstypen

Anfrage wird ausgeführt

Zusätzliche Anfrage für ein und denselben Abonnenten erhalten

Aktion

Erneute Authentifizierung

Coa

authd antwortet auf die CoA mit einem NAK.

Coa

Erneute Authentifizierung

Authentifizierungswarteschlangen für die erneute Authentifizierung, bis die CoA verarbeitet wird, und verarbeitet dann die Anforderung zur erneuten Authentifizierung.

Erneute Authentifizierung

Trennen

authd reagiert auf die Trennung mit einem NAK.

Trennen

Erneute Authentifizierung

authd antwortet auf die Anforderung zur erneuten Authentifizierung mit einem NAK und loggt den Abonnenten weiter aus.

Best Practices:

Da die Netzwerkfamilie im Rahmen der erneuten Authentifizierung nicht beendet oder neu eingeführt wird, werden die Abonnenteninhalte nicht im Hinblick auf die sichere Richtlinienspiegelung der Abonnenten neu bewertet. Verwenden Sie kein Attribut, das während der Verarbeitung der erneuten Authentifizierung geändert werden kann, als Auslöser für sichere Abonnentenrichtlinienspiegelung.

Wenn die erneute Authentifizierung nach der Bindung eines Clients zu einer Änderung der IP- oder IPv6-Adresse eines DHCPv6-Abonnenten führt, wertet der DHCPv6-Server die Adressänderungsanfrage aus. Der Server gibt einen Statuscode an den Client in der Identity Association (IA) der Antwort-PDU zurück. Wenn der DHCPv6-Server ein Problem mit der Adresse erkennt, wird ab Junos OS Version 18.4R1 zusätzlich zu den zuvor unterstützten Codes für NoAddrsAvail und NoPrefixAvail auch ein Statuscode für NotOnLink unterstützt. Diese Statuscodes sind wie folgt definiert:

  • NoAddrsAvail (2): Der Server kann in der Client-Anforderung keine Adressen für die IA zuweisen. Es gibt die IA ohne Adressen und NoAddrsAvail zurück.

  • NotOnLink (4): Der Server stellt fest, dass das Präfix für eine oder mehrere Adressen in einer IA in der Client-Anforderung nicht für den Link geeignet ist, der sich mit dem Client verbindet. Dieser Code wird auch im Falle eines Fehlers der erneuten Authentifizierung verwendet (RADIUS Access-Reject).

  • NoPrefixAvail (6): Der Server hat keine Präfixe für die IA in der Client-Anforderung verfügbar.

Wenn der Client den NotOnLink-Statuscode erhält, kann er eine weitere Anfrage ohne Adressen senden oder den Aushandlungsprozess neu starten. Wenn er eine Anfrage sendet, ignoriert der lokale DHCPv6-Serer die Anforderung und erwartet, dass eine neue Aushandlung beginnt.

Dual-Stack-Abonnenten

In Versionen vor Junos OS Version 18.1R1 werden Dual-Stack-DHCP-Abonnenten als unabhängige Client-Sitzungen behandelt. Jeder Stack erneuert und erhält neue Services unabhängig davon.

Ab Junos OS Version 18.1R1 werden familienspezifische Authentifizierung und erneute Authentifizierung für Dual-Stack-Anwender mit single-session unterstützt. Ein Dual-Stack-Anwender mit einer Sitzung ist in der Regel ein Haushalt mit einem eigenen VLAN in einem 1:1-Zugriffsmodell. Der Haushalt wird als einzelner Anwender mit einer einzigen Sitzung in der Sitzungsdatenbank dargestellt, aber er verfügt über zwei separate DHCP-Bindungen, eine für jede Familie, DHCPv4 und DHCPv6. Folglich sendet Authd separate Zugriffsanfragen, wie jede Familie in den Sitzungsprotokollen einträgt, oder versucht, dies erneut zu authentifizieren:

  • Die Authentifizierung pro Familie erfolgt, wenn eine Erkennungs- oder Aufforderungsnachricht empfangen wird, während sich eine Abonnentensitzung im DHCP-init-Status befindet.

  • Eine erneute Authentifizierung pro Familie erfolgt, wenn die erneute Authentifizierung und die On-Demand-Adresszuweisung konfiguriert sind und eine Erneuerungs-, Bindungs-, Erkennungs- oder Aufforderungsnachricht für die Familiensitzung empfangen wird, während sie sich im DHCP-gebundenen Zustand befindet.

Hinweis:

Die On-Demand-Adressenzuweisung bewirkt, dass eine Adresse für jede Familie separat zugewiesen wird, während sie sich anmeldet. Die On-Demand-Adressenzuweisung muss für Dual-Stack-Abonnenten, Abonnenten mit einer Sitzung oder familienspezifische Authentifizierung konfiguriert werden, und die erneute Authentifizierung kann nicht aktiviert werden. Für eine erneute Authentifizierung gilt dies unabhängig davon, ob sie in der CLI oder mit der VSA erneut authentifiziert wird (26-206).

Authentifizierung und erneute Authentifizierung werden beide pro Familie verarbeitet. Die erste Familie, die den Prozess auslösen soll, wird betreut, bevor die andere (zweite) Familie eine Authentifizierung oder erneute Authentifizierung auslöst. Nachrichten aus der zweiten Familie werden ignoriert, bis die erste Familie gebunden ist. Dann wird die zweite Familienanfrage bearbeitet.

Wenn sich nur eine Familie der Dual-Stack-Sitzung anmeldet, wird nur eine Authentifizierung verarbeitet. Erneute Authentifizierungen werden nur für die eine Client-Familie verarbeitet.

Der Authentifizierungsprozess klassifiziert Attribute als teil der DHCPv4- oder DHCPv6-Familie und tagst sie entsprechend. Für Authentifizierung und erneute Authentifizierung, je nachdem, welche Familie die Anforderung initiiert, umfasst die Authentifizierung entweder die DHCP-Options VSA (26-55) oder die DHCPv6-Options VSA (26-65). Je nach Konfiguration gibt der RADIUS-Server Möglicherweise Informationen nur für die Familie zurück, die die Anfrage initiiert hat (die anfragende Familie) oder für beide Familien.

Wenn authd Attribute in der Access-Accept-Nachricht empfängt, aktivieren die Familientags die Authentifizierung, um zu bestimmen, welche Attribute der anfordernden Familie oder der anderen Familie (nicht anfragend) entsprechen. Nur Attribute für die anfordernde Familie werden in die Sitzungsdatenbank geschrieben.

Für Erneuteauthentifizierungsanforderungen vergleicht Authentifizierung die zurückgegebenen Attribute mit der Sitzungsdatenbank, um zu ermitteln, ob Änderungen am RADIUS-Server vorgenommen wurden. Auch hier werden nur Änderungen, die der anfordernden Familie entsprechen, in die Sitzungsdatenbank geschrieben und die alten Werte überschrieben.

Änderungen während der erneuten Authentifizierung werden wie folgt verarbeitet:

  • Attribut (außer Adresse): Wenn Authentifizierung feststellt, dass sich eines oder mehrere dieser Attribute für die anfordernde Familie geändert haben, speichert es die neuen Werte in der Sitzungsdatenbank. Nachdem jdhcpd von der Authentifizierung benachrichtigt wurde, sendet es einen ACK mit den neuen Attributwerten an den DHCP-Client.

  • Adressen- oder Adresspool: Wenn Authentifizierung eine Änderung für die anfordernde Familie erkennt, benachrichtigt es den lokalen DHCP-Server, der wiederum einen NAK (DHCPv4) oder einen logischen NAK (DHCPv6) an den DHCP-Client sendet.

    Wenn die anfragende Familie die einzige Familie ist, die gebunden ist, meldet sich jdhcpd beim Abonnenten ordnungsgemäß aus. Wenn die nicht nachfragende Familie ebenfalls gebunden ist, deaktiviert jdhcpd die anfragende Familie, lässt jedoch die nicht nachfragende Familie gebunden, ohne dass der Dienst an die nicht nachfragende Familie unterbrochen wird. Die Deaktivierung der anfragenden Familie hat keine Auswirkungen auf eine nachträgliche Auslösung einer erneuten Authentifizierung durch die Nicht-Anfragende.

    Wenn die deaktivierte Familie anschließend eine Entdeckungs- oder Aufforderungsnachricht sendet, um sich wieder anzumelden, wird wie üblich eine Zugriffsanfrage zur erneuten Authentifizierung gesendet, und die neue Adresse, die im Access-Accept empfangen wurde, wird auf den Abonnenten angewendet.

Wenn der RADIUS-Server auf eine Authentifizierungs- oder erneute Authentifizierungsanforderung mit einer Access-Reject-Nachricht antwortet, benachrichtigt authentifizierung den lokalen DHCP-Server, der abwechselnd einen NAK (DHCPv4) oder ein logisches NAK (DHCPv6) an den DHCP-Client sendet. Die bittende Familie wird gnadenlos beendet; wird die Familie deaktiviert und der Anwender wird ausgeloggt. Dann wird die nicht nachfragende Familie deaktiviert und ausgeloggt, aber der Kunde wird nicht über die Kündigung informiert.

Wenn die Liveness-Erkennung auf der nicht angeforderten Familie ausgeführt wird, erkennt der Client den Verlust der Verbindung, wenn die Familie beendet wird, und sendet anschließend eine Erkennungs- oder Aufforderungsnachricht an den lokalen DHCP-Server. Wenn die Liveness-Erkennung jedoch nicht ausgeführt wird, erkennt der Client den Verlust der Verbindung erst, wenn die Rebinding-Zeit (T2, Option 59) abläuft und der Dienst verloren geht. Je nach Dauer des Leasingverhältnisses kann das lange dauern.

Best Practices:

Konfigurieren Sie die Liveness-Erkennung für beide Adressfamilien, um die Zeit bis zur Erkennung von Verbindungsverlusten zu verkürzen. Informationen zur Konfiguration der Liveness-Erkennung finden Sie in der Übersicht über die DHCP-Liveness-Erkennung .

Paketfluss

In der folgenden Abbildung wird die Reihenfolge für die erste Aushandlung einer Abonnentensitzung zwischen einem DHCP-Client, einem DHCP-Server und dem RADIUS-Server beschrieben. Der Serviceplan des Clients wird in der zweiten Teilzeichenfolge in der Remote-ID angegeben, die in DHCPv4-Option 82, Unteroption 2 oder DHCPv6-Option 37 enthalten ist.

Erste Aushandlung

Abbildung 1 veranschaulicht die Abfolge der Schritte bei der ersten Aushandlung zwischen einem DHCP-Client, einem DHCP-Server und dem RADIUS-Server. In der Abbildung werden folgende Begriffe verwendet:

CPE – Customer Premises Equipment (fungiert als DHCP-Client oder Anwender).

OLT – Optischer Line-Terminator– zum Beispiel ein DSL Access Multiplexer (DSLAM) oder ein anderes Aggregationsgerät.

Gerät der MX-Serie– Dient als DHCP-Server.

Abbildung 1: Anfängliche Aushandlung Initial Negotiation

Änderung des Serviceplans

Abbildung 2 veranschaulicht die Reihenfolge der Schritte bei einer Änderung der Servicepläne, von einem 100-Mbit/s-Plan zu einem 1-Gbit/s-Plan.:

Abbildung 2: Serviceplan Service Plan

Für die erneute Authentifizierung unterstützte RADIUS-Attribute

Tabelle 2 listet die RADIUS-Standardattribute und VSAs auf, die während der erneuten Authentifizierung verarbeitet werden können, wenn sie in der RADIUS Access-Accept-Nachricht empfangen werden, und beschreibt, wie Authentifizierung Änderungen an Attributen behandelt. Die Attributverarbeitung ist mit der Verarbeitung von CoA-Anforderung konsistent. Die Merkmale der erneuten Authentifizierung der Abonnentensitzung ändern sich nur, wenn neue Werte oder neue Attribute in der Nachricht Access-Accept empfangen werden.

Tabelle 2: RADIUS-Attribute, die durch erneute Authentifizierung unterstützt werden

Attributnummer

Attributname

Ergebnis der Verarbeitung

8

Framed-IP-Adresse

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

22

Gerahmte Route

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden angefügt.

24

Staat

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

25

Klasse

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

26-4

Primär-DNS

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

26-5

Sekundäres DNS

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

26-6

Primär-WINS

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

26-7

Sekundäre WINS

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

26-55

DHCP-Optionen

Der Wert wird an den lokalen DHCP-Server gesendet, um die Änderungen an der DHCP-Konfiguration des Anwenders zu verarbeiten.

26-65

Aktivierungsservice

Der Authentifizierungsprozess vergleicht die Liste der Services in der VSA mit den Services, die für diese Abonnentensitzung bereits aktiv sind.

  • Wenn die Liste in der VSA noch nicht aktive Services enthält, aktiviert die Authd diese Services für den Abonnenten.

  • Wenn ein Dienst, der für die Abonnentensitzung bereits aktiv ist, nicht in der VSA aufgeführt wird, deaktiviert der Autor diesen Dienst.

Nehmen wir beispielsweise an, die Dienste A und B sind in der Sitzung aktiv, die VSA umfasst jedoch nur Die Dienste B und C. Service A ist nicht in der VSA-Liste und wird deaktiviert. Service C ist in der Liste, aber derzeit nicht aktiv. Authd aktiviert C. Service B ist sowohl bereits aktiv als auch in der Liste, sodass er aktiv bleibt.

26-161

IPv6-Delegierter Poolname

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

26-206

Erneute Authentifizierung bei der Erneuerung

Wenn der Wert 1 (aktiviert) ist, fügt authd den Wert der Abonnentensitzungsdatenbank hinzu, wenn er nicht bereits vorhanden ist.

Wenn der Wert 0 (deaktivieren) ist und ein Wert von 1 bereits in der Datenbank vorhanden ist, setzt Authd den Datenbankwert auf 0.

Wenn der Wert in der Nachricht fehlt oder ungültig ist und ein Wert bereits in der Datenbank vorhanden ist, löscht der authentifizierte Wert aus der Datenbank.

26-207

DHCPv6-Optionen

Der Wert wird an den lokalen DHCPv6-Server gesendet, um die Änderungen an der DHCP-Konfiguration des Anwenders zu verarbeiten.

88

Framed-Pool

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

97

Framed-IPv6-Prefix

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

100

Framed-IPv6-Pool

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

123

Delegiertes IPv6-Präfix

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

168

Framed-IPv6-Adresse

Ein neuer Wert wird in der Abonnentensitzungsdatenbank gespeichert. alte Daten werden überschrieben.

Tabelle "Versionshistorie"
Release
Beschreibung
18,4R1
Wenn der DHCPv6-Server ein Problem mit der Adresse erkennt, wird ab Junos OS Version 18.4R1 zusätzlich zu den zuvor unterstützten Codes für NoAddrsAvail und NoPrefixAvail auch ein Statuscode für NotOnLink unterstützt.
18.1R1
Die Erkennungs- und Werbenachrichten unterstützen die erneute Authentifizierung ab Junos OS Version 18.1R1.