One document matched: draft-ietf-ngtrans-routing-aspects-00.txt
Internet Engineering Task Force Ross Callon
Internet Draft Dimitry Haskin
Expires April 1996 Bay Networks Inc.
October 1995
Routing Aspects Of IPv6 Transition
(draft-ietf-ngtrans-routing-aspects-00.txt)
Status of this memo
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as ''work in progress.''
To learn the current status of any Internet-Draft, please
check the ''1id-abstracts.txt'' listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).
Abstract
This paper discusses routing aspects associated with the
transition from IPv4 to IPv6. The approach outlined here
is designed to be compatible with the existing mechanisms
for IPv4 to IPv6 Transition [1].
The proposals contained in this document are based on the
work of the Ngtrans working group.
Expires April 1996 [Page 1]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
1. TERMINOLOGY
This paper uses the following terminology:
node - a protocol module that implements IPv4 or IPv6.
router - a node that forwards packets not explicitly
addressed to itself.
host - any node that is not a router.
border router - a router that forwards packets across
routing domain boundaries.
link - a communication facility or medium over which
nodes can communicate at the link layer, i.e.,
the layer immediately below internet layer.
interface - a node's attachment to a link.
address - an network layer identifier for an interface or
a group of interfaces.
neighbors - nodes attached to the same link.
routing domain - a collection of routers which coordinate
routing knowledge using a single routing
protocol.
routing region (or just "region") - a collection of routers
interconnected by a single internet protocol
(e.g. IPv6) and coordinating their routing
knowledge using routing protocols from a single
internet protocol stack. A routing region may be
a superset of a routing domain.
tunneling - encapsulation of protocol A within protocol B,
such that A treats B as though it were a
datalink layer.
reachability information - information describing the set of
reachable destinations that can be used for
packet forwarding decisions.
routing information - same as reachability information.
address prefix - the high-order bits in an address.
Expires April 1996 [Page 2]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
routing prefix - address prefix that expresses destinations
which have addresses with the matching address
prefixes. It is used by routers to advertise what
systems they are capable of reaching.
route leaking - advertisement of network layer reachability
information across routing region boundaries.
2. ISSUES AND OUTLINE
This internet draft gives an overview of the routing aspects of
IPv4 to IPv6 transition. The approach outlined here is designed
to be compatible with the existing mechanisms for IPv6 transition
[1].
During an extended IPv4-to-IPv6 transition period, IPv6-based
systems must coexist with the installed base of IPv4 systems. In
such a dual internetworking protocol environment, both IPv4 and
IPv6 routing infrastructure will be present. Initially, deployed
IPv6-capable domains might not be globally interconnected via
IPv6-capable internet infrastructure and therefore may need to
communicate across IPv4-only routing regions. In order to achieve
dynamic routing in such a mixed environment, there need to be
mechanisms to globally distribute IPv6 network layer reachability
information between dispersed IPv6 routing regions. The same
techniques can be used in later stages of IPv4-to-IPv6 transition
to route IPv4 packets between isolated IPv4-only routing region
over IPv6 infrastructure.
The IPng transition provides a dual-IP-layer transition, augmented
by use of encapsulation where necessary and appropriate. Routing
issues related to this transition include:
(1) Routing for IPv4 packets
(2) Routing for IPv6 packets
(2a) IPv6 packets with IPv6-native addresses
(2b) IPv6 packets with IPv4-compatible addresses
(3) Operation of manually configured static tunnels
(4) Operation of automatic encapsulation
(4a) Locating encapsulators
(4b) Ensuring that routing is consist with
encapsulation
Expires April 1996 [Page 3]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
Basic mechanisms required to accomplish these goals include:
(i) Dual-IP-layer Route Computation; (ii) Manual configuration of
point-to-point tunnels; and (iii) Route leaking to support
automatic encapsulation.
The basic mechanism for routing of IPv4 and IPv6 involves
dual-IP-layer routing. This implies that routes are separately
calculated for IPv4 addresses and for IPv6 addressing. This is
discussed in more detail in section 3.1.
Tunnels (either IPv4 over IPv6, or IPv6 over IPv4) may be manually
configured. For example, in the early stages of transition this
may be used to allow two IPv6 domains to interact over an IPv4
infrastructure. Manually configured static tunnels are treated as
if they were a normal data link. This is discussed in more detail
in section 3.2.
Use of automatic encapsulation requires consistency of routes
between IPv4 routes and IPv6 routes for destinations using
IPv4-compatible addresses. For example, consider a packet which
starts off as an IPv6 packet, but then is encapsulated in an IPv4
packet in the middle of its path from source to destination. This
packet must locate an encapsulator at the correct part of its
path. Also, this packet has to follow a consistent route for the
entire path from source to destination. This is discussed in more
detail in section 3.3.
3. MORE DETAIL OF BASIC APPROACHES
3.1 Basic Dual-IP-layer Operation
In the basic dual-IP-layer transition scheme, routers may
independently support IPv4 and IPv6 routing. Other parts of the
transition, such as DNS support, and selection by the source host
of which packet format to transmit (IPv4 or IPv6) are discussed
in [1]. Forwarding of IPv4 packets is based on routes learned
through running IPv4-specific routing protocols. Similarly,
forwarding of IPv6 packets (including IPv6-packets with
IPv4-compatible addresses) is based on routes learned through
running IPv6-specific routing protocols. This implies that
separate instances of routing protocols are used for IPv4 and for
IPv6 (although note that this could consist of two instances of
OSPF and/or two instances of RIP, since both OSPF and RIP are
capable of supporting both IPv4 and IPv6 routing).
Expires April 1996 [Page 4]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
A minor enhancement would be to use an single instance of an
integrated routing protocol to support routing for both IPv4 and
IPv6. At the time that this is written there is no protocol which
has yet been enhanced to support this. This minor enhancement
does not change the basic dual-IP-layer nature of the transition.
For initial testing of IPv6 with IPv4-compatible addresses, it
may be useful to allow forwarding of IPv6 packets without running
any IPv6-compatible routing protocol. In this case, a dual (IPv4
and IPv6) router could run routing protocols for IPv4 only. It
then forwards IPv4 packets based on routes learned from IPv4
routing protocols. Also, it forwards IPv6 packets with an
IPv4-compatible destination address based on the route for the
associated IPv4 address. There are a couple of drawbacks with
this approach: (i) It does not specifically allow for routing of
IPv6 packets via IPv6-capable routers while avoiding and routing
around IPv4-only routers; (ii) It does not produce routes for
"non-compatible" IPv6 addresses. With this method the routing
protocol does not tell the router whether neighboring routers
are IPv6-compatible. However, neighbor discovery may be used to
determine this. Then if an IPv6 packet needs to be forwarded to
an IPv4-only router it can be encapsulated to the destination
host.
3.2 Manually Configured Static Tunnels
Tunneling techniques are already widely deployed for bridging
non-IP network layer protocols (e.g. Appletalk, CLNP, IPX) over
IPv4 routed infrastructure. IPv4 tunneling is an encapsulation of
arbitrary packets inside IPv4 datagrams that are forwarded over
IPv4 infrastructure between tunnel endpoints. For a tunneled
protocol, a tunnel appears as a single-hop link (i.e. routers
that establish a tunnel over a network layer infrastructure can
inter-operate over the tunnel as if it were a one-hop, point-to-
point link). Once a tunnel is established, routers at the tunnel
endpoints can establish routing adjacencies and exchange routing
information. Describing the protocols for performing
encapsulation is outside the scope of this paper (see [1]).
Static point-to-point tunnels may also be established between a
host and a router, or between two hosts. Again, each manually
configured point-to-point tunnel is treated as if it was a simple
point-to-point link.
In order for an IPv6 router to be able to encapsulate IPv6
packets into IPv4 datagrams and to forward encapsulated packets
over an IPv4 tunnel, such a router must also be able to speak
Expires April 1996 [Page 5]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
IPv4 (i.e. must be a dual router). The route tunneling technique
requires dual routers to be deployed at boundaries between
adjacent IPv6-capable and IPv4-only routing regions:
~~~~~ IPv6 region ~~~~~ ~~~~~ IPv6 region ~~~~~
| |
dual router dual router
| tunnel |
| <=================> |
~~~~~ IPv4 region ~~~~~
Figure 1: Example of Manually Configured Tunnel
Forwarding of IPv6 packets between IPv6 routing domains is
straightforward -- when a packet reaches a border router, the
border router examines it's routing database to find an interface
to the next-hop router. If the forwarding interface is connected
to a tunneled link, the packet must be encapsulated into an IPv4
datagram according to the adopted encapsulation scheme, and the
resulting datagram is forwarded over the tunnel. Intermediate
IPv4 routers between the tunnel endpoints forward the datagram as
they would any other IPv4 datagram, using information in the
encapsulating header. The recipient border router, in an adjacent
IPv6 region, strips off the encapsulating header and forwards the
original IPv6 packets toward its ultimate destination. Note that
the destination and source addresses in the encapsulating header
are the IPv4 addresses of the tunnel endpoints, not derivatives
of the destination and source addresses of the encapsulated IPv6
packet.
In the route tunneling scheme described here, there is a complete
separation of the IPv6 network reachability information from the
IPv4 routing information; i.e. this is a dual-IP-layer approach.
Nevertheless, an IPv4 routing region and an IPv6 routing region
can overlap. Each such region can share routers which support
both IPv4 and IPv6 routing.
There are the following advantages to employ manually configured
tunneling for exchanging datagrams and routing information:
- The underlying infrastructure which furnishes a tunnel link
is transparent to protocols that are bridged with the tunnel
(i.e. there is no changes to tunneled protocols).
- All types of IPv6 route prefixes without exception can be
Expires April 1996 [Page 6]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
advertised with routing protocols. Therefore, no restriction
needs to be imposed on formats of the addresses in IPv6
packets that can be routed with this scheme.
- If a connectivity between IPv6 nodes is all that needed, only
border routers at boundaries with IPv4-only routing regions
need to be dual protocol routers.
- Since IPv6 packets are encapsulated only when they travel
over network segments that don't support IPv6, and are
forwarded according to their native headers anywhere else,
this method does not constrain the types of policy routing
which may be employed over the IPv6 portion of the data path.
- Routers from major vendors already support the multiprotocol
operation that is needed at tunnel endpoints.
- Since a manually configured point to point tunnel works like
any normal point to point link, IPv6 multicast works over
manually configured point to point tunnels. No enhancement
nor change to IPv6 multicast is needed for this purpose.
The disadvantages of manually configured tunneling are that:
- Tunnels need to be manually configured.
- Manually configured tunnels are inherently point-to-point.
This may be a drawback in a region where for example a large
number of (IPv6-capable) dual hosts need to communicate over
an IPv4 infrastructure with a small number of (IPv6-capable)
dual routers.
- Tunnels may circumvent security firewalls of the
encapsulating infrastructure -- only addresses of the tunnel
endpoints are normally visible to such firewalls, not actual
attributes of the encapsulated packets. Note that the same
stands true for automatic tunneling described in the next
section.
- Since a tunnel may appear as a one-hop link, some routing
protocols may prefer a tunnel over a real multi-hop link.
Therefore, IPv6 packets may be routed across an IPv4 routing
region even when an alternative homogeneous IPv6 path is
available. Note that this disadvantage may be eliminated by
using a routing protocol such as OSPF which allows a
considerable dynamic range of metric values to be assigned
to links.
Expires April 1996 [Page 7]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
Though this section describes tunneling of IPv6 routing
information and IPv6 packets over IPv4 infrastructure, when a
need arises for IPv4 routing regions to communicate via IPv6
routing infrastructure, the similar tunneling technique can be
used -- except IPv4 packets will be encapsulated within IPv6
datagrams.
3.3 Automatic Tunnels
Automatic tunneling allows the addresses of one or both tunnel
endpoints to be determined automatically from the IPv6 source and
destination addresses. Automatic tunneling is based on use of
IPv4-compatible IPv6 addresses, and is only applicable for IPv6
over IPv4 use (i.e., for encapsulating an IPv6 packet within an
IPv4 header in order to allow the packet to be forwarded via
IPv4-only routers).
Automatic tunneling may be used for IPv6 packets when 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). In order for automatic
tunneling to work, any host which does not have any local
adjacent IPv6-capable router must have an IPv4-compatible IPv6
address assigned to it.
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
Expires April 1996 [Page 8]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
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.
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.
If the source host knows of any neighboring IPv6-capable router,
or if the source and destination hosts are on the same subnet,
then it is not necessary to use host to host automatic tunneling.
In this case other means of forwarding the packet are possible.
This document does not specify the preference between various
forms of forwarding the packet (such as the preference between
end to end encapsulation of IPv6 in IP versus using native IPv6
for part of the path and encapsulation for part of the path).
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
Expires April 1996 [Page 9]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
(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.
Similary 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.
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 IP 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.
If the destination address is also IPv4-compatible, then an
alternate method in this case is to use end to end automatic
tunneling. If the source host does know of at least one
neighboring IPv6-capable router, then an alternate method in this
case is for the source host to forward a native IPv6 packet to
the IPv6-capable router.
Expires April 1996 [Page 10]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
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
to the router for use as a tunnel endpoint. The dual router which
has connectivity to the IPv6 backbone and which is capable of
serving as tunnel endpoint advertises 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.
In some cases there may be multiple dual routers which can server
as endpoints for configured default tunneling from any one IPv4-
only region. In this case again each host may again be configured
with a single address representing the tunnel endpoint. However,
all dual routers with connectivity to the IPv6 backbone which are
capable of serving as configured tunnel endpoints from this
region must advertise a host route to the associated IPv4
address. This allows encapsulating packets using host to router
configured default tunneling to be forwarded to the tunnel
endpoint that is selected by the local routing policy (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 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
Expires April 1996 [Page 11]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
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 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 operation of the encapsulating router is
straightforward. The encapsulating router creates the
encapsulating IPv4 header using an IPv4 address assigned to
itself as the source IPv4 address, and using a destination IPv4
address extracted from the destination IPv4-compatible IPv6
address. The encapsulated packet is forwarded from the
encapsulating router to the destination host using normal IPv4
routing.
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, somehow the encapsulating router has
to advertise reachability for the appropriate IPv4-compatible
IPv6 addresses into the IPv6 routing region. There are several
options for how this may be accomplished:
(1) Implicit Routes based on IPv4 Routing
IPv4 routing will be used in the dual region to calculate
routes for IPv4 packets. It is possible (as mentioned in
section 3.1) to also use this to implicitly calculate routes
for IPv6 packets with IPv4-compatible addresses. In the case
that there is a boundary between a dual region and an IPv4-only
region, it is necessary for the dual routers at the boundary to
know that they are on the boundary, and that some neighboring
routers are not capable of receiving nor forwarding IPv6
packets. This may be specified by manual configuration of the
Expires April 1996 [Page 12]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
border routers, or may be determined through neighbor discovery.
As mentioned in section 3.1, this approach is limited in
usefulness. For example, it does not allow use of the full IPv6
address space.
(2) Implicit Routes for V4-compatible addresses Plus V6-routing
The solution 1 above may be enhanced by also running native
IPv6 routing for "native IPv6 addresses" (i.e., for addresses
which are not IPv4-compatible). In this case IPv6 packets with
v4-compatible addresses would be routed using routes calculated
by IPv4 routing, and other IPv6 packets would be routed using
routes calculated by IPv6 routing.
(3) Route Leaking
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 addresses 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 leaked into IPv6 routing protocols.
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 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. With approaches 1 and 2, advertising this one prefix
into IPv4 routing in the backbone implies that the same border
routers can also route IPv6 packets with corresponding
IPv4-compatible addresses into the same stub domain. With
approach 3, 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, use of
the third approach 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
Expires April 1996 [Page 13]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
routing table include one or more IPv6-capable systems, and only
these addresses be advertised into IPv6 routing in the dual
domain.
In some cases it is possible that some but not all of the dual
routers at a boundary between regions are capable of
encapsulation. In this case it is necessary that the IPv6 packets
with IPv4-compatible destination addresses are forwarded to the
correct boundary router (just any boundary router is not
sufficient). However, in this case native IPv4 packets traversing
the dual region destined for within the IPv4-only region may be
forwarded to any border router. In this case, the first two
solutions above are not feasible. Rather, manual configuration of
route leaking from IPv4 routing into IPv6 routing must be used.
Only those border routers which are actually capable of automatic
tunneling may leak routes in this case. It is recommended that
this situation be avoided, by having all routers at borders
between regions be capable of doing automatic tunneling.
Dual routers which implement option 2 above when forwarding IPv6
packets with IPv4-compatible addresses MUST give preference to
routes which are obtained directly from v6 routing, and only use
the routes implied from IPv4 routing as a last resort. This allows
explicit routes to be fed into IPv6 routing at those places where
the border routers between regions are not all capable of
automatic tunneling, but allows implicit routes based on IPv4
routing to be used in other cases. Clearly specifying the order of
preference of routes in this case is necessary in order to prevent
looping.
3.3.4 Operation when Multiple Methods are Feasible
There may be some cases in which more than one of the forms of
communications described here are feasible. In this case, the
decision regarding which form is to be used in any one actually
case is a policy decision, and is outside of the scope of this
document.
One example of this may occur if both source and destination
hosts have IPv4-compatible IPv6 addresses, and where both
source and destination hosts have connectivity to both IPv4 and
IPv6 routers. In this case it is possible to either use native
IPv6 on an end to end (host to host) basis, or to use IPv6
encapsulated over IPv4 on a host to host basis. Which method to
use in any one case may be decided via policy mechanisms which
Expires April 1996 [Page 14]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
are outside of the scope of this document. As one example of a
policy mechanism which could in principle be used in this case:
(i) A host might be configured to always use native IPv6 in this
case; (ii) A host may be configured to use IPv6 first but then
switch to IPv4 encapsulation if an error condition arises; (ii)
A host may be configured to use IPv4 encapsulation first but
switch to IPv6 if an error condition arises; or (iv) A host may
be configured to always use IPv4 encapsulation. It is not
necessary to use the same approach in each direction.
Another example occurs where an IPv6-capable host has no local
IPv6 router, where the host has been configured with the address
of a default configured tunnel endpoint, and where both source
and destination addresses are IPv4-compatible IPv6 addresses. In
this case an IPv6 packet may be transmitted by the host either
using host to host tunneling or using host to router tunneling.
Again, which form of tunneling to prefer in this case is a
policy mechanism and is not specified in this specification.
3.3.5 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 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.
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.
Expires April 1996 [Page 15]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
However, since this internet draft 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 internet draft.
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
4. EXAMPLE
Figure 2 illustrates an example network with two regions A and B.
Region A is dual, meaning that the routers within region A are
capable of forwarding both IPv4 and IPv6. Region B is IPv4-only,
implying that the routers within region B are capable of routing
only IPv4. The illustrated routers R1 through R4 are dual. The
illustrated routers r5 through r9 are IP-only. Also assume
Expires April 1996 [Page 16]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
that hosts H3 through H8 are dual. Thus H7 and H8 have been
upgraded to be IPv6-capable, even though they exist in a region
in which the routers are not IPv4-capable. However, host h1 and
h2 are IPv4-only.
......................... .......................
. . . .
. h1 . . |-h2 .
. | . . | .
. H3---R1--------R2---------------r5----r9----+ .
. | | . . | |-H7 .
. | | . . | .
. | | . . | .
. H4---R3--------R4---------------r6----r8-----H8 .
. . . .
......................... .......................
Region A (Dual Routers) Region B (IP-only Rtrs)
Figure 2: Example of Automatic Tunneling
Consider a packet from h1 to H8. In this case, since h1 is IPv4-
only, it will send an IPv4 packet. This packet will traverse
regions A and B as a normal IPv4 packet for the entire path.
Routing will take place using normal IPv4 routing methods, with
no change from the operation of the current IPv4 Internet (modulo
normal advances in the operation of IPv4, of course). Similarly,
consider a return packet from H8 to h1. Here again H8 will
transmit an IPv4 packet, which will be forwarded as a normal IPv4
packet for the entire path.
Consider a packet from H3 to H8. In this case, since H8 is in an
IPv4-only routing domain, we can assume that H8 uses an
IPv4-compatible IPv6 address. Since both source and destination are
IPv6-capable, H3 may transmit an IPv6 packet destined to H8. The
packet will be forwarded as far as R2 (or R4) as an IPv6 packet.
Router R2 (or R4) will then encapsulate the full IPv6 packet in
an IPv4 header for delivery to H8. In this case it is necessary
for routing of IPv6 within region A to be capable of delivering
this packet correctly to R2 (or R4). As explained in section 3.3,
this may either make use of implicit routes (using the v4 routing
within region A to provide routes for IPv6 packets with
IPv4-compatible addresses), or routers R2 and R4 may leak routes
to IPv4-compatible IPv6 addresses into the v6 routing used within
region A corresponding to the routes which are available via IPv4
routing within region B.
Expires April 1996 [Page 17]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
Consider a return packet from H8 to H3. Again, since both source
and destination are IPv6-capable, a V6 packet may be transmitted
by H8. However, since H8 does not have any direct connectivity to
an IPv6-capable router, H8 must make use of an automatic tunnel.
Which form of automatic tunnel will be used depends upon the type
of address assigned to H3.
If H3 is assigned an IPv4-compatible address, then the
requirements specified in section 3.3.1 will all be satisfied. In
this case host H8 may encapsulate the full IPv6 packet in an
IPv4 header using a source IPv4 address extracted from the IPv6
address of H8, and using a destination IPv4 address extracted
from the IPv6 address of H3.
If H3 has an incompatible IPv6 address, then it is not possible
for H8 to extract an IPv4 address to use as the destination
tunnel address from the IPv6 address of H3. In this case H8 must
use host to router tunneling, as specified in section 3.3.2. In
this case one or both of R2 and R4 must have been configured with
a tunnel endpoint IPv4 address (R2 and R4 may use either the same
address or different addresses for this purpose). R2 and/or R4
therefore advertise reachability to the tunnel endpoint address to r5
and r6 (respectively), which advertise this reachability information
into region B. Also, H8 must have been configured to know which
tunnel endpoint address to use for host to router tunneling. This
will result in the IPv6 packet, encapsulated in an IPv4 header,
to be transmitted as far as the border router R2 or R4. The
border router will then strip off the IPv4 header, and forward
the remaining IPv6 packet as a normal IPv6 packet using the
normal IPv6 routing used in region A.
5. INTERACTION BETWEEN IPv4 AND IPv6 INTER-DOMAIN ROUTING
As discussed above, if route leaking is employed then IPv4 routes
which are acquired by an inter-region dual router may need to be
injected into an IPv6 routing region. Such an inter-region dual
router may use BGP-4 for IPv4 inter-domain routing. Since the
Inter-Domain Routing Protocol (IDRP) has been adopted for IPv6
inter-domain routing, IDRP may need to be used to propagate the
IPv4 route into IPv6 routing.
When routes learned with BGP are injected into IDRP, it would be
highly desirable to preserve routing attributes associated with
the routes in order to minimize the effect of the inter-region
route leaking onto the routing integrity. Since practically all
routing attributes that are carried in BGP-4 are also present in
Expires April 1996 [Page 18]
Internet Draft Routing Aspects Of IPv6 Transition October 1995
IDRP, the mapping of the BGP-4 attributes to the IDRP attributes
is straightforward. However, since addresses and routing domain
identifiers that are carried by IDRP and BGP-4 are assigned from
different number spaces there is a need to ensure that 32-bit
IPv4 addresses and 16-bit routing domain identifiers (Autonomous
System numbers in IPv4 terminology) are uniquely represented in
the larger IPv6 number space.
It has been already agreed that IPv6 addresses with 96 leading
zero bits are reserved to represent addresses assigned from the
IPv4 address space. Since IPv6 domain identifiers are allocated
from the 128-bit IPv6 address space, it will be natural to
reserve IPv6 addresses (for use as routing domain identifiers)
with 112 leading zero bits to uniquely represent IPv4 Autonomous
System numbers.
6. SECURITY CONSIDERATIONS
Use of tunneling may violate firewalls of underlying routing
infrastructure.
No other security issues are discussed in this paper.
7. REFERENCES
[1] Transition Mechanisms for IPv6 Hosts and Routers,
Bob Gilligan and Erik Nordmark, Sun Microsystems,
Internet Draft draft-ietf-ngtrans-trans-mech-01.txt,
May 15 1995.
8. AUTHORS' ADDRESSES
Ross Callon
Bay Networks Inc.
3 Federal Street
Billerica, MA 01821
email: rcallon@baynetworks.com
Dimitry Haskin
Bay Networks, Inc.
2 Federal Street
Billerica, MA 01821
email: dhaskin@baynetworks.com
Expires April 1996 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 16:07:50 |