12. IP-Header-Felder (IP Header Fields)

Dieser Abschnitt beschreibt, wie der Server verschiedene Felder im IP-Header beim Weiterleiten zwischen Client und Peer oder umgekehrt setzt. Die Beschreibungen in diesem Abschnitt gelten für (a) wenn der Server ein UDP-Datagramm an einen Peer sendet, oder (b) wenn der Server eine Data-Indikation oder ChannelData-Nachricht über einen UDP-Transport an den Client sendet. Die Beschreibungen in diesem Abschnitt gelten nicht für TURN-Nachrichten, die vom Server über einen TCP- oder TLS-Transport an den Client gesendet werden.

Die nachstehenden Beschreibungen sind in zwei Verhaltensweisen unterteilt: ein bevorzugtes Verhalten und ein alternatives Verhalten. Ein Server SOLLTE (SHOULD) das bevorzugte Verhalten implementieren. Wenn dies jedoch für ein bestimmtes Feld nicht möglich ist, dann SOLLTE (SHOULD) er das alternative Verhalten implementieren.

Time to Live (TTL)-Feld

Bevorzugtes Verhalten: Wenn der eingehende Wert 0 ist, verwerfen Sie das eingehende Paket. Andernfalls setzen Sie die ausgehende Time to Live/Hop Count auf einen Wert, der um eins kleiner ist als der eingehende Wert.
Alternatives Verhalten: Setzen Sie den ausgehenden Wert auf den Standard für ausgehende Pakete.

Differentiated Services Code Point (DSCP)-Feld [RFC2474]

Bevorzugtes Verhalten: Setzen Sie den ausgehenden Wert auf den eingehenden Wert, es sei denn, der Server enthält einen Differentiated Services Classifier and Marker [RFC2474].
Alternatives Verhalten: Setzen Sie den ausgehenden Wert auf einen festen Wert, der standardmäßig Best Effort ist, aber konfigurierbar sein kann.
In beiden Fällen, wenn der Server unmittelbar an einen Differentiated Services Classifier and Marker angrenzt, dann KANN (MAY) in Richtung des Klassifizierers der DSCP auf einen beliebigen Wert gesetzt werden.

Explicit Congestion Notification (ECN)-Feld [RFC3168]

Bevorzugtes Verhalten: Setzen Sie den ausgehenden Wert auf den eingehenden Wert, es sei denn, der Server führt Active Queue Management durch, in diesem Fall ist das eingehende ECN-Feld auf ECT(1) (=0b01) oder ECT(0) (=0b10) gesetzt und der Server möchte anzeigen, dass eine Überlastung aufgetreten ist, in diesem Fall setzen Sie den ausgehenden Wert auf CE (=0b11).
Alternatives Verhalten: Setzen Sie den ausgehenden Wert auf Not-ECT (=0b00).

IPv4-Fragmentierungsfelder

Bevorzugtes Verhalten: Wenn der Server ein Paket an einen Peer als Antwort auf eine Send-Indikation sendet, die das DONT-FRAGMENT-Attribut enthält, setzen Sie das DF-Bit im ausgehenden IP-Header auf 1. In allen anderen Fällen beim Senden eines ausgehenden Pakets, das Anwendungsdaten enthält (z. B. Data-Indikation, ChannelData-Nachricht oder eine Send-Indikation ohne das DONT-FRAGMENT-Attribut), kopieren Sie das DF-Bit vom DF-Bit des eingehenden Pakets, das die Anwendungsdaten enthielt.

Setzen Sie die anderen Fragmentierungsfelder (Identification, More Fragments, Fragment Offset) entsprechend für ein vom Server gesendetes Paket.
Alternatives Verhalten: Wie bei Bevorzugt, außer dass immer angenommen wird, dass das eingehende DF-Bit 0 ist.
Bei sowohl bevorzugtem als auch alternativem Verhalten kann das resultierende Paket für den ausgehenden Link zu groß sein. Wenn dies der Fall ist, gelten die normalen Fragmentierungsregeln [RFC1122].

IPv4-Optionen

Bevorzugtes Verhalten: Das ausgehende Paket wird ohne IPv4-Optionen gesendet.
Alternatives Verhalten: Identisch mit Bevorzugt.