Internet DRAFT - draft-haskin-ipv6-routing-aspects
draft-haskin-ipv6-routing-aspects
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:18:54 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 06 Jun 1995 00:24:00 GMT
ETag: "2e9ae9-9fe1-2fd3a020"
Accept-Ranges: bytes
Content-Length: 40929
Connection: close
Content-Type: text/plain
Internet Engineering Task Force Ross Callon
Internet Draft Dimitry Haskin
Expires December 1995 Bay Networks Inc.
June 1995
Routing Aspects Of IPv6 Transition
(draft-haskin-ipv6-routing-aspects-01.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 the opinions
of the authors, and have not yet been discussed in detail
by the working group. This document is intended as input
to the IPv6, Tacit, and Ngtrans working groups.
Expires December 1995 [Page 1]
Internet Draft Routing Aspects Of IPv6 Transition June 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.
Expires December 1995 [Page 2]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
address prefix - the high-order bits in an address.
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-stack 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 December 1995 [Page 3]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
Basic mechanisms required to accomplish these goals include:
(i) Dual Stack 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-
stack 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 Stack Operation
In the basic dual stack 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 December 1995 [Page 4]
Internet Draft Routing Aspects Of IPv6 Transition June 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 stack 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 addresses based on the route for the
associated IPv4 address. There are a couple of drawbacks with
this approach: (i) It does not allow the router any practical way
to know whether neighboring routers are IPv6-capable, and thereby
presents the possibility of IPv6 packets being forwarded to
routers which are not capable of dealing with them (i.e., it does
not provide knowledge of when encapsulation is appropriate); (ii)
Similarly, it does not specifically allow for routing of IPv6
packets via IPv6-capable routers while avoiding and routing
around IPv4-only routers; (iii) It does not produce routes for
"non-compatible" IPv6 addresses.
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
IPv4 (i.e. must be a dual router). The route tunneling technique
Expires December 1995 [Page 5]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
requires dual routers to be deployed at boundaries between
adjacent IPv6 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 stack 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
advertised with routing protocols. Therefore, no restriction
Expires December 1995 [Page 6]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
need 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.
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.
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.
Expires December 1995 [Page 7]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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
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.
Expires December 1995 [Page 8]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
A source host may make use of Host to Host automatic tunneling
provided that ALL of the following are true:
- the source address is an IPv4-compatible IPv6 address.
- the destination address is an IPv4-compatible IPv6 address.
- the source host does not know of any neighboring IPv6-capable
router
- the source host does know of one or more neighboring IPv4-
capable routers
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 Automatic Tunneling
In some cases the source host may not have a local IPv6-capable
router, but the destination host may be using a "normal" IPv6
address (i.e., an IPv6-address which is not IPv4-compatible). In
this case, automatic tunneling may be used to encapsulate the IPv6
packet for transmission from the source host to an IPv6-backbone.
However, host to router automatic tunneling requires that the
source host be configured with an IPv4 address to use for
tunneling to the backbone.
A source host may make use of host to router automatic tunneling
provided that ALL of the following are true:
- the source address is an IPv4-compatible IPv6 address.
- the destination address is NOT IPv4-compatible
- the source host does not know of any neighboring IPv6-capable
router
- 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
Expires December 1995 [Page 9]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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 automatic 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 Automatic Tunnel
The dual router which is serving as the end point of the
automatic 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 automatic 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 endpoints for the automatic tunnels from
this region must advertise a host route to the associated IPv4
address. This allows encapsulating packets using host to router
automatic 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
Expires December 1995 [Page 10]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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
class C IPv4 address 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 (network) route to the
associated IPv4 address block (e.g., to the class C IPv4 network
in the normal case). 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 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
Expires December 1995 [Page 11]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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 must be specified by manual configuration of the
border routers. 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
Expires December 1995 [Page 12]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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
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.
It is proposed that 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.
3.3.4 Summary of How Automatic Tunnels may be Combined
Clearly automatic tunneling is useful only if communication can
be achieved in both directions. However, different forms of
automatic tunneling may be used in each direction, depending upon
the local environment and form of address of the two hosts which
are exchanging IPv6 packets.
Expires December 1995 [Page 13]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
Table 1 summarizes the form of tunneling that will result given
each possible combination of host capabilities. This table is
derived directly from the requirements for automatic tunneling
discussed above.
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 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
Expires December 1995 [Page 14]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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 border routers R5 and R6 are dual. Also assume
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 will transmit an IPv6 packet destined to H8. The
packet will be forwarded as far as R5 (or R6) as an IPv6 packet.
Router R5 (or R6) 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 R5 (or R6). As explained in section 3.3,
Expires December 1995 [Page 15]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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 R5 and R6 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.
Consider a return packet from H8 to H3. Again, since both source
and destination are IPv6-capable, a V6 packet will 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 will 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 R5 and R6 must have been configured with
a tunnel endpoint IPv4 address (R5 and R6 may use either the same
address or different addresses for this purpose). R5 and/or R6
therefore advertise reachability to the tunnel endpoint address
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 R5 or R6. 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.
Expires December 1995 [Page 16]
Internet Draft Routing Aspects Of IPv6 Transition June 1995
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
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 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.
Expires December 1995 [Page 17]
Internet Draft Routing Aspects Of IPv6 Transition June 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 December 1995 [Page 18]
