1
00:00:00,000 --> 00:00:00,942

2
00:00:00,942 --> 00:00:04,239
[AUDIO LOGO]

3
00:00:04,239 --> 00:00:08,680

4
00:00:08,680 --> 00:00:13,420
So we just saw 6to4 tunnels, and
we saw that they have a little

5
00:00:13,420 --> 00:00:18,250
bit of a downside, and that they
have to use a reserved address

6
00:00:18,250 --> 00:00:23,470
space, specifically
that 2002::/16.

7
00:00:23,470 --> 00:00:25,990
Well, in order to
address that, we

8
00:00:25,990 --> 00:00:30,050
got 6RD or Rapid
Deployment tunnels,

9
00:00:30,050 --> 00:00:35,200
which are essentially 6to4
tunnels, except they allow

10
00:00:35,200 --> 00:00:39,130
us to specify which
address ranges

11
00:00:39,130 --> 00:00:41,410
we're using for the tunnels.

12
00:00:41,410 --> 00:00:46,300
This allows us to use any
IPv6 address space, which

13
00:00:46,300 --> 00:00:49,750
means that once we assign
this to a customer,

14
00:00:49,750 --> 00:00:51,700
that customer can
have that address

15
00:00:51,700 --> 00:00:54,130
space essentially permanently.

16
00:00:54,130 --> 00:00:56,980
They could even use
their own address space.

17
00:00:56,980 --> 00:00:59,830
They would, of course, have
to notify us what that is.

18
00:00:59,830 --> 00:01:02,920
We have to route it
anyway, but we could also

19
00:01:02,920 --> 00:01:05,060
use that for the
tunneling as well.

20
00:01:05,060 --> 00:01:07,120
So the big advantage
here is that we

21
00:01:07,120 --> 00:01:09,570
can use any address space.

22
00:01:09,570 --> 00:01:11,810
Let's go ahead and
jump in and take a look

23
00:01:11,810 --> 00:01:14,940
at some more detail.

24
00:01:14,940 --> 00:01:19,280
So 6RD or Rapid
Deployment tunnels

25
00:01:19,280 --> 00:01:23,960
were created to overcome
those limitations

26
00:01:23,960 --> 00:01:27,590
of the 6to4 tunnels,
specifically

27
00:01:27,590 --> 00:01:30,060
using that required prefix.

28
00:01:30,060 --> 00:01:34,220
Now, they do in fact still
use the same encapsulation

29
00:01:34,220 --> 00:01:36,140
as 6to4 tunnels.

30
00:01:36,140 --> 00:01:39,000
And I know we didn't
exactly mention this before,

31
00:01:39,000 --> 00:01:42,740
but this is using
IP protocol 41.

32
00:01:42,740 --> 00:01:46,910
So again, these are
essentially 6in4 or 6to4.

33
00:01:46,910 --> 00:01:48,800
They're all the
same encapsulation.

34
00:01:48,800 --> 00:01:50,720
But again, the big
difference here

35
00:01:50,720 --> 00:01:58,340
is these do not require the use
of any specific IPv6 prefix.

36
00:01:58,340 --> 00:02:02,330
We as the provider
can specify any prefix

37
00:02:02,330 --> 00:02:05,700
we want for these 6RD tunnels.

38
00:02:05,700 --> 00:02:09,630
That's the big advantage
because if, at some point,

39
00:02:09,630 --> 00:02:14,610
we as the provider switch
to native IPv6 support,

40
00:02:14,610 --> 00:02:19,710
the customer can just keep
right on using that assigned

41
00:02:19,710 --> 00:02:21,600
IPv6 prefix.

42
00:02:21,600 --> 00:02:24,570
They don't have to change
anything on their network.

43
00:02:24,570 --> 00:02:27,930
We just stop tunneling it
and just start forwarding

44
00:02:27,930 --> 00:02:32,310
the exact same prefixes
over native IPv6.

45
00:02:32,310 --> 00:02:36,660
So as far as moving forward in
the long-term goal of someday

46
00:02:36,660 --> 00:02:41,140
fading out IPv4, this is
going to be a better solution.

47
00:02:41,140 --> 00:02:45,840
Now, just like in 6to4
tunnels, each site

48
00:02:45,840 --> 00:02:48,210
is still going to
be given a prefix,

49
00:02:48,210 --> 00:02:52,020
and it is still going to be
based on its IPv4 endpoint

50
00:02:52,020 --> 00:02:55,200
address, and this is
all still in conjunction

51
00:02:55,200 --> 00:02:58,380
with that assigned IPv6 prefix.

52
00:02:58,380 --> 00:03:00,660
The main difference, of
course, is that we're

53
00:03:00,660 --> 00:03:02,290
assigning the prefix.

54
00:03:02,290 --> 00:03:06,120
So as an example, maybe
we assign the prefix

55
00:03:06,120 --> 00:03:11,160
2001:db8::/32.

56
00:03:11,160 --> 00:03:13,680
Now, just as a quick
note, we would never

57
00:03:13,680 --> 00:03:15,490
actually assign this address.

58
00:03:15,490 --> 00:03:20,310
This address is used in a lot
of lab environments and research

59
00:03:20,310 --> 00:03:21,210
environments.

60
00:03:21,210 --> 00:03:23,980
It's actually reserved
for that purpose.

61
00:03:23,980 --> 00:03:26,760
So I'm just using it here
as an example because this

62
00:03:26,760 --> 00:03:28,170
is a training course.

63
00:03:28,170 --> 00:03:31,920
However, you would use
a legitimate IPv6 prefix

64
00:03:31,920 --> 00:03:33,640
to give to the customer.

65
00:03:33,640 --> 00:03:37,740
Then we take the IPv4
endpoint address.

66
00:03:37,740 --> 00:03:43,410
In this case, I'm just giving
an example of 221.56.78.34,

67
00:03:43,410 --> 00:03:45,390
and we convert that.

68
00:03:45,390 --> 00:03:48,960
The way we convert it,
we put our given prefix

69
00:03:48,960 --> 00:03:49,900
at the beginning.

70
00:03:49,900 --> 00:03:52,350
So the 2001:db8.

71
00:03:52,350 --> 00:03:54,840
And then just like
we did before, we're

72
00:03:54,840 --> 00:03:59,766
going to take our 221,
convert that to the dd.

73
00:03:59,766 --> 00:04:04,230
We'll take our 56,
convert that to the 38.

74
00:04:04,230 --> 00:04:08,460
We'll take our 78,
convert that to the 4e.

75
00:04:08,460 --> 00:04:13,050
And we'll take our 34 and
convert that to the 22.

76
00:04:13,050 --> 00:04:16,180
Again, just converting
decimal to hex.

77
00:04:16,180 --> 00:04:19,360
So we convert the IP
portion the exact same way.

78
00:04:19,360 --> 00:04:22,410
However, interesting
thing we can do here.

79
00:04:22,410 --> 00:04:26,100
Rather than taking up
the entire address space

80
00:04:26,100 --> 00:04:30,360
with those IPv4
bits, we can actually

81
00:04:30,360 --> 00:04:32,580
limit the number
of those bits that

82
00:04:32,580 --> 00:04:39,340
are needed if there is a
prefix and a suffix in common.

83
00:04:39,340 --> 00:04:42,870
In other words, if all
of the tunnel endpoints

84
00:04:42,870 --> 00:04:47,460
have the same beginning numbers
and the same ending number,

85
00:04:47,460 --> 00:04:50,100
that'll make a little more sense
when we look at our example

86
00:04:50,100 --> 00:04:52,150
here in just a moment.

87
00:04:52,150 --> 00:04:54,240
And just one last little
statement here before we

88
00:04:54,240 --> 00:04:55,680
look at that example.

89
00:04:55,680 --> 00:04:59,430
Because this does use those
provider-assigned address

90
00:04:59,430 --> 00:05:03,450
spaces rather than the
reserved addresses,

91
00:05:03,450 --> 00:05:06,120
this really is the
recommended method

92
00:05:06,120 --> 00:05:09,990
for deploying these quickly
and being able to move forward

93
00:05:09,990 --> 00:05:12,180
in the future when we
get rid of tunnels,

94
00:05:12,180 --> 00:05:16,390
and we just go directly
to IPv6 support only.

95
00:05:16,390 --> 00:05:19,650
So let's go ahead and take
a look at our example.

96
00:05:19,650 --> 00:05:22,190
So for this example,
we are going

97
00:05:22,190 --> 00:05:25,940
to assume that all of
the tunnel endpoints

98
00:05:25,940 --> 00:05:30,030
do have a prefix and
a suffix in common.

99
00:05:30,030 --> 00:05:35,930
So as far as the prefix, these
are all going to start 202.20.

100
00:05:35,930 --> 00:05:39,470
So these all have the
first 16 bits in common,

101
00:05:39,470 --> 00:05:43,580
and they're all
ending with a dot 1.

102
00:05:43,580 --> 00:05:47,570
So they have the last
8 bits in common.

103
00:05:47,570 --> 00:05:49,670
The part that's, of
course, different

104
00:05:49,670 --> 00:05:53,960
is the subnet here in the
middle, the third octet where

105
00:05:53,960 --> 00:05:57,060
we're going 10, 20,
30, 40 and so on.

106
00:05:57,060 --> 00:05:59,360
So let's take a look at
what this would look like,

107
00:05:59,360 --> 00:06:01,943
and we're going to be focusing
on what the configuration would

108
00:06:01,943 --> 00:06:08,120
be for our first example
here, the 202.20.10.1.

109
00:06:08,120 --> 00:06:10,130
So first, we just
create a tunnel,

110
00:06:10,130 --> 00:06:12,800
like we've been doing for
all of our other examples.

111
00:06:12,800 --> 00:06:16,680
But now, take a look
at that IPv6 address.

112
00:06:16,680 --> 00:06:21,720
Notice that it's 2001:db8,
which is our given prefix.

113
00:06:21,720 --> 00:06:25,620
We can see our given prefix
is actually defined down here

114
00:06:25,620 --> 00:06:29,640
a little further, where
we say tunnel 6rd prefix

115
00:06:29,640 --> 00:06:34,080
2001:db8::/32.

116
00:06:34,080 --> 00:06:38,400
Then what we do is back
to the IPv6 address,

117
00:06:38,400 --> 00:06:45,220
the next portion is the unique
portion of the IPv4 address.

118
00:06:45,220 --> 00:06:47,340
So notice that that's a 10.

119
00:06:47,340 --> 00:06:50,230
Then we simply put on a host
portion because, of course,

120
00:06:50,230 --> 00:06:52,300
we need that for
the tunnel itself.

121
00:06:52,300 --> 00:06:54,450
So we're just saying ::1.

122
00:06:54,450 --> 00:06:57,210
Now, the tunnel source
is just our loopback0.

123
00:06:57,210 --> 00:06:59,970
We, of course, always
have to specify a source.

124
00:06:59,970 --> 00:07:01,900
Notice the tunnel mode.

125
00:07:01,900 --> 00:07:06,630
It is still ipv6ip,
but this time, it's

126
00:07:06,630 --> 00:07:10,050
specifying that it's 6rd.

127
00:07:10,050 --> 00:07:12,640
Of course, we already
talked about the prefix.

128
00:07:12,640 --> 00:07:16,780
Now, let's talk about the
prefix length and suffix length.

129
00:07:16,780 --> 00:07:20,760
Notice for the IPv4,
we're telling it

130
00:07:20,760 --> 00:07:25,110
that the prefix or the beginning
bits, the first 16 bits

131
00:07:25,110 --> 00:07:26,250
are in common.

132
00:07:26,250 --> 00:07:30,580
And for the suffix, the
last 8 bits are in common.

133
00:07:30,580 --> 00:07:34,560
So this leaves only the
8 bits in the third octet

134
00:07:34,560 --> 00:07:38,470
that have to be specified
in the IPv6 address.

135
00:07:38,470 --> 00:07:44,550
So that's how we build this for
the 6RD addresses using really

136
00:07:44,550 --> 00:07:48,920
whatever prefix we
want for the customer.

137
00:07:48,920 --> 00:07:54,410
So in this video, we took
a look at 6RD tunnels,

138
00:07:54,410 --> 00:07:59,080
which are essentially
6in4 tunnels, again,

139
00:07:59,080 --> 00:08:03,040
automatically configured
using the prefixes

140
00:08:03,040 --> 00:08:05,080
that we, as the
service provider,

141
00:08:05,080 --> 00:08:07,250
get to provide to the customers.

142
00:08:07,250 --> 00:08:09,910
So it's not a
given address space

143
00:08:09,910 --> 00:08:12,400
that would, at some
point, need to be retired.

144
00:08:12,400 --> 00:08:16,780
This way, when we move to
native IPv6 at some point,

145
00:08:16,780 --> 00:08:19,990
this customer can keep
right on using this prefix,

146
00:08:19,990 --> 00:08:24,370
and we just forward it without
tunneling it once everything

147
00:08:24,370 --> 00:08:26,620
has IPv6 support.

148
00:08:26,620 --> 00:08:30,430
So that pretty much wraps
up all of the direct tunnels

149
00:08:30,430 --> 00:08:32,030
that we need to talk about.

150
00:08:32,030 --> 00:08:35,360
However, we do have something
else we need to discuss,

151
00:08:35,360 --> 00:08:39,340
which is tunneling, and that
it's being encapsulated,

152
00:08:39,340 --> 00:08:44,470
but we need to discuss
IPv6 support over MPLS.

153
00:08:44,470 --> 00:08:47,020
And of course, there's a
couple ways to do that.

154
00:08:47,020 --> 00:08:50,640
That's exactly what you and
I get to talk about next.

155
00:08:50,640 --> 00:08:51,780
Until then.

156
00:08:51,780 --> 00:08:53,900
I hope this has been
informative for you,

157
00:08:53,900 --> 00:08:57,040
and I'd like to thank
you for viewing.

158
00:08:57,040 --> 00:09:01,000