IPv6の仕様(オプション)

広告

広告

原文

最終更新
2006-10-10T00:12:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1883/rfc1883_42.html#source

IPv6の仕様(和訳)

最終更新
2006-10-10T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1883/rfc1883_42.html#translation

4.2 オプション

   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.
オプションタイプ
オプションタイプを表す8bit識別子。
オプションデータ長
8bitの符号なし整数。当オプションのオプションデータフィールドのサイズをオクテットで表す。
オプションデータ
可変長フィールド。オプションタイプ特定のデータ。
   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.
00
当オプションを無視した上でヘッダの処理を続けなさい。
01
当パケットを破棄しなさい。
10
当パケットを破棄し、パケットの宛先アドレスがマルチキャストアドレスかどうかに関らず、パケットの発信元アドレスへ未承認オプションタイプを示すコード"2"の ICMP不正パラメータメッセージを送信する。
11
当パケットを破棄し、パケットの宛先アドレスがマルチキャストアドレスでなかった場合に限り、パケットの発信元アドレスへ未承認オプションタイプを示すコード"2"の ICMP不正パラメータメッセージを送信する。
   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
0
オプションデータは途中で変化しない。
1
オプションデータは途中で変化するかもしれない。
   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.
2n
ヘッダの開始位置から2オクテットのオフセットを意味する。
8n+2
ヘッダの開始位置から8オクテットのオフセットプラス2オクテットを意味する。
   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実装で認識されなければならない:

パッド1オプション(整列要求なし)

   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オプションを用いるべきである。

パッド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. オプションのためのフォーマットガイドライン」にて、新しいオプションを設計するためのフォーマットガイドラインを紹介している。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年10月10日 最終更新:2006年10月10日