12. Identity Association
Dieser Abschnitt bewahrt den RFC-Text zu DHCPv6, einschliesslich Nachrichtenaustausch, Relay-Verhalten, DUIDs, IA_NA, IA_TA, IA_PD, DHCP-Optionen, RKAP-Authentifizierung, IANA-Registern, normativen Anforderungen und der Optionsvorkommensmatrizen im Anhang.
Originaler RFC-Text
12. Identity Association
Eine Identity Association (IA) ist ein Konstrukt, ueber das ein Server
und ein Client eine Menge zusammenhaengender IPv6-Adressen oder
delegierter Praefixe identifizieren, gruppieren und verwalten koennen.
Jede IA besteht aus einem IAID und zugehoerigen
Konfigurationsinformationen.
Der IAID identifiziert die IA eindeutig und MUST so gewaehlt werden,
dass er unter den IAIDs dieses IA-Typs auf dem Client eindeutig ist
(z. B. gelten eine IA_NA mit einem IAID von 0 und eine IA_PD mit einem
IAID von 0 jeweils als eindeutig). Der IAID wird vom Client gewaehlt.
Fuer jede gegebene Verwendung einer IA durch den Client MUST der IAID
fuer diese IA ueber Neustarts des DHCP-Clients hinweg konsistent
bleiben. Der Client kann Konsistenz wahren, indem er den IAID
entweder in nichtfluechtigem Speicher speichert oder einen Algorithmus
verwendet, der konsistent denselben IAID erzeugt, solange sich die
Konfiguration des Clients nicht geaendert hat. Es gibt moeglicherweise
keine Moeglichkeit fuer einen Client, die Konsistenz der IAIDs zu
wahren, wenn er keinen nichtfluechtigen Speicher besitzt und sich die
Hardwarekonfiguration des Clients aendert. Wenn der Client nur einen
IAID verwendet, kann er einen wohlbekannten Wert verwenden, z. B. null.
Wenn der Client eine eindeutig neue Adresse oder ein neues Praefix
erhalten und die bestehende Adresse bzw. das bestehende Praefix
deprecaten moechte, sendet der Client eine Release-Nachricht fuer die
IAs mit dem urspruenglichen IAID an den Server. Danach erstellt der
Client einen neuen IAID, der in zukuenftigen Nachrichten verwendet
wird, um Leases fuer die neue IA zu erhalten.
12.1. Identity Associations fuer Adresszuweisung
Ein Client muss mindestens eine eindeutige IA mit jeder seiner
Netzwerkschnittstellen verknuepfen, fuer die er die Zuweisung von
IPv6-Adressen von einem DHCP-Server anfordern soll. Der Client
verwendet die einer Schnittstelle zugewiesenen IAs, um von einem
Server Konfigurationsinformationen fuer diese Schnittstelle zu
erhalten. Jede solche IA muss genau einer Schnittstelle zugeordnet
sein.
Die Konfigurationsinformationen in einer IA_NA option bestehen aus
einer oder mehreren IPv6-Adressen zusammen mit den T1- und T2-Werten
fuer die IA. Siehe Section 21.4 fuer Details zur Darstellung einer
IA_NA in einer DHCP-Nachricht.
Jede Adresse in einer IA hat eine preferred lifetime und eine valid
lifetime, wie in [RFC4862] definiert. Die lifetimes werden vom
DHCP-Server an den Client in der IA Address option (siehe
Section 21.6) uebertragen. Die lifetimes gelten fuer die Verwendung
von Adressen; siehe Section 5.5.4 von [RFC4862].
12.2. Identity Associations fuer Praefixdelegation
Eine IA_PD unterscheidet sich von einer IA fuer Adresszuweisung
dadurch, dass sie nicht genau einer Schnittstelle zugeordnet sein muss.
Eine IA_PD kann dem Client, einer Menge von Schnittstellen oder genau
einer Schnittstelle zugeordnet sein. Ein Client, der fuer die
Anforderung delegierter Praefixe konfiguriert ist, muss mindestens
eine eindeutige IA_PD erstellen. Er kann jeder seiner Downstream-
Netzwerkschnittstellen eine eigene IA_PD zuordnen und diese IA_PD
verwenden, um vom Server ein Praefix fuer diese Schnittstelle zu
erhalten.
Die Konfigurationsinformationen in einer IA_PD option bestehen aus
einem oder mehreren Praefixen zusammen mit den T1- und T2-Werten fuer
die IA_PD. Siehe Section 21.21 fuer Details zur Darstellung einer
IA_PD in einer DHCP-Nachricht.
Jedes delegierte Praefix in einer IA hat eine preferred lifetime und
eine valid lifetime, wie in [RFC4862] definiert. Die lifetimes werden
vom DHCP-Server an den Client in der IA Prefix option (siehe
Section 21.22) uebertragen. Die lifetimes gelten fuer die Verwendung
delegierter Praefixe; siehe Section 5.5.4 von [RFC4862].