[AUDIO LOGO]
So we just saw 6to4 tunnels, and we saw that they have a little
bit of a downside, and that they have to use a reserved address
space, specifically that 2002::/16.
Well, in order to address that, we
got 6RD or Rapid Deployment tunnels,
which are essentially 6to4 tunnels, except they allow
us to specify which address ranges
we're using for the tunnels.
This allows us to use any IPv6 address space, which
means that once we assign this to a customer,
that customer can have that address
space essentially permanently.
They could even use their own address space.
They would, of course, have to notify us what that is.
We have to route it anyway, but we could also
use that for the tunneling as well.
So the big advantage here is that we
can use any address space.
Let's go ahead and jump in and take a look
at some more detail.
So 6RD or Rapid Deployment tunnels
were created to overcome those limitations
of the 6to4 tunnels, specifically
using that required prefix.
Now, they do in fact still use the same encapsulation
as 6to4 tunnels.
And I know we didn't exactly mention this before,
but this is using IP protocol 41.
So again, these are essentially 6in4 or 6to4.
They're all the same encapsulation.
But again, the big difference here
is these do not require the use of any specific IPv6 prefix.
We as the provider can specify any prefix
we want for these 6RD tunnels.
That's the big advantage because if, at some point,
we as the provider switch to native IPv6 support,
the customer can just keep right on using that assigned
IPv6 prefix.
They don't have to change anything on their network.
We just stop tunneling it and just start forwarding
the exact same prefixes over native IPv6.
So as far as moving forward in the long-term goal of someday
fading out IPv4, this is going to be a better solution.
Now, just like in 6to4 tunnels, each site
is still going to be given a prefix,
and it is still going to be based on its IPv4 endpoint
address, and this is all still in conjunction
with that assigned IPv6 prefix.
The main difference, of course, is that we're
assigning the prefix.
So as an example, maybe we assign the prefix
2001:db8::/32.
Now, just as a quick note, we would never
actually assign this address.
This address is used in a lot of lab environments and research
environments.
It's actually reserved for that purpose.
So I'm just using it here as an example because this
is a training course.
However, you would use a legitimate IPv6 prefix
to give to the customer.
Then we take the IPv4 endpoint address.
In this case, I'm just giving an example of 221.56.78.34,
and we convert that.
The way we convert it, we put our given prefix
at the beginning.
So the 2001:db8.
And then just like we did before, we're
going to take our 221, convert that to the dd.
We'll take our 56, convert that to the 38.
We'll take our 78, convert that to the 4e.
And we'll take our 34 and convert that to the 22.
Again, just converting decimal to hex.
So we convert the IP portion the exact same way.
However, interesting thing we can do here.
Rather than taking up the entire address space
with those IPv4 bits, we can actually
limit the number of those bits that
are needed if there is a prefix and a suffix in common.
In other words, if all of the tunnel endpoints
have the same beginning numbers and the same ending number,
that'll make a little more sense when we look at our example
here in just a moment.
And just one last little statement here before we
look at that example.
Because this does use those provider-assigned address
spaces rather than the reserved addresses,
this really is the recommended method
for deploying these quickly and being able to move forward
in the future when we get rid of tunnels,
and we just go directly to IPv6 support only.
So let's go ahead and take a look at our example.
So for this example, we are going
to assume that all of the tunnel endpoints
do have a prefix and a suffix in common.
So as far as the prefix, these are all going to start 202.20.
So these all have the first 16 bits in common,
and they're all ending with a dot 1.
So they have the last 8 bits in common.
The part that's, of course, different
is the subnet here in the middle, the third octet where
we're going 10, 20, 30, 40 and so on.
So let's take a look at what this would look like,
and we're going to be focusing on what the configuration would
be for our first example here, the 202.20.10.1.
So first, we just create a tunnel,
like we've been doing for all of our other examples.
But now, take a look at that IPv6 address.
Notice that it's 2001:db8, which is our given prefix.
We can see our given prefix is actually defined down here
a little further, where we say tunnel 6rd prefix
2001:db8::/32.
Then what we do is back to the IPv6 address,
the next portion is the unique portion of the IPv4 address.
So notice that that's a 10.
Then we simply put on a host portion because, of course,
we need that for the tunnel itself.
So we're just saying ::1.
Now, the tunnel source is just our loopback0.
We, of course, always have to specify a source.
Notice the tunnel mode.
It is still ipv6ip, but this time, it's
specifying that it's 6rd.
Of course, we already talked about the prefix.
Now, let's talk about the prefix length and suffix length.
Notice for the IPv4, we're telling it
that the prefix or the beginning bits, the first 16 bits
are in common.
And for the suffix, the last 8 bits are in common.
So this leaves only the 8 bits in the third octet
that have to be specified in the IPv6 address.
So that's how we build this for the 6RD addresses using really
whatever prefix we want for the customer.
So in this video, we took a look at 6RD tunnels,
which are essentially 6in4 tunnels, again,
automatically configured using the prefixes
that we, as the service provider,
get to provide to the customers.
So it's not a given address space
that would, at some point, need to be retired.
This way, when we move to native IPv6 at some point,
this customer can keep right on using this prefix,
and we just forward it without tunneling it once everything
has IPv6 support.
So that pretty much wraps up all of the direct tunnels
that we need to talk about.
However, we do have something else we need to discuss,
which is tunneling, and that it's being encapsulated,
but we need to discuss IPv6 support over MPLS.
And of course, there's a couple ways to do that.
That's exactly what you and I get to talk about next.
Until then.
I hope this has been informative for you,
and I'd like to thank you for viewing.