|
0:00:13
|
In our next section of class here we're going to begin our discussion
|
|
0:00:16
|
of IP version 6, we're going to spend some time talking about
|
|
0:00:20
|
the general architecture of the protocol, how the
|
|
0:00:23
|
addressing format differs between IP version 4 and
|
|
0:00:27
|
IP version 6, then get into the specifics about the routing protocols
|
|
0:00:31
|
how we implement static routing, dynamic routing with RIP
|
|
0:00:35
|
EIGRP, OSPF and BGP
|
|
0:00:38
|
and then some of the additional tunneling mechanisms that we can
|
|
0:00:42
|
use to route IPv6 over the IP version 4 only network
|
|
0:00:46
|
or the reverse path where we can route IP version 4
|
|
0:00:49
|
over an IP version 6 only network.
|
|
0:00:53
|
Now as we know, the main motivation for migrating to
|
|
0:00:57
|
IP version 6 is that the address base is much larger
|
|
0:01:00
|
than IP version 4, now, we're not really going to get
|
|
0:01:04
|
into the details of the packet levels formats for IPv6
|
|
0:01:07
|
and a lot of the RFC level type details
|
|
0:01:12
|
you'll see I have lots of links to the specific RFCs that define
|
|
0:01:16
|
those different portions of the protocol whether it's talking about the
|
|
0:01:19
|
addressing or talking about the routing, so if you want to get
|
|
0:01:22
|
more detail on those, you can reference the RFCs
|
|
0:01:25
|
you'll see that for a lot of this information as long as you
|
|
0:01:28
|
understand how the addressing works, the principles of routing
|
|
0:01:32
|
are going to be almost identical between IP version 4
|
|
0:01:35
|
and IP version 6
|
|
0:01:38
|
so this means that if you really understand how OSPF version 2
|
|
0:01:42
|
works for IP version 4 routing, then you're inherently going to
|
|
0:01:45
|
understand how OSPF version 3 works as long as you can get
|
|
0:01:49
|
past the portion of the addressing.
|
|
0:01:53
|
Now specifically IPv6 uses 16 bytes for addresses
|
|
0:01:57
|
which means it has a range of 2 to the 128
|
|
0:02:01
|
or 340 undecillion addresses which is just an insanely
|
|
0:02:06
|
amount of large address base where with IP version 4 we
|
|
0:02:10
|
have 32 bits which means that it's about 4.2-4.3 billion addresses.
|
|
0:02:18
|
Now the notation for the IP version 4 versus IPv6
|
|
0:02:22
|
is where a lot of people get into trouble
|
|
0:02:25
|
especially during the implementation it's very easy to make a mistake
|
|
0:02:29
|
when we're typing in addresses that are so long where with IPv4
|
|
0:02:33
|
it's only four digits, it's not that many that we need to
|
|
0:02:35
|
deal with, but with IPv6 it is denoted in hex
|
|
0:02:40
|
where two digits is going to be one byte.
|
|
0:02:45
|
So we have the 16-byte address that is eight fields
|
|
0:02:50
|
that are separated by colons where typically
|
|
0:02:53
|
the first four fields separated by the colons are going to be
|
|
0:02:56
|
the network portion of the address where the
|
|
0:02:59
|
last 64 bits are going to be the host portion.
|
|
0:03:06
|
Now per the more recent RFC which is 4291 that defines
|
|
0:03:11
|
what the address allocations are supposed to be
|
|
0:03:14
|
you'll see that it has changed versus some of the older ones
|
|
0:03:17
|
that were defined in the late 90s when IPv6
|
|
0:03:20
|
specification was originally coming out
|
|
0:03:22
|
specifically, the unspecified address is ::/128
|
|
0:03:28
|
which is the 0 address.
|
|
0:03:31
|
The loopback address where in IP version 4 this is the
|
|
0:03:34
|
127/8 address, in IPv6 this is going to be ::1/128
|
|
0:03:42
|
so it's just all 0s followed by a 1
|
|
0:03:45
|
Multicast is always going to start with FF
|
|
0:03:50
|
so anything with the first eight bits being 1
|
|
0:03:53
|
that's going to be multicast addresses.
|
|
0:03:55
|
Specifically for our implementations, we'll see that this is going to
|
|
0:03:59
|
relate to the dynamic routing protocols
|
|
0:04:02
|
that are using multicast for transport of the hello packets
|
|
0:04:07
|
and then the updates between the neighbors.
|
|
0:04:09
|
We have the link local addresses that start with
|
|
0:04:13
|
FE80, this would be the equivalent of the 169.254/16
|
|
0:04:21
|
address base in IPv4
|
|
0:04:23
|
so these addresses are going to be really important
|
|
0:04:25
|
for IPv6 because regardless of what the global addressing that
|
|
0:04:30
|
we assign on the interface or to the devices
|
|
0:04:33
|
all links are going to have a link local unicast address
|
|
0:04:37
|
automatically assigned.
|
|
0:04:40
|
So technically anything that is not these first four
|
|
0:04:43
|
that's the unspecified loopback, the multicast and the link local
|
|
0:04:46
|
range, technically all of the rest of the stuff is going to fall
|
|
0:04:49
|
under the global unicast range which is the actual
|
|
0:04:53
|
addresses that would be globally routable on the
|
|
0:04:55
|
internet. We'll see the addresses that are left over
|
|
0:04:58
|
it's a much smaller subset that's actually being allocated
|
|
0:05:01
|
right now, generally, only addresses somewhere in the
|
|
0:05:05
|
2001 2000 and then some range after that
|
|
0:05:10
|
it's actually 2000::/3 is what's being allocated
|
|
0:05:15
|
so the vast majority of the rest of the global unicast addresses
|
|
0:05:19
|
are still currently reserved for allocations that are going to
|
|
0:05:22
|
happen much further down the road.
|
|
0:05:26
|
Now the link local addresses again, are the ones that are going to
|
|
0:05:30
|
start with the FE80, we'll see specifically in the IOS's
|
|
0:05:34
|
implementation every time that we turn IPv6 on whether we are
|
|
0:05:40
|
routing it or not, so any time an IPv6 address is
|
|
0:05:44
|
assigned to the interface, the interface is also going to get
|
|
0:05:46
|
a link local address.
|
|
0:05:49
|
Now this is going to be used for the stateless auto configuration
|
|
0:05:54
|
which for the actual end hosts like your Windows or Mac OS
|
|
0:05:58
|
or Linux machine that's connecting to the LAN, they will use
|
|
0:06:02
|
stateless auto configuration in order to learn what is the
|
|
0:06:05
|
actual routable prefix that the routers have assigned onto the link
|
|
0:06:11
|
then they can do the neighbor discover which is going to be the
|
|
0:06:13
|
replacement for the address resolution protocol
|
|
0:06:17
|
and the router discovery which is kind of a replacement for
|
|
0:06:21
|
DHCP where without having to do an actual allocation of a pool of
|
|
0:06:27
|
addresses, the end host can still figure out who is the router
|
|
0:06:30
|
under the segment and then start to route traffic out to
|
|
0:06:33
|
other remote hosts.
|
|
0:06:36
|
Previously there was also another space that was called the
|
|
0:06:38
|
site local addresses
|
|
0:06:40
|
which originally were designed to be locally significant within
|
|
0:06:44
|
an internal network that were not going to be
|
|
0:06:48
|
publicly routable, these are the ones that start with the FEC0 range
|
|
0:06:53
|
so specifically it's FEC0/10
|
|
0:06:56
|
This was originally defined in RFC 1884, but now it's
|
|
0:07:02
|
been removed, it's been deprecated in a more recent RFC 3879
|
|
0:07:07
|
basically because nobody could agree on what the
|
|
0:07:10
|
site definition actually was, so you could technically still
|
|
0:07:14
|
use these addresses if you wanted to assign them FEC0
|
|
0:07:18
|
they're not going to be publicly routable in the BGP
|
|
0:07:20
|
table so when a provider is accepting advertisements in
|
|
0:07:25
|
they should be filtering prefixes that would be in this range.
|
|
0:07:29
|
Essentially they are then replaced by what's now known as
|
|
0:07:32
|
the unique local addresses.
|
|
0:07:35
|
So the unique locals or the ULAs, these are the equivalent
|
|
0:07:39
|
of the private use addresses for IPv4 which is the 10 network
|
|
0:07:44
|
the 172.16
|
|
0:07:47
|
and the 192.168
|
|
0:07:49
|
these start in the FC00::/7 range
|
|
0:07:56
|
so either FC or FD
|
|
0:08:00
|
which are specified in RFC 4193
|
|
0:08:04
|
Now technically, these addresses are not going to be globally routable
|
|
0:08:08
|
in the BGP table, but since the address space is so large
|
|
0:08:13
|
it's pretty likely that the address is going to be unique
|
|
0:08:16
|
anyways, so if you take a look at that particular RFC
|
|
0:08:20
|
there's a recommendation as to how the address should be
|
|
0:08:23
|
derived based on basically a random number function
|
|
0:08:27
|
and since there's so many bits left over, essentially a 121 bits left over
|
|
0:08:32
|
for the rest of the address it's very very unlikely
|
|
0:08:35
|
that two hosts would end up assigning the same address.
|
|
0:08:38
|
So this is any address base that you could use internal
|
|
0:08:42
|
toward your network where if you were to not get an allocation
|
|
0:08:45
|
from IANA, so if you want to do some sort of test deployment
|
|
0:08:49
|
without actually allocating addresses, this is what you should
|
|
0:08:52
|
then use is the FC00 range.
|
|
0:08:55
|
Now the global unicast ones these are the actual public
|
|
0:08:59
|
routable addresses on the internet.
|
|
0:09:01
|
Technically, again it's everything that is outside of the unspecified
|
|
0:09:05
|
the loopback, the multicast and the link local
|
|
0:09:08
|
but allocation wise, if you look on the IANA website
|
|
0:09:12
|
it's actually a much much smaller range that they're currently
|
|
0:09:16
|
allocating to the different routing authorities.
|
|
0:09:21
|
Now the RFC technically says that any address that is being
|
|
0:09:26
|
allocated in the network to an end host must have a
|
|
0:09:31
|
64-bit interface identifier that uses the EUI-64 addressing format.
|
|
0:09:39
|
So this means that your end host or your router who actually
|
|
0:09:42
|
has an IPv6 address assigned they're always supposed to be /64
|
|
0:09:47
|
so even though that's basically half of the address range that is on a
|
|
0:09:53
|
per subnet basis, this is what the end hosts would be looking for
|
|
0:09:58
|
when they're trying to do the stateless auto configuration.
|
|
0:10:01
|
So the basically half of the address is going to be the
|
|
0:10:05
|
network portion and then the other half is going to be the host portion.
|
|
0:10:09
|
Specifically in IOS's implementation, you can technically configure it to
|
|
0:10:13
|
be anything that you want, but for the actual end hosts
|
|
0:10:17
|
you should be assigning them as /64s
|
|
0:10:19
|
For the point-to-point links between the routers, you could
|
|
0:10:22
|
technically use /127 for just two individual addresses
|
|
0:10:26
|
ultimately it depends on how you want the routing design to work.
|
|
0:10:31
|
But for the end hosts, generally they should have a /64
|
|
0:10:35
|
address for the network and then they're going to figure out
|
|
0:10:38
|
their end host interface ID based on the EUI-64 format.
|
|
0:10:44
|
Now specifically this format is part of the addressing architecture's
|
|
0:10:49
|
specification in RFC 4291
|
|
0:10:52
|
There's a section towards the end in the appendix
|
|
0:10:55
|
that shows you how to do the conversion
|
|
0:10:58
|
into the EUI-64 address format.
|
|
0:11:01
|
We'll take a look at this on the IOS command line.
|
|
0:11:04
|
This is how the router automatically originates or automatically assigns
|
|
0:11:08
|
a link local address on a per interface basis
|
|
0:11:13
|
or if you are doing automatic assignment of the interface
|
|
0:11:16
|
ID or you're doing stateless auto configuration
|
|
0:11:19
|
this is how the router is going to figure out what the end host
|
|
0:11:22
|
address should be.
|
|
0:11:23
|
So in the case of an Ethernet LAN
|
|
0:11:27
|
that we are assigning an IPv6 address on
|
|
0:11:30
|
it's going to take the seventh most significant bit of the address
|
|
0:11:34
|
which is called the universal local bit, it's going to flip this
|
|
0:11:39
|
bit, so it's going to invert it from either a 0 to a 1 or
|
|
0:11:43
|
a 1 to a 0
|
|
0:11:45
|
then add padding that is FFFE in the middle of the address
|
|
0:11:52
|
because the problem is an Ethernet Mac address
|
|
0:11:54
|
is only 48 bits long so we need to get up to 64
|
|
0:12:01
|
so by adding the additional two bytes into it
|
|
0:12:04
|
we can get to a 64-bit interface identifier
|
|
0:12:07
|
which is going to allow us to have a subnet mask of
|
|
0:12:10
|
/64 at the link level.
|
|
0:12:17
|
Now we'll see design wise the potential problem of doing this
|
|
0:12:19
|
is that it gets very difficult to keep track of in the network
|
|
0:12:22
|
what are the actual addresses of the end hosts in the topology.
|
|
0:12:26
|
So for a real implementation when you're numbering your
|
|
0:12:30
|
routers, usually it's probably not a good idea to use the
|
|
0:12:33
|
EUI-64 address unless you have some sort of external
|
|
0:12:37
|
mapping table or maybe DNS set up that you can quickly
|
|
0:12:41
|
figure out what are the particular addresses that correspond to the
|
|
0:12:44
|
routers because otherwise, we're essentially going to have to
|
|
0:12:47
|
keep track of what is the Mac address of the router
|
|
0:12:51
|
and if there is a change in the Mac address
|
|
0:12:54
|
let's say for example one of the line cards on the router
|
|
0:12:56
|
fails and we need to swap it out, it means that the
|
|
0:12:59
|
end host address is going to change, so this
|
|
0:13:02
|
could potentially then affect our filtering or our
|
|
0:13:05
|
routing design in the topology if the router's address is changing.
|
|
0:13:11
|
So again, technically the RFC says that you're supposed to
|
|
0:13:13
|
automatically assign this, but from the actual IOS implementation
|
|
0:13:18
|
point of view, you can do it however you want.
|
|
0:13:22
|
Now another key point that we'll see here that has changed
|
|
0:13:25
|
with IP version 6 is the neighbor discovery process
|
|
0:13:29
|
that is now part of the ICMP version 6 stack
|
|
0:13:33
|
which is essentially a replacement to the address resolution protocol.
|
|
0:13:39
|
Now the reason that this is important is that with IP version 4
|
|
0:13:43
|
ARP was kind of an afterthought where it's technically a separate
|
|
0:13:47
|
protocol that is unrelated to IP
|
|
0:13:50
|
When we look at it from a Layer 2 point of view
|
|
0:13:53
|
IP uses the Layer 2 protocol type code 0 by 800
|
|
0:13:57
|
where IP version 4 ARP uses 0 by 806
|
|
0:14:03
|
In the case of IP version 6 this is already built in for us
|
|
0:14:06
|
through the ICMP stack so in the case of Ethernet, this is going to
|
|
0:14:10
|
be a 100 percent automatic for us.
|
|
0:14:12
|
The only time that we would really need to worry about this
|
|
0:14:15
|
is if there's some sort of filtering that is blocking the
|
|
0:14:18
|
ICMP neighbor discovery process, then the routers would
|
|
0:14:21
|
not be able to resolve their IPv6 addresses to their Ethernet
|
|
0:14:25
|
Mac addresses.
|
|
0:14:30
|
Additionally, just like we saw in IP version 4
|
|
0:14:33
|
there's some design problems we need to think about
|
|
0:14:35
|
when we are running the protocol over multipoint
|
|
0:14:38
|
non-broadcast interfaces which in our particular case
|
|
0:14:43
|
would be a multipoint frame relay link, but the same design
|
|
0:14:46
|
case would be if we were running it over multipoint
|
|
0:14:48
|
ATM or if we had legacy ISDN dial-up and we were trying to
|
|
0:14:53
|
run IPv6 over that.
|
|
0:14:57
|
Now technically there is a specification for inverse
|
|
0:15:01
|
neighbor discovery which would be the equivalent
|
|
0:15:04
|
of inverse ARP for frame relay, but I don't believe
|
|
0:15:07
|
that Cisco IOS actually implements this even in the
|
|
0:15:10
|
newest versions
|
|
0:15:11
|
so we'll see the end result of this is that for multipoint
|
|
0:15:15
|
non-broadcast interfaces, we always need to provide
|
|
0:15:18
|
a static Layer 3 to Layer 2 mapping for the IPv6 stack.
|
|
0:15:25
|
Now this is going to be the same exact logic as we saw
|
|
0:15:27
|
previously with the frame relay map for IPv4
|
|
0:15:31
|
which is going to resolve our local Layer 2 address
|
|
0:15:35
|
to our remote Layer 3 address and in the case that we want to
|
|
0:15:40
|
send multicasts over the link, we would need to
|
|
0:15:43
|
tell the frame relay interface to support pseudo broadcast for
|
|
0:15:46
|
that particular circuit.
|
|
0:15:52
|
So similar to IP version 4 where RIP is using the
|
|
0:15:55
|
address 224.0.0.9
|
|
0:15:59
|
for IPv4
|
|
0:16:02
|
then IPv6 is going to use FF02::9
|
|
0:16:07
|
so this means that if we were running RIPng over frame relay
|
|
0:16:10
|
just like if we were running RIP version 2 over frame relay for
|
|
0:16:13
|
IPv4, not only would we need our unicast Layer 3 to
|
|
0:16:17
|
Layer 2 mapping, but we would also have to make sure that
|
|
0:16:20
|
broadcast support is included.
|
|
0:16:24
|
So let's take a look at this basic process on the command line
|
|
0:16:28
|
where we're enabling IPv6 routing on the Ethernet segment
|
|
0:16:31
|
and then also on the non-broadcast multi-access segment
|
|
0:16:35
|
and we'll look at the differences in the automatic resolution
|
|
0:16:38
|
through the ICMPv6 neighbor discovery.
|
|
0:16:44
|
So the topology that we're using for IPv6
|
|
0:16:47
|
is essentially the same as the previous sections
|
|
0:16:50
|
where I have the transit network here configured
|
|
0:16:53
|
as 155.28.YY.Y
|
|
0:17:00
|
where Y is the router numbers
|
|
0:17:02
|
so for example between routers 1, 4 and 6 this
|
|
0:17:05
|
would be 155.28.146 where Router 1's address is
|
|
0:17:12
|
.1, Router 4's address is 4
|
|
0:17:14
|
Router 6's address is .6
|
|
0:17:18
|
Now to keep the IPv6 addresses a little bit easier to
|
|
0:17:21
|
keep track of, I'm going to use the same type of addressing
|
|
0:17:24
|
structure, but its key to note that since I'm using what
|
|
0:17:29
|
previously was decimal numbers in a hexadecimal notation
|
|
0:17:35
|
in binary it's not going to be the same values.
|
|
0:17:39
|
So even though the addresses are going to look similar
|
|
0:17:41
|
when we look at the address that is 2001:155:28:146::1/64
|
|
0:17:52
|
in binary this is a completely different address
|
|
0:17:56
|
than IPv4's equivalent 155.28.146.1
|
|
0:18:05
|
so within the scope of the lab exam, this is one of the
|
|
0:18:07
|
big issues that you need to be aware of with IPv6
|
|
0:18:11
|
that if you make a mistake in the addressing, then it's going to
|
|
0:18:14
|
cause a lot of problems in the upper layer protocols and it's
|
|
0:18:17
|
very unlikely that you would get credit for those particular sections.
|
|
0:18:20
|
So definitely double check and triple check your work to make sure that
|
|
0:18:23
|
you're not transposing any of the digits because minor mistakes
|
|
0:18:28
|
like that can really cost you a lot of points within the scope of the exam.
|
|
0:18:33
|
So let's now take a look at the command line between Router 1
|
|
0:18:36
|
4 and 6 and we will configure IPv6 on their LAN interfaces.
|
|
0:18:43
|
Now before I do this, it might be a good idea just to test
|
|
0:18:46
|
my basic IP version 4 connectivity
|
|
0:18:49
|
to make sure that there's no underlying problems in the
|
|
0:18:52
|
Ethernet LAN or in the frame relay non-broadcast interfaces
|
|
0:18:57
|
because I don't want to be troubleshooting something
|
|
0:18:59
|
in IPv6 that ends up to be a lower layer problem like simply
|
|
0:19:03
|
the interface being shut down or the VLAN is not correctly assigned.
|
|
0:19:10
|
So on Router 1 first thing I'm going to do is make sure I
|
|
0:19:12
|
can ping 155.28.146.4
|
|
0:19:19
|
and 6
|
|
0:19:21
|
so this is routers 1, 4 and 6 over the LAN.
|
|
0:19:25
|
Now before I actually enable the IPv6 protocol, I'm going to
|
|
0:19:28
|
turn some of the debugs on
|
|
0:19:30
|
so we can see exactly what's going on with the ICMPv6
|
|
0:19:33
|
neighbor discovery process.
|
|
0:19:35
|
We're going to look at the debug ipv6 packet detail
|
|
0:19:41
|
and the debug ipv6 neighbor discovery
|
|
0:19:53
|
Next step on Router 1 let's go to the LAN interface here which is
|
|
0:19:57
|
Fast Ethernet 0/0
|
|
0:19:59
|
I'll configure an IPv6 address
|
|
0:20:02
|
that is 2001:155:58 or actually 28
|
|
0:20:10
|
28:146::1/64
|
|
0:20:19
|
now we can see as soon as I assign the prefix
|
|
0:20:22
|
the router automatically starts running the ICMPv6 neighbor
|
|
0:20:26
|
discovery protocol which is going to do a couple different
|
|
0:20:29
|
things for us.
|
|
0:20:31
|
First and foremost, it's going to run the duplicate
|
|
0:20:33
|
address detection feature to make sure that I have not
|
|
0:20:37
|
assigned an address that someone on that same particular
|
|
0:20:40
|
link already has.
|
|
0:20:45
|
Now in IPv4 we can kind of indirectly figure this out
|
|
0:20:49
|
if we hear an unsolicited ARP reply which is called a
|
|
0:20:54
|
gratuitous ARP for the same address that we have
|
|
0:20:57
|
assigned. Based on this we can assume that someone has a
|
|
0:21:01
|
duplicate address configured as us.
|
|
0:21:04
|
But in the case of IPv6 there's a specific question
|
|
0:21:07
|
and answer protocol which is the duplicate address detection
|
|
0:21:11
|
for ICMPv6 neighbor discovery that if the address is not unique
|
|
0:21:16
|
it's not going to allow the router to assign it there or
|
|
0:21:18
|
it's not going to allow the end host to assign it.
|
|
0:21:25
|
So once Router 1 figures out that no one else has this
|
|
0:21:27
|
address assigned, it says through ICMP neighbor discovery
|
|
0:21:31
|
I'm sending a neighbor advertisement or the NA
|
|
0:21:34
|
for my particular address on Fast Ethernet 0/0
|
|
0:21:39
|
This is the equivalent of the IPv4 gratuitous ARP
|
|
0:21:45
|
so it's essentially an ARP reply that someone did not ask for.
|
|
0:21:51
|
We're doing this in order to update their basically
|
|
0:21:54
|
ARP cache so they know what Mac address corresponds
|
|
0:21:58
|
to my local IPv6 address.
|
|
0:22:05
|
Now additionally if we scroll up a little bit further, we'll see
|
|
0:22:07
|
the first thing that Router 1 did was to add the prefix that we
|
|
0:22:14
|
assigned to the link and then elect a link local address
|
|
0:22:20
|
which here is FE80 20D BCFF FE1F 8C00
|
|
0:22:29
|
so again, anything that starts with FE80, this is not routable
|
|
0:22:34
|
between the interfaces on the device.
|
|
0:22:38
|
So it's only locally significant between the devices on that
|
|
0:22:43
|
particular LAN.
|
|
0:22:44
|
Now from this format here, we should be able to
|
|
0:22:48
|
infer what the Mac address that Router 1 has assigned on
|
|
0:22:51
|
its interface, so if we were to look at this EUI-64 address
|
|
0:22:59
|
and we have actually one leading 0 that's not shown
|
|
0:23:02
|
up there
|
|
0:23:03
|
If we were to take the first byte which in this case is 0 by 02
|
|
0:23:10
|
and look at this in binary which 0000 0010
|
|
0:23:17
|
and then we were to take the seventh most significant
|
|
0:23:20
|
bit so we have 1234 5678
|
|
0:23:25
|
we take the seventh most significant bit and invert this
|
|
0:23:29
|
so now this becomes 0 by 00
|
|
0:23:32
|
which is 0000 0000
|
|
0:23:36
|
then remove the padding
|
|
0:23:39
|
that is FF FE
|
|
0:23:43
|
so we essentially now have 000D BC1F 8C00
|
|
0:23:55
|
we should see that this should be the Mac address
|
|
0:23:57
|
that Router 1 has assigned on its Fast Ethernet 0/0
|
|
0:24:14
|
so we can see its value there 000D BC1F 8C00
|
|
0:24:21
|
so automatically as soon as we start running the IPv6
|
|
0:24:24
|
process, the router is going to generate a link local address
|
|
0:24:27
|
which FE80 plus the address that is derived from the Mac address.
|
|
0:24:36
|
Now the key point here is that this is going to be used
|
|
0:24:38
|
for the automatic address configuration, so for any hosts
|
|
0:24:46
|
that are on our link they're not going to be
|
|
0:24:49
|
manually assigning what their IPv6 addresses are.
|
|
0:24:54
|
If we look at Router 1 and look at the show ipv6 interface
|
|
0:24:59
|
Fast Ethernet 0/0
|
|
0:25:03
|
it says that right now we have this particular link local
|
|
0:25:06
|
address assigned, we have this global address assigned
|
|
0:25:12
|
this is the particular prefix.
|
|
0:25:15
|
So right now we have a 64-bit network portion
|
|
0:25:18
|
we have a 64-bit host portion.
|
|
0:25:22
|
The actual full address here for Router 1 if we were to
|
|
0:25:27
|
include the zeros would then be 2001: 0155:0028:0146:0000:0000:0000:0001
|
|
0:25:48
|
so this would be our full 128-bit address
|
|
0:25:53
|
we can see that by default the router is going to show the
|
|
0:25:55
|
short notation for this where it's going to take the
|
|
0:25:59
|
maximum number of zeros and then replace that with the
|
|
0:26:03
|
two colons.
|
|
0:26:06
|
So you'll see in cases where there are multiple sets of zeros
|
|
0:26:11
|
in a row, the router is only going to be able to use the
|
|
0:26:14
|
double colon notation once
|
|
0:26:16
|
because if we said 2001::155::1
|
|
0:26:22
|
we essentially wouldn't know how many zeros did we delete
|
|
0:26:25
|
in the first portion of the address versus how many zeros did we delete in
|
|
0:26:29
|
the second portion of the address.
|
|
0:26:37
|
So we can see once I type that address in there
|
|
0:26:40
|
the router's actually configured with the transport input
|
|
0:26:44
|
telnet command by default
|
|
0:26:47
|
which means that we are going to if type an address in there
|
|
0:26:50
|
it's going to try to telnet to the address -- actually it's
|
|
0:26:55
|
transport preferred telnet so if I wanted to turn this
|
|
0:26:58
|
behavior off and sometimes this could be useful if you want to
|
|
0:27:02
|
keep DNS resolution on but you don't want the
|
|
0:27:06
|
router to automatically telnet when you mistype a command
|
|
0:27:10
|
this would be under the console.
|
|
0:27:12
|
You would say transport preferred is none.
|
|
0:27:17
|
So by default, the preferred transport is telnet.
|
|
0:27:20
|
So now if I type that address in, the router's not going to try to telnet to it.
|
|
0:27:24
|
But it still would allow me to do DNS resolution
|
|
0:27:28
|
if I still said ip domain lookup
|
|
0:27:38
|
so kind of unrelated to IPv6 there, just a side note to keep in mind.
|
|
0:27:45
|
Now again, if we look at the show ipv6 interface Fast Ethernet 0/0
|
|
0:27:51
|
right now the router does not have IPv6 unicast routing on
|
|
0:27:57
|
so we see that it is not sending ICMP ND router advertisements
|
|
0:28:02
|
or the RAs.
|
|
0:28:04
|
Right now essentially Router 1 is just an end host for IPv6
|
|
0:28:09
|
we are not announcing ourselves as a router and we do not have
|
|
0:28:13
|
ourselves configured for auto configuration of hosts on the link.
|
|
0:28:20
|
In order to do this, we would have to turn the routing process on.
|
|
0:28:23
|
So just like we have IP routing on, we need to simply say
|
|
0:28:27
|
ipv6 unicast routing.
|
|
0:28:36
|
Once we do this, we can see that Router 1 starts to announce
|
|
0:28:39
|
itself as a Router 1, it says it's sending the ICMP neighbor discovery
|
|
0:28:43
|
router advertisement to the all host multicast which is FF02::1
|
|
0:28:50
|
Router is saying the MTU of my link is 1500
|
|
0:28:54
|
This is the prefix that you could use for auto config
|
|
0:28:58
|
and this is the specific time that you can use it for.
|
|
0:29:03
|
So you can configure a priority between the routers
|
|
0:29:06
|
if you want to try to prefer one over the other
|
|
0:29:08
|
this is kind of like a light-weight version of DHCP
|
|
0:29:12
|
so we cannot use this to assign options like DNS server
|
|
0:29:16
|
or the other DHCP options like the call manager server
|
|
0:29:21
|
for IP phones. For that, we're still going to need DHCPv6
|
|
0:29:26
|
but for just an address assignment and giving the end host a default gateway
|
|
0:29:29
|
stateless auto configuration is going to automatically do that for us.
|
|
0:29:39
|
So now let's go to someone else on the LAN, let's go to Router 4
|
|
0:29:43
|
and instead of manually assigning an address to the link
|
|
0:29:46
|
let's simply say on Fast Ethernet 0/1
|
|
0:29:50
|
that the IPv6 address is going to come from auto config.
|
|
0:29:56
|
So now we should see on Router 1 that there was a
|
|
0:29:58
|
router solicitation being sent which essentially means that
|
|
0:30:04
|
Router 4 was asking Router 1
|
|
0:30:11
|
that it wants an address to be assigned.
|
|
0:30:14
|
So once Router 4 enables the IPv6 process on the interface
|
|
0:30:19
|
it means that it's automatically going to choose a link local address.
|
|
0:30:23
|
So in this particular case, the link local address of Router 4
|
|
0:30:26
|
is FE80::21A:6CFF:FE6B etc.
|
|
0:30:38
|
This router solicitation that comes in, this is essentially
|
|
0:30:41
|
an ARP request just for the routing devices on the segment.
|
|
0:30:47
|
So this is different than the neighbor solicitation
|
|
0:30:50
|
which is the NS
|
|
0:30:52
|
the neighbor advertisement and the neighbor solicitation
|
|
0:30:55
|
those are like the ARP request and the ARP responses.
|
|
0:30:58
|
The router advertisement and the router solicitation
|
|
0:31:02
|
those are ARP requests and responses that are specifically for
|
|
0:31:05
|
the routing devices on the network.
|
|
0:31:14
|
So if we now look at the end result of this on Router 4
|
|
0:31:17
|
and look at the show ipv6 interface Fast Ethernet 0/1
|
|
0:31:23
|
we can see that it did learn the prefix 2001:155:28:146
|
|
0:31:30
|
it says stateless address auto config is enabled.
|
|
0:31:34
|
Our end host 21A:6CFF etc.
|
|
0:31:39
|
this is coming from the Mac address of the interface.
|
|
0:31:43
|
So again, if we were to do the reverse conversion here
|
|
0:31:46
|
it essentially means that Router 2 -- Router 4's
|
|
0:31:49
|
Mac address should be 001a:6c:6b:d3:9b
|
|
0:32:00
|
If I show interface Fast Ethernet 0/1 and include
|
|
0:32:04
|
the burned in address
|
|
0:32:06
|
001a:6c:6b:d3:9b so we can see that's a match there.
|
|
0:32:14
|
Now again, it's really not going to matter what the end host
|
|
0:32:16
|
of the address or the address of the end host is
|
|
0:32:20
|
if this is not a routing device.
|
|
0:32:23
|
The problem is that if you're trying to keep track of who are the
|
|
0:32:26
|
routers versus the end hosts, most likely
|
|
0:32:28
|
you wouldn't want the router's address to be dynamic.
|
|
0:32:31
|
So the same reason you normally wouldn't have your
|
|
0:32:33
|
router learning an address through DHCP for IP version 4
|
|
0:32:38
|
you generally would not want to do the same thing for
|
|
0:32:40
|
IPv6 so once the router turns unicast routing on
|
|
0:32:45
|
it's automatically going to start sending those router
|
|
0:32:48
|
advertisements, then any of the end hosts on the interfaces
|
|
0:32:53
|
they would automatically learn the prefix from the router
|
|
0:32:56
|
and then basically use is as a default gateway.
|
|
0:33:03
|
So we can see now that I turned IPv6 unicast routing on
|
|
0:33:06
|
Router 1 says I'm sending router advertisements every 200 seconds
|
|
0:33:11
|
the router advertisements are live for 1800 seconds
|
|
0:33:14
|
which is basically the idle timeout
|
|
0:33:18
|
then we could change the specific attributes for the
|
|
0:33:20
|
stateless auto configuration. If we go to the link level
|
|
0:33:24
|
and look at the IPv6
|
|
0:33:29
|
neighbor discovery ipv6 nd
|
|
0:33:32
|
the advertisement interval this would be to say
|
|
0:33:39
|
how often we're going to send the advertisement.
|
|
0:33:42
|
We could change this with the RA interval
|
|
0:33:46
|
so if I say I could send it every five seconds
|
|
0:33:50
|
the RA life time would be how long is that valid for.
|
|
0:33:53
|
If I did not want to send the advertisements, I would
|
|
0:33:57
|
say ipv6 nd suppress ra
|
|
0:34:00
|
so let's say that there's multiple routers on the segment, but I
|
|
0:34:03
|
only want one of them to be used as the default gateway.
|
|
0:34:06
|
On the ones that I don't want to be used as the
|
|
0:34:09
|
gateways, I would tell them to suppress the routing advertisements.
|
|
0:34:15
|
So a lot of these general protocol things about IPv6
|
|
0:34:20
|
it would be assumed that you know this before you get to the
|
|
0:34:22
|
exam, so a lot of this I'm not going to spend tons of time on
|
|
0:34:25
|
today, there's a lot of good resources for this that you can
|
|
0:34:29
|
see in either the Cisco documentation in the RFC, there's a lot of good books
|
|
0:34:34
|
on IPv6, one of them specifically that you may want to take a look at
|
|
0:34:40
|
is the IPv6 theory protocol and practice.
|
|
0:34:52
|
Now this is a vendor independent book so similar to that MPLS enabled
|
|
0:34:58
|
applications I was talking about before, this is IPv6 from a
|
|
0:35:02
|
standardized point of view what are the design problems
|
|
0:35:05
|
they're trying to solve with it versus IPv4, what do the
|
|
0:35:08
|
RFCs say that the implementation should do, it's not really going to
|
|
0:35:12
|
focus on the specific syntax for Cisco IOS's implementation.
|
|
0:35:17
|
Now there are separate books on that, that talk about configuration
|
|
0:35:21
|
of this on IOS, if we look for IPv6 Cisco IOS
|
|
0:35:29
|
there is -- you can see there's some other ones that aren't Cisco
|
|
0:35:32
|
press.
|
|
0:35:36
|
There's one specifically that is
|
|
0:35:40
|
let's see I think it's IPv6 configuration on Cisco IOS
|
|
0:35:49
|
let's say Cisco press
|
|
0:36:05
|
and it must be this one here implementing Cisco IPv6 networks
|
|
0:36:10
|
which is pretty similar to the configuration guides
|
|
0:36:14
|
where it just talks about how do you implement the specific
|
|
0:36:17
|
protocols in IPv6, so a lot of this configuration we're going to go
|
|
0:36:22
|
over today quickly, but again, if you understand the IP version 4
|
|
0:36:26
|
counterparts, then it really shouldn't be that much further
|
|
0:36:29
|
to get the IPv6 implementation.
|
|
0:36:32
|
The biggest thing that most people have trouble with is to understand
|
|
0:36:35
|
how the addressing structure works and then to make sure
|
|
0:36:38
|
that you don't make any minor mistakes when we're implementing
|
|
0:36:41
|
the actual addressing on the interfaces.
|
|
0:36:46
|
But as we can see here on the routers' LAN interfaces
|
|
0:36:50
|
there's not really that much configuration you need to do
|
|
0:36:52
|
as long as you enable the protocol through ICMP
|
|
0:36:56
|
neighbor discovery, the routers should automatically figure out
|
|
0:36:59
|
who are the other devices on the link, then if we send a
|
|
0:37:03
|
packet to Router 1, we can see we didn't drop one packet first
|
|
0:37:09
|
which is normally what you would do with IPv4
|
|
0:37:12
|
because the router waits for traffic to be sent before
|
|
0:37:15
|
it sends an ARP request for the particular destination.
|
|
0:37:19
|
In the case of IPv6, this address table is already
|
|
0:37:22
|
pre-populated because as soon as we turn the IPv6
|
|
0:37:26
|
stack on, the device automatically starts sending the neighbor
|
|
0:37:30
|
advertisements and again, that's the equivalent of the
|
|
0:37:33
|
gratuitous ARP in IPv4 where it's an ARP reply
|
|
0:37:39
|
without getting the ARP request to begin with.
|
|
0:37:44
|
So next let's take a look at an example of running IPv6
|
|
0:37:47
|
over the non-broadcast frame relay segments
|
|
0:37:52
|
so between Router 1 and Router 5, right now on this
|
|
0:37:58
|
segment we have for IPv4 we have 155.28.0.0/24 assigned
|
|
0:38:07
|
where Router 1 is .1 Router 5 is .5
|
|
0:38:14
|
On Router 1's end, this is configured to use a point-to-point
|
|
0:38:18
|
sub interface
|
|
0:38:20
|
if we look at the show ip interface brief
|
|
0:38:26
|
this is serial 0/0.1
|
|
0:38:30
|
so similar to IPv4,
|
|
0:38:33
|
point-to-point interfaces do not require Layer 3 to Layer 2
|
|
0:38:37
|
resolution for IPv6
|
|
0:38:41
|
So this essentially means the only thing I would need to do
|
|
0:38:44
|
here is go to the link level and say ipv6 address
|
|
0:38:50
|
I'll say 2001:155:28::1/64
|
|
0:38:56
|
and essentially that's it.
|
|
0:39:03
|
We're assuming here that there's not going to be any
|
|
0:39:06
|
problems in the Layer 3 to Layer 2 resolution
|
|
0:39:09
|
because when the routing table points a packet towards
|
|
0:39:12
|
serial 0/0.1 the router already knows that there's
|
|
0:39:16
|
only one possible Layer 2 destination.
|
|
0:39:19
|
So it's always going to use circuit number 105
|
|
0:39:22
|
in the Layer 2 frame that is being sent towards that interface.
|
|
0:39:30
|
Now on the other end of the link from Router 5's perspective
|
|
0:39:33
|
this is a multipoint non-broadcast interface
|
|
0:39:38
|
so Router 5 will need to know specifically what DLCI number do I need to use
|
|
0:39:42
|
in order to reach Router 1
|
|
0:39:48
|
So first let's turn routing on let's say ipv6 unicast routing
|
|
0:39:54
|
then on the frame relay interface, we'll say IPv6
|
|
0:39:58
|
address 2001:155:28::5/64
|
|
0:40:08
|
if we were to look at the debug frame relay packets
|
|
0:40:14
|
and debug ipv6 packets
|
|
0:40:32
|
we should see that when we try to send packet out to
|
|
0:40:34
|
Router 1's address on the frame relay interface
|
|
0:40:39
|
the frame relay process is going to tell us that we do not
|
|
0:40:42
|
know what is the Layer 2 circuit number we need to use
|
|
0:40:45
|
for that particular destination.
|
|
0:40:48
|
So frame relay is saying encapsulation has failed because
|
|
0:40:50
|
there's no map entry link. Basically it means there's no frame relay mapping.
|
|
0:40:56
|
IPv6 is reporting back that encapsulation is failing because
|
|
0:40:59
|
it could not queue for resolution.
|
|
0:41:02
|
This again means that there's a problem in the Layer 3 to
|
|
0:41:05
|
Layer 2 mapping, the Layer 3 to Layer 2 resolution.
|
|
0:41:13
|
So essentially what this means here is that we're missing
|
|
0:41:16
|
the frame relay mapping.
|
|
0:41:18
|
For this particular version of IOS, they do not implement
|
|
0:41:21
|
inverse neighbor discovery and like I said, even in the
|
|
0:41:24
|
in the newest IOS versions, I don't think they have added support for it.
|
|
0:41:28
|
So this means that on any multipoint non-broadcast interface
|
|
0:41:34
|
we always need a manual resolution for the next hop values
|
|
0:41:39
|
of the IPv6 neighbors on the other ends of the link.
|
|
0:41:45
|
So on Router 5 we'll say to get to Router 1
|
|
0:41:48
|
which is this address
|
|
0:41:52
|
followed by a 1
|
|
0:41:53
|
we need to use circuit 501
|
|
0:41:56
|
and I'm going to assume down the road that I'm running some
|
|
0:41:59
|
routing protocol, so I'm going to include the pseudo broadcast support.
|
|
0:42:10
|
Now at this point, we can see that we do have reachability
|
|
0:42:13
|
to Router 1
|
|
0:42:14
|
using the global unicast address.
|
|
0:42:18
|
Now we'll see this does not imply that I have link local
|
|
0:42:23
|
reachability to Router 1
|
|
0:42:25
|
which is going to be necessary once we actually run our routing protocols.
|
|
0:42:32
|
So if this were point-to-point on both sides
|
|
0:42:36
|
either point-to-point sub interfaces for frame relay
|
|
0:42:39
|
or if we were to run IPv6 on the point-to-point serial link
|
|
0:42:43
|
between Router 4 and Router 5, then we would not
|
|
0:42:46
|
need to worry about the Layer 3 to Layer 2 resolution.
|
|
0:42:49
|
The same thing with the Ethernet between routers 1, 4 and 6
|
|
0:42:54
|
since the ICMPv6 neighbor discovery is going to take care
|
|
0:43:00
|
of the Mac address to IPv6 mapping, we don't have to
|
|
0:43:04
|
worry about any of the Layer 3 to Layer 2 resolution.
|
