[AUDIO LOGO]
So let's begin our discussion by talking about dual stack.
Now, this is simply the concept of running both IPv4
and IPv6 on the same device.
Now, this skill, of course, is mostly about tunneling.
Now, tunneling, of course, is meant
to be a transition mechanism as we move from IPv4 to IPv6.
Ultimately, dual stack is actually a really good
migration strategy.
But in some cases, we can't do this,
and therefore we need to tunnel IPv6
through an IPv4 environment.
So why are we talking about dual stack, then?
Well, first, of course, it can be a migration strategy.
But second, even if we're going to tunnel,
the endpoints of the tunnel still have to be dual stack.
For one thing, they have to be able to talk
to the IPv6 networks on each side
that we're trying to connect.
They also, of course, need to be able to transport IPv6
across the tunnel, and they also need
to be able to talk IPv4 to the underlying network.
So that's why understanding dual stack
is important, even if our main topic is going to be tunneling.
So let's start off here, making sure
we have a good grasp of dual stack
and what it entails on our devices.
So when we're talking about dual stack,
we're simply talking about all of the nodes
on the network running both IPv4 and IPv6.
Now, keep in mind, these are completely separate protocols,
so we would be talking about supporting
two different environments.
That's the downside.
But the upside here is, if we're allowing both protocols
to be supported, we can do this for as long as this is needed.
So we could support this for three years, five years, 10
years.
There's no limit on how long we can support this,
but we do have to support both protocols.
So again, it's a good and a bad.
Again, the downside here being that we
need to support both of these networks concurrently.
So we're actually running two networks.
From that perspective, tunneling becomes
more of an attractive option, particularly for a service
provider.
Keep in mind that in most cases, the service provider
has no need or desire to support both protocols.
We just want to support the customers
and whether they want to support IPv4 or IPv6.
So at the end of the day, tunneling
might be a really good solution because we only
have to support one protocol in our core, then,
but we can support both protocols for our customers.
However, running our entire network as dual stack
is still an option, and it actually works quite well.
The downside, of course, being that we're effectively
supporting two different networks.
So all of that said, if we are going
to support two networks in our environment,
we do have several protocols that
allow us to have one instance but still support
both protocols.
We can do this with IS-IS.
We can do this with OSPF version 3.
This is assuming the code on your router is current.
I'm bringing this up because originally, OSPF version 3
only supported IPv6.
The ability to support both protocols
was actually added in the code later.
So just be aware of that.
As long as you're running new enough code,
then yes, we can have one instance
to support both protocols.
And of course, we can do this with BGP.
We just end up calling it multiprotocol BGP.
And of course, it's simply the ability
to handle multiple address families.
The other thing to consider with dual stack
is the applications themselves.
The applications will either support IPv4, IPv6, or both.
Now, this is really assuming that we're
doing dual stack through the entire environment
and shifting that focus from doing
tunneling, which is our main discussion here in this skill.
But if we're going to go with pure dual stack the whole way
through, some of the newer applications
actually support both protocols, which is
what we just discussed up here.
If we prefer both, the choice of which one to use
is going to be up to the application itself.
IPv6 is generally the preferred choice.
The reason for this is as we move our network towards IPv6,
if all of the applications kept preferring IPv4,
well, it just makes the transition harder
because everything would still be using IPv4
since both are supported.
But if things prefer IPv6, they'll
start migrating themselves to our new IPv6 network.
And then at some point in the future,
if we turn off IPv4 in the environment,
everything will keep working because they were already
preferring IPv6.
So this preference of IPv6, we can
see it referenced in the RFC here,
and this is really just set this way
to aid with that transition.
This is also generally going to require that our DNS or domain
name system also supports both protocols.
IPv6 uses what we call AAAA records for host
to IPv6 address resolution.
So of course, since most things are referenced by host name,
we're going to have to have a DNS server that supports both.
Now, as I've already indicated, this
is really the preferred method to transition to IPv6.
There's a couple reasons for that.
But possibly, the biggest one is that this is really
a time-tested method of transitioning to new protocols.
This has been done for years in IT.
If anybody out there has been doing networking
as long as I have, you may remember back
in the days of NetWare when we had things like IPX/SPX.
We had NetBEUI on our network.
We had a couple of different protocols
that we were supporting.
Of course, with the popularity of the internet growing, which
was, of course, TCP/IP, specifically version 4,
we started phasing out those other protocols.
And in most environments, we were, for a long time,
using either NetBEUI or IPX/SPX to talk to internal file
servers inside the company.
So what we just generically refer
to as file and print sharing, those
would use our internal protocols,
but people going out to the internet
would, of course, be using TCP/IP.
So we were supporting both environments
for quite some time until things like NetWare, which
was a very popular file and print server,
finally we moved over and started supporting
a native TCP/IP stack.
Once everything moved over to TCP/IP, of course,
there wasn't much of a need to support dual stack.
But the main point here, whether you remember all of that
or not, the main thing is dual stack
has been done for a really long time.
We know it works.
There's really no problem with it
because it's essentially supporting
two different networks that are simply coexisting
on the same physical cable.
That's really what's going on here.
So again, it's a really good solution
because again, we know that it always works.
Just keep in mind that no matter which solution we choose,
the end host or in the case of our discussion here,
usually, we're referring to the end host as the tunnel endpoint
because we're going to be, again, focusing on tunnels.
That tunnel endpoint is still going
to have to be dual stacked.
And one final point that's really important,
this is not a security-focused course.
However, always remember that whatever security policies you
have in place for your IPv4 network, well,
you're going to need to implement those
on the IPv6 network as well because you
have to provide security.
And remember, these are two completely separate protocols.
So whatever you do for one, you're
going to have to do to the other.
And again, that's that drawback of having
to support two environments.
So in this video, we focused in on running
dual stack, where the devices support both IPv4 and IPv6.
Now, again, our main focus in this skill is on tunneling.
But this is still important to understand
because again, those tunnel endpoints are going
to have to be dual stacked.
IPv6 for the tunnel itself and IPv6
to talk to the two end networks or the IPv6 islands.
Then, of course, we need IPv4 to communicate
to the underlay network or the transport network
that our tunnel is going to go over.
So that's why those tunnel endpoints
need to be dual stack.
Ultimately, however, you could build your network
to completely support dual stack end-to-end,
and then we wouldn't need any tunneling.
However, that's not going to happen
in a lot of environments, so we do
need to talk about tunneling.
We'll start off by talking about some
of our manual tunneling options, and that's
exactly what we get to do next.
Until then.
I hope this has been informative for you,
and I'd like to thank you for viewing.