広告
広告
https://www.7key.jp/rfc/1883/rfc1883_8.html#sourcehttps://www.7key.jp/rfc/1883/rfc1883_8.html#translationAny transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses. In particular, the following illustration shows the TCP and UDP "pseudo-header" for IPv6:
チェックサムの計算にIPヘッダのアドレスを含むトランスポート層やその他の上位層プロトコルは、IPv6を用いるために32bitのIPv4アドレスの代わりに128bitのIPv6アドレスを含むよう修正されなくてはならない。特に、下図でIPv6用のTCPとUDPの擬似ヘッダを示す：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o If the packet contains a Routing header, the Destination
Address used in the pseudo-header is that of the final
destination. At the originating node, that address will be in
the last element of the Routing header; at the recipient(s),
that address will be in the Destination Address field of the
IPv6 header.
パケットがルーティングヘッダを含むのであれば、擬似ヘッダ内の宛先アドレスは最終の宛先のアドレスである。発信元ノードにおいてそのアドレスはルーティングヘッダの最後の要素にあるとみなされ、受信者においてそのアドレスはIPv6ヘッダの着信アドレスフィールドにあるとみなされる。
o The Next Header value in the pseudo-header identifies the
upper-layer protocol (e.g., 6 for TCP, or 17 for UDP). It will
differ from the Next Header value in the IPv6 header if there
are extension headers between the IPv6 header and the upper-
layer header.
擬似ヘッダ内のネクストヘッダ値は、上位層プロトコルを識別する（例えば、6ならばTCP、17ならばUDP）。IPv6ヘッダと上位層のヘッダの間に拡張ヘッダがある場合、それはIPv6ヘッダのネクストヘッダ値とは異なるだろう。
o The Payload Length used in the pseudo-header is the length of
the upper-layer packet, including the upper-layer header. It
will be less than the Payload Length in the IPv6 header (or in
the Jumbo Payload option) if there are extension headers
between the IPv6 header and the upper-layer header.
擬似ヘッダ内で用いられるペイロード長は、上位層のヘッダを含めた上位層パケットの長さである。IPv6ヘッダと上位層のヘッダの間に拡張ヘッダがある場合、それはIPv6ヘッダのペイロード長（又は特大ペイロードオプション）よりも短いだろう。
o Unlike IPv4, when UDP packets are originated by an IPv6 node,
the UDP checksum is not optional. That is, whenever
originating a UDP packet, an IPv6 node must compute a UDP
checksum over the packet and the pseudo-header, and, if that
computation yields a result of zero, it must be changed to hex
FFFF for placement in the UDP header. IPv6 receivers must
discard UDP packets containing a zero checksum, and should log
the error.
IPv6ノードによってUDPパケットが生成されるのであれば、IPv4とは異なりUDPチェックサムは任意ではない。つまり、UDPパケットを生成する際IPv6ノードはパケットと擬似ヘッダによりUDPチェックサムを計算しなければならず、且つその計算結果がゼロとなるのであれば、UDPヘッダへの設置のために16進数のFFFFに変更されなければならない。IPv6の受信者は、チェックサムゼロを含むUDPを破棄せねばならず、エラーをログに記述すべきである。
The IPv6 version of ICMP [RFC-1885] includes the above pseudo-header in its checksum computation; this is a change from the IPv4 version of ICMP, which does not include a pseudo-header in its checksum. The reason for the change is to protect ICMP from misdelivery or corruption of those fields of the IPv6 header on which it depends, which, unlike IPv4, are not covered by an internet-layer checksum. The Next Header field in the pseudo-header for ICMP contains the value 58, which identifies the IPv6 version of ICMP.
ICMPのIPv6バージョン[RFC 1885]は、そのチェックサムの計算に上記の擬似ヘッダを含める。これは、チェックサムに擬似ヘッダを含まないICMPのIPv4バージョンからの変更点となる。変更の理由は、依存するIPv6ヘッダのそれらのフィールドの伝送ミスや破損からICMPを保護するためであり、これはIPv4とは異なりインターネット層のチェックサムによってカバーされない。ICMP用擬似ヘッダ内のネクストヘッダフィールド値は、ICMPのIPv6バージョンを識別する"58"を採る。
Unlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime. That is the reason the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 implementations conform to the requirement that they limit packet lifetime, so this is not a change in practice. Any upper-layer protocol that relies on the internet layer (whether IPv4 or IPv6) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets.
IPv4とは異なり、IPv6ノードは最大パケット生存期間の強制を要求されない。これはIPv4の"生存期間"フィールドがIPv6では"ホップ限界"と名前の変更された理由である。実際にはごく少数のIPv4実装のみが、パケットの生存期間を限定する要求に準拠し、つまりこれは実質的な変更ではない。パケット生存期間の制限をインターネット層に頼る上位層プロトコル（IPv4かIPv6かは問わない）は、古いパケットを検出し破棄する自身の機構を提供するためのアップグレードがなされるべきである。
When computing the maximum payload size available for upper-layer data, an upper-layer protocol must take into account the larger size of the IPv6 header relative to the IPv4 header. For example, in IPv4, TCP's MSS option is computed as the maximum packet size (a default value or a value learned through Path MTU Discovery) minus 40 octets (20 octets for the minimum-length IPv4 header and 20 octets for the minimum-length TCP header). When using TCP over IPv6, the MSS must be computed as the maximum packet size minus 60 octets, because the minimum-length IPv6 header (i.e., an IPv6 header with no extension headers) is 20 octets longer than a minimum-length IPv4 header.
上位層データにて利用可能な最大ペイロードサイズを計算する際、上位層プロトコルがIPv4ヘッダに比べてIPv6ヘッダのサイズの方が大きいことを考慮しなければならない。例えばIPv4において、TCPのMSSオプションは最大パケットサイズ（初期値又は経路MTU探索から得た値）から40オクテット（IPv4ヘッダの最小値20オクテットとTCPヘッダの最小値20オクテット）を引いた値である。IPv6の上位層としてTCPを用いる際、IPv6ヘッダの最小値（つまり拡張ヘッダを持たないIPv6ヘッダ）はIPv4ヘッダの最小値より20オクテット長いため、MSSは最大パケットサイズから60オクテット引いた値である。
広告