[music]
Now as far as the actual addressing goes.
So for IPv6 addressing I think most people probably know this but
it does create a little bit of a problem.
We're using 8 16-- I wrote byte there, that's not right,
sorry about that, that is a mistake.
That should be 16-bit fields.
That would make it one heck of a long address but,
yeah, it's 8 16-bit fields or two bytes on each field separated by
a colon. Now the colon, you know, I always joke about this when I'm
teaching classes and stuff.
Look down at your keyboard.
Couldn't they have come up with some other character,
really? I mean, we have a lot of them.
There's a lot lot of keys on the keyboard.
Couldn't we have picked something other than the colon?
And I'll tell you two problems I have with it.
One of them is, well, quite frankly, you have to hit shift every
time. I mean, first off, inconvenience.
Now, you can do keyboard maps and stuff.
There's ways to fix that.
But the second problem I have with it, I think I have it outlined
on the screen here for you, is if you just typed into your browser
to go to http://2001db8100::10:8080, I would have to ask you,
Oh, that's great, that's cute, now, the 8080,
is that part of the address, or is that the port number?
Now, this is a little bit of a problem with teaching and explanations,
I haven't gotten into the rules of shortening the address yet
but I want to talk about the colon.
That's sort of one of those-- hopefully,
everybody's at least semi-familiar with the double colons.
If not, you will be in a minute.
The problem with the double colons is it eliminates a whole field
or fields of zeroes.
That's great. How many fields?
See, you don't know.
Was that address supposed to be four fields and then the 8080 is
a port number, or is that just a five-field address and the colons
are eliminating three fields, not four fields of zeroes?
See, that's the question.
It's not really a question but I can tell you.
That top address, the 8080, is part of the host address.
Well, I'm assuming host.
I'm assuming they're following the RFCs in doing a /64 but we'll
get to that later.
The 8080 - as it's listed right there - is part of the host address.
If that was supposed to be a port number,
then you need to look at the address right below it,
that's using it as a port number.
That format is referred to as a literal IPv6 address,
if you ever want to look that up and get a little more detail on
it. But that's using brackets around it to contain the IPv6 address
so it becomes really clear what part is IPv6 address,
and which part is port number.
It's actually really funny, by the way,
if you read up on some of the documentation and such.
And I've seen in a couple of various different places.
People make comments like, This isn't new.
When I'm referring to this I mean the use of the brackets to contain
the address. It's part of standard URL formatting,
is what it comes down to.
This isn't new, you can do this with IPv4 addresses.
you know when I first read that I'm looking at it going,
you know, that's interesting.
I never actually knew that you could do that with IPv4 addresses
because I never had to because there was no confusion,
you know what I'm saying?
So, you know, it's fun and all but the fact of the matter is it does
create confusion, plus you've got to hit the shift key.
I don't know, I just sit there and go, couldn't you have used any
other key on the keyboard?
Not to mention the fact, I mean, I'm picking on the right side of
this address, there's a colon on the left too.
HTTP: I mean, how many colons can we have in the same line that mean
three different things?
It's just sort of funny but it is what it is,
we have to live with it, so I like to make fun of things.
Nonetheless it is, it's there, it's not changing,
so let's move on.
so as you've gathered by now of course 8 x 16 gives us 128 bits.
So this is 2^128.
There's the math.
It's 340-- I'm not a 100% sure even how to say that,
undecillion, something or the other.
It's a lot, how about that?
And again, I will not be the person to sit around and say,
it'll be more addresses than we'll ever need in our entire lifetime.
Again, I have no idea what's happening tomorrow.
So I will not be the one to say that.
Does it certainly appear to be more addresses than we could possibly
ever need? Yes, it does.
But again, we don't know what's going to happen.
So for things the way they are right now-- and that would be every
man, woman, and child alive on planet Earth and all of that stuff,
they're estimating it's probably enough address space to address
the entire solar system.
I think we're probably okay but some of the jokes I always use,
you never know when they come out with nanomite technology next week
and we all get injected with 150 billion nanomites that heal our
bodies from the inside.
They're all networked and they all need an IPv6 address.
All of a sudden, every person walking on the planet needs 100 billion
addresses just for them.
You never know.
I'm just saying.
I won't be the one to say it's more addressing than we'll ever need.
I won't say it, will not but it's a lot.
The main reason I'm bringing this up too is that as we start getting
into things and you look at the RFCs for IPv6 addressing,
you're going to find that they recommend using /64s for client networks.
end devices, hosts, subnets, things like that. And for people who
have worked with IPv4,
we look at that and I know I did as well,
to really start looking at the big picture,
you look at that and go, Yeah, okay, I hear that it's a ton of address
space, but then I look over here and I see you telling me to use a
/64 for every client-facing subnet.
I mean that's crazy.
That's exponentially double the size of our current address space,
right? I mean the entire IPv4 address space is only 32 bits,
and you're telling me to put-- and mathematically of course it's
way, way, way more than double, it's exponentially double the bits
just on one segment.
And a lot of people who've been doing IPv4 a long time have a big
problem with that.
And possibly the best way to explain it is yes that's true.
That is true. You are using way, way, way,
way, super way more addresses on a single subnet,
than you could possibly ever want or need.
By billions and billions and billions.
But, you know, a lot of people look at that,
Yeah, they have a lot of space.
But they're just throwing it away.
Yeah, but that's like taking a bucket of water out of the ocean,
throwing it away.
And saying, Oh, that's it.
You just wasted a bucket of water.
I think the ocean's going to be okay, without that bucket of water.
And I bet I can give everybody a bucket of water out of the ocean.
And we all still have plenty.
So if you see the point I'm trying to make here.
You know, with IPv4, I was giving you, you know,
maybe a little shot glass or something,
out of the ocean.
Now I'm giving you a bucket.
Maybe you want to open it up to a 55 gallon drum or something, whatever.
The point is even with giving host /64s,
there's still such a sliver that that is out of the overall address
space, it's not even funny.
I know that can be tough for people just coming out of the IPv4 world
to get their head around because believe me,
I'm the same way.
The first glance was, Oh yeah, so you got all this address space.
Why don't you just throw it around?
Let's just waste it.
Why not? It's sort of a valid point on one level but...
Just some quick things about shortening these addresses because at
128 bits, they're obviously going to get incredibly long.
The first rule is any zeroes out of a field can be dropped.
If you look at our first example there,
2001:0DB8:0100::1 can very easily just drop the leading zeroes -
and I've already given you some examples like this already,
but 2001:DB8:100.
The basic idea look at it almost like your paycheck.
If they dropped a bunch of leading zeros out of your paycheck you
wouldn't care.
If they dropped trailing zeros that would make a big difference,
so that's how you sort of have to look at this too.
Leading zeros, no problem.
You cannot drop trailing zeros.
That 100 field there, you can't make that 1::,
1 is not the same as 100 is what it comes down to,
but 0100 is the same as 100, so pretty easy one.
The other thing is the consecutive fields of zeros.
Now, again, I addressed this a little bit a few minutes ago but I
just want to make sure a couple things are clear.
I'm sure most of you are probably aware of this but in case you're
not the double colons can represent any number of fields of zeros.
The easiest way to explain this, is all the devices will take everything
to the left of the ::, and move it to the beginning of the address
everything to the right of the ::, move it to the far right of the
address, and anything in the middle becomes zeros.
That's the easiest way to explain it.
So a lot of people look at it and go,
So if I'm eliminating three fields of zeroes,
do I use :::? Absolutely not.
No. It's always :: together, and everything in the middle pads.
You know what?
I don't care. One field, two fields, three fields.
In the top example there, we're eliminating five fields of zeroes.
If you look at the second example with the default,
just ::, that's all zeroes.
That's eight fields of zeroes.
Loopback.
Yes, they did not blow a whole class of addresses on a loopback address
this time. With IPv6, they did learn their lesson.
Even though we have tons of address space,
they did not waste a couple of million like they did in IPv4 with
reserving the whole 127 address range for one address,
127.0.0.1? It's real easy to look back and say,
Oh, it was really stupid.
Why did they do that?
It's easy to look back and say that.
At the time, I'm sure that they looked at it and said-- you've got
to remember, IPv4 was developed to be an internal defense network
originally. Then it expanded to colleges and stuff like that.
Nobody saw the Internet coming.
Obviously a few people did or at least had an idea maybe.
But the point is nobody was designing IPv4 going,
You better not waste those millions of addresses,
we're going to need those.
No, no, they were looking at it going, there's billions of addresses
usable. That's more than we could possibly ever need by the way.
See why I'm not saying that about IPv6.
That's exactly my point.
I'm sure they felt that way about the first loopback 127.0.0.1.
Who cares? Just take the highest value in a class A address,
make it a loopback.
What difference does it make?
I'm sure that's how it happened, but now looking back,
we go, Hmm, bad idea, let's create a loopback and we'll just make
it colon colon one.
And of course, we have another example there.
I'm showing you what you cannot do.
So the last one of course-- the one that I put first is correct.
You could eliminate-- and again if you look at this,
you could theoretically eliminate either the zeroes before the 37
or the zeroes after the 37.
Either one of those is is actually correct.
What you cannot do-- so in other words just to make sure we're clear.
I could have done 2001:0:0:0:37::1 and that would have been okay
- nothing illegal about that.
It's not the most efficient.
Usually you would want to eliminate the more fields of zeros rather
than the fewer fields of zeros, but neither one is incorrect.
What you cannot do - notice the all caps - you cannot do the double
colons twice. That introduces ambiguity.
How many fields of zeros go before the 37 versus how many fields
go after? The router would look at that and go,
okay, so you've eliminated five fields of zeros,
great. Is that one in front, four after?
Two in front, three after?
Four in front, one after?
There's at least - and that's just off the top of my head - there's
at least three combinations or whatever,
of how those could be split up.
And you can't do that with an address, right?
You know, try that with the post office.
Just put 3 different addresses on a letter.
Well it could be this street address, or maybe this one,
or maybe this one.
Yeah, that's not going to work.
So yeah, there's no way you can do that.
So that would just be an illegal address,
cannot be done.
Just want to make sure we're all very clear on that.
The other thing to consider with IPv6 addressing,
are the different address types.
First we have the address types themselves.
And for those of you coming from IPv4, this could be a big one to
get used to, which is link local addresses.
These are taken from the range Fe80::/10.
Now please note that it's a /10.
So really that means FE8, FE9, FEA, and FEB are all part of that
because the 10, the F, and the E represent 8 bits and leaves-- it
means there's 2 bits left coming out of the 8 field.
If you take 8, it's of course 1000 in those bits but of course in
this case, it will just be one 0, which means that it can be either -
like I said - 8, 9, A or B are all still technically link-local.
I've never seen anybody use them.
Every link-local I've ever seen has been FE80.
But I just want to make sure we're clear that that's not an FE80/16.
It's a /10. Just being a little technical there but just be aware
of it, okay? The more important thing is what the heck's a link-local
address? This is where things get a little different with IPv6.
And again you could make the argument-- while we're wasting possibly,
you could argue addresses handing out /64s to clients like we just
discussed, the flip side of this is this lets us save tons of addresses
elsewhere in our network.
The idea behind the link-local address is it is a non-routable address.
This address, this communication, can never ever leave the segment.
This is perfect for sending traffic, say,
between two routers.
You've got a WAN link going out to a remote site.
I don't care what it is - Metro E, MPLS over Metro E or over PBP
- I don't care what it is.
The fact of the matter is with IPv4, you really only have a couple
of choices. You could do IP unnumbered on it.
That gets a little tricky you could do-- everybody knows you can
do a /30 or a /31.
Great, but you're still doing a /30 or a /31.
You're putting addresses on that WAN link,
and at the end of the day you have to ask yourself a very fundamental
question: Why?
And I'm not saying why on IPv4, because on IPv4 you have to,
so the answer to why is because I have to.
Of course. What I'm saying is in the big picture,
why does the WAN link between a remote site and your headquarters
need to be globally addressable?
You don't need to be able to route that WAN segment from your desktop
machine. See the point is a lot of the segment's on your network--
this can be point-to-point links between switches.
I mean it doesn't matter.
I'm just picking on WAN links as an example.
Anywhere there are not, I mean just to generalize,
anywhere there's not printers, servers,
PCs, workstations, anywhere there's not an end device,
you don't need to be able to route to that segment.
We call those transit segments.
There's no need to be able to get to those,
so why do they have addresses then?
In IPv4 they have addresses because that's really our only choice
but in IPv6 they looked at it and they said if you don't need to
route to that segment, if all you literally need to do is pass IPv6
traffic through the segment, not to the segment,
then in no way do you need globally routable IPv6 addresses,
and we'll see these quite a bit as we go,
but that's the idea behind link local.
You don't even have to have routable IPv6 addresses on transit links
between routers. All of your routing protocols, RIP, OSPF,
EIGRP, even BGP depending on the conditions.
BGP gets a little different like it does for so many things.
It's always our little odd ball routing protocol
because of what it does and what it's for,
it does things a little bit different.
But it can, but it can also maybe not, use link local addresses for it's communication.
When we start looking at routing tables and routing protocols and
stuff later in the course, we're going to discover that all of those
things used the link local addresses.
All your next hops are going to be link locals until we get to
BGP. But they're used a ton, and we really sort of didn't have an
equivalent to that in IPv4.
Now of course there is global, which are, of course,
the globally-routable, managed by IANA,
all that kind of stuff, just like your public IPv4 addresses today.
Now there's also another one here.
I almost hesitated even putting it in here.
It should be addressed.
I'm not sure why people would be using it,
but there's always some business case for something somewhere.
So private addressing.
Sort of like RFC 1918 addressing for IPv4.
Now if anybody's been studying IPv6 before,
don't get this confused with Site-Local Addressing,
which was the FEC0 range.
Those have been officially deprecated,
so you're not supposed to be using those anymore.
There were a lot of concerns with them.
It wasn't as clear as it should be and various things.
Unique local are the addresses that you're supposed to be using to
replace that. Now if you read the RFCs,
they basically state that this is for use inside of a non-connected
private network.
In other words, you're literally not connecting to the Internet or anything else.
You just want some addressing to use inside for some reason.
A lot of people look at this and go, Oh,
so I'm supposed to use this inside of NAT then.
No, NAT was a crutch.
NAT was to deal with the fact that we were running out of IPv4 addresses.
You're not supposed to be using NAT with IPv6.
I hear people say it all the time, Oh, we're going to keep doing
NAT. Let me address that real quick.
If you're going to keep doing NAT, then let me ask you why you're
even looking at IPv6 anyway.
We'll start with that.
Well eventually they're going to make us go to IPv6 for the internet.
Translate IPv4 inside of your network to IPv6 outside of your
network. Just do protocol translation and,
you know, you're done.
The whole thing is this: NAT has been great,
we all love it, we appreciate it, it's wonderful,
it's gotten us as far as we have gotten today without having to make
the big jump to IPv6 just yet, but the fact of the matter is it does
break the end-to-end connectivity model.
It breaks a lot of the stuff that we're trying to head towards in
this industry and, at the end of the day,
it doesn't buy you anything and I've heard a lot of push back on
this, especially from security folks, oh it hides my inside network.
To an extent, but on the other hand,
if you're following RFC 1918, I can guess within about three guesses
what your internal addressing structure is.
If you're using some different, public range inside of your network,
then you've got a whole other level of NAT problems I'm not even
going to talk about right now.
And at the end of the day - I'm just going to be blunt here -
if your firewall cannot protect you from threats without NAT,
then you've got a major problem with your firewall,
and you need a new one.
I'm just going to throw it out there.
You should not be using NAT as a security mechanism.
Security through obscurity is never a good idea.
You can't get my stuff, because you don't know what the addresses
are, or you can't get my stuff, because the traffic has to originate
from the inside for a NAT translation to be set up.
I've heard that one.
And my answer to that is stateful inspection.
Two words. Done.
So all the arguments about we need to keep NAT for security,
it's nonsense.
It's just nonsense.
The fact of the matter is, like I said,
your firewall needs to be able to protect you either way.
They have provided this address space.
If you don't believe me, go read the RFCs.
They don't recommend doing it with NAT and all that kind of stuff,
so I would just not even go there.
That's why I said I almost considered not even mentioning them.
The other thing we needed to talk about is the communication types.
Unicast versus multicast versus anycast.
Unicast, pretty simple just like IPv4, one-to-one.
Multicast and anycast...
Multicast, same exact idea as IPv4.
So it's one machine sending a packet going to multiple destinations.
The addressing of course changes.
We'll talk a little bit more about this later.
But in IPv6, all multicast addresses start FF.
But beyond that multicast is multicast.
Anycast. I almost hate to put this under communication types.
This is a big pet peeve of mine personally,
but since this is how everybody lists it,
I'll play along.
I'll do it too.
And we'll say that anycast is a communications type.
Fine. Anycast is really nothing more than a specialized manner in
which you're going to use unicast addresses.
So there is nothing special about an Anycast address,
which is sort of why I split it out of the communication types.
I've seen Anycast listed as address types before,
and I'm like, Oh, that just bothers me so bad.
All Anycast is, is very simply this, and we'll do it a couple of
times. I do it for all sorts of different things.
Something as simple as, take two servers that are offering up,
I don't care, a web page, whatever. The trick is,
they have to be offering identical services,
give them both the same address, either IPv6 or IPv4,
I don't care. Give them the same address,
and then advertise that address into your routing protocol.
So OSPF, RIP, EIGRP, BGP, whatever you're running.
What everybody on your network is going to get is they're then going
to get two routes to the same destination.
Now, do they know that that's two separate devices offering the same
service? No. They just know that they have two routes to get to what
they perceive to be the same destination.
So of course, if you're not advertising this as a host route you're
going to have to advertise this as like a /24 subnet,
something like that.
Just make sure it's being advertised the same on both routers advertising
the subnet. Everybody else on the network should then see two routes
to get there. According to any routing protocol I've ever seen
that means that we then follow whatever that routing protocols method--
of course, you know if it's RIP it's hop count,
if it's EIGRP, by default, it's bandwidth and delay.
With OSPF, well, there's a lot of variables,
but to keep things simple for right now we'll just say that it generically
comes down to lowest cost.
There's a lot more OSPF in that of course.
We're not going to get into that right now but it always prefers
internal routes over external routes and routes from Area 0 and prefer
Type 1 over Type 2 externals.
We could go on.
The point is, just to be very generic right now,
we'll just say it comes down to cost.
All the routers look at those two routes to get to that Anycast destination
and they simply follow whatever that routing protocol says is the
closest target.
That, by definition, right there is what Anycast is.
It's the guy making the decision of how to go to closest,
closest as determined by whatever the routing protocol is - RIP,
OSPF, EIGRP, BGP, doesn't matter,
static routes, I don't care.
That, by definition, is what Anycast is.
There is a big difference - well, one big difference - between Anycast
for IPv4 and Anycast for IPv6.
Anycast on IPv4, those two servers that you just gave the same address
would have to be on two different segments.
So you would have to say, I don't care,
have VLAN10 and VLAN20.
Have both of them with the same subnet and put your servers on each
of those separate VLANs then have two separate routers advertise
those VLANs into OSPF or whatever.
So they would have to be separate otherwise what do you end up with?
Duplicate address exists on the network and you have that whole overlapping
IPv4 address problem.
With IPv6 you can actually do Anycast on the same segment.
You can actually put them literally on the same VLAN on the same
segment and you'll go to, well frankly whichever one answers neighbor
discovery first.
So we've been going for a while here.
We're going to take a quick break and we'll start up in the next
section here with wrapping up the rest of the introduction lesson.
[music]