[music]
In this section we're going to start with an introduction
to IPv6. I'm not going to be getting
on any equipment or CLI at this
point for this first lesson here.
We're just going to start with
some basic things you need to know
about IPv6 before we even really start jumping in and configuring
it and setting it up.
So, the first question of course,
which I think at this point most
people are aware of, but why are we even going to IPv6?
What's the point?
The first and foremost reason, of course,
is that IPv4 only has a maximum of
2^32 IP addresses being a 32 bit address,
and mathematically that comes
out to right around 3.4 billion addresses.
But hopefully you're
already aware of the fact that we
lose considerable amounts of
addresses once you start backing out
all your multicast addresses.
You start backing out the entire class A loopback address space.
Not to mention all the addresses you lose simply by the fact that
we broke it all up into class A, class B,
class C addresses and so on.
Realistically, there's actually far fewer addresses than that.
But even if we had them all usable,
we'd still be running out of them of course.
Here's what we're saying here right after classes,
multicast, reserved ranges, and so on,
there's actually far few that are actually usable.
Now, if any of you have been in
this industry for quite some time,
you may remember back in,
I'm going to say somewhere in the 95,
1996 time frame, even back then,
IANA was yelling, Oh we're going
to run out of address space in IPv4.
Of course that's when all this all started with--
it didn't start then, I mean it already under development.
There's where the whole push for IPv6 really started.
Of course, it's been a long time
since then, regardless of when you're
listening to this,
it's been a long time when I'm
recording it and even longer since
you're listening to it here.
The point is we've known for quite
some time that this was coming.
Now, in the meantime of course,
they came up with a technology called NAT,
or network address translation.
The idea here I'm sure you're all familiar with,
is that we take a range, usually from the RFC-1918 address space,
so our private addresses, and we enumerate
our entire internal
network with these RFC-1918 addresses,
and then we hide all of those
behind NAT, or if you want to be a little more specific,
we generally use PAT or Port Address Translation.
NAT is the more generic term for it.
Everybody calls it that.
Just generically say, yeah, we're using NAT.
Fact of the matter is, I think that probably very,
very, very few companies in situations actually use NAT.
NAT is a one-to-one translation where
you would have one public outside address
for every one internal private address.
That doesn't mean they have to be statically mapped,
they can still be dynamic.
The way it was done is you would have an outside pool.
Let's say just as an example,
your company owned - we'll just make
it simple - we'll say a class C address range.
So let's say you own essentially 254 usable addresses,
and what that would mean with NAT
is that you would have 254 possible
hosts inside of your network that
could access the internet at any
given time. Now the reason for that, of course,
is like I said, it's one-to-one.
For every one internal address that
tried to go to the outside world,
it would go through NAT and it would
be given one of the public addresses
out of the pool.
And then all traffic, all ports, everything going back and forth
between that private and public address would be translated.
Now, the obvious problem with this
is every machine inside talking
to the internet needs a public outside address.
When this was first created,
you have to keep in mind that back then
not everybody had the internet on
every machine, and not every device
inside a company network actually
needed internet access,
or was even allowed internet access, or anything else.
Quite honestly, half the people
didn't even know what the internet
was yet. You have to look at from a time frame perspective,
at a certain point in time, it would
have been no problem to have,
it of course varies based on company size,
but maybe a block of 16 outside addresses,
or 32, or maybe a whole class C, whatever.
You'd have X number of outside
addresses and then you'd have 200
machines inside the company with 16 outside addresses.
Only 16 of those machines could communicate at once,
because you only have 16 public addresses.
Now the obvious problem here becomes is as the network grows,
and the internet becomes more popular,
everybody wants internet access.
Yeah, you could argue whether they
actually need it or not inside
of a company, but regardless,
everybody had to have internet.
We're now all of a sudden having
16 out of 200 machines capable of
communicating simultaneously, just frankly wasn't enough.
So that's where we step up to, of course,
Port Address Translation where we
can take hundreds of machines
and hide them behind a single IPv4 address.
Now, for your really large companies,
you could still take that block
of 16 or 254 addresses, whatever it is you have and overload -
that's what Cisco calls it.
Other devices honestly just refer to it as NAT.
Cisco refers to it as NAT Overload
on the CLI, but at the end of the day,
we're really talking about PAT or Port Address Translation.
All in all what does this give us?
It buys us from 1996, when we already
started throwing up the panic flags -
holy cow, the internet's growing like crazy -
and they're looking at it, looking at the math,
going, uh, we're in big trouble.
This cannot grow the way we're trying to.
To really getting us all the way through until modern times,
where we're still on IPv4 for the most part.
Obviously, since you're watching this course,
we're hoping that you're at least
interested in IPv6 and learning
more about it, and we are ultimately heading here.
It's not a question, it's not a maybe we're going to.
Someday we will look back on this and say,
ha ha, remember when we used to run IPv4?
I can't believe anybody would still run that anymore.
How quickly? I'm not even going to
bother trying to make a prediction.
There have been numerous times where people have said,
oh, it's going to happen in two years.
Yeah, okay, no.
This is going to take a long time.
There's no two ways about it.
We're going to have transition phases.
My personal prediction is that this is going to be very,
very much like, if anybody's been around for a while,
the transition from IPX/SPX to IP for a lot of your LANs.
Now, some of your big networks
started off that way and stayed on IP.
But for people who are running
Novell, NetWare, and stuff back
and in the day, it was not an overnight
translation from one protocol
to the other. It was a long transition,
relatively speaking, where we were, for quite a long time,
running both protocols.
We would have IPX/SPX running to
support the LAN, file and print sharing services,
that sort of thing.
And right next to it,
running TCP/IP to support internet access.
Now obviously, things like NetWare, things like that,
of course, all start moving over to IP.
The need for IPX/SPX goes away.
Someday we do that whole fake full flip the switch,
click, okay, IPX/SPX is off.
Let's see what breaks.
Hopefully, it's not guess work.
Hopefully, you've done your research
and you know that nothing else
is using it. A little bit of
protocol analysis goes a long way.
The point is this.
I think we're going to be doing the same thing for a really long
time with IPv6.
A lot of companies are just at the point,
as I'm recording this, of just starting to mess with IPv6.
Well let's get it running.
Let's get it set up and going, but we're still really IPv4.
It's going to be a long drawn out process.
The good news is everything is supported with IPv6.
It's ready to go.
There's a couple few little things
here and there that are not supported
in code, like specifically on Cisco
devices and such and other manufacturers,
but it's down to little things.
When this all started, you had basic
IPv6 support, but none of the
fancy features.
None of the really cool stuff.
Now we pretty much have everything
and now it's more the other way.
Yeah, okay, this little feature
here is not supported yet or that
little thing there is not supported yet.
It's really come a long way since this whole thing started.
The other thing.
I have one more thing on this slide
I want to talk about which is
the whole broadcasts.
Layer 2, Layer 3 broadcasts cause
a lot of unnecessary CPU load on
our end devices because the fact of the matter is if something's
going to a broadcast that means that it's destined to you.
That's actually one of those
things I always like to point out
to people because you love the question,
so what does a router do with a broadcast?
And so many times I get the answer
- because I love asking that in
classes and stuff - and I'll often hear
the answer, it drops them.
And I have to say, no, not specifically.
If a router dropped broadcasts
then RIP version 1 would have had a really hard time working.
The fact of the matter is
routers don't drop them. They don't
forward broadcasts, or they don't route broadcasts -
however you want to say that.
But the point is this, they do in fact process broadcasts.
Just like your own machine does,
the problem is that every device on the segment is,
in fact, the target.
So if you want to look at it from this perspective,
why would a router forward a broadcast
when it is the destination?
That's sort of the point,
that everybody is the destination for the broadcast.
The problem is, that packet
may only be intended for one,
two, a couple devices on that segment.
I just used the example of RIP version 1.
Let's say that you were running
RIP version 1 - I'm hoping you're not,
I'm just using an example -
but let's say you were running
RIP version 1 between two devices
on a multi-access LAN segment - so VLAN.
On that VLAN, just for the sake of argument,
let's say there's 100 machines on there.
Every time RIP sends out its
broadcast update every 30 seconds,
sending out the entire routing table,
that means that every single
device on that segment - every PC, MAC,
Linux box - everybody needs to process that frame.
What they're going to process is
they're going to get it and they're
going to bring it up to UDP,
and they're going to look at the port number,
and they're going to say,
oh, I'm not listening on that UDP port.
Now, depending on the operating system,
they may or may not realize, wait, this is RIP.
I'm not running RIP.
Why am I getting this?
They may just look at it and go, I'm not listening on that port.
However it works programmatically
inside's not really important.
But the fact of the matter is, they had to interrupt the CPU,
take cycles to look at this frame to realize,
hey, this isn't for me.
Ultimately a better thing to do
would be to throw this frame away
in hardware. At the end of the day--
hopefully we're all running switches.
I don't even know if they make hubs anymore.
I'm sure somebody does somewhere.
We'll just pretend for a minute
that we have hubs and everything's
just one big broadcast segment, one big collision domain.
The issue becomes, even with unicast, and multicast,
with a hub environment or just a flat out multi-access segment,
everybody gets those frames anyway.
I think it sometimes confused people;
what's the difference if there's a hub?
The difference, honestly, all comes down to your network card.
Your network card has a burned in
address from the manufacturer.
If it's Ethernet, which I'm going
to assume for this course that it is,
we call it a MAC address.
The thing is this, if you receive that frame,
and it's not destined to your broadcast--
sorry, to your MAC address,
if it's a broadcast or a multicast
that you're-- and for the sake of the multicast,
you have not joined that group, so
you're not listening for that multicast.
Your network card will look at that.
It'll look at the destination MAC address and it will say,
well, this clearly came in on my segment.
Here it is. Here are the bits coming
in on the wire, but when he looks
at the destination address and it's
not his unicast MAC address
or any multicast he's listening for, he'll just throw that away.
He just discards it right there in hardware at the neck.
He's not going to bother the CPU.
He's not going to bother the operating system.
He just says, not for me and I'm going to throw this away.
I just want to make sure we're
clear on the difference on why we
say that a broadcast creates CPU load, yet multicasts and nicasts
do not. In the case of most of our modern switches,
that stuff wouldn't have happened anyway.
The first couple frames might for
like an unknown unicast or even
multicast if the switch does not
support IGMP snooping or something like that.
It is still possible,
even with today's switches, to get
a couple frames, or in the case
of multicast, maybe even a bunch.
The fact of the matter is is your
network card in hardware will be
throwing that away, where with a broadcast,
it can't do that because again,
everybody is the destination.
So the network card looks at that and goes,
well, it's not my MAC address,
but it's a broadcast so I'm going to
send it on up to the CPU because he has to decide whether this is
for us or not.
We'll talk more about that in a little
bit when we get into multicasts
and the advantages that they give us.
The flip side of that is, of course,
they bring a little bit of discussion
to the table. That means things have to change.
We'll take a look at that here in
just a second as well.
[music]