Appendix B. Changes since RFC 3484 (Änderungen)

Appendix B. Changes since RFC 3484 (Änderungen seit RFC 3484)

Einige Änderungen wurden an der Standard-Richtlinientabelle vorgenommen, die als universell nützlich erachtet wurden und in jeder vernünftigen Netzwerkumgebung keinen Schaden anrichten. Dabei wurde darauf geachtet, wann immer möglich dieselben Präzedenz- und Label-Werte wie in RFC 3484 zu verwenden und für neue Zeilen Label-Werte zu verwenden, die weniger wahrscheinlich mit Werten kollidieren, die möglicherweise bereits in zusätzlichen Zeilen auf einigen Hosts verwendet werden. Diese Änderungen sind:

1. Das Teredo [RFC4380] Präfix (2001::/32) wurde mit den Präzedenz- und Label-Werten hinzugefügt, die bereits weit verbreitet in populären Implementierungen verwendet werden.

2. Eine Zeile für ULAs (fc00::/7) wurde unterhalb von nativem IPv6 hinzugefügt, da sie nicht global erreichbar sind, wie in Abschnitt 10.6 diskutiert.

3. Eine Zeile für site-local Adressen (fec0::/10) wurde hinzugefügt, um sie zurückzustufen, zur Konsistenz mit dem Beispiel in Abschnitt 10.3, da sie veraltet sind [RFC3879].

4. 6to4 (2002::/32) wurde unter nativem IPv4 zurückgestuft, da 6to4-Konnektivität heute weniger zuverlässig ist (und voraussichtlich im Laufe der Zeit auslaufen wird, anstatt zuverlässiger zu werden). Es bleibt über Teredo, da 6to4 in Bezug auf Verbindungsaufbauzeit, Bandbreite und Serverlast effizienter ist.

5. IPv4-kompatible Adressen (::/96) wurden zurückgestuft, da sie jetzt veraltet sind [RFC4291] und nicht in allgemeiner Verwendung.

6. Eine Zeile für 6bone-Testadressen (3ffe::/16) wurde hinzugefügt, um sie zurückzustufen, da sie ebenfalls ausgelaufen sind [RFC3701].

7. Optionale Fähigkeit für eine Implementierung wurde hinzugefügt, automatische Zeilen zur Tabelle für site-spezifische ULA-Präfixe und site-spezifische native 6to4-Präfixe hinzuzufügen.

Ebenso wurden einige Änderungen an den Regeln wie folgt vorgenommen:

1. Die Definition von CommonPrefixLen() wurde geändert, um nur Bits bis zur Präfixlänge der Quelladresse zu vergleichen. Die vorherige Definition verwendete die gesamte Quelladresse anstatt nur ihr Präfix. Als Ergebnis würden, wenn Quell- und Zieladressen dasselbe Präfix hatten, gemeinsame Bits in der Interface-ID zuvor dazu führen, dass DNS-Load-Balancing [RFC1794] überschrieben wird, indem die Zieladresse mit den meisten gemeinsamen Bits immer gewählt wird. Die aktualisierte Definition ermöglicht es, dass DNS-Load-Balancing weiterhin als Tiebreaker verwendet wird.

2. Regel 5.5 wurde hinzugefügt, um die Wahl einer Quelladresse aus einem Präfix zu ermöglichen, das vom gewählten Next-Hop für ein gegebenes Ziel beworben wird. Dies ermöglicht bessere Konnektivität in Gegenwart von BCP 38 [RFC2827] Ingress-Filterung und Egress-Filterung. Zuvor hatte RFC 3484 Probleme mit mehreren Egress-Netzwerken, die über dieselbe Schnittstelle erreicht wurden, wie in [RFC5220] diskutiert.

3. Die Einschränkung gegen Anycast-Adressen in der Kandidatenmenge von Quelladressen wurde entfernt, da die Einschränkung gegen die Verwendung von IPv6-Anycast-Adressen als Quelladressen in Abschnitt 2.6 von RFC 4291 [RFC4291] entfernt wurde.

4. Die Zuordnung von RFC 1918 [RFC1918] Adressen zu globalem Bereich in Abschnitt 3.2 wurde geändert. Zuvor wurden sie site-local Bereich zugeordnet. Erfahrungen haben jedoch dazu geführt, dass aktuelle Implementierungen bereits globalen Bereich verwenden. Als sie site-local zugeordnet wurden, würde Destination Address Selection Rule 2 (Prefer matching scope) dazu führen, dass IPv6 in Szenarien wie dem in Abschnitt 10.7 beschriebenen bevorzugt wird. Die Änderung zu globalem Bereich ermöglicht Konfigurierbarkeit über die Präfix-Richtlinientabelle.

5. Die Standardempfehlung für Source Address Selection Rule 7 wurde geändert, um temporäre Adressen anstelle öffentlicher Adressen zu bevorzugen, während eine administrative Übersteuerung bereitgestellt wird (zusätzlich zur anwendungsspezifischen Übersteuerung, die bereits spezifiziert war). Diese Änderung wurde aufgrund der zunehmenden Bedeutung von Datenschutzüberlegungen sowie der Tatsache vorgenommen, dass weit verbreitete Implementierungen temporäre Adressen seit vielen Jahren ohne größere Anwendungsprobleme bevorzugt haben.

Schließlich wurden einige redaktionelle Änderungen vorgenommen, einschließlich:

1. Globale IP-Adressen in Beispielen wurden geändert, um Bereiche zu verwenden, die für die Dokumentation reserviert sind.

2. Zusätzliche Beispiele in den Abschnitten 10.6 und 10.7 wurden hinzugefügt.

3. Abschnitt 10.3.1 über "defektes" IPv6 wurde hinzugefügt.

4. Referenzen wurden aktualisiert.