3.15. Configuration Payload (Konfigurations-Nutzdaten)

Das Configuration-Payload, in diesem Dokument als CP bezeichnet, dient dem Austausch von Konfigurationsinformationen zwischen IKE-Peers. Der Austausch ermöglicht es einem IRAC, eine interne IP-Adresse von einem IRAS anzufordern und weitere Informationen auszutauschen, die man mit dem Dynamic Host Configuration Protocol (DHCP) erhalten würde, wenn der IRAC direkt an ein LAN angeschlossen wäre.

Das Configuration-Payload ist wie folgt definiert:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C| RESERVED    |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CFG Type    |                    RESERVED                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Configuration Attributes                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 22: Format des Configuration-Payloads

Der Nutzdatentyp für das Configuration-Payload ist siebenundvierzig (47).

CFG Type (1 Oktett) - Der von den Configuration Attributes dargestellte Austauschtyp. Die Werte in der folgenden Tabelle gelten nur bis zum Veröffentlichungsdatum von RFC 4306. Später hinzugekommene Werte siehe [IKEV2IANA].

CFG Type	Wert
CFG_REQUEST	1
CFG_REPLY	2
CFG_SET	3
CFG_ACK	4

RESERVED (3 Oktette) - MUSS als Null gesendet und beim Empfang ignoriert werden.
Configuration Attributes (variable Länge) - Typ-Länge-Wert-Strukturen (TLV) speziell für das Configuration-Payload, unten definiert. Es können null oder mehr Configuration Attributes in dieser Nutzlast enthalten sein.

3.15.1. Configuration Attributes

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|         Attribute Type      |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Value                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 23: Format des Configuration Attribute

Reserved (1 Bit) - Dieses Bit MUSS null sein und MUSS beim Empfang ignoriert werden.
Attribute Type (15 Bits) - Eindeutiger Bezeichner für jeden Configuration-Attribute-Typ.
Length (2 Oktette, vorzeichenlose Ganzzahl) - Länge des Wertes in Oktetten.
Value (null oder mehr Oktette) - Variabler Wert dieses Configuration Attribute. Die Attributtypen folgen unten.

Die Werte der folgenden Tabelle gelten bis zum Veröffentlichungsdatum von RFC 4306 (INTERNAL_ADDRESS_EXPIRY und INTERNAL_IP6_NBNS wurden durch RFC 5996 entfernt). Neuere Werte in [IKEV2IANA].

Attribute Type	Wert	Mehrwertig	Länge
INTERNAL_IP4_ADDRESS	1	YES*	0 oder 4 Oktette
INTERNAL_IP4_NETMASK	2	NO	0 oder 4 Oktette
INTERNAL_IP4_DNS	3	YES	0 oder 4 Oktette
INTERNAL_IP4_NBNS	4	YES	0 oder 4 Oktette
INTERNAL_IP4_DHCP	6	YES	0 oder 4 Oktette
APPLICATION_VERSION	7	NO	0 oder mehr
INTERNAL_IP6_ADDRESS	8	YES*	0 oder 17 Oktette
INTERNAL_IP6_DNS	10	YES	0 oder 16 Oktette
INTERNAL_IP6_DHCP	12	YES	0 oder 16 Oktette
INTERNAL_IP4_SUBNET	13	YES	0 oder 8 Oktette
SUPPORTED_ATTRIBUTES	14	NO	Vielfaches von 2
INTERNAL_IP6_SUBNET	15	YES	17 Oktette

* Diese Attribute dürfen in der Antwort nur dann mehrwertig sein, wenn mehrere Werte angefordert wurden.

INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - Eine Adresse im internen Netz, manchmal Red-Node- oder Privatadresse genannt; KANN eine private Adresse im Internet sein. In einer Anfragenachricht ist die angegebene Adresse eine gewünschte Adresse (oder Länge null, wenn keine spezifische Adresse gewünscht ist). Eine spezifische Adresse deutet oft auf eine frühere Verbindung mit dieser Adresse hin und Wiederverwendungswunsch. Bei IPv6 KANN der Anforderer die gewünschten niederwertigen Adressoktette angeben. Mehrere interne Adressen KÖNNEN durch mehrere interne Adressattribute angefordert werden. Der Responder DARF höchstens so viele Adressen senden wie angefordert. INTERNAL_IP6_ADDRESS besteht aus zwei Feldern: 16-Oktett-IPv6-Adresse und 1-Oktett-Präfixlänge gemäß [ADDRIPV6]. Die angeforderte Adresse ist gültig, solange diese IKE SA (oder ihre Nachfolger nach Rekey), die sie angefordert hat, gültig ist. Siehe Abschnitt 3.15.3.
INTERNAL_IP4_NETMASK - Die Netzmaske des internen Netzes. Nur eine Netzmaske ist in Anfrage- und Antwortnachrichten erlaubt (z. B. 255.255.255.0) und MUSS nur mit INTERNAL_IP4_ADDRESS verwendet werden. INTERNAL_IP4_NETMASK in CFG_REPLY bedeutet in etwa dasselbe wie INTERNAL_IP4_SUBNET mit denselben Informationen („Trafik zu diesen Adressen über mich senden“), impliziert aber auch eine Linkgrenze. Der Client kann z. B. mit eigener Adresse und Maske die Broadcast-Adresse des Links berechnen. Ein leeres INTERNAL_IP4_NETMASK-Attribut kann in CFG_REQUEST diese Information anfordern (Gateway kann sie auch ohne Anfrage sendieren). Nicht leere Werte in CFG_REQUEST sind unsinnig und DÜRFEN NICHT vorkommen.
INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Adresse eines DNS-Servers im Netz. Mehrere DNS-Server KÖNNEN angefordert werden. Der Responder KANN mit null oder mehr DNS-Server-Attributen antworten.
INTERNAL_IP4_NBNS - Adresse eines NetBios Name Server (WINS) im Netz. Mehrere NBNS-Server KÖNNEN angefordert werden. Der Responder KANN mit null oder mehr NBNS-Attributen antworten.
INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Weist den Host an, interne DHCP-Anfragen an die im Attribut enthaltene Adresse zu senden. Mehrere DHCP-Server KÖNNEN angefordert werden. Der Responder KANN mit null oder mehr DHCP-Server-Attributen antworten.
APPLICATION_VERSION - Versions- oder Anwendungsinformation des IPsec-Hosts. Druckbare ASCII-Zeichenkette OHNE Nullterminator.
INTERNAL_IP4_SUBNET - Die geschützten Teilnetze, die dieses Randgerät schützt. Zwei Felder: IP-Adresse und Netzmaske. Mehrere Teilnetze KÖNNEN angefordert werden. Der Responder KANN mit null oder mehr Teilnetz-Attributen antworten. Siehe Abschnitt 3.15.2.
SUPPORTED_ATTRIBUTES - In einer Request MUSS dieses Attribut Länge null haben und den Responder auffordern, alle unterstützten Attribute zurückzugeben. Die Antwort enthält ein Attribut mit Kennungen je 2 Oktette. Länge geteilt durch 2 ergibt die Anzahl unterstützter Attribute.
INTERNAL_IP6_SUBNET - Geschützte Teilnetze dieses Randgeräts. 16-Oktett-IPv6-Adresse und 1-Oktett-Präfixlänge gemäß [ADDRIPV6]. Mehrere Teilnetze KÖNNEN angefordert werden. Siehe Abschnitt 3.15.2.

Dieses Dokument empfiehlt keine konkrete Methode, wie eine Implementierung feststellt, welche Informationen in einer Antwort zu senden sind; insbesondere keine spezifische Methode, mit der ein IRAS bestimmt, welcher DNS-Server an einen anfragenden IRAC zurückgegeben wird.

CFG_REQUEST und CFG_REPLY erlauben einem IKE-Endpunkt, Informationen vom Peer anzufordern. Ist ein Attribut im CFG_REQUEST-Configuration-Payload nicht länge-null, gilt es als Vorschlag für dieses Attribut. CFG_REPLY KANN denselben oder einen neuen Wert zurückgeben, neue Attribute hinzufügen oder angeforderte weglassen. Nicht erkannte oder nicht unterstützte Attribute MÜSSEN in Anfragen und Antworten ignoriert werden.

CFG_SET und CFG_ACK erlauben das Pushen von Konfigurationsdaten. Das CFG_SET-Configuration-Payload enthält Attribute, die der Initiator vom Peer geändert haben möchte. Hat der Responder Konfigurationsdaten akzeptiert, MUSS er ein Configuration-Payload zurückgeben, das die akzeptierten Attribute mit länge-null-Daten enthält. Nicht akzeptierte Attribute DÜRFEN nicht im CFG_ACK-Configuration-Payload stehen. Wurde nichts akzeptiert, MUSS der Responder entweder ein leeres CFG_ACK-Payload oder eine Antwort ohne CFG_ACK zurückgeben. Für CFG_SET/CFG_ACK gibt es derzeit keine definierten Verwendungen; Erweiterungen mit Vendor-IDs sind möglich. Implementierungen DÜRFEN CFG_SET-Payloads ignorieren.

3.15.2. Bedeutung von INTERNAL_IP4_SUBNET und INTERNAL_IP6_SUBNET

INTERNAL_IP4/6_SUBNET-Attribute können zusätzliche Teilnetze anzeigen, die über das Gateway erreichbar sind, das die Attribute ankündigt, und eine oder mehrere getrennte SAs erfordern. Sie können auch die Gateway-Richtlinie ausdrücken, welcher Trafik durch das Gateway gehen soll; der Client kann wählen, ob anderer Trafik (von TSr abgedeckt, aber nicht in INTERNAL_IP4/6_SUBNET) über das Gateway oder direkt geht. Trafik zu den in INTERNAL_IP4/6_SUBNET aufgeführten Adressen sollte über das ankündigende Gateway gesendet werden. Gibt es keine Child-SA, deren Traffic Selectors die Adresse abdecken, müssen neue SAs erstellt werden.

Beispiel mit zwei Teilnetzen 198.51.100.0/26 und 192.0.2.0/24:

CP(CFG_REQUEST) =
  INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

Gültige Antwort (TSr und INTERNAL_IP4_SUBNET gleiche Information):

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
       (0, 0-65535, 192.0.2.0-192.0.2.255))

Hier trägt INTERNAL_IP4_SUBNET wenig nützliche Zusatzinformation.

Alternative Antwort:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

Der Client darf den gesamten Trafik über das Gateway senden; das Gateway erlaubt auch direkten Trafik außerhalb INTERNAL_IP4_SUBNET.

Erfordert die Gateway-Richtlinie getrennte SAs für die beiden Teilnetze, zeigt folgende Antwort, dass für das zweite Teilnetz eine separate SA nötig ist:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

INTERNAL_IP4_SUBNET ist auch nützlich, wenn der TSr des Clients nur einen Teil des Adressraums abdeckt:

CP(CFG_REQUEST) =
  INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

Mögliche Gateway-Antwort:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

Da die Bedeutung von INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in CFG_REQUESTs unklar ist, sind sie dort nicht zuverlässig verwendbar.

3.15.3. Configuration payloads für IPv6

Die IPv6-Configuration-Payloads basieren auf den IPv4-Pendants und folgen nicht vollständig der „üblichen IPv6-Vorgehensweise“. Insbesondere keine zustandslose IPv6-Autokonfiguration oder Router-Advertisements, auch keine Neighbor Discovery. Siehe [IPV6CONFIG] zu IPv6 in IKEv2 (derzeit experimentell).

Ein Client kann eine IPv6-Adresse über INTERNAL_IP6_ADDRESS erhalten. Minimaler Austausch:

CP(CFG_REQUEST) =
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

CP(CFG_REPLY) =
  INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

Der Client KANN ein nicht leeres INTERNAL_IP6_ADDRESS in CFG_REQUEST senden. Das Gateway prüft die Adresse; bei Ablehnung versucht es den Schnittstellen-Identifier mit anderem Präfix oder wählt einen anderen Identifier.

INTERNAL_IP6_ADDRESS enthält ein Präfixlängenfeld; in CFG_REPLY entspricht es INTERNAL_IP4_NETMASK in IPv4.

IPsec-Tunnel über IKEv2 sind keine vollwertigen „Schnittstellen“ im Sinne der IPv6-Adressarchitektur [ADDRIPV6]; insbesondere fehlen oft Link-Local-Adressen, was Protokolle wie [MLDV2] erschwert.

3.15.4. Fehler bei der Adresszuweisung

Tritt beim Zuweisen einer IP-Adresse an den Initiator während der Verarbeitung eines Configuration-Payloads ein Fehler auf, antwortet der Responder mit INTERNAL_ADDRESS_FAILURE. Die IKE SA wird dennoch erzeugt, auch wenn die anfängliche Child-SA deswegen fehlschlägt. Innerhalb von IKE_AUTH wird keine Child-SA erzeugt. Komplexere Fehlerfälle existieren.

Unterstützt der Responder keine Configuration-Payloads, kann er alle ignorieren. Solche Implementierungen senden nie INTERNAL_ADDRESS_FAILURE.

Fordert der Initiator zwingend eine IP-Adresse, gilt eine Antwort ohne CFG_REPLY als Fehler.

Der Initiator kann einen Adresstyp (IPv4 oder IPv6) anfordern, den der Responder nicht unterstützt, obwohl er Configuration-Payloads unterstützt. Der Responder ignoriert diesen Typ und verarbeitet den Rest wie üblich.

Schlagen einige (nicht alle) Anfragen mehrerer Adressen fehl, antwortet der Responder nur mit den erfolgreichen. INTERNAL_ADDRESS_FAILURE nur, wenn gar keine Adresse zuweisbar ist.

Erhält der Initiator die von der Politik geforderte(n) Adresse(n) nicht, KANN er die IKE SA aufrechterhalten und das Configuration-Payload nach Timeout in einem separaten INFORMATIONAL erneut versuchen, oder die IKE SA mit Delete-Payload abbauen und später neu starten. Timeouts sollten nicht zu kurz sein (mehrere Minuten). Adressmangel löst sich oft erst bei Client-Abmeldungen oder größerem Pool.