3. Überprüfung der ND-Minderungslösungen

Tabelle 1 fasst die verfügbaren ND-Minderungslösungen für die in Abschnitt 2.4 beschriebenen Probleme 1-15 zusammen. Ähnliche Lösungen sind gruppiert, beginnend mit denen, die die meisten Probleme behandeln.

In Tabelle 1 geben die Buchstabencodes die RFC-Kategorie an (siehe BCP 9 [RFC2026]):

• S: Standards Track, E: Experimental, I: Informational, B: Best Current Practice, N/A: Not Applicable

Tabelle 1: Lösungen für identifizierte Probleme

ND-Lösung	RFC-Kat.	Multicast-Perf.	Zuverl.	Link-Sich.	NCE-Ersch.	Wtl.-Verz.	Adr.-Verantw.
		1	2	3	4	5	6
MBBv6	I	Löst alle identifizierten Probleme
FBBv6	N/A	Löst alle identifizierten Probleme
UPPH	I		X		X	X
WiND	S	Löst alle Probleme für LLN-Netzwerke
SARP	E					X
ND TRILL	S					X
ND EVPN	S					X
RFC 7772	B		X
GRAND	S				X
SAVI/RA-G	I
RFC 6583	I
RFC 9686	S

3.1. Mobile Broadband IPv6 (MBBv6)

Die in [RFC6459], [RFC7066] und [RFC7278] für 3GPP-Mobilfunknetze definierten IPv6-Lösungen werden als MBBv6 bezeichnet. Hauptpunkte:

• Platziert alle Hosts auf Point-to-Point (P2P) Links mit dem Router, wodurch alle Multicasts effektiv in Unicast konvertiert werden
• P2P-Links haben keine MAC-Adressen, daher ist Router-NCE-on-Demand unnötig
• Vertrauen in alle Knoten betrifft nur den Router; durch Filterung können böswillige Hosts keinen Schaden anrichten
• Weist jedem Host ein eindeutiges /64-Präfix zu
• Führt (Präfix, Interface)-Bindungen für Weiterleitungszwecke

Da alle drei ND-Problemursachen behandelt werden, werden alle in Abschnitt 2.4 besprochenen Probleme gelöst.

3.2. Fixed Broadband IPv6 (FBBv6)

Die in [TR177] definierte FBBv6-Lösung hat zwei Varianten:

P2P: Alle Hosts auf P2P-Links mit dem Router. Funktional ähnlich zu MBBv6, löst alle ND-Probleme aus Abschnitt 2.4.

P2MP: Alle Hosts auf einem Point-to-Multipoint (P2MP) Link mit dem Router, realisiert durch:

• Platzierung aller Hosts in einem einzigen VLAN am Router
• Konfiguration des Zugangsgeräts (z.B. OLT) zur Blockierung von Frame-Weiterleitung zwischen Zugangsports
• Implementierung von DAD Proxy [RFC6957] am Router
• Zuweisung eines eindeutigen /64-Präfixes pro Host

Vorteile:

• Host-zu-Router-Multicast wird effektiv zu Unicast
• Vertrauen in alle Knoten auf Router beschränkt
• Router installiert Weiterleitungseinträge vorab, eliminiert Router-NCE-on-Demand
• Router-zu-Host-Multicast auf nicht angeforderte RAs beschränkt, als Unicast gesendet [RFC6085]

Löst alle ND-Probleme aus Abschnitt 2.4.

3.3. Unique Prefix per Host (UPPH)

Beschrieben in [RFC8273] und [RFC9663] (beide informativ). Verbessert "Host-Isolierung und erweiterte Teilnehmerverwaltung auf gemeinsam genutzten Netzwerksegmenten". Hauptpunkte:

• Router installiert Weiterleitungseinträge vorab nach Präfixzuweisung, kein Router-NCE-on-Demand
• Router-zu-Host-Multicast auf nicht angeforderte RAs beschränkt, als Unicast gesendet
• Hosts senden Verkehr über Router, keine Host-zu-Host-Adressauflösung

Verhindert Router-NCE-on-Demand und Router-zu-Host-Multicast-Probleme.

[RFC8273] gibt an: "Netzwerke mit eindeutigem IPv6-Präfix pro Host können einfach garantieren, dass Geräte nur über First-Hop-Router Pakete aneinander senden." Bei gemeinsam genutzten Medien (z.B. Ethernet) sind jedoch zusätzliche Maßnahmen wie Private VLANs [RFC5517] erforderlich. Ohne diese können Hosts sich auf L2 erreichen und Vertrauen-in-alle-Knoten sowie Host-Multicast-Probleme verursachen.

Von Host-Multicast-Problemen (Probleme 1, 3, 5, 6, 7) verhindert UPPH Probleme 5 und 7 (keine Host-zu-Host-Auflösung, keine GUA-Duplikate), aber Probleme 1, 3, 6 können auftreten.

3.4. Wireless ND (WiND)

Der Begriff "WiND" beschreibt grundlegend unterschiedliche ND-Lösungen für Low-Power and Lossy Networks (LLNs) [RFC7102], definiert in [RFC6775], [RFC8505], [RFC8928] und [RFC8929] (Standards Track). WiND ändert Host- und Router-Verhalten, um Multicast nur für Router Discovery zu verwenden. Hauptpunkte:

• Hosts registrieren Adressen vorab mit Unicast beim Router
• Router kommuniziert mit Hosts über Unicast, wird abstrakter Registrar und Schiedsrichter für Adresseigentum
• Router installiert Host-NCEs vorab, vermeidet Host-Adressauflösung
• Router setzt PIO L-Bit auf 0; Hosts kommunizieren nur mit dem Router [RFC4861, Abschnitt 6.3.4]
• Weitere LLN-spezifische Funktionen

WiND behandelt alle ND-Probleme (Abschnitt 2.4) für LLNs. WiND-Unterstützung ist jedoch für allgemeine Hosts nicht obligatorisch, daher nicht als Deployment-Option ohne zusätzliche Einschränkungen für teilnehmende Knoten verfügbar.

3.5. Scalable Address Resolution Protocol (SARP)

SARP [RFC7586] war eine experimentelle Lösung (Experiment endete 2017). Das Nutzungsszenario sind Rechenzentren mit großen L2-Domänen über mehrere Standorte. An jedem Standort sind mehrere Hosts (möglicherweise VMs) mit Switches verbunden, die über reine oder Overlay-L2-Netzwerke vernetzt sind.

Switches:

• Snoopen und installieren (IP, MAC-Adresse) Proxy-Tabellen für lokale Hosts
• Antworten auf Adressauflösungsanfragen von anderen Standorten mit eigener MAC-Adresse
• Alle Hosts innerhalb eines Standorts erscheinen für andere Standorte als eine einzige MAC-Adresse
• Fügen (IP, MAC-Adresse) Antworten von Remote-Switches zu Proxy-ND-Tabellen hinzu für direkte Antworten auf zukünftige lokale Anfragen

Reduziert Switch-MAC-Adresstabellengröße erheblich und Anzahl der Adressauflösungs-Multicasts im Netzwerk.

Im Gegensatz zu MBBv6, FBBv6 und UPPH konzentriert sich SARP auf Reduzierung von Adressauflösungs-Multicast zur Verbesserung von Performance und Skalierbarkeit in DC-großen L2-Domänen.

3.6. ND Optimization for TRILL

TRILL ARP und ND Optimization [RFC8302] (Standards Track) ähnelt SARP (Abschnitt 3.5) und kann als Anwendung von SARP in TRILL-Umgebungen betrachtet werden.

Wie SARP fokussiert sich TRILL ND Optimization auf Reduzierung von Multicast-Adressauflösung, behandelt Problem 5 (Abschnitt 2.1).

3.7. Proxy ND in Ethernet Virtual Private Networks (ND EVPN)

Proxy ARP/ND in EVPN ist in [RFC9161] (Standards Track) spezifiziert. Nutzungsszenario sind Rechenzentren mit großen L2-Domänen über mehrere Standorte. An jedem Standort sind mehrere Hosts mit Provider Edge (PE) Routern verbunden, die über EVPN-Tunnel vernetzt sind.

Jeder Standort-PE:

• Snoopt lokale Adressauflösungs-NAs und baut (IP, MAC-Adresse) Proxy-ND-Tabelleneinträge
• Propagiert solche Einträge über BGP an andere PEs
• Snoopt NS für Remote-Hosts von lokalen Hosts
• Antwortet direkt, wenn Remote-Host-Eintrag in Proxy-ND-Tabelle existiert

Reduziert Anzahl der Multicast-Adressauflösungsnachrichten erheblich.

Wie SARP konzentriert sich auch Proxy ARP/ND in EVPN auf Reduzierung von Adressauflösungs-Multicast.

3.8. Reducing Router Advertisements per RFC 7772

IPv6-Konnektivität erfordert, dass Hosts periodische Multicast-RAs empfangen können [RFC4861]. Schlafende Hosts, die Unicast-Pakete verarbeiten, müssen auch Multicast-RAs im Schlaf verarbeiten. Übermäßige RAs können Batterielebensdauer mobiler Hosts erheblich reduzieren.

[RFC7772] (Best Current Practice) spezifiziert Lösungen zur RA-Reduzierung:

• Router SOLLTEN mit Unicast-RA (nicht normalem Multicast-RA) auf RS antworten, wenn Host-Quell-IP-Adresse und MAC-Adresse angegeben und gültig sind (andere Hosts empfangen diese RA nicht)
• Router SOLLTEN Multicast-RA-Frequenz reduzieren

[RFC7772] behandelt Problem 2 (Abschnitt 2.1).

3.9. Gratuitous Neighbor Discovery (GRAND)

GRAND [RFC9131] (Standards Track) ändert ND wie folgt:

• Knoten sendet unaufgeforderte NA bei Zuweisung neuer IPv6-Adresse zu seinem Interface
• Router erstellt neue NCE für diesen Knoten und setzt Status auf STALE

Wenn Host-Paket später ankommt, kann Router sofort mit vorhandener STALE-NCE weiterleiten ([RFC4861], Abschnitt 7.2.2). Sendet dann Unicast-NS (nicht Multicast-NS für Adressauflösung) zur Erreichbarkeitsprüfung.

GRAND eliminiert Router-Weiterleitungsverzögerung, löst aber andere Router-NCE-on-Demand-Probleme nicht (z.B. NCE-Erschöpfung kann weiterhin auftreten).

3.10. Source Address Validation Improvement (SAVI) und Router Advertisement Guard (RA-Guard)

SAVI [RFC7039] (Informativ) bindet Adressen an L2-Switch-Ports und lehnt Anfragen von anderen Ports für diese Adresse ab. Knoten können IP-Adressen anderer Knoten nicht spoofen.

RA-Guard [RFC6105] [RFC7113] (Informativ) erlaubt nur RAs von Ports, an denen Router angeschlossen sind. Knoten an anderen Ports können sich nicht als Router ausgeben.

SAVI und RA-Guard behandeln On-Link-Sicherheitsprobleme.

3.11. Dealing with NCE Exhaustion Attacks per RFC 6583

[RFC6583] (Informativ) behandelt NCE-Erschöpfungsangriffsproblem (Abschnitt 2.3). Empfiehlt:

• Operatoren SOLLTEN:

  • Ungenutzten Adressraum filtern, sodass Nachrichten an solche Adressen gedroppt statt NCE-Erstellung ausgelöst werden
  • Rate-Limiting-Mechanismen für ND-Nachrichtenverarbeitung implementieren zur CPU/Speicherüberlastungsvermeidung

• Anbieter SOLLTEN:

  • NDP-Verarbeitung existierender NCEs über neue NCE-Erstellung priorisieren

[RFC6583] erkennt an: "Einige dieser Optionen sind 'Pflaster' und können operativ schwierig zu verwalten sein." [RFC6583] behandelt Router-NCE-Erschöpfungsproblem teilweise. In der Praxis setzen Router-Anbieter Obergrenzen für NCE-Anzahl pro Interface. Wenn Link mehr Adressen hat, kann Router nicht alle Einträge halten; Pakete an Adressen ohne NCE werden einfach gedroppt [RFC9663].

3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6 per RFC 9686

In IPv4 können Netzwerkadministratoren Host-IP-Adressen von DHCP-Servern für Teilnehmerverwaltung abrufen. In IPv6 mit SLAAC ist dies unmöglich (Abschnitt 2.3).

[RFC9686] (Standards Track) definiert Methode für Hosts, DHCPv6-Server über eine oder mehrere selbstgenerierte oder statisch konfigurierte Adressen zu informieren. Ermöglicht Netzwerkadministratoren Abruf von Host-IPv6-Adressen von DHCPv6-Servern.

[RFC9686] bietet Lösung für Problem 15 (Abschnitt 2.3).

3.13. Enhanced DAD

Enhanced DAD [RFC7527] (Standards Track) behandelt DAD-Versagensproblem in spezifischer Situation: Loopback-Interfaces. DAD versagt auf Loopback-Interfaces, da sendender Host DAD-Nachricht zurück empfängt und interpretiert, dass anderer Host dieselbe Adresse verwenden möchte.

Lösung: Jede DAD-Nachricht enthält Nonce-Option [RFC3971], damit sendender Host erkennen kann, dass zurückgeschleifte DAD-Nachricht von ihm selbst gesendet wurde.

Enhanced DAD löst kein ND-Problem; erweitert ND, um in neuem Szenario (Loopback-Interface) zu funktionieren. Hier für Vollständigkeit überprüft.

3.14. ND Mediation for IP Interworking of Layer 2 VPNs

ND-Vermittlung ist in [RFC6575] (Standards Track) spezifiziert. Wenn zwei Attachment Circuits (ACs) durch VPWS verbunden sind und unterschiedliche Medien haben (z.B. eines Ethernet, anderes Frame Relay), müssen zwei PEs zusammenarbeiten, um Vermittlungsdienst bereitzustellen, damit CE MAC-Adresse des Remote-Endes auflösen kann.

ND-Vermittlung behandelt kein ND-Problem; erweitert ND, um in neuem Szenario (zwei ACs verschiedener Medien über VPWS verbunden) zu funktionieren. Hier für Vollständigkeit überprüft.

3.15. ND Solutions Defined Before the Latest Versions of ND

Die neuesten ND- und SLAAC-Versionen sind in [RFC4861] und [RFC4862] spezifiziert. Einige ND-Minderungsmaßnahmen wurden vor [RFC4861] veröffentlicht. Hier für Vollständigkeit überprüft.

3.15.1. Secure Neighbor Discovery (SEND)

SEND [RFC3971] (Standards Track) zielt darauf ab, sicherzustellen, dass Hosts und Router vertrauenswürdig sind. SEND definierte drei neue ND-Optionen: Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track), RSA-Public-Key-Kryptographie und Timestamp/Nonce. SEND definierte auch Authorization Delegation Discovery-Prozess, Adresseigentumsnachweis-Mechanismus und Anforderungen für Verwendung dieser Komponenten im ND-Protokoll.

3.15.2. Cryptographically Generated Addresses (CGA)

CGA-Zweck ist Zuordnung kryptographischer öffentlicher Schlüssel zu IPv6-Adressen im SEND-Protokoll. Hauptpunkt: Berechnung kryptographischen Hash des öffentlichen Schlüssels zur Generierung des Interface Identifier (IID) der IPv6-Adresse. Resultierende IPv6-Adresse heißt CGA. Entsprechender privater Schlüssel kann verwendet werden, um von Adresse gesendete Nachrichten zu signieren.

CGA nimmt an, dass legitimer Host sich nicht um IID-Bitkombination kümmert, die durch Hash-Verfahren erstellt wird. Angreifer benötigt genaues IID zur Impersonierung legitimen Hosts, steht dann vor Herausforderung der Reverse-Hash-Berechnung - starke mathematische Herausforderung.

CGA ist Teil von SEND. Keine gemeldeten Deployments.

3.15.3. ND Proxy

ND Proxy [RFC4389] (Experimentell) zielt darauf ab, mehrere durch ND-Proxy-Gerät verbundene Links als einzelner Link zu funktionieren.

• Bei Empfang von ND-Anfrage von Host auf Link proxyt ND-Proxy Nachricht vom "besten" ausgehenden Interface (nächster Absatz definiert). Falls kein bestes Interface, proxyt ND-Proxy Nachricht an alle anderen Links. Proxy bedeutet: agiert, als ob ND-Nachricht vom ND-Proxy selbst stammt - ändert Quell-IP und Quell-MAC zu IP und MAC des ausgehenden Interfaces und erstellt NCE-Eintrag am ausgehenden Interface entsprechend.

• Bei Empfang von ND-Antwort agiert ND-Proxy, als ob ND-Nachricht an ihn adressiert wäre, aktualisiert NCE-Eintrags-Status des Empfangsinterfaces. Basierend auf solchen Statusinformationen kann ND-Proxy "bestes" ausgehendes Interface für zukünftige ND-Anfragen bestimmen. Dann proxyt ND-Proxy Nachricht zurück zum anfragenden Host.

ND-Proxy wird in SARP (Abschnitt 3.5), TRILL ND Optimization (Abschnitt 3.6) und Proxy ARP/ND in EVPN (Abschnitt 3.7) weit verbreitet.

3.15.4. Optimistic DAD

Optimistic DAD [RFC4429] (Standards Track) zielt darauf ab, Adresskonfigurationsverzögerung im Erfolgsfall zu minimieren und Unterbrechung im Fehlerfall soweit wie möglich zu reduzieren. Optimistic DAD erlaubt Host sofortige Nutzung neu gebildeter Adresse zur Kommunikation, bevor DAD abgeschlossen ist, unter Annahme, dass DAD erfolgreich sein wird. Falls Adresse dupliziert ist, bietet Optimistic DAD Mechanismen zur Auswirkungsminimierung.

Optimistic DAD modifizierte ursprüngliches ND [RFC2461] und ursprüngliches SLAAC [RFC2462] (beide obsolet), aber Lösung wurde nicht in neueste ND- und SLAAC-Spezifikationen [RFC4861] [RFC4862] integriert. Optimistic DAD-Implementierungen existieren jedoch.

Optimistic DAD löst keine ND-Probleme (Abschnitt 2). Hier für Vollständigkeit überprüft.

---