1
00:00:00,000 --> 00:00:00,990

2
00:00:00,990 --> 00:00:04,455
[AUDIO LOGO]

3
00:00:04,455 --> 00:00:08,130

4
00:00:08,130 --> 00:00:12,530
So let's begin our discussion
by talking about dual stack.

5
00:00:12,530 --> 00:00:17,320
Now, this is simply the
concept of running both IPv4

6
00:00:17,320 --> 00:00:21,080
and IPv6 on the same device.

7
00:00:21,080 --> 00:00:24,940
Now, this skill, of course,
is mostly about tunneling.

8
00:00:24,940 --> 00:00:27,280
Now, tunneling, of
course, is meant

9
00:00:27,280 --> 00:00:33,710
to be a transition mechanism
as we move from IPv4 to IPv6.

10
00:00:33,710 --> 00:00:37,690
Ultimately, dual stack
is actually a really good

11
00:00:37,690 --> 00:00:39,370
migration strategy.

12
00:00:39,370 --> 00:00:41,950
But in some cases,
we can't do this,

13
00:00:41,950 --> 00:00:45,760
and therefore we
need to tunnel IPv6

14
00:00:45,760 --> 00:00:48,710
through an IPv4 environment.

15
00:00:48,710 --> 00:00:51,550
So why are we talking
about dual stack, then?

16
00:00:51,550 --> 00:00:55,120
Well, first, of course, it
can be a migration strategy.

17
00:00:55,120 --> 00:00:58,390
But second, even if
we're going to tunnel,

18
00:00:58,390 --> 00:01:03,460
the endpoints of the tunnel
still have to be dual stack.

19
00:01:03,460 --> 00:01:05,890
For one thing, they
have to be able to talk

20
00:01:05,890 --> 00:01:08,450
to the IPv6 networks
on each side

21
00:01:08,450 --> 00:01:10,160
that we're trying to connect.

22
00:01:10,160 --> 00:01:13,820
They also, of course, need
to be able to transport IPv6

23
00:01:13,820 --> 00:01:16,760
across the tunnel,
and they also need

24
00:01:16,760 --> 00:01:21,330
to be able to talk IPv4
to the underlying network.

25
00:01:21,330 --> 00:01:23,840
So that's why
understanding dual stack

26
00:01:23,840 --> 00:01:28,710
is important, even if our main
topic is going to be tunneling.

27
00:01:28,710 --> 00:01:30,860
So let's start off
here, making sure

28
00:01:30,860 --> 00:01:33,440
we have a good
grasp of dual stack

29
00:01:33,440 --> 00:01:35,460
and what it entails
on our devices.

30
00:01:35,460 --> 00:01:38,290

31
00:01:38,290 --> 00:01:40,560
So when we're talking
about dual stack,

32
00:01:40,560 --> 00:01:43,830
we're simply talking
about all of the nodes

33
00:01:43,830 --> 00:01:51,300
on the network running
both IPv4 and IPv6.

34
00:01:51,300 --> 00:01:55,360
Now, keep in mind, these are
completely separate protocols,

35
00:01:55,360 --> 00:01:58,020
so we would be talking
about supporting

36
00:01:58,020 --> 00:01:59,790
two different environments.

37
00:01:59,790 --> 00:02:02,160
That's the downside.

38
00:02:02,160 --> 00:02:07,500
But the upside here is, if
we're allowing both protocols

39
00:02:07,500 --> 00:02:13,030
to be supported, we can do this
for as long as this is needed.

40
00:02:13,030 --> 00:02:16,440
So we could support this for
three years, five years, 10

41
00:02:16,440 --> 00:02:17,110
years.

42
00:02:17,110 --> 00:02:20,640
There's no limit on how
long we can support this,

43
00:02:20,640 --> 00:02:24,490
but we do have to
support both protocols.

44
00:02:24,490 --> 00:02:27,540
So again, it's a good and a bad.

45
00:02:27,540 --> 00:02:30,780
Again, the downside
here being that we

46
00:02:30,780 --> 00:02:34,600
need to support both of
these networks concurrently.

47
00:02:34,600 --> 00:02:37,990
So we're actually
running two networks.

48
00:02:37,990 --> 00:02:40,570
From that perspective,
tunneling becomes

49
00:02:40,570 --> 00:02:44,530
more of an attractive option,
particularly for a service

50
00:02:44,530 --> 00:02:45,910
provider.

51
00:02:45,910 --> 00:02:49,750
Keep in mind that in most
cases, the service provider

52
00:02:49,750 --> 00:02:54,040
has no need or desire to
support both protocols.

53
00:02:54,040 --> 00:02:57,070
We just want to
support the customers

54
00:02:57,070 --> 00:03:02,050
and whether they want
to support IPv4 or IPv6.

55
00:03:02,050 --> 00:03:04,360
So at the end of
the day, tunneling

56
00:03:04,360 --> 00:03:07,540
might be a really good
solution because we only

57
00:03:07,540 --> 00:03:10,570
have to support one
protocol in our core, then,

58
00:03:10,570 --> 00:03:14,540
but we can support both
protocols for our customers.

59
00:03:14,540 --> 00:03:18,910
However, running our entire
network as dual stack

60
00:03:18,910 --> 00:03:22,730
is still an option, and it
actually works quite well.

61
00:03:22,730 --> 00:03:25,810
The downside, of course,
being that we're effectively

62
00:03:25,810 --> 00:03:28,280
supporting two
different networks.

63
00:03:28,280 --> 00:03:30,400
So all of that said,
if we are going

64
00:03:30,400 --> 00:03:33,700
to support two networks
in our environment,

65
00:03:33,700 --> 00:03:36,430
we do have several
protocols that

66
00:03:36,430 --> 00:03:40,720
allow us to have one
instance but still support

67
00:03:40,720 --> 00:03:42,400
both protocols.

68
00:03:42,400 --> 00:03:45,610
We can do this with IS-IS.

69
00:03:45,610 --> 00:03:49,690
We can do this with
OSPF version 3.

70
00:03:49,690 --> 00:03:54,580
This is assuming the code
on your router is current.

71
00:03:54,580 --> 00:03:58,960
I'm bringing this up because
originally, OSPF version 3

72
00:03:58,960 --> 00:04:01,600
only supported IPv6.

73
00:04:01,600 --> 00:04:05,050
The ability to
support both protocols

74
00:04:05,050 --> 00:04:08,120
was actually added
in the code later.

75
00:04:08,120 --> 00:04:10,000
So just be aware of that.

76
00:04:10,000 --> 00:04:12,160
As long as you're
running new enough code,

77
00:04:12,160 --> 00:04:14,680
then yes, we can
have one instance

78
00:04:14,680 --> 00:04:16,570
to support both protocols.

79
00:04:16,570 --> 00:04:19,779
And of course, we
can do this with BGP.

80
00:04:19,779 --> 00:04:23,710
We just end up calling
it multiprotocol BGP.

81
00:04:23,710 --> 00:04:25,960
And of course, it's
simply the ability

82
00:04:25,960 --> 00:04:28,450
to handle multiple
address families.

83
00:04:28,450 --> 00:04:30,850
The other thing to
consider with dual stack

84
00:04:30,850 --> 00:04:33,550
is the applications themselves.

85
00:04:33,550 --> 00:04:39,530
The applications will either
support IPv4, IPv6, or both.

86
00:04:39,530 --> 00:04:41,620
Now, this is really
assuming that we're

87
00:04:41,620 --> 00:04:44,260
doing dual stack through
the entire environment

88
00:04:44,260 --> 00:04:47,200
and shifting that
focus from doing

89
00:04:47,200 --> 00:04:51,350
tunneling, which is our main
discussion here in this skill.

90
00:04:51,350 --> 00:04:54,460
But if we're going to go with
pure dual stack the whole way

91
00:04:54,460 --> 00:04:57,520
through, some of the
newer applications

92
00:04:57,520 --> 00:05:00,310
actually support both
protocols, which is

93
00:05:00,310 --> 00:05:02,200
what we just discussed up here.

94
00:05:02,200 --> 00:05:07,090
If we prefer both, the
choice of which one to use

95
00:05:07,090 --> 00:05:11,020
is going to be up to
the application itself.

96
00:05:11,020 --> 00:05:16,890
IPv6 is generally
the preferred choice.

97
00:05:16,890 --> 00:05:22,470
The reason for this is as we
move our network towards IPv6,

98
00:05:22,470 --> 00:05:27,630
if all of the applications
kept preferring IPv4,

99
00:05:27,630 --> 00:05:29,790
well, it just makes
the transition harder

100
00:05:29,790 --> 00:05:32,580
because everything would
still be using IPv4

101
00:05:32,580 --> 00:05:34,450
since both are supported.

102
00:05:34,450 --> 00:05:38,430
But if things
prefer IPv6, they'll

103
00:05:38,430 --> 00:05:42,910
start migrating themselves
to our new IPv6 network.

104
00:05:42,910 --> 00:05:45,180
And then at some
point in the future,

105
00:05:45,180 --> 00:05:48,510
if we turn off IPv4
in the environment,

106
00:05:48,510 --> 00:05:51,420
everything will keep working
because they were already

107
00:05:51,420 --> 00:05:53,580
preferring IPv6.

108
00:05:53,580 --> 00:05:56,340
So this preference
of IPv6, we can

109
00:05:56,340 --> 00:05:58,600
see it referenced
in the RFC here,

110
00:05:58,600 --> 00:06:01,110
and this is really
just set this way

111
00:06:01,110 --> 00:06:03,850
to aid with that transition.

112
00:06:03,850 --> 00:06:09,400
This is also generally going to
require that our DNS or domain

113
00:06:09,400 --> 00:06:14,410
name system also
supports both protocols.

114
00:06:14,410 --> 00:06:19,180
IPv6 uses what we call
AAAA records for host

115
00:06:19,180 --> 00:06:21,940
to IPv6 address resolution.

116
00:06:21,940 --> 00:06:25,970
So of course, since most things
are referenced by host name,

117
00:06:25,970 --> 00:06:30,500
we're going to have to have a
DNS server that supports both.

118
00:06:30,500 --> 00:06:33,190
Now, as I've already
indicated, this

119
00:06:33,190 --> 00:06:38,950
is really the preferred
method to transition to IPv6.

120
00:06:38,950 --> 00:06:41,060
There's a couple
reasons for that.

121
00:06:41,060 --> 00:06:44,380
But possibly, the biggest
one is that this is really

122
00:06:44,380 --> 00:06:50,350
a time-tested method of
transitioning to new protocols.

123
00:06:50,350 --> 00:06:54,680
This has been done
for years in IT.

124
00:06:54,680 --> 00:06:57,080
If anybody out there has
been doing networking

125
00:06:57,080 --> 00:07:00,230
as long as I have,
you may remember back

126
00:07:00,230 --> 00:07:05,390
in the days of NetWare when
we had things like IPX/SPX.

127
00:07:05,390 --> 00:07:07,460
We had NetBEUI on our network.

128
00:07:07,460 --> 00:07:09,110
We had a couple of
different protocols

129
00:07:09,110 --> 00:07:10,430
that we were supporting.

130
00:07:10,430 --> 00:07:13,700
Of course, with the popularity
of the internet growing, which

131
00:07:13,700 --> 00:07:17,510
was, of course, TCP/IP,
specifically version 4,

132
00:07:17,510 --> 00:07:20,540
we started phasing out
those other protocols.

133
00:07:20,540 --> 00:07:24,500
And in most environments,
we were, for a long time,

134
00:07:24,500 --> 00:07:30,950
using either NetBEUI or IPX/SPX
to talk to internal file

135
00:07:30,950 --> 00:07:33,210
servers inside the company.

136
00:07:33,210 --> 00:07:35,210
So what we just
generically refer

137
00:07:35,210 --> 00:07:37,790
to as file and
print sharing, those

138
00:07:37,790 --> 00:07:40,040
would use our
internal protocols,

139
00:07:40,040 --> 00:07:42,050
but people going
out to the internet

140
00:07:42,050 --> 00:07:44,810
would, of course,
be using TCP/IP.

141
00:07:44,810 --> 00:07:46,820
So we were supporting
both environments

142
00:07:46,820 --> 00:07:51,320
for quite some time until
things like NetWare, which

143
00:07:51,320 --> 00:07:54,050
was a very popular
file and print server,

144
00:07:54,050 --> 00:07:56,520
finally we moved over
and started supporting

145
00:07:56,520 --> 00:07:58,890
a native TCP/IP stack.

146
00:07:58,890 --> 00:08:02,590
Once everything moved
over to TCP/IP, of course,

147
00:08:02,590 --> 00:08:05,400
there wasn't much of a
need to support dual stack.

148
00:08:05,400 --> 00:08:07,950
But the main point here,
whether you remember all of that

149
00:08:07,950 --> 00:08:11,400
or not, the main
thing is dual stack

150
00:08:11,400 --> 00:08:13,750
has been done for
a really long time.

151
00:08:13,750 --> 00:08:14,970
We know it works.

152
00:08:14,970 --> 00:08:16,410
There's really no
problem with it

153
00:08:16,410 --> 00:08:18,870
because it's
essentially supporting

154
00:08:18,870 --> 00:08:22,050
two different networks
that are simply coexisting

155
00:08:22,050 --> 00:08:24,120
on the same physical cable.

156
00:08:24,120 --> 00:08:26,050
That's really what's
going on here.

157
00:08:26,050 --> 00:08:28,290
So again, it's a
really good solution

158
00:08:28,290 --> 00:08:31,760
because again, we know
that it always works.

159
00:08:31,760 --> 00:08:36,169
Just keep in mind that no
matter which solution we choose,

160
00:08:36,169 --> 00:08:40,460
the end host or in the case
of our discussion here,

161
00:08:40,460 --> 00:08:45,170
usually, we're referring to the
end host as the tunnel endpoint

162
00:08:45,170 --> 00:08:48,410
because we're going to be,
again, focusing on tunnels.

163
00:08:48,410 --> 00:08:51,320
That tunnel endpoint
is still going

164
00:08:51,320 --> 00:08:53,090
to have to be dual stacked.

165
00:08:53,090 --> 00:08:55,920
And one final point
that's really important,

166
00:08:55,920 --> 00:08:58,550
this is not a
security-focused course.

167
00:08:58,550 --> 00:09:04,250
However, always remember that
whatever security policies you

168
00:09:04,250 --> 00:09:08,060
have in place for your
IPv4 network, well,

169
00:09:08,060 --> 00:09:10,040
you're going to need
to implement those

170
00:09:10,040 --> 00:09:13,640
on the IPv6 network
as well because you

171
00:09:13,640 --> 00:09:15,230
have to provide security.

172
00:09:15,230 --> 00:09:20,490
And remember, these are two
completely separate protocols.

173
00:09:20,490 --> 00:09:22,730
So whatever you
do for one, you're

174
00:09:22,730 --> 00:09:24,630
going to have to
do to the other.

175
00:09:24,630 --> 00:09:27,530
And again, that's that
drawback of having

176
00:09:27,530 --> 00:09:30,880
to support two environments.

177
00:09:30,880 --> 00:09:34,260
So in this video, we
focused in on running

178
00:09:34,260 --> 00:09:40,470
dual stack, where the devices
support both IPv4 and IPv6.

179
00:09:40,470 --> 00:09:45,600
Now, again, our main focus in
this skill is on tunneling.

180
00:09:45,600 --> 00:09:47,670
But this is still
important to understand

181
00:09:47,670 --> 00:09:50,610
because again, those
tunnel endpoints are going

182
00:09:50,610 --> 00:09:52,590
to have to be dual stacked.

183
00:09:52,590 --> 00:09:57,300
IPv6 for the tunnel
itself and IPv6

184
00:09:57,300 --> 00:10:02,460
to talk to the two end
networks or the IPv6 islands.

185
00:10:02,460 --> 00:10:05,730
Then, of course, we
need IPv4 to communicate

186
00:10:05,730 --> 00:10:09,210
to the underlay network
or the transport network

187
00:10:09,210 --> 00:10:11,380
that our tunnel is
going to go over.

188
00:10:11,380 --> 00:10:13,350
So that's why those
tunnel endpoints

189
00:10:13,350 --> 00:10:15,030
need to be dual stack.

190
00:10:15,030 --> 00:10:18,360
Ultimately, however, you
could build your network

191
00:10:18,360 --> 00:10:21,570
to completely support
dual stack end-to-end,

192
00:10:21,570 --> 00:10:23,940
and then we wouldn't
need any tunneling.

193
00:10:23,940 --> 00:10:26,040
However, that's
not going to happen

194
00:10:26,040 --> 00:10:27,960
in a lot of
environments, so we do

195
00:10:27,960 --> 00:10:29,610
need to talk about tunneling.

196
00:10:29,610 --> 00:10:31,750
We'll start off by
talking about some

197
00:10:31,750 --> 00:10:34,210
of our manual tunneling
options, and that's

198
00:10:34,210 --> 00:10:36,530
exactly what we get to do next.

199
00:10:36,530 --> 00:10:37,700
Until then.

200
00:10:37,700 --> 00:10:39,790
I hope this has been
informative for you,

201
00:10:39,790 --> 00:10:42,870
and I'd like to thank
you for viewing.

202
00:10:42,870 --> 00:10:46,000