5. Intra-SR-Domain Deployment Model (Intra-SR-Domänen-Bereitstellungsmodell)

Die ausschließliche Verwendung der SIDs innerhalb der SR-Domäne und nur für Pakete der SR-Domäne ist ein wichtiges Bereitstellungsmodell.

Dies ermöglicht es der SR-Domäne, als ein einziges Routing-System zu agieren.

Dieser Abschnitt behandelt:

die Sicherung der SR-Domäne vor externen Versuchen, ihre SIDs zu verwenden
die Verwendung der SR-Domäne als ein einziges System mit Delegation zwischen Komponenten
die Verarbeitung von Paketen der SR-Domäne

5.1. Securing the SR Domain (Sicherung der SR-Domäne)

Knoten außerhalb der SR-Domäne sind nicht vertrauenswürdig: sie können die SIDs der Domäne nicht direkt verwenden. Dies wird durch zwei Ebenen von Zugriffskontrolllisten durchgesetzt:

Jedes Paket, das in die SR-Domäne eintritt und für eine SID innerhalb der SR-Domäne bestimmt ist, wird verworfen. Dies kann mit der folgenden Logik realisiert werden. Andere Methoden mit gleichwertigem Ergebnis gelten als konform:
- Alle SIDs aus einem Block S/s zuweisen
- Jede externe Schnittstelle jedes Edge-Knotens der Domäne mit einer eingehenden Infrastruktur-Zugriffskontrollliste (IACL) konfigurieren, die jedes eingehende Paket mit einer Zieladresse in S/s verwirft
- Das Versäumnis, diese Methode der Ingress-Filterung zu implementieren, setzt die SR-Domäne Source-Routing-Angriffen aus, wie in [RFC5095] beschrieben und referenziert
Der verteilte Schutz in #1 wird durch knotenweisen Schutz ergänzt, der Pakete zu SIDs von Quelladressen außerhalb der SR-Domäne verwirft. Dies kann mit der folgenden Logik realisiert werden. Andere Methoden mit gleichwertigem Ergebnis gelten als konform:
- Alle Schnittstellenadressen aus dem Präfix A/a zuweisen
- Am Knoten k werden alle lokalen SIDs von k aus dem Präfix Sk/sk zugewiesen
- Jede interne Schnittstelle jedes SR-Knotens k in der SR-Domäne mit einer eingehenden IACL konfigurieren, die jedes eingehende Paket mit einer Zieladresse in Sk/sk verwirft, wenn die Quelladresse nicht in A/a liegt.

5.2. SR Domain as a Single System with Delegation among Components (SR-Domäne als ein einziges System mit Delegation zwischen Komponenten)

Alle Intra-SR-Domänen-Pakete gehören zur SR-Domäne. Der IPv6-Header stammt von einem Knoten der SR-Domäne und ist für einen Knoten der SR-Domäne bestimmt.

Alle Interdomänen-Pakete werden für den Teil der Paketreise gekapselt, der sich innerhalb der SR-Domäne befindet. Der äußere IPv6-Header stammt von einem Knoten der SR-Domäne und ist für einen Knoten der SR-Domäne bestimmt.

Folglich gehört jedes Paket innerhalb der SR-Domäne zur SR-Domäne.

Die SR-Domäne ist ein System, in dem der Betreiber verschiedene Operationen des äußersten Headers an verschiedene Knoten innerhalb des Systems verteilen oder delegieren möchte.

Ein Betreiber einer SR-Domäne kann wählen, das Hinzufügen von SRH an einen Host-Knoten innerhalb der SR-Domäne zu delegieren und die Validierung der Inhalte jedes SRH an einen vertrauenswürdigeren Router oder Switch zu delegieren, der an den Host angeschlossen ist. Betrachten Sie einen Top-of-Rack-Switch T, der über Schnittstelle I mit Host H verbunden ist. H empfängt einen SRH (SRH1) mit einem berechneten HMAC über eine SDN-Methode, die außerhalb des Geltungsbereichs dieses Dokuments liegt. H klassifiziert den von ihm erzeugten Verkehr und fügt SRH1 zu Verkehr hinzu, der ein bestimmtes Service Level Agreement (SLA) erfordert. T ist mit einer IACL auf I konfiguriert, die die Überprüfung des SRH für jedes Paket erfordert, das für den SID-Block der SR-Domäne (S/s) bestimmt ist. T prüft und verifiziert, dass SRH1 gültig ist und ein HMAC TLV enthält; T verifiziert dann den HMAC.

Ein Betreiber der SR-Domäne kann wählen, dass alle Segmente in der SR-Domäne den HMAC verifizieren. Dieser Mechanismus würde verifizieren, dass die SRH Segment List beim Durchqueren der SR-Domäne nicht modifiziert wird.

5.3. MTU Considerations (MTU-Überlegungen)

Ein SR-Domänen-Ingress-Edge-Knoten kapselt Pakete, die die SR-Domäne durchqueren, und muss die MTU der SR-Domäne berücksichtigen. Innerhalb der SR-Domäne werden bekannte Abmilderungstechniken EMPFOHLEN, wie die Bereitstellung eines größeren MTU-Werts innerhalb der SR-Domäne als an den Ingress-Edges.

Die Kapselung mit einem äußeren IPv6-Header und SRH teilt die gleichen MTU- und Fragmentierungsüberlegungen wie IPv6-Tunnel, die in [RFC2473] beschrieben werden. Eine weitere Untersuchung der Einschränkungen verschiedener Tunneling-Methoden (einschließlich IPv6-Tunnel) wird in [INTAREA-TUNNELS] diskutiert und SOLLTE von Betreibern bei der Betrachtung der MTU innerhalb der SR-Domäne berücksichtigt werden.

5.4. ICMP Error Processing (ICMP-Fehlerverarbeitung)

ICMP-Fehlerpakete, die innerhalb der SR-Domäne generiert werden, werden an Quellknoten innerhalb der SR-Domäne gesendet. Das auslösende Paket in der ICMP-Fehlermeldung kann einen SRH enthalten. Da sich die Zieladresse eines Pakets mit einem SRH ändert, während jedes Segment verarbeitet wird, ist sie möglicherweise nicht das Ziel, das vom Socket oder der Anwendung verwendet wird, die das auslösende Paket generiert hat.

Damit die Quelle eines auslösenden Pakets die ICMP-Fehlermeldung verarbeiten kann, kann die endgültige Zieladresse des IPv6-Headers erforderlich sein. Die folgende Logik wird verwendet, um die Zieladresse für die Verwendung durch Protokollfehler-Handler zu bestimmen.

Durchlaufen Sie alle Erweiterungsheader des auslösenden IPv6-Pakets bis zum Routing-Erweiterungsheader, der dem Upper-Layer-Header vorausgeht.
- Wenn der Routing-Header vom Typ 4 Segment Routing Header (SRH) ist
  
  o Die SID bei Segment List[0] kann als Zieladresse des auslösenden Pakets verwendet werden.

ICMP-Fehler werden dann von Upper-Layer-Transporten verarbeitet, wie in [RFC4443] definiert.

Für IP-Pakete, die in einem äußeren IPv6-Header gekapselt sind, erfolgt die ICMP-Fehlerbehandlung wie in [RFC2473] definiert.

5.5. Load Balancing and ECMP (Lastverteilung und ECMP)

Für jedes Interdomänen-Paket MUSS der SR-Quellknoten ein Flow-Label auferlegen, das basierend auf dem inneren Paket berechnet wird. Die Berechnung des Flow-Labels erfolgt wie in [RFC6438] für den sendenden Tunnel End Point empfohlen.

Für jedes Intradomänen-Paket SOLLTE der SR-Quellknoten ein Flow-Label auferlegen, das wie in [RFC6437] beschrieben berechnet wird, um die ECMP-Lastverteilung an Transit-Knoten zu unterstützen, die nicht in der Lage sind, ein 5-Tupel jenseits des SRH zu berechnen.

An jedem Transit-Knoten innerhalb einer SR-Domäne MUSS das Flow-Label wie in [RFC6438] definiert verwendet werden, um den ECMP-Hash zur Zieladresse zu berechnen. Wenn ein Flow-Label nicht verwendet wird, würde der Transit-Knoten wahrscheinlich alle Pakete zwischen einem Paar von SR-Edge-Knoten auf denselben Link hashen.

An einem SR-Segment-Endpunkt-Knoten MUSS das Flow-Label wie in [RFC6438] definiert verwendet werden, um jeden ECMP-Hash zu berechnen, der verwendet wird, um das verarbeitete Paket zum nächsten Segment weiterzuleiten.

5.6. Other Deployments (Andere Bereitstellungen)

Andere Bereitstellungsmodelle und ihre Auswirkungen auf Sicherheit, MTU, HMAC, ICMP-Fehlerverarbeitung und Interaktion mit anderen Erweiterungsheadern liegen außerhalb des Geltungsbereichs dieses Dokuments.