IPv6の仕様(IPv6拡張ヘッダ)

広告

広告

原文

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

IPv6の仕様(和訳)

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

4. IPv6拡張ヘッダ

   In IPv6, optional internet-layer information is encoded in separate
   headers that may be placed between the IPv6 header and the upper-
   layer header in a packet.  There are a small number of such extension
   headers, each identified by a distinct Next Header value.  As
   illustrated in these examples, an IPv6 packet may carry zero, one, or
   more extension headers, each identified by the Next Header field of
   the preceding header:

IPv6において、オプションであるインターネット層の情報は、IPv6ヘッダとパケット内の上位層ヘッダの間に位置する可能性のある個別のヘッダの中でコード化される。このような拡張ヘッダはいくつかあり、それぞれ異なるネクストヘッダ値によって識別される。下記例図のように、IPv6パケットはゼロ、もしくはそれ以上の拡張ヘッダを含む可能性があり、それぞれが先行するヘッダのネクストヘッダフィールドによって識別される。

   +---------------+------------------------
   |  IPv6 header  | TCP header + data
   |               |
   | Next Header = |
   |      TCP      |
   +---------------+------------------------


   +---------------+----------------+------------------------
   |  IPv6 header  | Routing header | TCP header + data
   |               |                |
   | Next Header = |  Next Header = |
   |    Routing    |      TCP       |
   +---------------+----------------+------------------------


   +---------------+----------------+-----------------+-----------------
   |  IPv6 header  | Routing header | Fragment header | fragment of TCP
   |               |                |                 |  header + data
   | Next Header = |  Next Header = |  Next Header =  |
   |    Routing    |    Fragment    |       TCP       |
   +---------------+----------------+-----------------+-----------------
   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.
   There, normal demultiplexing on the Next Header field of the IPv6
   header invokes the module to process the first extension header, or
   the upper-layer header if no extension header is present.  The
   contents and semantics of each extension header determine whether or
   not to proceed to the next header.  Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

例外として、パケットがIPv6ヘッダの宛先アドレスフィールドによって識別されたノード(又はマルチキャストの際のノード集合)に届くまで、パケットの配送パス上のノードは拡張ヘッダを調べることも処理することもできない。そこで、IPv6ヘッダのネクストヘッダフィールドにある正常なデマルチプレクシングは最初の拡張ヘッダを、拡張ヘッダがないのであれば上位層のヘッダを処理するためにモジュールを起動する。それぞれの拡張ヘッダの内容と意味は、後続するヘッダに処理を移すべきかどうかを決定するものである。従って、拡張ヘッダは厳密にパケット内での順番通りに処理されなければならない。例えば、受信者がパケットの中から特定の拡張ヘッダを検索し、その前に位置する未処理のヘッダを全て処理する前にそのヘッダを処理してはならない。

   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header.

前段落で触れた例外は、発信元ノードと宛先ノードを含むパケットの配送パス上にある全てのノードによって調べられ処理されるべき情報を伝えるホップバイホップなオプションヘッダである。ホップバイホップなオプションは、含むのであればIPv6ヘッダの直後に位置しなければならない。その存在は、IPv6ヘッダのネクストヘッダフィールド値がゼロであることにより明示される。

   If, as a result of processing a header, a node is required to proceed
   to the next header but the Next Header value in the current header is
   unrecognized by the node, it should discard the packet and send an
   ICMP Parameter Problem message to the source of the packet, with an
   ICMP Code value of 2 ("unrecognized Next Header type encountered")
   and the ICMP Pointer field containing the offset of the unrecognized
   value within the original packet.  The same action should be taken if
   a node encounters a Next Header value of zero in any header other
   than an IPv6 header.

ヘッダ処理の結果、ノードが次のヘッダに移るよう要求され、しかし現在のヘッダのネクストヘッダ値がノードによって認められない場合、パケットを破棄し、ICMPコード値が2(未承認のネクストヘッダタイプに遭遇した)で且つICMPポインタフィールドが元のパケットの中で認められない値のオフセットを含むICMP 不正パラメータメッセージをパケットの発信元に送信すべきである。IPv6ヘッダではないヘッダで値がゼロのネクストヘッダであれば、同じ処置が講じられるべきである。

   Each extension header is an integer multiple of 8 octets long, in
   order to retain 8-octet alignment for subsequent headers.  Multi-
   octet fields within each extension header are aligned on their
   natural boundaries, i.e., fields of width n octets are placed at an
   integer multiple of n octets from the start of the header, for n = 1,
   2, 4, or 8.

それぞれの拡張ヘッダは、後続するヘッダの先頭位置を8オクテットごとにするため、8オクテット長の整数倍である。それぞれの拡張ヘッダ内のマルチオクテットフィールドはそれらの自然境界上に整列する、つまり、n = 1,2,4,8に対し、幅 n オクテットのフィールドがヘッダの開始位置から数えて n オクテットの整数倍の位置に置かれることとなる。

   A full implementation of IPv6 includes implementation of the
   following extension headers:

           Hop-by-Hop Options
           Routing (Type 0)
           Fragment
           Destination Options
           Authentication
           Encapsulating Security Payload

   The first four are specified in this document; the last two are
   specified in [RFC-1826] and [RFC-1827], respectively.

IPv6の完全な実装は、以下の拡張ヘッダの実装を含む:

上から4番目までは当文書で規定し、残り2つについてはそれぞれ[RFC 1826]と[RFC 1827]で規定する

広告

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