IPv6の仕様(フラグメントヘッダ)

広告

広告

原文

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

IPv6の仕様(和訳)

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

4.5 フラグメントヘッダ

   The Fragment header is used by an IPv6 source to send packets larger
   than would fit in the path MTU to their destinations.  (Note: unlike
   IPv4, fragmentation in IPv6 is performed only by source nodes, not by
   routers along a packet's delivery path -- see section 5.)  The
   Fragment header is identified by a Next Header value of 44 in the
   immediately preceding header, and has the following format:

フラグメントヘッダは、宛先へパスMTUに入るより大きいパケットを送信するためにIPv6発信元によって用いられるヘッダである。(注記:IPv4とは異なり、IPv6でのフラグメンテーションはパケットの伝送経路上のルータによってではなく発信元ノードによってのみ行われる/「5. パケットサイズに関する問題」を参照)フラグメントヘッダは直前のヘッダのネクストヘッダ値"44"によって識別され、下記のフォーマットである。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Next Header          8-bit selector.  Identifies the initial header
                        type of the Fragmentable Part of the original
                        packet (defined below).  Uses the same values
                        as the IPv4 Protocol field [RFC-1700 et seq.].

   Reserved             8-bit reserved field.  Initialized to zero for
                        transmission; ignored on reception.

   Fragment Offset      13-bit unsigned integer.  The offset, in 8-octet
                        units, of the data following this header,
                        relative to the start of the Fragmentable Part
                        of the original packet.

   Res                  2-bit reserved field.  Initialized to zero for
                        transmission; ignored on reception.

   M flag               1 = more fragments; 0 = last fragment.

   Identification       32 bits.  See description below.
ネクストヘッダ
8bitのセレクタ。元のパケットの分割可能な部分の最初のヘッダを識別するために用いる(詳細は下記)。IPv4プロトコルフィールド[RFC 1700]と同じ値を用いる。
予約済み
8bitの予約されたフィールド。送信時はゼロで埋められ、受信時は無視される。
フラグメントオフセット
13bitの符号なし整数。元のパケットの分割可能な部分の始まりからみてこのヘッダに後続するデータの位置を8オクテット単位で示すオフセット。
予約済み
2bitの予約されたフィールド。送信時はゼロで埋められ、受信時は無視される。
Mフラグ
1:途中のフラグメント/0:最後のフラグメント。
識別子
32bit。下記を参照。
   In order to send a packet that is too large to fit in the MTU of the
   path to its destination, a source node may divide the packet into
   fragments and send each fragment as a separate packet, to be
   reassembled at the receiver.

宛先への経路で定められているMTUよりも大きなパケットを送信するために、発信元ノードはパケットをフラグメント化し、パケット分割により生じたそれぞれのフラグメントを受信者側が再構築可能な状態で送信することができる。

   For every packet that is to be fragmented, the source node generates
   an Identification value. The Identification must be different than
   that of any other fragmented packet sent recently* with the same
   Source Address and Destination Address.  If a Routing header is
   present, the Destination Address of concern is that of the final
   destination.

フラグメント化された全てのパケット用に、発信元ノードは識別値を生成する。識別子は、発信元アドレスと宛先アドレスが同じで最近送信された他のフラグメント化されたパケットの間で重複してはならない。ルーティングヘッダがあるのであれば、宛先アドレスとは最終宛先のアドレスのことである。

      * "recently" means within the maximum likely lifetime of a packet,
        including transit time from source to destination and time spent
        awaiting reassembly with other fragments of the same packet.
        However, it is not required that a source node know the maximum
        packet lifetime.  Rather, it is assumed that the requirement can
        be met by maintaining the Identification value as a simple, 32-
        bit, "wrap-around" counter, incremented each time a packet must
        be fragmented.  It is an implementation choice whether to
        maintain a single counter for the node or multiple counters,
        e.g., one for each of the node's possible source addresses, or
        one for each active (source address, destination address)
        combination.

最近は、発信元から宛先までの伝送時間や同一パケットの他のフラグメントを待ち受けて再構築するのに費やした時間を含む、パケットの生存期間の最大値を指す。ただし、発信元ノードがパケット生存期間の最大値を知ることは要求されていない。この要求は、パケットがフラグメント化されたるたびに増加する単純な32bitの巡回式カウンタのような識別値で満たすことができると想定される。ノードが1つのカウンターを用いるか、それぞれのノードの適当な発信元アドレスのごとやアドレスの組み合わせ(発信元アドレスと宛先アドレス)ごとに複数のカウンタを用いるかは、実装が選択することである。

   The initial, large, unfragmented packet is referred to as the
   "original packet", and it is considered to consist of two parts, as
   illustrated:

初期の、そして大きい、フラグメント化される前のパケットは元のパケットとして示し、下図のように2つの部分で構成されるとみなされる:

   original packet:

   +------------------+----------------------//-----------------------+
   |  Unfragmentable  |                 Fragmentable                  |
   |       Part       |                     Part                      |
   +------------------+----------------------//-----------------------+
      The Unfragmentable Part consists of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

フラグメント化不可部分は、IPv6ヘッダと宛先までの経路中でノードによって処理されなければならない拡張ヘッダ――つまり、もしあればルーティングヘッダ以下の全てのヘッダ、でなければホップバイホップオプションヘッダ以下の全てのヘッダ、でなければ拡張ヘッダはなし――から構成される。

      The Fragmentable Part consists of the rest of the packet, that is,
      any extension headers that need be processed only by the final
      destination node(s), plus the upper-layer header and data.

フラグメント化可能部分は、パケットの中の残りの部分――つまり、最終宛先ノードのみが処理する拡張ヘッダと、上位層ヘッダ及びデータ――から構成される。

   The Fragmentable Part of the original packet is divided into
   fragments, each, except possibly the last ("rightmost") one, being an
   integer multiple of 8 octets long.  The fragments are transmitted in
   separate "fragment packets" as illustrated:

元のパケットのフラグメント化可能部分は、可能な限り最後(右端)以外は8オクテットの整数倍となるようフラグメントに分割される。フラグメントは下図のように個々の"フラグメントパケット"として伝送される:

   original packet:

   +------------------+--------------+--------------+--//--+----------+
   |  Unfragmentable  |    first     |    second    |      |   last   |
   |       Part       |   fragment   |   fragment   | .... | fragment |
   +------------------+--------------+--------------+--//--+----------+
   fragment packets:

   +------------------+--------+--------------+
   |  Unfragmentable  |Fragment|    first     |
   |       Part       | Header |   fragment   |
   +------------------+--------+--------------+

   +------------------+--------+--------------+
   |  Unfragmentable  |Fragment|    second    |
   |       Part       | Header |   fragment   |
   +------------------+--------+--------------+
                         o
                         o
                         o
   +------------------+--------+----------+
   |  Unfragmentable  |Fragment|   last   |
   |       Part       | Header | fragment |
   +------------------+--------+----------+

それぞれのフラグメントパケットの構成

   Each fragment packet is composed of:

      (1) The Unfragmentable Part of the original packet, with the
          Payload Length of the original IPv6 header changed to contain
          the length of this fragment packet only (excluding the length
          of the IPv6 header itself), and the Next Header field of the
          last header of the Unfragmentable Part changed to 44.

(1)元のパケットのフラグメント化不可部分において、元のIPv6ヘッダのペイロード長はこのフラグメントパケットのみのサイズ(IPv6ヘッダ自身のサイズは除く)に変更され、フラグメント不可部分の最後のヘッダのネクストヘッダフィールドは"44"に変更される。

      (2) A Fragment header containing:

               The Next Header value that identifies the first header of
               the Fragmentable Part of the original packet.

               A Fragment Offset containing the offset of the fragment,
               in 8-octet units, relative to the start of the
               Fragmentable Part of the original packet.  The Fragment
               Offset of the first ("leftmost") fragment is 0.

               An M flag value of 0 if the fragment is the last
               ("rightmost") one, else an M flag value of 1.

               The Identification value generated for the original
               packet.

(2)フラグメントヘッダは下記を含む:

元のパケットのフラグメント化可能部分の最初のヘッダを識別するネクストヘッダ値。

元のパケットのフラグメント化可能部分の始まりから数えたそのフラグメントの位置を8オクテット単位で示すフラグメントオフセット。最初の(左端の)フラグメントのフラグメントオフセットは"0"である。

そのフラグメントが最後(右端)であればMフラグは0であり、そうでなければ1である。

元のパケットのために生成された識別値。

      (3) The fragment itself.

(3)フラグメント自身。

   The lengths of the fragments must be chosen such that the resulting
   fragment packets fit within the MTU of the path to the packets'
   destination(s).

パケットを分割した結果のフラグメント長は、宛先までの経路のMTUに合わせて決定されなければならない。

   At the destination, fragment packets are reassembled into their
   original, unfragmented form, as illustrated:

宛先では、分割されたパケットを元のパケットに再構成することとなる:

   reassembled original packet:

   +------------------+----------------------//------------------------+
   |  Unfragmentable  |                 Fragmentable                   |
   |       Part       |                     Part                       |
   +------------------+----------------------//------------------------+

再構築の際の規則

   The following rules govern reassembly:

      An original packet is reassembled only from fragment packets that
      have the same Source Address, Destination Address, and Fragment
      Identification.

発信元アドレス、宛先アドレス、フラグメント識別子が同じフラグメントパケットのみが、元のパケットの再構築に用いられる。

      The Unfragmentable Part of the reassembled packet consists of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

再構築されたパケットのフラグメント不可部分は、最初のフラグメントパケットのフラグメントヘッダ(つまり、フラグメントオフセットがゼロのパケット)を除き、次の2つの変更がなされた全てのヘッダからなる:

         The Next Header field of the last header of the Unfragmentable
         Part is obtained from the Next Header field of the first
         fragment's Fragment header.

フラグメント化不可部分の最後のヘッダのネクストヘッダフィールドは、最初のフラグメントのフラグメントヘッダにあるネクストヘッダフィールドから得られる。

         The Payload Length of the reassembled packet is computed from
         the length of the Unfragmentable Part and the length and offset
         of the last fragment.  For example, a formula for computing the
         Payload Length of the reassembled original packet is:

           PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

           where
           PL.orig  = Payload Length field of reassembled packet.
           PL.first = Payload Length field of first fragment packet.
           FL.first = length of fragment following Fragment header of
                      first fragment packet.
           FO.last  = Fragment Offset field of Fragment header of
                      last fragment packet.
           FL.last  = length of fragment following Fragment header of
                      last fragment packet.

再構築されたパケットのペイロード長は、フラグメント不可部分のサイズと最後のフラグメントの長さとオフセットから算出される。例えば、再構築された元のパケットのペイロード長を計算するための公式は以下:

PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

PL.orig
再構築されたパケットのペイロード長フィールド
PL.first
最初のフラグメントパケットのペイロード長フィールド
FL.first
最初のフラグメントパケットのフラグメントヘッダに後続するフラグメント長
FO.last
最後のフラグメントパケットのフラグメントヘッダのフラグメントオフセットフィールド
FL.last
最後のフラグメントパケットのフラグメントヘッダに後続するフラグメント長
      The Fragmentable Part of the reassembled packet is constructed
      from the fragments following the Fragment headers in each of the
      fragment packets.  The length of each fragment is computed by
      subtracting from the packet's Payload Length the length of the
      headers between the IPv6 header and fragment itself; its relative
      position in Fragmentable Part is computed from its Fragment Offset
      value.

再構築されたパケットのフラグメント化可能部分は、各フラグメントパケットのフラグメントヘッダに後続するフラグメントで構成される。各フラグメントの長さは、自身のパケットのペイロード長からIPv6ヘッダとフラグメント間のヘッダの長さを引くことによって算出される。そのフラグメント化可能部分中の相対位置はそのフラグメントオフセット値から算出される。

      The Fragment header is not present in the final, reassembled
      packet.

フラグメントヘッダは、最終的に再構築されたパケット内に存在しない。

   The following error conditions may arise when reassembling fragmented
   packets:

次のエラーは、フラグメントパケットを再構築する際に起こり得る:

      If insufficient fragments are received to complete reassembly of a
      packet within 60 seconds of the reception of the first-arriving
      fragment of that packet, reassembly of that packet must be
      abandoned and all the fragments that have been received for that
      packet must be discarded.  If the first fragment (i.e., the one
      with a Fragment Offset of zero) has been received, an ICMP Time
      Exceeded -- Fragment Reassembly Time Exceeded message should be
      sent to the source of that fragment.

最初に到着した該当パケットのフラグメントを受け取ってから60秒以内に、パケットを完全に再構築するに十分なフラグメントを全て受信できないのであれば、そのパケットの再構築は放棄しなければならず、該当のパケット再構築のために受信した全てのフラグメントを破棄しなくてはならない。最初のフラグメント(つまり、フラグメントオフセットが0のフラグメント)が受信されていたのであれば、ICMPタイム超過メッセージ(フラグメント再構築時間の超過との意)を該当のフラグメントの発信者に送信すべきである。

      If the length of a fragment, as derived from the fragment packet's
      Payload Length field, is not a multiple of 8 octets and the M flag
      of that fragment is 1, then that fragment must be discarded and an
      ICMP Parameter Problem, Code 0, message should be sent to the
      source of the fragment, pointing to the Payload Length field of
      the fragment packet.

フラグメントパケットのペイロード長フィールドから得られるフラグメント長が8オクテットの倍数ではなく、且つそのフラグメントのMフラグが"1"であれば、そのフラグメントは破棄されなければならず、フラグメントパケットのペイロード長フィールドの値を示すICMP不正パラメータメッセージ、コード"0"をフラグメントの発信元に送信すべきである。

      If the length and offset of a fragment are such that the Payload
      Length of the packet reassembled from that fragment would exceed
      65,535 octets, then that fragment must be discarded and an ICMP
      Parameter Problem, Code 0, message should be sent to the source of
      the fragment, pointing to the Fragment Offset field of the
      fragment packet.

フラグメントの長さとオフセット、つまりフラグメントから再構築したパケットのペイロード長が65,535オクテットを超えるのであれば、そのフラグメントは破棄されねばならず、フラグメントパケットのフラグメントオフセットフィールドの値を示すICMP不正パラメータメッセージ、コード"0"をフラグメントの発信元に送信すべきである。

   The following conditions are not expected to occur, but are not
   considered errors if they do:

以下の事象は生じる可能性が低く、仮に生じたとしてもエラーとは見なされない:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

同じ元のパケットの異なるフラグメントのフラグメントヘッダに先行するヘッダの数量と内容は異なることがある。各フラグメントパケット内のフラグメントヘッダに先行するヘッダは全て、再構築のためフラグメントを待ち行列に入れる前に到着し次第処理される。つまり、オフセットがゼロのフラグメントパケットの中のヘッダのみが、パケットの再構築のために保持されることとなる。

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

同じ元のパケットの異なるフラグメントのフラグメントヘッダ内のネクストヘッダ値は異なることがある。これは、オフセットがゼロのフラグメントパケットの値だけが再構築のために用いられるためである。

広告

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