Zum Hauptinhalt springen

4.4.1.3. Mehr zu Feldern, die mit Next Layer Protocols verbunden sind (More Regarding Fields Associated with Next Layer Protocols)

Zusätzliche Selektoren sind oft mit Feldern im Next Layer Protocol-Header verbunden. Ein bestimmtes Next Layer Protocol kann null, einen oder zwei Selektoren haben. Es kann Situationen geben, in denen es nicht sowohl lokale als auch entfernte Selektoren für die Felder gibt, die vom Next Layer Protocol abhängig sind. Der IPv6 Mobility Header hat nur einen Mobility Header-Nachrichtentyp. AH und ESP haben keine weiteren Selektorfelder. Ein System kann bereit sein, einen ICMP-Nachrichtentyp und -code zu senden, den es nicht empfangen möchte.

Hinweis: In den folgenden Beschreibungen wird "Port" verwendet, um ein Feld zu bezeichnen, das vom Next Layer Protocol abhängig ist.

A. Protokolle ohne Port-Selektoren

Wenn ein Next Layer Protocol keine "Port"-Selektoren hat, dann werden die lokalen und entfernten "Port"-Selektoren im relevanten SPD-Eintrag auf OPAQUE gesetzt, z.B.:

Beispiel - AH-Protokoll:

Lokal (Local's)
next layer protocol = AH
"port" selector = OPAQUE

Entfernt (Remote's)
next layer protocol = AH
"port" selector = OPAQUE

B. Protokolle mit einem Selektor

Selbst wenn ein Next Layer Protocol nur einen Selektor hat, z.B. den Mobility Header-Typ, dann werden die lokalen und entfernten "Port"-Selektoren verwendet, um anzugeben, ob ein System bereit ist, Verkehr mit den angegebenen "Port"-Werten zu senden und/oder zu empfangen.

Beispiel 1: Senden und Empfangen

Wenn Mobility Header eines bestimmten Typs über eine SA gesendet und empfangen werden dürfen, dann würde der relevante SPD-Eintrag wie folgt festgelegt:

Lokal (Local's)
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

Entfernt (Remote's)
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

Beispiel 2: Nur Senden

Wenn Mobility Header eines bestimmten Typs über eine SA gesendet, aber NICHT empfangen werden dürfen, dann würde der relevante SPD-Eintrag wie folgt festgelegt:

Lokal (Local's)
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

Entfernt (Remote's)
next layer protocol = Mobility Header
"port" selector = OPAQUE

Beispiel 3: Nur Empfangen

Wenn Mobility Header eines bestimmten Typs über eine SA empfangen, aber NICHT gesendet werden dürfen, dann würde der relevante SPD-Eintrag wie folgt festgelegt:

Lokal (Local's)
next layer protocol = Mobility Header
"port" selector = OPAQUE

Entfernt (Remote's)
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

C. Protokolle mit zwei Selektoren - Nur Senden

Wenn ein System bereit ist, Verkehr mit einem bestimmten "Port"-Wert zu senden, aber NICHT Verkehr mit dieser Art von Port-Wert zu empfangen, werden die Verkehrsselektoren des Systems im relevanten SPD-Eintrag wie folgt festgelegt:

Lokal (Local's)
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>

Entfernt (Remote's)
next layer protocol = ICMP
"port" selector = OPAQUE

D. Protokolle mit zwei Selektoren - Nur Empfangen

Um anzugeben, dass ein System bereit ist, Verkehr mit einem bestimmten "Port"-Wert zu empfangen, aber diese Art von Verkehr NICHT zu senden, werden die Verkehrsselektoren des Systems im relevanten SPD-Eintrag wie folgt festgelegt:

Lokal (Local's)
next layer protocol = ICMP
"port" selector = OPAQUE

Entfernt (Remote's)
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>

Praktisches Beispiel: ICMP Traceroute

Zum Beispiel, wenn ein Sicherheitsgateway bereit ist, Systemen hinter sich zu erlauben, ICMP-Traceroutes zu senden, aber nicht bereit ist, externen Systemen zu erlauben, ICMP-Traceroutes zu Systemen hinter sich auszuführen, dann werden die Verkehrsselektoren des Sicherheitsgateways im relevanten SPD-Eintrag wie folgt festgelegt:

Lokal (Local's)
next layer protocol = 1 (ICMPv4)
"port" selector = 30 (traceroute)

Entfernt (Remote's)
next layer protocol = 1 (ICMPv4)
"port" selector = OPAQUE