Referenzen
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC-1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
Änderungen seit RFC-1883
Dieses Dokument enthält folgende Änderungen gegenüber RFC-1883. Die Nummern identifizieren die Version des Internet-Drafts, in der die Änderung vorgenommen wurde.
02) Alle Verweise auf Jumbogramme und die Jumbo-Payload-Option wurden entfernt (in ein separates Dokument verschoben).
02) Der größte Teil der Flow-Label-Beschreibung wurde aus Abschnitt 6 in den (neuen) Anhang A verschoben.
02) In der Flow-Label-Beschreibung (jetzt in Anhang A) wurde der maximale Flow-Label-Wert von FFFFFF auf FFFFF korrigiert (d. h. ein „F" weniger), da die Größe des Flow-Label-Feldes von 24 Bit auf 20 Bit reduziert wurde.
02) Der frühere Anhang A wurde in Anhang B umbenannt.
02) Der Wortlaut des Abschnitts „Sicherheitsüberlegungen" wurde geändert, um eine zirkuläre Abhängigkeit zwischen dieser Spezifikation und den IPsec-Spezifikationen zu vermeiden.
02) Die E-Mail-Adresse und Firmenzugehörigkeit von R. Hinden wurden aktualisiert.
01) In Abschnitt 3 wurde der Feldname „Class" in „Traffic Class" geändert und seine Größe von 4 Bit auf 8 Bit erhöht. Die Größe des Flow-Label-Feldes wurde von 24 Bit auf 20 Bit reduziert, um die Vergrößerung des Traffic-Class-Feldes auszugleichen.
01) In Abschnitt 4.1 wurde die Reihenfolge des Authentication Headers und des ESP-Headers wiederhergestellt, die in Version 00 dieses Dokuments fälschlicherweise vertauscht worden war.
01) In Abschnitt 4.4 wurden das Strict/Loose-Bit-Map-Feld und die Strict-Routing-Funktionalität aus dem Type-0-Routing-Header entfernt sowie die Beschränkung der Anzahl der Adressen, die in einem Type-0-Routing-Header enthalten sein können, aufgehoben (zuvor aufgrund der Größe der Strict/Loose-Bitmap auf 23 Adressen begrenzt).
01) In Abschnitt 5 wurde die minimale IPv6-MTU von 576 Oktetten auf 1280 Oktetten geändert, und es wurde eine Empfehlung hinzugefügt, Verbindungen mit konfigurierbarer MTU (z. B. PPP-Verbindungen) mit einer MTU von mindestens 1500 Oktetten zu konfigurieren.
01) In Abschnitt 5 wurde die Anforderung entfernt, dass Knoten keine fragmentierten Pakete senden dürfen, die nach der Wiederzusammensetzung größer als 1500 Oktette sind, wenn sie die Größe des Wiederzusammensetzungspuffers des Ziels nicht kennen, und durch eine Empfehlung ersetzt, dass Protokolle oder Anwendungen der oberen Schicht dies nicht tun sollten.
01) Der Verweis auf die IPv4-Path-MTU-Discovery-Spezifikation (RFC-1191) wurde durch einen Verweis auf die IPv6-Path-MTU-Discovery-Spezifikation (RFC-1981) ersetzt, und der Hinweis zur Path MTU Discovery am Ende von Abschnitt 5 wurde entfernt, da diese Details nun von RFC-1981 abgedeckt werden.
01) In Abschnitt 6 wurde die Spezifikation der „opportunistischen (opportunistic)" Flusseinrichtung entfernt sowie alle Verweise auf die maximale Lebensdauer von 6 Sekunden für opportunistisch eingerichtete Flusszustände.
01) In Abschnitt 7 wurde die vorläufige Beschreibung der internen Struktur und Semantik des Traffic-Class-Feldes entfernt und festgelegt, dass solche Beschreibungen in separaten Dokumenten bereitgestellt werden.
00) In Abschnitt 4 wurde der Code-Wert in der ICMP-Parameter-Problem-Nachricht, der „unrecognized Next Header type encountered" anzeigt, korrigiert (von 2 auf 1 geändert).
00) In der Beschreibung des Payload-Length-Feldes in Abschnitt 3 und der Beschreibung des Jumbo-Payload-Length-Feldes in Abschnitt 4.3 wurde klarer dargestellt, dass Erweiterungsheader in der Nutzlastlängenangabe enthalten sind.
00) In Abschnitt 4.1 wurden die Reihenfolge des Authentication Headers und des ESP-Headers vertauscht. (Hinweis: Dies war ein Fehler, der in Version 01 rückgängig gemacht wurde.)
00) In Abschnitt 4.2 wurde klarer dargestellt, dass Optionen durch den vollständigen 8-Bit-Option-Type identifiziert werden, nicht nur durch die niederwertigen 5 Bits des Option-Types. Außerdem wurde festgelegt, dass Hop-by-Hop-Options- und Destination-Options-Header denselben Option-Type-Nummernraum verwenden.
00) In Abschnitt 4.4 wurde ein Satz hinzugefügt, der verlangt, dass ein Knoten, der einen Routing Header verarbeitet, eine ICMP-Packet-Too-Big-Nachricht als Antwort auf ein Paket senden MUSS, das für den nächsten Hop zu groß ist (anstatt z. B. eine Fragmentierung durchzuführen).
00) Der Name des IPv6-Priority-Feldes wurde in „Class" geändert, und die frühere Beschreibung von Priority in Abschnitt 7 wurde durch eine Beschreibung des Class-Feldes ersetzt. Außerdem wurde dieses Feld aus der Menge der Felder ausgeschlossen, die für alle Pakete desselben Flusses gleich sein müssen, wie in Abschnitt 6 spezifiziert.
00) Im Pseudo-Header in Abschnitt 8.1 wurde der Name des „Payload Length"-Feldes in „Upper-Layer Packet Length" geändert. Außerdem wurde klargestellt, dass für Protokolle, die ihre eigenen Längeninformationen tragen (wie Nicht-Jumbogramm-UDP), die von der oberen Schicht abgeleitete Länge im Pseudo-Header verwendet wird, nicht die von der IP-Schicht abgeleitete Länge.
00) Abschnitt 8.4 wurde hinzugefügt, der festlegt, dass Protokolle der oberen Schicht bei der Antwort auf empfangene Pakete mit Routing-Headern keinen umgekehrten Routing Header in die Antwortpakete einschließen dürfen, es sei denn, der empfangene Routing Header wurde authentifiziert.
00) Einige Tipp- und Grammatikfehler wurden korrigiert.
00) Die Kontaktinformationen der Autoren wurden aktualisiert.
Vollständige Urheberrechtserklärung
Copyright (C) The Internet Society (1998). All Rights Reserved.
Dieses Dokument und seine Übersetzungen dürfen kopiert und anderen zur Verfügung gestellt werden, und abgeleitete Werke, die es kommentieren oder anderweitig erläutern oder bei seiner Implementierung helfen, dürfen ganz oder teilweise ohne Einschränkung vorbereitet, kopiert, veröffentlicht und verteilt werden, vorausgesetzt, dass der obige Urheberrechtshinweis und dieser Absatz in allen solchen Kopien und abgeleiteten Werken enthalten sind. Dieses Dokument selbst darf jedoch in keiner Weise modifiziert werden, z. B. durch Entfernen des Urheberrechtshinweises oder von Verweisen auf die Internet Society oder andere Internet-Organisationen, außer soweit dies für den Zweck der Entwicklung von Internet-Standards erforderlich ist, in welchem Fall die im Internet-Standards-Prozess definierten Urheberrechtsverfahren befolgt werden müssen, oder soweit es für die Übersetzung in andere Sprachen als Englisch erforderlich ist.
Die oben gewährten eingeschränkten Berechtigungen sind dauerhaft und werden von der Internet Society oder ihren Nachfolgern oder Abtretungsempfängern nicht widerrufen.
Dieses Dokument und die darin enthaltenen Informationen werden auf einer „AS IS"-Basis bereitgestellt, und THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE lehnen alle ausdrücklichen oder stillschweigenden Garantien ab, einschließlich, aber nicht beschränkt auf jede Garantie, dass die Verwendung der hierin enthaltenen Informationen keine Rechte verletzt oder eine stillschweigende Garantie der Marktgängigkeit oder Eignung für einen bestimmten Zweck.