[music]
First the other thing we pick up with IPv6 is we get a
simplified header.
Now don't misunderstand and before I even bring up the image here
I want to make sure we're clear on one very important word here and
it's not IPv6 and it's not header.
So I think you can figure out which one it is.
It's simplified header, not shorter nobody ever said shorter.
You're not going to put two 128 bit addresses into an IPv6 header
where an IPv4 header only has 32 bit addresses.
That's not going to happen without making the header larger.
So here it is.
The header is definitely larger.
We have the IPv4 header on the left, the IPv6 header on the right
and, as you can see, there's a little legend down there telling us
which fields have been kept and if you notice there's only three
fields that have been kept unchanged from IPv4 to IPv6 and that's
the version. Now, notice it says the field was kept,
even just the name but not necessarily the contents.
In other words version is of course going to flip from 4 to 6 so
it doesn't have the same contents as far as the value.
I mean, contents being version, yes, but it's going to switch the
version number.
If you look at the IPv4, the next header is the IHL which is the
IP Header Length.
Now the reason for the header length is,
if you look down and we're going to have to jump ahead just a little
bit here to the bottom of the IPv4 header there,
where it says option and padding.
Well, here's the problem.
The IPv4 header had available options in it that you could set and
not too many people use.
We're not going to get into all that.
This is not an IPv4 class but there were available options and here
became the question.
Are there options?
Aren't there options?
There's a reason we call them options.
It's because they're optional.
So, how is the router who's just receiving 10110110101
a stream of binary ones and zeros, how is he supposed to know are
there options or aren't there?
What am I expecting to see after the destination address.
Should it be the start of the TCP or UDP header or are there options
there? What's there I don't know?
That's what the IP header length was used for,
was to indicate whether options were there and let the receiving
device know do I need to look for options?
How long is this header?
And, I know I'm making a big deal out of this,
but I want you to understand something.
This is a big part of what we mean by a simplified header by not
putting the options.
Look at the IPv6 header.
Also, the fact that these are all in red,
which means that they were killed when we go to IPv6.
IPv6, they decided to handle this differently.
They said, okay, you know what?
The IPv6 header is going to be a fixed length.
What you see on the right is not variable,
okay? Yes, it becomes 40 bytes instead of 20 bytes,
okay? But the fact of the matter is, and when I say 20 bytes for
the IPv4 header, I'm also not including options in the padding,
okay? And the reason for the padding, by the way,
is the IP header has to land on a 4 byte boundary.
So, if the options were only 2 byte, then you'd have 2 bytes of padding
and so on. For the IPv6 - excuse me - it becomes longer.
Like we said, it becomes 40 bytes but the fact of the matter is,
there's no options.
If there's no options, there's no question how long is the header.
Let me help you out.
The first header on the first packet is going to be 40 bytes.
On the second packet, it's going to be 40 bytes.
On the 897 millionth packet, it's going to be 40 bytes.
I don't need a header telling me how long,
oh yeah. The header is-- if it's always the same length.
By making the IPv6 header a fixed header length,
that does two things.
It eliminates the overhead of the IHL, which I know you're looking
at it and you're going, It's not really very big anyway.
It's not really necessarily about the packet efficiency and eliminating
the header. It's much, much more about saving,
once again, the CPU on the receiving device.
He doesn't have to look at that and process it,
just to figure out, oh, this header doesn't have any options which
99.99% or a little higher of all the packets out there don't have
the options on them.
We had this header for really very, very minimal use and it just
slowed everything down.
So step 1, make it a fixed header length and get rid of that header
length field. Next, of course, is the type of service field.
Type of service field or the ToS byte is used for quality of service
and that does not change in IPv6.
Notice that that field is in blue and what that means is that the
name and position have changed, position of course because it's right
after version and name because they decided to call it Traffic Class
instead of Type of Service.
So it got a minor
- I'm not going to spend a lot of time on that
one - minor facelift, that was about it.
The next header on the IPv4 side, I'm just going to compare 4 to
6 and then we'll hit that little unique guy up there,
the new one on IPv6 towards the end there but,
total length is the next one on IPv4 and again this is so you'd know
how much was actually in the payload.
Well this one they just modified because total length would've been
the total length of the entire Layer 3 frame and then the IHL was
the length of the actual header itself.
Well, since our header's a fixed size, we don't need the IHL but
we do still have to know how long the pay load is because that can
of course vary depending on your application and so on.
So again it moved because they put flow label in there on the IPv6
side. So it moved after flow label on the right,
we call it pay load length now serves the exact same purpose and
the exact same function.
Okay. Now, back to the IPv4 side we have a section here of three
headers that all go together.
The identification, the flags and the fragment offset.
Now basically what these three headers were pretty much used for and
flags is a little bit trickier.
But really identification, fragment offset this was to if you had
to do packet fragmentations. So if a packet was too large for the
MTU or the maximum transfer unit on a segment then we'd have to break
that packet up into smaller chunks.
That's great-- take a big packet, chop it up,
and send it through the wire.
It's going to come out the other side and on the other side,
it generally helps if we can put it back together.
We needed really two of these fields.
One of the flags is used to indicate that fragmentation has occurred.
Let the receiver know, hey, this packet is part of a fragment.
Then how would it know which fragments go back together to form the
complete packet again?
That's where the identification field came in.
You would end up-- if it made three fragments,
you would end up with three packets that had the same number in the
identification field so it would know, okay,
so these are the three pieces that make up the original packet.
Then over on the far right there of the IPv4 header,
the fragment offset, that's what told us which fragment of that packet
this was. So it was just an offset invites from immediately after
the IP header, how far is this fragment?
So it could reassemble the layer four and up pay load.
So if you noticed all three of those fields are in red,
they are gone.
Now, does that mean we can't do fragmentation in IPv6?
This is one of those fun answers.
Sort of but no.
Let's see. What it means is that no interim device in the middle
can do fragmentation in IPv6, okay?
There are still fragmentation headers, we're going to get to those
on our next slide here coming up.
But the point is you shouldn't have to.
I think that's the biggest thing.
We're going to talk about some things as we go here through this
lesson. Just to give you a little bit of a heads up,
one of them is something called Path MTU Discovery.
Basically IPv6 will discover the full MTU on the entire path to the
destination before it starts sending.
So, if there's a tunnel or something in the middle that makes your
normal 1500 byte MTU only be allowed to be 1460 bytes or something
like that, then what it comes down to is your sender,
your windows machine, Lenox, MAC, whatever it is,
it's going to know that before it starts sending frames.
So the fact of the matter is, it should just generate the frames
at 1460 to begin with.
So if it's generating the frames at the appropriate size,
then there should be no reason in the world for anybody in the middle
to have to fragment.
Because, we already know how large of a frame - or packet,
actually - will fit through our entire network.
So if all of those mechanisms are working correctly,
then there should never be a need for fragmentation.
That's part of why - when they designed IPv6 - we said that Path
MTU Discovery should be built-in, on, running,
and working pretty much as a requirement.
If it's not, you can have connectivity problems with IPv6.
So, it really pretty much needs to be on and enabled.
Because we don't have fragmentation flags and such readily available.
Now we can do it, but again, only the sender can do it - only the
originating machine.
And if you read through the documentation I'm one of those people,
I read it and go, yeah, got all that.
Then I sit there and I ponder and I say,
Okay, if the sending machine knows that the path MTU is 1460,
why would it ever have to actually fragment?
It should just be generating.
The only thing I've come up with is I guess if you had really badly
written application or something I suppose that just always sent
at 1500 bites no matter what and then the underlying operating system
went it goes to put the packets in goes,
I can't do that and it fragments.
But I would find it to be incredibly rare in an IPv6 environment.
All right so over to the time to live field in IPv6 of course the
TTL, this is of course to-- this is another one that's a lot of fun
to listen to how people say things sometimes.
Question I love to ask is what is the TTL field for and an answer
I get so many times is it's to prevent loops in IPv4.
Oh, I so wish that was true.
It's not to prevent loops in IPv4.
It's if there is a loop, to prevent the packet from looping indefinitely
and ultimately get removed from the wire.
To actually prevent the loops in IPv4, hopefully you are running
a routing protocol that has loop prevention.
Should that fail, there are certainly things you can do with routing
protocols to make the loop prevention not work correctly.
It's relatively easy to do.
That's what the TTL is for.
Again, we're not going to spend a ton of time on it.
It's the exact same field, does the exact same thing in IPv6 except
they renamed it.
It's no longer Time to Live.
If you look over to the right there, it's now called Hop Limit.
We have the same sort of thing going on with the protocol.
The protocol is basically to tell you what's next,
right? TCP, UDP, OSPF, EIGRP, GRE any of the things that run directly
on top of IP without running inside of TCP or UDP.
Now if it's an application inside of TCP or UDP then of course it
comes down to port number to know what application everything goes
to. But this is just for the Layer 3 header to be able to identify
the Layer 4 header.
Now if you look to the right notice that they renamed that to next
header. Now, could that next header still be OSPF,
EIGRP, UDP, TCP?
Of course. But the reason they changed it from protocol to next header,
that name will become clear, I think, on the next slide because the
next header could be another IPv6 header.
It may not be TCP or UDP yet.
IPv6 may just have more than it needs to tell you.
That's why they changed the name of that one.
Back to the left again, header checksum.
This comes down, I think, a little bit to history here.
You've got to remember that IPv4 was developed by the Department
of Defense, the DARPA project, and all that kind of fun stuff.
When it was written, there was no standard.
It wasn't running on the OSI model or anything like that.
In fact, they called it the DoD Model.
If anybody's recently come through CCNA - I know I'm probably giving
you horrible flashbacks or something here - the fact of the matter
is the problem with the DoD Model that this was built built on is
it just referred to the whole bottom layers as network connectivity,
and it depends what documents you look at,
what they named it, but you know.
Basically what I'm trying to get at is there was no specification
to say that Layer 2 should be doing error checking.
Well, if Layer 2 is not doing error checking then they had the attitude
of, well then IPv4 better check itself.
So let's put in this header checksum to make sure that the IPv4 header
didn't get corrupted.
Okay, great, but now move forward.
We get the OSI model and we get all of these standards for Layer
2 and they all have something in common.
If you're talking about ethernet, PPP, frame relay,
even all the way to X.25, ISDN, all of these,
they all had one thing in common.
There may have only been one thing in common but they had one thing
in common they all did error checking.
Now some of them went so far as to do correcting,
as far as maybe even trying to fix the problem,
some just check for the error.
But either way they all did error checking.
So if Layer 2 is already checking the entire frame to make sure it
hasn't been corrupted in transit, then why in the world should the
Layer 3 header be checking itself?
There's no need for that.
So as you can see on the right it's gone.
One less calculation that the receiving router has to do once again.
So again, good thing.
Save CPU you notice a trend here.
With the IHL gone, the header checksum gone,
broadcast gone, yes our header gets longer however,
it really saves a lot of CPU on the devices.
Now all of that said and truth be told,
I don't know. On today's devices do we really think it makes that
much of a difference on the CPU?
I don't know, we can call that a political discussion,
I'm not going to get into.
I'm just going to stick with facts, it does take less CPU to process
IPv6 frames than it does IPv4.
Whether that makes any difference on today's equipment who's to say.
In fact, if you look at packet forwarding statistics for a lot of
the devices you'll actually find that a lot of the devices actually
forward IPv4 traffic faster than IPv6.
If you look at the spec sheets and I think a lot of that has to do
with optimization and CPU prioritization within the devices and such
at this point.
I mean I can tell you from a from a pure technical standpoint IPv6
processing should be faster than IPv4, but I can also tell you on
a realistic side that again, if you look at device specifications
that's not the case right now for a lot of equipment.
Some of it, it's equal but a lot of it IPv6 processing is just slower,
and I think for some devices, mostly not Cisco,
but I think for a lot of devices that could just come down to the
fact that a lot of devices are implementing all of this in software
and they don't have the hardware support and acceleration there yet.
So, we'll see this change of course, but for right now just watch
the specs on the devices you're going to use because they may in
fact have slower IPv6 forwarding rates.
All right, I think I already covered the options and padding at
the bottom there as far as the IPv4 header goes,
and of course the other two are the source and destination address.
None of this would work without that.
And of course, those are the fields that get much larger in IPv6.
I'm sure you already know I have a slide coming up on it,
but if you're even watching this, I'm sure you're already aware of
the fact that we go to a 128-bit address.
So that means, we are now talking about 16 octets essentially.
We don't call them octets anymore, we call them fields,
because we break them up in to 16-bit fields.
But you understand, the point that I'm trying to make is that,
they are four times - just bit-wise - they are four times the size
of IPv4. Well, that doesn't fit in a header without the source and
destination addresses getting four times the size.
So there it is, you can see it there, and of course,
they just get bigger.
[music]