7. Deployment Considerations (Bereitstellungsüberlegungen)

7.1. Traffic Engineering

Auch wenn der ISP für Endbenutzer sich vom PLAT-Anbieter unterscheidet (z.B. ein anderer ISP), kann er Traffic Engineering unabhängig vom PLAT-Anbieter implementieren. Detaillierte Gründe sind nachfolgend aufgeführt:

Der ISP für Endbenutzer kann die IPv4-Zieladresse aus dem übersetzten IPv6-Paketheader ermitteln, sodass er Traffic Engineering basierend auf der IPv4-Zieladresse implementieren kann (z.B. Verkehrsüberwachung für jede IPv4-Zieladresse, Paketfilterung für jede IPv4-Zieladresse usw.). Die Tunnelmethoden haben ohne Deep Packet Inspection zur Verarbeitung des inneren IPv4-Pakets des Tunnelpakets keinen solchen Vorteil.
Wenn der ISP für Endbenutzer jedem Teilnehmer ein IPv6-Präfix größer als /64 zuweisen kann, kann diese 464XLAT-Architektur das IPv6-Präfix für native IPv6-Pakete und die XLAT-Präfixe für IPv4/IPv6-Übersetzungspakete trennen. Dementsprechend kann er den Pakettyp ("native IPv6-Pakete" und "IPv4/IPv6-Übersetzungspakete") identifizieren und Traffic Engineering basierend auf dem IPv6-Präfix implementieren.

7.2. Traffic Treatment Scenarios (Verkehrsbehandlungsszenarien)

Die folgende Tabelle skizziert, wie verschiedene Permutationen der Konnektivität in der 464XLAT-Architektur behandelt werden.

Hinweis: Die 464XLAT-Doppelübersetzungsbehandlung wird zustandslos sein, wenn ein dediziertes /64 für die Übersetzung auf dem CLAT verfügbar ist. Andernfalls wird der CLAT sowohl zustandsbehaftet als auch zustandslos sein, da er NAT44 vom LAN zu einer einzelnen IPv4-Adresse und dann zustandslose Übersetzung zu einer einzelnen IPv6-Adresse erfordert.

Server	Application and Host	Traffic Treatment	Location of Translation
IPv6	IPv6	End-to-End IPv6	None
IPv4	IPv6	Stateful Translation	PLAT
IPv4	IPv4	464XLAT	PLAT/CLAT

Verkehrsbehandlungsszenarien