IPv6用RIPng(メッセージフォーマット)

広告

広告

原文

最終更新
2006-11-01T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2080/rfc2080_21.html#source

IPv6用RIPng(和訳)

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

2.1 メッセージフォーマット

   RIPng is a UDP-based protocol.  Each router that uses RIPng has a
   routing process that sends and receives datagrams on UDP port number
   521, the RIPng port.  All communications intended for another
   router's RIPng process are sent to the RIPng port.  All routing
   update messages are sent from the RIPng port.  Unsolicited routing
   update messages have both the source and destination port equal to
   the RIPng port.  Those sent in response to a request are sent to the
   port from which the request came.  Specific queries may be sent from
   ports other than the RIPng port, but they must be directed to the
   RIPng port on the target machine.

RIPngは、UDPベースのプロトコルである。RIPngを用いる各ルータは、RIPngポートとしてUDPポート512番でデータグラムの送受信を行うルーティングプロセスを備える。他のRIPngプロセスとの全ての通信は、RIPngポートへ送信される。全てのルーティングアップデートメッセージは、RIPngポートから送信される。応答ではないルーティングアップデートメッセージは、発信元及び宛先の両方で同じRIPngポートを用いる。リクエストへの応答メッセージ送信は、リクエストを送ってきたポートに送られる。特別なクエリがRIPngポート以外のポートから送信されることもあるが、その宛先ポートはRIPngポートでなければならない。

RIPngパケットフォーマット

   The RIPng packet format is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  command (1)  |  version (1)  |       must be zero (2)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Route Table Entry 1 (20)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ...                                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Route Table Entry N (20)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTEフォーマット

   where each Route Table Entry (RTE) has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                        IPv6 prefix (16)                       ~
      |                                                               |
      +---------------------------------------------------------------+
      |         route tag (2)         | prefix len (1)|  metric (1)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The maximum number of RTEs is defined below.

RTEの最大数は後に定義される。

   Field sizes are given in octets.  Unless otherwise specified, fields
   contain binary integers, in network byte order, with the most-
   significant octet first (big-endian).  Each tick mark represents one
   bit.

フィールドサイズはオクテットで与えられている。特に指定がなければ、フィールドは2進数の整数を含み、上位オクテットが最初にくる(ビッグエンディアン)ネットワークバイトオーダとなる。各印(+)が1bitを表す。

   Every message contains a RIPng header which consists of a command and
   a version number.  This document describes version 1 of the protocol
   (see section 2.4).  The command field is used to specify the purpose
   of this message.  The commands implemented in version 1 are:

   1 - request    A request for the responding system to send all or
                  part of its routing table.

   2 - response   A message containing all or part of the sender's
                  routing table.  This message may be sent in response
                  to a request, or it may be an unsolicited routing
                  update generated by the sender.

全てのメッセージがコマンドとバージョン数からなるRIPngヘッダを含む。当文書は、プロトコルバージョン1について触れる(2.4 入力処理を参照)。コマンドフィールドは、このメッセージの目的を定義するために用いられる。バージョン1に実装されたコマンドは次の通り:

1:要求
応答システムにルーティングテーブル全てもしくは一部の送信を求める。
2:応答
送信者のルーティングテーブルの全てもしくは一部を含むメッセージ。このメッセージはリクエストに対するメッセージとして送られるかもしれないし、送信者によって生成される自律的なルーティングアップデートかもしれない。
   For each of these message types, the remainder of the datagram
   contains a list of RTEs.  Each RTE in this list contains a
   destination prefix, the number of significant bits in the prefix, and
   the cost to reach that destination (metric).

これらのメッセージタイプはそれぞれ、データグラムの残りにRTEリストを含む。このリスト内の各RTEは、宛先プレフィックスとプレフィックスの有効ビット数、宛先までのコスト(距離)を含む。

   The destination prefix is the usual 128-bit, IPv6 address prefix
   stored as 16 octets in network byte order.

宛先プレフィックスは通常128bitのIPv6で、ネットワークバイトオーダの16オクテットに設定される。

   The route tag field is an attribute assigned to a route which must be
   preserved and readvertised with a route.  The intended use of the
   route tag is to provide a method of separating "internal" RIPng
   routes (routes for networks within the RIPng routing domain) from
   "external" RIPng routes, which may have been imported from an EGP or
   another IGP.

経路タグフィールドは経路に割り当てられる属性であり、その属性は経路によって維持され再アドバタイズされる。経路タグの意図される利用法は、"内部"RIPng経路(RIPngルーティングドメイン内のネットワーク経路)をEGPか他のIGPからもたらされた"外部"RIPng経路から分離するための方法を提供することである。

   Routers supporting protocols other than RIPng should be configurable
   to allow the route tag to be configured for routes imported from
   different sources.  For example, routes imported from an EGP should
   be able to have their route tag either set to an arbitrary value, or
   at least to the number of the Autonomous System from which the routes
   were learned.

RIPng以外のプロトコルをサポートするルータは、異なる発信元から取り込まれた経路によって設定される経路タグを認めるべきである。例えば、TGPから取り込まれた経路は任意の値か、少なくとも経路を学習した自律システムの番号を経路タグとして設定可能とすべきである。

   Other uses of the route tag are valid, as long as all routers in the
   RIPng domain use it consistently.

経路タグの他の利用法は、全てのRIPngドメインのルータが整合性を持ってそれを使うといった有効確認である。

   The prefix length field is the length in bits of the significant part
   of the prefix (a value between 0 and 128 inclusive) starting from the
   left of the prefix.

プレフィックス長フィールドは、プレフィックス(0から128までの値)の左から始まるプレフィックスの有効部分の長さである。

   The metric field contains a value between 1 and 15 inclusive,
   specifying the current metric for the destination; or the value 16
   (infinity), which indicates that the destination is not reachable.

距離フィールドは、宛先から現在の距離を示す1から15までの値か、宛先への到達不可を示す値16(無限)である。

   The maximum datagram size is limited by the MTU of the medium over
   which the protocol is being used.  Since an unsolicited RIPng update
   is never propagated across a router, there is no danger of an MTU
   mismatch.  The determination of the number of RTEs which may be put
   into a given message is a function of the medium's MTU, the number of
   octets of header information preceeding the RIPng message, the size
   of the RIPng header, and the size of an RTE.  The formula is:

               +-                                                   -+
               | MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
   #RTEs = INT | --------------------------------------------------- |
               |                      RTE_size                       |
               +-                                                   -+

最大データグラムサイズは、プロトコルが用いられる媒体のMTUによって制限がなされている。自律的なRIPngアップデートはルータを超えて送られることがないので、MTU不一致による危険性はない。与えられたメッセージに設定可能なRTE数の決定は、媒体のMTUとRIPngメッセージの前にあるヘッダ情報のオクテット数、RIPngヘッダの大きさ、経路の大きさからの関数によってなされる。式は以下の通り:(式は原文参照)

2.1.1 ネクストホップ

   RIPng provides the ability to specify the immediate next hop IPv6
   address to which packets to a destination specified by a route table
   entry (RTE) should be forwarded in much the same way as RIP-2 [2].
   In RIP-2, each route table entry has a next hop field.  Including a
   next hop field for each RTE in RIPng would nearly double the size of
   the RTE.  Therefore, in RIPng, the next hop is specified by a special
   RTE and applies to all of the address RTEs following the next hop RTE
   until the end of the message or until another next hop RTE is
   encountered.

RIPngはRIP-2[2]と同じく、経路テーブルエントリ(RTE)で示される宛先へパケットを転送すべき直接なネクストホップのIPv6アドレスを指定する能力を提供する。RIP2では、各RTEはネクストホップフィールドを有している。RIPngの各RTEのネクストホップフィールドを含めることは、RTEの大きさを倍近くとすることになるだろう。従ってRIPngでは、ネクストホップは特別なRTEによって指定され、メッセージの終りまでか他の次の転送先までのネクストホップRTEに従う全てのアドレスRTEに適用される。

   A next hop RTE is identified by a value of 0xFF in the metric field
   of an RTE.  The prefix field specifies the IPv6 address of the next
   hop.  The route tag and prefix length in the next hop RTE must be set
   to zero on sending and ignored on receiption.

ネクストホップRTEは、RTEの距離フィールドの0xFFによって識別される。プレフィックスフィールドは、ネクストホップのIPv6アドレスを指定する。ルートタグとネクストホップRTEのプレフィックス長は、送信時にゼロが設定され、受信者によってこれは無視されなければならない。

ネクストホップRTEフォーマット
   The next hop Route Table Entry (RTE) has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    IPv6 next hop address (16)                 ~
   |                                                               |
   +---------------------------------------------------------------+
   |        must be zero (2)       |must be zero(1)|     0xFF      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next
   hop RTE indicates that the next hop address should be the originator
   of the RIPng advertisement.  An address specified as a next hop must
   be a link-local address.

ネクストホップRTEのプレフィックスフィールドで0:0:0:0:0:0:0:0値を指定することは、ネクストホップアドレスがRIPngアドバタイズの送信者であることを示す。ネクストホップとして指定されたアドレスは、リンクローカルアドレスでなければならない。

   The purpose of the next hop RTE is to eliminate packets being routed
   through extra hops in the system.  It is particularly useful when
   RIPng is not being run on all of the routers on a network.  Note that
   next hop RTE is "advisory".  That is, if the provided information is
   ignored, a possibly sub-optimal, but absolutely valid, route may be
   taken.  If the received next hop address is not a link-local address,
   it should be treated as 0:0:0:0:0:0:0:0.

ネクストホップの目的は、システムにおいて不要なホップにパケットがルーティングされることを避けるためである。RIPngがネットワーク上の全てのルータで実行されているわけではない場合、特に有効である。ネクストホップRTEは"助言"であることに注意が必要である。つまり、提供された情報が無視されるのであれば、おそらく最良ではないが、完全に正確な経路が得られるだろう。受信したネクストホップアドレスがリンクローカルアドレスでなければ、0:0:0:0:0:0:0:0として扱われるべきである。

広告

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