Let's talk about a few of the methods available to
migrate the IPv4 networks to IPv6 networks.
Let's say you're looking for some options to help you with this feat.
There are many available,
but we're not going to get into the weeds of a lot of these.
Instead,
we're going to focus on one that we can't use with IPsec and one that
we can for an explanation as to why they're needed.
The first method I want to talk about is dual stack.
This is one of the most popular methods for transitioning
IPv4 to IPv6 in today's environments, but it has its downsides.
One of them is the lack of support for IPsec.
It's not really a support thing since we know both IPv4 and IPv6 support IPsec.
It's more of that reachability thing.
It's also about how the traffic is protected.
With this methodology, you essentially need that reachability from IPv6 to IPv6,
so we still would have the same issue as before.
We still need reachability.
That brings me to my next method, IPv6 over IPv4.
Using this method,
we're able to protect our IPv6 traffic without having the reachability concern.
We will essentially configure an IPv4 VPN tunnel,
then send our IPv6 traffic through it, protected by IPsec.
This allows us to have the best of both worlds,
that is until the rest of the world decides to migrate
and fix our reachability problem.
Let's hop into the lab and configure this really quickly on our
equipment so that we can see it in action.
We'll configure our IPv4 tunnel and send our IPv6 traffic over it.
Then, we'll take a look at the behavior and see how it all works.
If you're ready, I am too.
So we're going to do this first lab and show you how this works by creating an
IPsec tunnel using IPv4 and sending our IPv6 traffic over it.
To do this, I have this configuration right here that we'll look at.
In your configuration that's available in the course download files,
it's the correct configuration, but in this one shown,
I inserted a couple faults that are needed to explain some of the
functionality of this type of tunnel and operation.
With this configuration, we're not using DMVPN.
We're only using a virtual tunnel interface and connecting to the other end.
The crypto part of the configuration where we're setting up the SAs and
defining all the parameters is the same as in the other configurations
that we've done earlier in the course.
We're allowing it from any address and using IKEv1.
The differences for this come into play for the tunnel interface configuration.
Since we're not using DMVPN,
we don't really need the NHRP configuration in there.
From a very basic level,
all we need are the tunnel configurations that are shown here.
We have the tunnel mode, the source interface,
the destination, and the IPsec protection.
We also have the IPv6 address here.
Before we get into the configuration,
can you think of some of the reasons as to why this
won't work for an IPv6 over IPv4 tunnel?
We'll drill down into that during this demo after we paste
in the configurations and explain why.
Really quickly, before I copy-paste the configs into the routers,
I need to turn on the packet capture again.
While I'm copy-pasting these configs in here,
the router takes the commands with no issues.
Before doing this,
you'll need to load your IPv6 base configs that are
included in the exercise files as well.
Then, once you have your IPv6 connectivity,
go ahead and insert these configs into the devices.
You really don't need the IPv6 connectivity in this lab,
but you can use it to prepare for the next one as well.
After pasting the configs, we see that our ISAKMP is turned on,
but look at this!
The tunnel is showing an up-down status.
This means that for some reason connectivity can't be established.
It's definitely due to the errors that I threw into the configs on this one,
which brings me to the operation of the tunnel using this method.
Doing a show ip interface brief command,
we see that the interface G0/1 has an IPv4 address,
but Tunnel0 doesn't.
That is okay, as we only want our IPv6 traffic going through it.
Let's issue this show ipv6 interface brief command and see what we have.
Okay, so G0/1 has IPv6 addresses, and so does Tunnel0.
Now let's take a minute and think about how we want
the traffic flow to be for this one.
We want to establish a tunnel using IPv4 addresses and
routes and send the IPv6 traffic through it.
So the two interfaces connecting the tunnels are the G0/1
interfaces on both the HQ and site one routers.
These are the IPv4 addresses, not the IPv6 addresses.
But we want the IPv6 address to be the tunnel address so that we
know that's the protocol that's going to be sent through the
interface and encrypted by the IPsec tunnel.
So looking at this, we have the IPv6 address assigned to the interface,
which is good.
We designated our tunnel source as the G0/1 interface, also good.
The first fault is going to be right here, with the tunnel destination command.
Right now, as it is,
the tunnel is trying to be established by looking for
an IPv6 address on the other end.
This isn't going to work since there are no IPv6 routes to that destination.
We want it to be IPv4.
So let's change it and paste it in to see if that fixes our problem.
Looks like it's still down after fixing the tunnel destinations on both sides.
Can you think of what else may be wrong with this configuration?
We need all of the tunnel commands in the interface
configuration to be for IPv4 addresses, not IPv6.
Looking at the tunnel mode, this is wrong here.
We need to have this as an IPv4 tunnel, not IPv6.
So let me issue the command tunnel mode gre ip so we can fix the issue.
ISAKMP gets turned on, and look here!
The tunnel link comes up.
Moving over to the HQ router,
I'm pinging the Tunnel0 interface on the other side using its IPv6 address,
and it goes through!
This is great!
Now it's working.
Let's see some of the SA information here.
Notice how when I issue the show crypto ipsec sa ipv6 command nothing comes up?
This is due to the fact that this isn't an IPv6 tunnel.
It's only an IPv4 tunnel that we're sending IPv6 traffic over.
We can see this as a fact when we look at the IPsec SA
information using the standard IPv4 command.
The IPv6 packets were still encrypted, but the SA addresses are IPv4 addresses.
So we have the IPv4 tunnel established, not the IPv6.
I'm going to go ahead and stop the capture and pull it up in Wireshark
so that we can see how this affected our packets.
I'll save it as IPv6 Over IPv4 PCAP, and look here.
We see a whole bunch of IPv6 traffic,
including some ICMPv6 traffic that's used for neighbor discovery.
Scrolling down to see where the ISAKMP traffic starts, it's about right here.
Look at what mode it's in.
It's main mode.
So we have our three main mode exchanges followed by the quick mode.
In this first set of packets,
the ISAKMP SA is established just fine and completed the process.
But look, there was only one quick mode message.
That's due to the error in the configuration.
The routers bailed on the establishment.
If we look a little further down, here's the setup again for ISAKMP,
and it looks like quick mode was able to finish its process this time.
That means we got the configuration right,
and the IPsec SA is established successfully.
As you can see after these messages,
we have ESP packets for the rest of the conversations.
What's cool is look at the source and destination addresses.
We can't see the IPv6 addresses.
All we see are the G0/1 interface IPv4 addresses.
This how the IPv6 packets ride over the IPv4 tunnels.
Up next,
we're going to go through and establish IPv6-to-IPv6 tunnels and see how all of that works.