1
00:00:02,001 --> 00:00:08,600
[music]

2
00:00:08,600 --> 00:00:12,500
First the other thing we pick
up with IPv6 is we get a

3
00:00:12,500 --> 00:00:13,400
simplified header.

4
00:00:13,700 --> 00:00:17,300
Now don't misunderstand and before
I even bring up the image here

5
00:00:17,600 --> 00:00:22,700
I want to make sure we're clear on
one very important word here and

6
00:00:22,700 --> 00:00:24,500
it's not IPv6 and it's not header.

7
00:00:24,500 --> 00:00:27,524
So I think you can figure
out which one it is.

8
00:00:27,824 --> 00:00:34,424
It's simplified header, not
shorter nobody ever said shorter.

9
00:00:34,424 --> 00:00:42,824
You're not going to put two 128
bit addresses into an IPv6 header

10
00:00:43,124 --> 00:00:47,024
where an IPv4 header only
has 32 bit addresses.

11
00:00:47,024 --> 00:00:51,924
That's not going to happen without
making the header larger.

12
00:00:52,224 --> 00:00:52,825
So here it is.

13
00:00:52,825 --> 00:00:54,924
The header is definitely larger.

14
00:00:54,924 --> 00:00:59,724
We have the IPv4 header on the
left, the IPv6 header on the right

15
00:00:59,724 --> 00:01:05,124
and, as you can see, there's a
little legend down there telling us

16
00:01:05,124 --> 00:01:10,224
which fields have been kept and
if you notice there's only three

17
00:01:10,524 --> 00:01:15,024
fields that have been kept unchanged
from IPv4 to IPv6 and that's

18
00:01:15,024 --> 00:01:19,224
the version. Now, notice it
says the field was kept,

19
00:01:19,524 --> 00:01:26,424
even just the name but not
necessarily the contents.

20
00:01:26,724 --> 00:01:31,824
In other words version is of course
going to flip from 4 to 6 so

21
00:01:32,124 --> 00:01:35,724
it doesn't have the same
contents as far as the value.

22
00:01:35,724 --> 00:01:39,624
I mean, contents being version,
yes, but it's going to switch the

23
00:01:39,624 --> 00:01:40,224
version number.

24
00:01:40,524 --> 00:01:46,224
If you look at the IPv4, the next
header is the IHL which is the

25
00:01:46,224 --> 00:01:48,024
IP Header Length.

26
00:01:48,024 --> 00:01:52,224
Now the reason for the header length is,

27
00:01:52,224 --> 00:01:54,924
if you look down and we're going to
have to jump ahead just a little

28
00:01:54,924 --> 00:01:58,224
bit here to the bottom of
the IPv4 header there,

29
00:01:58,524 --> 00:02:01,524
where it says option and padding.

30
00:02:01,524 --> 00:02:03,624
Well, here's the problem.

31
00:02:03,924 --> 00:02:09,924
The IPv4 header had available options
in it that you could set and

32
00:02:09,924 --> 00:02:10,882
not too many people use.

33
00:02:10,882 --> 00:02:12,382
We're not going to get into all that.

34
00:02:12,382 --> 00:02:16,582
This is not an IPv4 class but there
were available options and here

35
00:02:16,582 --> 00:02:17,482
became the question.

36
00:02:17,482 --> 00:02:19,282
Are there options?

37
00:02:19,282 --> 00:02:20,782
Aren't there options?

38
00:02:20,782 --> 00:02:22,582
There's a reason we call them options.

39
00:02:22,582 --> 00:02:24,082
It's because they're optional.

40
00:02:24,082 --> 00:02:30,282
So, how is the router who's
just receiving 10110110101

41
00:02:30,282 --> 00:02:36,282
a stream of binary ones and zeros,
how is he supposed to know are

42
00:02:36,282 --> 00:02:37,482
there options or aren't there?

43
00:02:37,482 --> 00:02:41,782
What am I expecting to see
after the destination address.

44
00:02:41,782 --> 00:02:48,682
Should it be the start of the TCP
or UDP header or are there options

45
00:02:48,982 --> 00:02:51,382
there? What's there I don't know?

46
00:02:51,382 --> 00:02:55,582
That's what the IP header
length was used for,

47
00:02:55,882 --> 00:02:59,482
was to indicate whether options
were there and let the receiving

48
00:02:59,482 --> 00:03:03,982
device know do I need to look for options?

49
00:03:04,282 --> 00:03:05,482
How long is this header?

50
00:03:05,482 --> 00:03:08,782
And, I know I'm making a
big deal out of this,

51
00:03:09,082 --> 00:03:10,282
but I want you to understand something.

52
00:03:10,582 --> 00:03:16,282
This is a big part of what we mean
by a simplified header by not

53
00:03:16,582 --> 00:03:17,482
putting the options.

54
00:03:17,482 --> 00:03:18,982
Look at the IPv6 header.

55
00:03:18,982 --> 00:03:21,382
Also, the fact that these are all in red,

56
00:03:21,682 --> 00:03:25,582
which means that they were
killed when we go to IPv6.

57
00:03:25,582 --> 00:03:28,582
IPv6, they decided to
handle this differently.

58
00:03:28,882 --> 00:03:30,982
They said, okay, you know what?

59
00:03:30,982 --> 00:03:34,582
The IPv6 header is going
to be a fixed length.

60
00:03:34,582 --> 00:03:37,882
What you see on the right is not variable,

61
00:03:37,882 --> 00:03:42,182
okay? Yes, it becomes 40
bytes instead of 20 bytes,

62
00:03:42,182 --> 00:03:47,382
okay? But the fact of the matter
is, and when I say 20 bytes for

63
00:03:47,382 --> 00:03:50,682
the IPv4 header, I'm also not
including options in the padding,

64
00:03:50,982 --> 00:03:54,282
okay? And the reason for
the padding, by the way,

65
00:03:54,582 --> 00:03:56,682
is the IP header has to
land on a 4 byte boundary.

66
00:03:56,682 --> 00:04:01,182
So, if the options were only 2 byte,
then you'd have 2 bytes of padding

67
00:04:01,182 --> 00:04:13,982
and so on. For the IPv6 -
excuse me - it becomes longer.

68
00:04:13,982 --> 00:04:16,682
Like we said, it becomes 40 bytes
but the fact of the matter is,

69
00:04:16,682 --> 00:04:17,582
there's no options.

70
00:04:17,582 --> 00:04:21,782
If there's no options, there's no
question how long is the header.

71
00:04:22,082 --> 00:04:23,282
Let me help you out.

72
00:04:23,282 --> 00:04:28,082
The first header on the first
packet is going to be 40 bytes.

73
00:04:28,382 --> 00:04:31,382
On the second packet, it's
going to be 40 bytes.

74
00:04:31,682 --> 00:04:37,082
On the 897 millionth packet,
it's going to be 40 bytes.

75
00:04:37,082 --> 00:04:40,286
I don't need a header telling me how long,

76
00:04:40,286 --> 00:04:46,286
oh yeah. The header is-- if
it's always the same length.

77
00:04:46,286 --> 00:04:50,786
By making the IPv6 header
a fixed header length,

78
00:04:50,786 --> 00:04:52,586
that does two things.

79
00:04:52,886 --> 00:04:56,486
It eliminates the overhead of the
IHL, which I know you're looking

80
00:04:56,786 --> 00:04:59,786
at it and you're going, It's
not really very big anyway.

81
00:04:59,786 --> 00:05:05,486
It's not really necessarily about the
packet efficiency and eliminating

82
00:05:05,486 --> 00:05:10,586
the header. It's much,
much more about saving,

83
00:05:10,886 --> 00:05:14,186
once again, the CPU on
the receiving device.

84
00:05:14,186 --> 00:05:17,486
He doesn't have to look
at that and process it,

85
00:05:17,786 --> 00:05:23,086
just to figure out, oh, this header
doesn't have any options which

86
00:05:23,086 --> 00:05:28,486
99.99% or a little higher of all
the packets out there don't have

87
00:05:28,486 --> 00:05:29,686
the options on them.

88
00:05:29,686 --> 00:05:36,586
We had this header for really very,
very minimal use and it just

89
00:05:36,886 --> 00:05:37,786
slowed everything down.

90
00:05:37,786 --> 00:05:46,186
So step 1, make it a fixed header
length and get rid of that header

91
00:05:46,486 --> 00:05:52,186
length field. Next, of course,
is the type of service field.

92
00:05:52,186 --> 00:05:59,386
Type of service field or the ToS
byte is used for quality of service

93
00:05:59,386 --> 00:06:02,986
and that does not change in IPv6.

94
00:06:03,286 --> 00:06:07,686
Notice that that field is in blue
and what that means is that the

95
00:06:07,686 --> 00:06:12,786
name and position have changed,
position of course because it's right

96
00:06:13,086 --> 00:06:17,586
after version and name because they
decided to call it Traffic Class

97
00:06:17,886 --> 00:06:19,386
instead of Type of Service.

98
00:06:19,686 --> 00:06:21,474
So it got a minor

99
00:06:21,486 --> 00:06:23,286
- I'm not going to spend
a lot of time on that

100
00:06:23,286 --> 00:06:26,286
one - minor facelift, that was about it.

101
00:06:26,286 --> 00:06:31,686
The next header on the IPv4 side,
I'm just going to compare 4 to

102
00:06:31,986 --> 00:06:34,986
6 and then we'll hit that
little unique guy up there,

103
00:06:35,286 --> 00:06:38,286
the new one on IPv6 towards
the end there but,

104
00:06:38,586 --> 00:06:43,386
total length is the next one on IPv4
and again this is so you'd know

105
00:06:43,386 --> 00:06:45,486
how much was actually in the payload.

106
00:06:45,486 --> 00:06:49,836
Well this one they just modified
because total length would've been

107
00:06:49,836 --> 00:06:54,636
the total length of the entire
Layer 3 frame and then the IHL was

108
00:06:54,636 --> 00:06:56,436
the length of the actual header itself.

109
00:06:56,436 --> 00:07:01,236
Well, since our header's a fixed
size, we don't need the IHL but

110
00:07:01,236 --> 00:07:04,836
we do still have to know how long
the pay load is because that can

111
00:07:04,836 --> 00:07:07,536
of course vary depending on
your application and so on.

112
00:07:07,536 --> 00:07:13,236
So again it moved because they put
flow label in there on the IPv6

113
00:07:13,536 --> 00:07:16,836
side. So it moved after
flow label on the right,

114
00:07:17,136 --> 00:07:21,336
we call it pay load length now
serves the exact same purpose and

115
00:07:21,336 --> 00:07:22,536
the exact same function.

116
00:07:22,536 --> 00:07:30,336
Okay. Now, back to the IPv4 side
we have a section here of three

117
00:07:30,636 --> 00:07:32,436
headers that all go together.

118
00:07:32,436 --> 00:07:37,736
The identification, the flags
and the fragment offset.

119
00:07:37,736 --> 00:07:43,436
Now basically what these three headers
were pretty much used for and

120
00:07:43,736 --> 00:07:45,236
flags is a little bit trickier.

121
00:07:45,536 --> 00:07:50,736
But really identification, fragment
offset this was to if you had

122
00:07:50,736 --> 00:07:55,536
to do packet fragmentations. So
if a packet was too large for the

123
00:07:55,536 --> 00:08:01,636
MTU or the maximum transfer unit on
a segment then we'd have to break

124
00:08:01,636 --> 00:08:03,736
that packet up into smaller chunks.

125
00:08:03,736 --> 00:08:08,236
That's great-- take a
big packet, chop it up,

126
00:08:08,236 --> 00:08:09,436
and send it through the wire.

127
00:08:09,436 --> 00:08:13,336
It's going to come out the other
side and on the other side,

128
00:08:13,336 --> 00:08:16,636
it generally helps if we
can put it back together.

129
00:08:16,636 --> 00:08:20,236
We needed really two of these fields.

130
00:08:20,236 --> 00:08:24,436
One of the flags is used to indicate
that fragmentation has occurred.

131
00:08:24,736 --> 00:08:31,136
Let the receiver know, hey, this
packet is part of a fragment.

132
00:08:31,436 --> 00:08:38,336
Then how would it know which fragments
go back together to form the

133
00:08:38,336 --> 00:08:39,236
complete packet again?

134
00:08:39,236 --> 00:08:41,836
That's where the
identification field came in.

135
00:08:42,136 --> 00:08:45,736
You would end up-- if it
made three fragments,

136
00:08:45,736 --> 00:08:49,336
you would end up with three packets
that had the same number in the

137
00:08:49,636 --> 00:08:52,036
identification field so
it would know, okay,

138
00:08:52,036 --> 00:08:55,336
so these are the three pieces
that make up the original packet.

139
00:08:55,636 --> 00:08:59,736
Then over on the far right
there of the IPv4 header,

140
00:08:59,736 --> 00:09:06,636
the fragment offset, that's what told
us which fragment of that packet

141
00:09:06,636 --> 00:09:11,436
this was. So it was just an offset
invites from immediately after

142
00:09:11,736 --> 00:09:15,636
the IP header, how far is this fragment?

143
00:09:15,636 --> 00:09:21,036
So it could reassemble the
layer four and up pay load.

144
00:09:21,336 --> 00:09:25,236
So if you noticed all three
of those fields are in red,

145
00:09:25,536 --> 00:09:26,736
they are gone.

146
00:09:27,036 --> 00:09:32,736
Now, does that mean we can't
do fragmentation in IPv6?

147
00:09:33,036 --> 00:09:37,236
This is one of those fun answers.

148
00:09:37,536 --> 00:09:39,636
Sort of but no.

149
00:09:39,636 --> 00:09:45,636
Let's see. What it means is that
no interim device in the middle

150
00:09:45,936 --> 00:09:51,036
can do fragmentation in IPv6, okay?

151
00:09:51,036 --> 00:09:54,636
There are still fragmentation
headers, we're going to get to those

152
00:09:54,936 --> 00:09:57,636
on our next slide here coming up.

153
00:09:57,636 --> 00:10:03,036
But the point is you shouldn't have to.

154
00:10:03,036 --> 00:10:05,136
I think that's the biggest thing.

155
00:10:05,136 --> 00:10:08,736
We're going to talk about some
things as we go here through this

156
00:10:08,736 --> 00:10:11,436
lesson. Just to give you a
little bit of a heads up,

157
00:10:11,436 --> 00:10:14,736
one of them is something
called Path MTU Discovery.

158
00:10:15,036 --> 00:10:24,036
Basically IPv6 will discover the
full MTU on the entire path to the

159
00:10:24,036 --> 00:10:26,736
destination before it starts sending.

160
00:10:26,736 --> 00:10:32,136
So, if there's a tunnel or something
in the middle that makes your

161
00:10:32,136 --> 00:10:39,336
normal 1500 byte MTU only be allowed
to be 1460 bytes or something

162
00:10:39,336 --> 00:10:43,536
like that, then what it comes
down to is your sender,

163
00:10:43,836 --> 00:10:47,736
your windows machine,
Lenox, MAC, whatever it is,

164
00:10:48,036 --> 00:10:52,836
it's going to know that before
it starts sending frames.

165
00:10:52,836 --> 00:10:56,136
So the fact of the matter is, it
should just generate the frames

166
00:10:56,136 --> 00:10:59,736
at 1460 to begin with.

167
00:11:00,036 --> 00:11:03,636
So if it's generating the
frames at the appropriate size,

168
00:11:03,636 --> 00:11:07,836
then there should be no reason in
the world for anybody in the middle

169
00:11:07,836 --> 00:11:09,036
to have to fragment.

170
00:11:09,336 --> 00:11:13,836
Because, we already know how
large of a frame - or packet,

171
00:11:13,836 --> 00:11:16,236
actually - will fit through
our entire network.

172
00:11:16,236 --> 00:11:19,236
So if all of those mechanisms
are working correctly,

173
00:11:19,536 --> 00:11:22,236
then there should never be
a need for fragmentation.

174
00:11:22,236 --> 00:11:27,936
That's part of why - when they
designed IPv6 - we said that Path

175
00:11:27,936 --> 00:11:32,436
MTU Discovery should be
built-in, on, running,

176
00:11:32,736 --> 00:11:36,336
and working pretty much as a requirement.

177
00:11:36,336 --> 00:11:40,836
If it's not, you can have
connectivity problems with IPv6.

178
00:11:40,836 --> 00:11:45,136
So, it really pretty much
needs to be on and enabled.

179
00:11:45,136 --> 00:11:50,536
Because we don't have fragmentation
flags and such readily available.

180
00:11:50,836 --> 00:11:55,036
Now we can do it, but again, only
the sender can do it - only the

181
00:11:55,036 --> 00:11:55,936
originating machine.

182
00:11:55,936 --> 00:12:01,036
And if you read through the
documentation I'm one of those people,

183
00:12:01,036 --> 00:12:03,136
I read it and go, yeah, got all that.

184
00:12:03,136 --> 00:12:06,636
Then I sit there and I ponder and I say,

185
00:12:06,636 --> 00:12:13,536
Okay, if the sending machine
knows that the path MTU is 1460,

186
00:12:13,836 --> 00:12:16,836
why would it ever have
to actually fragment?

187
00:12:16,836 --> 00:12:18,336
It should just be generating.

188
00:12:18,636 --> 00:12:22,236
The only thing I've come up with
is I guess if you had really badly

189
00:12:22,236 --> 00:12:26,436
written application or something
I suppose that just always sent

190
00:12:26,741 --> 00:12:30,436
at 1500 bites no matter what and
then the underlying operating system

191
00:12:30,736 --> 00:12:33,736
went it goes to put the packets in goes,

192
00:12:34,036 --> 00:12:37,036
I can't do that and it fragments.

193
00:12:37,036 --> 00:12:41,936
But I would find it to be incredibly
rare in an IPv6 environment.

194
00:12:41,936 --> 00:12:50,636
All right so over to the time to
live field in IPv6 of course the

195
00:12:50,636 --> 00:12:56,036
TTL, this is of course to-- this
is another one that's a lot of fun

196
00:12:56,036 --> 00:12:58,736
to listen to how people
say things sometimes.

197
00:12:58,736 --> 00:13:04,136
Question I love to ask is what is
the TTL field for and an answer

198
00:13:04,436 --> 00:13:09,405
I get so many times is it's
to prevent loops in IPv4.

199
00:13:09,405 --> 00:13:11,805
Oh, I so wish that was true.

200
00:13:11,805 --> 00:13:14,505
It's not to prevent loops in IPv4.

201
00:13:14,505 --> 00:13:22,005
It's if there is a loop, to prevent
the packet from looping indefinitely

202
00:13:22,305 --> 00:13:25,605
and ultimately get removed from the wire.

203
00:13:25,605 --> 00:13:30,405
To actually prevent the loops in
IPv4, hopefully you are running

204
00:13:30,405 --> 00:13:33,405
a routing protocol that
has loop prevention.

205
00:13:33,405 --> 00:13:39,105
Should that fail, there are certainly
things you can do with routing

206
00:13:39,105 --> 00:13:41,505
protocols to make the loop
prevention not work correctly.

207
00:13:41,505 --> 00:13:45,405
It's relatively easy to do.

208
00:13:45,405 --> 00:13:47,805
That's what the TTL is for.

209
00:13:47,805 --> 00:13:49,605
Again, we're not going to
spend a ton of time on it.

210
00:13:49,605 --> 00:13:53,505
It's the exact same field, does the
exact same thing in IPv6 except

211
00:13:53,505 --> 00:13:54,405
they renamed it.

212
00:13:54,405 --> 00:13:56,205
It's no longer Time to Live.

213
00:13:56,505 --> 00:13:59,505
If you look over to the right
there, it's now called Hop Limit.

214
00:13:59,805 --> 00:14:04,605
We have the same sort of thing
going on with the protocol.

215
00:14:04,905 --> 00:14:14,205
The protocol is basically
to tell you what's next,

216
00:14:14,205 --> 00:14:22,905
right? TCP, UDP, OSPF, EIGRP, GRE
any of the things that run directly

217
00:14:22,905 --> 00:14:27,105
on top of IP without running
inside of TCP or UDP.

218
00:14:27,406 --> 00:14:31,305
Now if it's an application inside
of TCP or UDP then of course it

219
00:14:31,305 --> 00:14:34,905
comes down to port number to know
what application everything goes

220
00:14:34,905 --> 00:14:38,805
to. But this is just for the Layer
3 header to be able to identify

221
00:14:39,105 --> 00:14:40,305
the Layer 4 header.

222
00:14:40,605 --> 00:14:45,105
Now if you look to the right notice
that they renamed that to next

223
00:14:45,105 --> 00:14:51,705
header. Now, could that
next header still be OSPF,

224
00:14:51,705 --> 00:14:57,405
EIGRP, UDP, TCP?

225
00:14:57,705 --> 00:15:02,805
Of course. But the reason they changed
it from protocol to next header,

226
00:15:02,805 --> 00:15:07,905
that name will become clear, I
think, on the next slide because the

227
00:15:08,205 --> 00:15:11,805
next header could be another IPv6 header.

228
00:15:11,805 --> 00:15:14,805
It may not be TCP or UDP yet.

229
00:15:15,105 --> 00:15:18,105
IPv6 may just have more
than it needs to tell you.

230
00:15:18,105 --> 00:15:21,405
That's why they changed
the name of that one.

231
00:15:21,405 --> 00:15:24,705
Back to the left again, header checksum.

232
00:15:24,705 --> 00:15:30,105
This comes down, I think, a
little bit to history here.

233
00:15:30,405 --> 00:15:34,605
You've got to remember that IPv4
was developed by the Department

234
00:15:34,605 --> 00:15:37,306
of Defense, the DARPA project,
and all that kind of fun stuff.

235
00:15:37,605 --> 00:15:43,005
When it was written, there was no standard.

236
00:15:43,005 --> 00:15:48,105
It wasn't running on the OSI
model or anything like that.

237
00:15:48,105 --> 00:15:49,927
In fact, they called it the DoD Model.

238
00:15:49,927 --> 00:15:54,727
If anybody's recently come through CCNA
- I know I'm probably giving

239
00:15:54,727 --> 00:15:58,627
you horrible flashbacks or something
here - the fact of the matter

240
00:15:58,627 --> 00:16:03,727
is the problem with the DoD Model
that this was built built on is

241
00:16:03,727 --> 00:16:10,227
it just referred to the whole bottom
layers as network connectivity,

242
00:16:10,227 --> 00:16:12,027
and it depends what documents you look at,

243
00:16:12,327 --> 00:16:13,527
what they named it, but you know.

244
00:16:13,527 --> 00:16:17,427
Basically what I'm trying to get
at is there was no specification

245
00:16:17,427 --> 00:16:22,227
to say that Layer 2 should
be doing error checking.

246
00:16:22,227 --> 00:16:28,527
Well, if Layer 2 is not doing error
checking then they had the attitude

247
00:16:28,527 --> 00:16:31,827
of, well then IPv4 better check itself.

248
00:16:31,827 --> 00:16:36,327
So let's put in this header checksum
to make sure that the IPv4 header

249
00:16:36,627 --> 00:16:37,827
didn't get corrupted.

250
00:16:37,827 --> 00:16:41,127
Okay, great, but now move forward.

251
00:16:41,427 --> 00:16:44,727
We get the OSI model and we get
all of these standards for Layer

252
00:16:44,727 --> 00:16:48,327
2 and they all have something in common.

253
00:16:48,627 --> 00:16:51,927
If you're talking about
ethernet, PPP, frame relay,

254
00:16:52,227 --> 00:16:56,427
even all the way to X.25,
ISDN, all of these,

255
00:16:56,727 --> 00:16:59,427
they all had one thing in common.

256
00:16:59,427 --> 00:17:01,827
There may have only been one thing
in common but they had one thing

257
00:17:02,127 --> 00:17:05,127
in common they all did error checking.

258
00:17:05,427 --> 00:17:08,727
Now some of them went so
far as to do correcting,

259
00:17:08,727 --> 00:17:11,427
as far as maybe even
trying to fix the problem,

260
00:17:11,727 --> 00:17:13,227
some just check for the error.

261
00:17:13,227 --> 00:17:15,927
But either way they all did error checking.

262
00:17:15,927 --> 00:17:21,027
So if Layer 2 is already checking
the entire frame to make sure it

263
00:17:21,027 --> 00:17:25,227
hasn't been corrupted in transit,
then why in the world should the

264
00:17:25,227 --> 00:17:28,527
Layer 3 header be checking itself?

265
00:17:28,827 --> 00:17:30,627
There's no need for that.

266
00:17:30,627 --> 00:17:33,927
So as you can see on the right it's gone.

267
00:17:34,227 --> 00:17:41,727
One less calculation that the receiving
router has to do once again.

268
00:17:41,727 --> 00:17:44,727
So again, good thing.

269
00:17:44,727 --> 00:17:47,427
Save CPU you notice a trend here.

270
00:17:47,427 --> 00:17:50,727
With the IHL gone, the
header checksum gone,

271
00:17:50,727 --> 00:17:56,827
broadcast gone, yes our
header gets longer however,

272
00:17:56,827 --> 00:18:00,427
it really saves a lot
of CPU on the devices.

273
00:18:00,427 --> 00:18:04,327
Now all of that said and truth be told,

274
00:18:04,327 --> 00:18:10,027
I don't know. On today's devices
do we really think it makes that

275
00:18:10,027 --> 00:18:11,827
much of a difference on the CPU?

276
00:18:11,827 --> 00:18:15,327
I don't know, we can call
that a political discussion,

277
00:18:15,627 --> 00:18:17,127
I'm not going to get into.

278
00:18:17,427 --> 00:18:26,127
I'm just going to stick with facts,
it does take less CPU to process

279
00:18:26,127 --> 00:18:29,727
IPv6 frames than it does IPv4.

280
00:18:30,027 --> 00:18:35,727
Whether that makes any difference
on today's equipment who's to say.

281
00:18:36,027 --> 00:18:40,769
In fact, if you look at packet
forwarding statistics for a lot of

282
00:18:40,769 --> 00:18:44,669
the devices you'll actually find
that a lot of the devices actually

283
00:18:44,669 --> 00:18:48,369
forward IPv4 traffic faster than IPv6.

284
00:18:48,369 --> 00:18:52,569
If you look at the spec sheets and
I think a lot of that has to do

285
00:18:52,569 --> 00:18:56,769
with optimization and CPU prioritization
within the devices and such

286
00:18:56,769 --> 00:18:57,669
at this point.

287
00:18:57,669 --> 00:19:06,669
I mean I can tell you from a from
a pure technical standpoint IPv6

288
00:19:06,669 --> 00:19:12,669
processing should be faster than
IPv4, but I can also tell you on

289
00:19:12,669 --> 00:19:16,269
a realistic side that again, if
you look at device specifications

290
00:19:16,569 --> 00:19:19,869
that's not the case right
now for a lot of equipment.

291
00:19:19,869 --> 00:19:24,969
Some of it, it's equal but a lot of
it IPv6 processing is just slower,

292
00:19:24,969 --> 00:19:29,169
and I think for some
devices, mostly not Cisco,

293
00:19:29,169 --> 00:19:32,469
but I think for a lot of devices
that could just come down to the

294
00:19:32,469 --> 00:19:35,769
fact that a lot of devices are
implementing all of this in software

295
00:19:35,769 --> 00:19:40,569
and they don't have the hardware
support and acceleration there yet.

296
00:19:40,569 --> 00:19:46,569
So, we'll see this change of course,
but for right now just watch

297
00:19:46,569 --> 00:19:49,569
the specs on the devices you're
going to use because they may in

298
00:19:49,869 --> 00:19:53,169
fact have slower IPv6 forwarding rates.

299
00:19:53,169 --> 00:19:57,369
All right, I think I already
covered the options and padding at

300
00:19:57,369 --> 00:20:00,669
the bottom there as far
as the IPv4 header goes,

301
00:20:00,969 --> 00:20:04,869
and of course the other two are the
source and destination address.

302
00:20:05,169 --> 00:20:07,569
None of this would work without that.

303
00:20:07,870 --> 00:20:12,969
And of course, those are the fields
that get much larger in IPv6.

304
00:20:12,969 --> 00:20:15,969
I'm sure you already know I
have a slide coming up on it,

305
00:20:15,969 --> 00:20:20,769
but if you're even watching this,
I'm sure you're already aware of

306
00:20:20,769 --> 00:20:23,169
the fact that we go to a 128-bit address.

307
00:20:23,169 --> 00:20:31,569
So that means, we are now talking
about 16 octets essentially.

308
00:20:31,869 --> 00:20:33,669
We don't call them octets
anymore, we call them fields,

309
00:20:33,669 --> 00:20:36,369
because we break them
up in to 16-bit fields.

310
00:20:36,369 --> 00:20:39,669
But you understand, the point
that I'm trying to make is that,

311
00:20:39,969 --> 00:20:46,269
they are four times - just bit-wise
- they are four times the size

312
00:20:46,269 --> 00:20:51,869
of IPv4. Well, that doesn't fit in
a header without the source and

313
00:20:51,869 --> 00:20:54,269
destination addresses getting
four times the size.

314
00:20:54,269 --> 00:20:59,369
So there it is, you can see
it there, and of course,

315
00:20:59,369 --> 00:21:00,269
they just get bigger.

316
00:21:00,269 --> 00:21:04,469
[music]