rfc2185.txt

中、英文RFC文档大全打包下载完全版 .

   tunneling to work, both nodes must be assigned IPv4-compatible IPv6
   addresses.  Automatic tunneling can be especially useful where either
   source or destination hosts (or both) do not have any adjacent IPv6-
   capable router.  Note that by "adjacent router", this includes
   routers which are logically adjacent by virtue of a manually
   configured point-to-point tunnel (which is treated as if it is a
   simple point-to-point link).

   With automatic tunneling, the resulting IPv4 packet is forwarded by
   IPv4 routers as a normal IPv4 packet, using IPv4 routes learned from
   routing protocols. There are therefore no special issues related to
   IPv4 routing in this case. There are however routing issues relating
   to how IPv6 routing works in a manner which is compatible with
   automatic tunneling, and how tunnel endpoint addresses are selected
   during the encapsulation process.  Automatic tunneling is useful from
   a source host to the destination host, from a source host to a
   router, and from a router to the destination host. Mechanisms for
   automatic tunneling from a router to another router are not currently
   defined.

3.3.1 Host to Host Automatic Tunneling

   If both source and destination hosts make use of IPv4-compatible IPv6
   addresses, then it is possible for automatic tunneling to be used for
   the entire path from the source host to the destination host. In this
   case, the IPv6 packet is encapsulated in an IPv4 packet by the source
   host, and is forwarded by routers as an IPv4 packet all the way to
   the destination host. This allows initial deployment of IPv6-capable
   hosts to be done prior to the update of any routers.








Callon & Haskin              Informational                      [Page 5]

RFC 2185           Routing Aspects Of IPv6 Transition     September 1997


   A source host may make use of Host to Host automatic tunneling
   provided that the following are both true:

     - the source address is an IPv4-compatible IPv6 address.
     - the destination address is an IPv4-compatible IPv6 address.
     - the source host does know of one or more neighboring IPv4-
       capable routers, or the source and destination are on the
       same subnet.

   If all of these requirements are true, then the source host may
   encapsulate the IPv6 packet in an IPv4 packet, using a source IPv4
   address which is extracted from the associated source IPv6 address,
   and using a destination IPv4 address which is extracted from the
   associated destination IPv6 address.

   Where host to host automatic tunneling is used, the packet is
   forwarded as a normal IPv4 packet for its entire path, and is
   decapsulated (i.e., the IPv4 header is removed) only by the
   destination host.

3.3.2 Host to Router Configured Default Tunneling

   In some cases "configured default" tunneling may be used to
   encapsulate the IPv6 packet for transmission from the source host to
   an IPv6-backbone. However, this requires that the source host be
   configured with an IPv4 address to use for tunneling to the backbone.

   Configured default tunneling is particularly useful if the source
   host does not know of any local IPv6-capable router (implying that
   the packet cannot be forwarded as a normal IPv6 packet directly over
   the link layer), and when the destination host does not have an
   IPv4-compatible IPv6 address (implying that host to host tunneling
   cannot be used).

   Host to router configured default tunneling may optionally also be
   used even when the host does know of a local IPv6 router. In this
   case it is a policy decision whether the host prefers to send a
   native IPv6 packet to the IPv6-capable router or prefers to send an
   encapsulated packet to the configured tunnel endpoint.

   Similarly host to router default configured tunneling may be used
   even when the destination address is an IPv4-compatible IPv6 address.
   In this case for example a policy decision may be made to prefer
   tunneling for part of the path and native IPv6 for part of the path,
   or alternatively to use tunneling for the entire path from source
   host to destination host.





Callon & Haskin              Informational                      [Page 6]

RFC 2185           Routing Aspects Of IPv6 Transition     September 1997


   A source host may make use of host to router configured default
   tunneling provided that ALL of the following are true:

     - the source address is an IPv4-compatible IPv6 address.
     - the source host does know of one or more neighboring IPv4-
       capable routers
     - the source host has been configured with an IPv4 address of
       an dual router which can serve as the tunnel endpoint.

   If all of these requirements are true, then the source host may
   encapsulate the IPv6 packet in an IPv4 packet, using a source IPv4
   address which is extracted from the associated source IPv6 address,
   and using a destination IPv4 address which corresponds to the
   configured address of the dual router which is serving as the tunnel
   endpoint.

   When host to router configured default tunneling is used, the packet
   is forwarded as a normal IPv4 packet from the source host to the dual
   router serving as tunnel endpoint, is decapsulated by the dual
   router, and is then forwarded as a normal IPv6 packet by the tunnel
   endpoint.

3.3.2.1 Routing to the Endpoint for the Configured Default Tunnel

   The dual router which is serving as the end point of the host to
   router configured default tunnel must advertise reachability into
   IPv4 routing sufficient to cause the encapsulated packet to be
   forwarded to it.

   The simplest approach is for a single IPv4 address to be assigned for
   use as a tunnel endpoint.  One or more dual routers,  which have
   connectivity to the IPv6 backbone and which are capable of serving as
   tunnel endpoint,  advertise a host route to this address into IPv4
   routing in the IPv4-only region.  Each dual host in the associated
   IPv4-only region is configured with the address of this tunnel
   endpoint and selects a route to this address for forwarding
   encapsulated packet to a tunnel end point  (for example, the nearest
   tunnel end point, based on whatever metric(s) the local routing
   protocol is using).

   Finally, in some cases there may be some reason for specific hosts to
   prefer one of several tunnel endpoints, while allowing all potential
   tunnel endpoints to serve as backups in case the preferred endpoint
   is not reachable. In this case, each dual router with IPv6 backbone
   connectivity which is serving as potential tunnel endpoint is given a
   unique IPv4 address taken from a single IPv4 address block (where the
   IPv4 address block is assigned either to the organization
   administering the IPv4-only region, or to the organization



Callon & Haskin              Informational                      [Page 7]

RFC 2185           Routing Aspects Of IPv6 Transition     September 1997


   administering the local part of the IPv6 backbone). In the likely
   case that there are much less than 250 such dual routers serving as
   tunnel endpoints, we suggest using multiple IPv4 addresses selected
   from a single 24-bit IPv4 address prefix for this purpose. Each dual
   router then advertises two routes into the IPv4 region: A host route
   corresponding to the tunnel endpoint address specifically assigned to
   it, and also a standard (prefix) route to the associated IPv4 address
   block. Each dual host in the IPv4-only region is configured with a
   tunnel endpoint address which corresponds to the preferred tunnel
   endpoint for it to use. If the associated dual router is operating,
   then the packet will be delivered to it based upon the host route
   that it is advertising into the IPv4-only region. However, if the
   associated dual router is down, but some other dual router serving as
   a potential tunnel endpoint is operating, then the packet will be
   delivered to the nearest operating tunnel endpoint.

3.3.3 Router to Host Automatic Tunneling

   In some cases the source host may have direct connectivity to one or
   more IPv6-capable routers,  but the destination host might not have
   direct connectivity to any IPv6-capable router. In this case,
   provided that the destination host has an IPv4-compatible IPv6
   address, normal IPv6 forwarding may be used for part of the packet's
   path, and router to host tunneling may be used to get the packet from
   an encapsulating dual router to the destination host.

   In this case, the hard part is the IPv6 routing required to deliver
   the IPv6 packet from the source host to the encapsulating router. For
   this to happen, the encapsulating router has to advertise
   reachability for the appropriate IPv4-compatible IPv6 addresses into
   the IPv6 routing region.  With this approach, all IPv6 packets
   (including those with IPv4-compatible addresses) are routed using
   routes calculated  from native IPv6 routing. This implies that
   encapsulating routers need to advertise into IPv6 routing specific
   route entries corresponding to any IPv4-compatible IPv6 addresses
   that belong to dual hosts which can be reached in an neighboring
   IPv4-only region. This requires manual configuration of the
   encapsulating routers to control which routes are to be injected into
   IPv6 routing protocols.  Nodes in the IPv6 routing region would use
   such a route to forward IPv6 packets along the routed path toward the
   router that injected (leaked) the route, at which point packets are
   encapsulated and forwarded to the destination host using normal IPv4
   routing.

   Depending upon the extent of the IPv4-only and dual routing regions,
   the leaking of routes may be relatively simple or may be more
   complex.  For example, consider a dual Internet backbone, connected
   via one or two dual routers to an IPv4-only stub routing domain. In



Callon & Haskin              Informational                      [Page 8]

RFC 2185           Routing Aspects Of IPv6 Transition     September 1997


   this case, it is likely that there is already one summary address
   prefix which is being advertised into the Internet backbone in order
   to summarize IPv4 reachability to the stub domain.  In such a case,
   the border routers would be configured to announce the IPv4 address
   prefix into the IPv4 routing within the backbone, and also announce
   the corresponding IPv4-compatible IPv6 address prefix into IPv6
   routing within the backbone.

   A more difficult case involves the border between a major Internet
   backbone which is IPv4-only, and a major Internet backbone which
   supports both IPv4 and IPv6. In this case, it requires that either
   (i) the entire IPv4 routing table be fed into IPv6 routing in the
   dual routing domain (implying a doubling of the size of the routing
   tables in the dual domain); or (ii) Manual configuration is required
   to determine which of the addresses contained in the Internet routing
   table include one or more IPv6-capable systems, and only these
   addresses be advertised into IPv6 routing in the dual domain.

3.3.4 Example of How Automatic Tunnels May be Combined

   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