広告
広告
https://www.7key.jp/rfc/1883/rfc1883_42.html#source
https://www.7key.jp/rfc/1883/rfc1883_42.html#translation
Two of the currently-defined extension headers -- the Hop-by-Hop Options header and the Destination Options header -- carry a variable number of type-length-value (TLV) encoded "options", of the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
現在定義された拡張ヘッダの2つ(ホップバイホップオプションヘッダと宛先オプションヘッダ)は、下記で示すフォーマットで可変数のTLVでエンコードされたオプションを持つ:
Option Type 8-bit identifier of the type of option. Opt Data Len 8-bit unsigned integer. Length of the Option Data field of this option, in octets. Option Data Variable-length field. Option-Type-specific data.
The sequence of options within a header must be processed strictly in the order they appear in the header; a receiver must not, for example, scan through the header looking for a particular kind of option and process that option prior to processing all preceding ones.
拡張ヘッダは厳密にパケット内での順番通りに処理されなければならない。例えば、受信者がパケットの中から特定の拡張ヘッダを検索し、その前に位置する未処理のヘッダを全て処理する前にそのヘッダを処理してはならない。
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type:
オプションタイプ識別子は、IPv6処理ノードによってオプションタイプを認識できない際に、取るべき処理が上位2bitで判断可能なように内部的にエンコードされる:
00 - skip over this option and continue processing the header. 01 - discard the packet. 10 - discard the packet and, regardless of whether or not the packets's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.
The third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en-route to the packet's final destination. When an Authentication header is present in the packet, for any option whose data may change en-route, its entire Option Data field must be treated as zero-valued octets when computing or verifying the packet's authenticating value.
オプションタイプの上位から3番目のビットは、そのオプションのオプションデータがパケットの最終の宛先までに変化可能かどうかを指定するものである。認証ヘッダがパケット内にある際、全てのオプションデータは転送の途中で変化するおそれがあるため、パケットの認証値を計算するか確かめるのであればオプションデータの値は"0"としなければならない。
0 - Option Data does not change en-route 1 - Option Data may change en-route
Individual options may have specific alignment requirements, to ensure that multi-octet values within Option Data fields fall on natural boundaries. The alignment requirement of an option is specified using the notation xn+y, meaning the Option Type must appear at an integer multiple of x octets from the start of the header, plus y octets. For example:
個別のオプションは、オプションデータフィールド内のマルチオクテット値が自然境界に当ることを保証するために、特定の整列要求条件を定義することがある。オプションの整列要求条件は、オプションタイプがヘッダの開始位置からx
オクテットの整数倍にy
オクテットを加算した長さの場所に位置しなければならないことを意味する、xn + y
の式を用いて指定される。以下に例を示す:
2n means any 2-octet offset from the start of the header. 8n+2 means any 8-octet offset from the start of the header, plus 2 octets.
There are two padding options which are used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length. These padding options must be recognized by all IPv6 implementations:
後続のオプションを整列し且つヘッダ長を8の整数倍にする必要がある場合、2つのパディングオプションを用いることができる。これらのパディングオプションは全てのIPv6実装で認識されなければならない:
Pad1 option (alignment requirement: none) +-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ NOTE! the format of the Pad1 option is a special case -- it does not have length and value fields. The Pad1 option is used to insert one octet of padding into the Options area of a header. If more than one octet of padding is required, the PadN option, described next, should be used, rather than multiple Pad1 options.
注意!:パッド1オプションは、長さと値のフィールドを含まない特殊なフォーマットである。
パッド1オプションは、1オクテットのパディングをヘッダ内のオプションエリアに挿入するために用いられる。1オクテット以上のパディングが要求されるのであれば、以下に記載のあるパッドNオプションを用いるべきである。
PadN option (alignment requirement: none) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - The PadN option is used to insert two or more octets of padding into the Options area of a header. For N octets of padding, the Opt Data Len field contains the value N-2, and the Option Data consists of N-2 zero-valued octets.
パッドNオプションは、ヘッダ内のオプションエリアに2オクテット以上のパディングを挿入するために用いられる。Nオクテットのパディングについて言えば、N-2 の値を持つオプションデータ長フィールドと N-2オクテットのゼロを含むオプションデータからなる。
Appendix A contains formatting guidelines for designing new options.
「付記A. オプションのためのフォーマットガイドライン」にて、新しいオプションを設計するためのフォーマットガイドラインを紹介している。
広告