ルーティング面でのIPv6移行(自動トンネルの組み合わせの例)

広告

広告

原文

最終更新
2006-11-09T05:13:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2185/rfc2185_34.html#source

ルーティング面でのIPv6移行(和訳)

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

3.3.4 自動トンネルの組み合わせの例

   Clearly tunneling is useful only if communication can be achieved in
   both directions. However, different forms of tunneling may be used in
   each direction, depending upon the local environment, the form of
   address of the two hosts which are exchanging IPv6 packets, and the
   policies in use.

   Table 1 summarizes the form of tunneling that will result given each
   possible combination of host capabilities, and given one possible set
   of policy decisions. This table is derived directly from the
   requirements for automatic tunneling discussed above.

   The example in table 1 uses a specific set of policy decisions: It is
   assumed in table 1 that the source host will transmit a native IPv6
   where possible in preference over encapsulation. It is also assumed
   that where tunneling is needed, host to host tunneling will be
   preferred over host to router tunneling. Other combinations are
   therefore possible if other policies are used.

   Due to a specific policy choice, the default sending rules in [1] may
   not be followed.

   Note that IPv6-capable hosts which do not have any local IPv6 router
   must be given an IPv4-compatible v6 address in order to make use of
   their IPv6 capabilities. Thus, there are no entries for IPv6-capable
   hosts which have an incompatible IPv6 address and which also do not
   have any connectivity to any local IPv6 router. In fact, such hosts
   could communicate with other IPv6 hosts on the same local network
   without the use of a router.  However, since this document focuses on
   routing and router implications of IPv6 transition, direct
   communication between two hosts on the same local network without any
   intervening router is outside the scope of this document.

   Also, table 1 does not consider manually configured point-to-point
   tunnels.  Such tunnels are treated as if they were normal point-to-
   point links. Thus any two IPv6-capable devices which have a manually
   configured tunnel between them may be considered to be directly
   connected.

  -----------------+------------------+--------------------------
  Host A           | Host B           | Result
  -----------------+------------------+--------------------------
  v4-compat. addr. | v4-compat. addr. | host to host tunneling
  no local v6 rtr. | no local v6 rtr. | in both directions
  -----------------+------------------+--------------------------
  v4-compat. addr. | v4-compat. addr. | A->B: host to host tunnel
  no local v6 rtr. | local v6 rtr.    | B->A: v6 forwarding plus
                   |                  |       rtr->host tunnel
  -----------------+------------------+--------------------------
  v4-compat. addr. | incompat. addr.  | A->B: host to rtr tunnel
  no local v6 rtr. | local v6 rtr.    |       plus v6 forwarding
                   |                  | B->A: v6 forwarding plus
                   |                  |       rtr to host tunnel
  -----------------+------------------+--------------------------
  v4-compat. addr. | v4-compat. addr. | end to end native v6
  local v6 rtr.    | local v6 rtr.    | in both directions
  -----------------+------------------+--------------------------
  v4-compat. addr. | incompat. addr.  | end to end native v6
  local v6 rtr.    | local v6 rtr.    | in both directions
  -----------------+------------------+--------------------------
  incompat. addr.  | incompat. addr.  | end to end native v6
  local v6 rtr.    | local v6 rtr.    | in both directions
  -----------------+------------------+--------------------------

          Table 1: Summary of Automatic Tunneling Combinations

広告

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