Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Most Enterprises do not move from having no formal IPv6 support to creating a full native
IPv6 implementation on all routers, hosts, servers, and other devices. In the real world,
some Enterprise networks will begin with several locations that need consistent and working
IPv6 support. Other companies may begin with a small set of people who want to experiment
with IPv6 in anticipation of the day in which IT will take advantage of IPv6.
Eventually, IPv6 may well become the predominate traffic in the Enterprise, and one day,
IPv4 may go away altogether, but that day may be decades away. As a result, IPv4 and
IPv6 will likely coexist in a given internetwork for a very long time.
During this possibly long migration, three main classes of tools may be used to allow IPv4
to continue to work well, while supporting IPv6:
■ Dual IPv4/IPv6 stacks (dual stacks)
■ Tunneling
■ NAT Protocol Translator (NAT-PT)
This section looks at each type of tool in succession.
IPv4/IPv6 Dual Stacks
The term dual stacks means that the host or router uses both IPv4 and IPv6 at the same
time. For hosts, this means that the host has both an IPv4 and IPv6 address associated
with each NIC, that the host can send IPv4 packets to other IPv4 hosts, and that the host
can send IPv6 packets to other IPv6 hosts. For routers, it means that in addition to the
usual IPv4 IP addresses and routing protocols, the routers would also have IPv6 addresses
and routing protocols configured as discussed in Chapters 16, “IP Version 6 Addressing,”
and 17, “IPv6 Routing Protocols and Redistribution.” To support both IPv4 and IPv6
hosts, the router could then receive and forward both IPv4 packets and IPv6 packets.
Note: Although not used as often today, the general term protocol stack refers to the layers
in a protocol suite, with a protocol stack referring to the implementation of all layers of
that protocol on a computer. Historical examples include Novell Netware, AppleTalk, and
IBM SNA protocol stacks.
The hosts using dual stacks follow the same general process of using DNS to resolve a
name into an IP address. The DNS requests can return either an IPv4 address or an IPv6
address. The dual stack host can then choose to use IPv4 to communicate with an IPv4
host or IPv6 to communicate with an IPv6 host.
To support dual stack hosts, routers need to forward both IPv4 and IPv6 packets. To forward
IPv6 packets to the various destinations, the design engineer can use one of two
general approaches:
■ Native IPv6: Configure IPv6 on most or all routers, on most or all production interfaces,
making all routers use a dual stack.
■ IPv6 tunnels: Configure some routers with IPv6, others without IPv6, and tunnel
the IPv6 packets over the IPv4 network by encapsulating IPv6 packets inside IPv4
packets.
Configuring native IPv6 simply means that you configure IPv6 as discussed in detail in
Chapters 16 and 17, giving each interface one or more IPv6 addresses, enabling IPv6 routing
protocols, and so on. Assuming an IPv4 network already exists, the engineer could
build and execute an implementation plan to configure native IPv6 by enabling IPv6 on
the same interfaces as IPv4, configuring an IPv6 routing protocol, and the routers would
be ready to forward both types of packets.
A router that has been configured to forward both IPv4 and IPv6 is a dual stack router.
This works well, but it does require the implementation of IPv6 on all routers that might
one day receive an IPv6 packet that needs to be forwarded. Alternatively, using tunnels
may be more reasonable to support smaller pockets of IPv6 hosts, because tunnels require
fewer routers to be configured with IPv6 at all.
From a practical exam-preparation perspective for the CCNP ROUTE exam, the implementation
of dual stacks means that you need to configure IPv6 as detailed in Chapters 16
and 17, while leaving the existing IPv4 configuration in place. Therefore, this chapter does
not discuss the dual stack option’s configuration, instead relying on the detail in Chapters
16 and 17.
Tunneling
Tunneling refers to a process by which one router or host encapsulates the IPv6 packet inside
an IPv4 packet. The networking devices forward the IPv4 packet, ignoring the fact
that the packet’s payload is an IPv6 packet. Some later device or host decapsulates the
original IPv6 packet, forwarding it on to the final destination.
From a network design perspective, tunneling IPv6 over IPv4 results in fewer routers
needing any IPv6 configuration at all. As such, it allows a quicker migration from no IPv6
support to enough support to get IPv6 packets between two sites. Fewer routers need new
configuration, the smaller number of changes means less operational risk, and the end
hosts can still forward IPv6 traffic to each other.
This section begins by examining the concepts behind IPv6 tunneling. Then the text more
closely examines the two main categories of tunnels: point-to-point tunnels and multipoint
tunnels.
General Tunneling Concepts
To appreciate the configuration of the many types of IPv6 tunnels discussed in this chapter,
you need a solid understanding of the basics. Throughout this chapter, most examples
will be built on a small internetwork that represents a pre-existing IPv4-only Enterprise
Step 2. R1 encapsulates the IPv6 packet into an IPv4 packet, with R1’s IPv4 address as
source IPv4 address, and R3’s IPv4 address as the destination IPv4 address.
Step 3. R2 forwards the IPv4 packet to R3, with no knowledge of IPv6.
Step 4. R3 decapsulates the original IPv6 packet, forwarding the IPv6 packet on its
IPv6-enabled F0/1 interface, to server S1.
Although the figure and steps show the mechanics of the IPv6 tunnel, with such a small
sample network, it may be easier to just natively configure IPv6 on all three routers. However,
imagine that the Enterprise has 500 branches, hundreds of servers, and only 10
branches and two servers need IPv6 support. Additionally, the distribution and core layers
were rightfully designed with redundancy, so to support 10 branches, 30-40 routers may
need IPv6 support added to support IPv6 natively just to cover all possible cases of links
or routers failing. Alternatively, a tunnel could be created from each branch router to the
new IPv6 server subnet. In such cases, the use of tunneling can give you a much quicker
and easier start to the journey toward IPv6.
Point-to-Point IPv6 Tunnels
Some tunnels use a point-to-point concept, whereas others use a multipoint concept. For
point-to-point, two devices (and only two) sit at the ends of the tunnel, as did routers R1
and R3 in Figure 18-2. These point-to-point tunnels work like a virtual point-to-point serial
link. Figure 18-3 shows these concepts, plus a few other details, using the same underlying
network as shown in Figures 18-1 and 18-2.
To create the tunnel shown in the figure, each router configures a type of virtual interface
called a tunnel interface. The configuration associated with the tunnel interfaces tells IOS
the encapsulation details as previously shown in Figure 18-2. In the example of Figure 18-
3, R1 uses tunnel interface 0, and R3 uses tunnel interface 3. The tunnel interface numbers
can be any integer (up into the low billions), much like choosing loopback interface numbers,
with no advantage or disadvantage of using any particular interface number.
www.CareerCert.info
Chapter 18: IPv4 and IPv6 Coexistence 615
The two routers on the ends of the tunnel treat the tunnel interfaces like serial interfaces
on a point-to-point serial link, at least from a Layer 3 forwarding perspective. For example,
to support IPv6, the engineer would actually enable IPv6 on the tunnel interfaces with
the same commands shown in Chapter 16 and configure a routing protocol so that it runs
over the tunnel interfaces, as shown in Chapter 17. In this case, Figure 18-3 shows IPv6 addresses
assigned to the tunnel interfaces from within the 2013::/64 subnet.
When the configuration is complete, R1 and R2 exchange IPv6 routes and route IPv6
packets over the tunnel interface, which then triggers the encapsulation seen back in
Figure 18-2.
Point-to-Multipoint IPv6 Tunnels
Multipoint IPv6 tunnels allow the sending router–the “point” if you will–to use a single
tunnel interface to send packets to multiple remote routers. In some ways, a multipoint
tunnel works much like a LAN, or even more like a Non-Broadcast Multi-Access (NBMA)
network like Frame Relay. Multipoint tunnels still encapsulate the IPv6 packets, but they
need additional logic so that the sending router (the “point”) knows to which of several remote
routers (the “multipoints”) to send the encapsulating IPv4 packet.
The biggest leap in logic from point-to-point tunnels to point-to-multipoint tunnels is the
logic in how a router chooses which of the many remote tunnel endpoints should receive a
particular packet. Multipoint tunnels rely on either the IPv6 packet’s destination address,
or next-hop information in the IPv6 routing table, to determine which of the multiple remote
devices should receive a given packet. This decision happens dynamically on the
sending router. In some cases, this dynamic decision process can result in less configuration
when adding a new member of the multipoint group. In other cases, the dynamic decision
just happen to be how it works, but with no real advantage over point-to-point
tunnels.
In all types of multipoint IPv6 tunnels, the tunneling process starts when the router receives
an IPv6 packet and then tries to route that packet out the multipoint tunnel interface.
This action triggers the logic by which the source router determines how to forward
the IPv6 packet, inside an IPv4 packet, to the correct router. Figure 18-4 shows the general
idea of how the logic works. In this case, R1 acts as the point–the encapsulating router
that must dynamically decide to what IPv4 address to encapsulate and send the IPv6
packet. The figure shows one example of how R1 reacts when it receives an incoming IPv6
packet from the left.
Figure 18-4 illustrates the following steps:
Step 1. R1 receives an IPv6 packet in its LAN interface and decides that the packet
should be forwarded out its multipoint tunnel interface.
Step 2. R1 analyzes the destination IPv6 address (listed as Y in the figure), deriving the
tunnel endpoint’s IPv4 address (in this case, R9’s IPv4 address).
Step 3. R1 builds an IPv4 packet header, with its own address as source address and
using R9’s IPv4 address as the destination (as derived at Step 2).
Step 4. R1 puts the original IPv6 packet into the new IPv4 packet.
The more detailed discussion of tunneling in the rest of this chapter more fully develops
these pros and cons. For now, Table 18-2 lists the tunneling techniques discussed in more
detail inside this chapter, along with some notes that will make more sense as you work
through the chapter.
NAT Protocol Translation
The migration toward IPv6 typically begins with no IPv6 installed but with pervasive IPv4
support on hosts, routers, and other devices. Next, engineers start adding IPv6 support,
typically making hosts dual stacked. To support those hosts, network engineers either
configure IPv6 natively in the network, or use some form of tunneling. Eventually, some
devices migrate fully to IPv6. Those devices may be new devices that speak only to IPv6
servers. They may be traditional end-user clients that need to communicate only with
IPv6-capable servers.
In all these cases, when any pair of hosts communicate, they both support the same protocol,
whether IPv4 and IPv6. Because they send and receive either IPv4 packets, or both
send and receive IPv6 packets, the network simply needs to deliver those packets. The
packets may be encapsulated at some point in its journey, but if the packet left one host as
a particular version of IP, the packet received by the other host is the same version.
However, at some time during the migration toward IPv6, the network may need to support
the ability for an IPv4-only host to communicate with an IPv6-only host. The IPv6
www.CareerCert.info
618 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
PC1
R1 R3
2111::1/64
S1
IPv4 Enterprise
NAT-PT
10.2.2.2/24
www.example.com
1 2 3
Src = 2111::1
Dest = 2333::1
Src = 10.9.9.1
Dest = 10.2.2.2
Src = 10.2.2.2
Dest = 10.9.9.1
Src = 2333::1
Dest = 2111::1
NAT-PT
5 4
IPv6 Packet
IPv6 Packet
IPv4 Packet
IPv4 Packet
6
Figure 18-5 NAT-PT Translation on Router R1
migration and coexistence RFCs actually make allowance for such a feature, but to do so,
something between the two hosts must translate between the two different protocols
(IPv4 and IPv6). The solution is the Network Address Translation–Protocol Translation
(NAT-PT) feature.
NAT-PT gets the first part of its name from the old IPv4 Network Address Translation
(NAT) feature. The venerable IPv4 NAT translates the IP addresses inside an IPv4 header,
most often changing the Enterprise host’s private IPv4 address into a public, Internetroutable
IPv4 address. NAT-PT translates both the source and destination IP address,
translating between an IPv4 and IPv6 address for both. Not only does NAT-PT translate
IP addresses, but also it translates the entire IPv4 and IPv6 header, plus other headers as
well, such as TCP, UDP, and ICMP. Figure 18-5 shows an example of the results of NATPT
on Router R1, with PC1 sending a packet to Server S1, and S1 returning the packet.
Following the steps in the figure
Step 1. PC1, an IPv6-only host, sends an IPv6 packet to destination 2333::1, source
2111::1. And 2333::1 actually resides on R1, so the IPv6 network forwards the
packet to R1.
Step 2. R1, with NAT-PT configured, listens for packets sent to 2333::1. R1 converts
the IPv6 header and other packet headers to IPv4 standards.
Step 3. The IPv4 network forwards the packet to IPv4 host Server S1.
Step 4. S1 sends an IPv4 packet back to what it thinks of as PC1, source IPv4 address
10.2.2.2, destination IPv4 address 10.9.9.1. 10.9.9.1 actually resides on Router
R1, so the IPv4 network forwards the IPv4 packet to R1.
Step 5. R1, with NAT-PT configured, listens for IPv4 packets sent to 10.9.9.1. R1 converts
the IPv4 header and other packet headers to IPv6 standards.
www.CareerCert.info
Chapter 18: IPv4 and IPv6 Coexistence 619
Step 6. R1 forwards the IPv6 packet through the IPv6 side of the network to PC1, the
IPv6-onlt host.
For the process in Figure 18-5 to work, NAT-PT must also be heavily involved in DNS
flows as well. For example, before the flow in Figure 18-5, PC1 will have sent a DNSv6 request
to resolve the name of the server (www.example.com in this case). The router performing
NAT-PT must convert the requests between DNSv4 and DNSv6, keeping track of
the names and address bindings so that the NAT-PT translation process converts to the
correct addresses.
Note: NAT-PT, while interesting, has actually been moved to historic status (RFC 2766).
IOS still supports NAT-PT, and the ROUTE course’s e-learning component still includes
coverage of NAT-PT. However, NAT-PT will likely fade away over time. Protocols meant to
replace the function of NAT-PT are under development as of the writing of this book.
This completes the overview of IPv6 coexistence tools. The final two major sections of
this chapter examine the various IPv6 tunneling methods in depth.
No comments:
Post a Comment