IPv 6

Table of Contents
IPv6.............................................................................................................................................................1
Course Description................................................................................................................................1
Course Highlights..................................................................................................................................1
Requirements.........................................................................................................................................1
Course Schedule....................................................................................................................................1
Introduction to IPv6..................................................................................................................................1
Shortening IPv6 Addresses.......................................................................................................................4
How to find IPv6 Prefix................................................................................................................................5
IPv6 Address Types......................................................................................................................................8
Unicast.....................................................................................................................................................9
Global Unicast......................................................................................................................................9
Unique Local........................................................................................................................................9
Link-Local...........................................................................................................................................10
Site-Local...........................................................................................................................................11
Unspecified........................................................................................................................................11
Loopback...........................................................................................................................................11
Multicast................................................................................................................................................11
Anycast..................................................................................................................................................12
IPv6 Address Assignment Example........................................................................................................12
IPv6 Global Unicast Prefix Assignments...........................................................................................12
IPv6 Global Unicast Subnet Assignments..........................................................................................14
Conclusion............................................................................................................................................16
IPv6 EUI-64 explained............................................................................................................................17
IPv6 Summarization Example................................................................................................................19
Example 1.............................................................................................................................................19
Example 2.............................................................................................................................................20
Example 3.............................................................................................................................................21
IPv6 General Prefix.................................................................................................................................21
Configuration.......................................................................................................................................22
Conclusion............................................................................................................................................24
IPv6 Solicited Node Multicast Address..................................................................................................24
Page 1 of 252
IPv6 Neighbor Discovery Protocol on Cisco Router...................................................................................26
IPv6 Neighbor Solicitation Message...................................................................................................26
IPv6 Neighbor Advertisement Message.............................................................................................27
Configuration.........................................................................................................................................28
Wireshark Captures...............................................................................................................................30
Stateless autoconfiguration for IPv6......................................................................................................31
Troubleshooting IPv6 Stateless Autoconfiguration....................................................................................33
IPv6 Router Advertisement Preference.....................................................................................................36
Configuration.........................................................................................................................................37
Conclusion.............................................................................................................................................43
Cisco DHCPv6 Server Configuration...........................................................................................................43
DHCPv6 Server Configuration................................................................................................................43
DHCPv6 Stateful Configuration..........................................................................................................44
DHCPv6 Stateless Configuration........................................................................................................45
DHCPv6 Client Configuration.................................................................................................................46
DHCPv6 Stateful Client Configuration................................................................................................46
DHCPv6 Stateless Client Configuration..............................................................................................48
IPv6 DHCPv6 Prefix Delegation..................................................................................................................50
Configuration.........................................................................................................................................52
ISP......................................................................................................................................................52
Customer Routers..............................................................................................................................53
Verification............................................................................................................................................54
ISP......................................................................................................................................................54
Customers..........................................................................................................................................55
Hosts..................................................................................................................................................57
Conclusion............................................................................................................................................59
How to configure IPv6 Static Route...........................................................................................................59
Configuration.........................................................................................................................................59
Static route for a prefix......................................................................................................................60
Static default route............................................................................................................................62
Static host route................................................................................................................................63
Static floating route...........................................................................................................................64
Conclusion.............................................................................................................................................66
Page 2 of 252
How to configure RIPNG on Cisco IOS Router....................................................................................67
roubleshooting IPv6 RIPNG.......................................................................................................................70
How to configure IPv6 EIGRP on Cisco IOS Router.....................................................................................72
Configuration.........................................................................................................................................73
OSPFv2 vs OSPFv3.................................................................................................................................76
LSA Types............................................................................................................................................76
Flooding Scope.....................................................................................................................................77
Headers.................................................................................................................................................78
Conclusion............................................................................................................................................78
How to configure IPv6 OSPFv3 on Cisco IOS Router..................................................................................78
IPv6 OSPFv3 Default Route........................................................................................................................81
Configuration.........................................................................................................................................81
Verification............................................................................................................................................83
Conclusion.............................................................................................................................................84
OSPFv3 Prefix Suppression....................................................................................................................84
Configuration.......................................................................................................................................86
Prefix Suppression Disabled...............................................................................................................89
Link LSA..............................................................................................................................................90
Intra Area Prefix LSA..........................................................................................................................91
Prefix Suppression Enabled...............................................................................................................92
Link LSA..............................................................................................................................................93
Prefix Intra Area LSA..........................................................................................................................94
Conclusion.............................................................................................................................................95
Troubleshooting IPv6 OSPFv3 Neighbor Adjacencies..........................................................................95
OSPFv3 Router ID..............................................................................................................................95
OSPFv3 Hello Packet Mismatch.........................................................................................................97
OSPFv3 over Frame-Relay.................................................................................................................99
Multiprotocol BGP (MP-BGP) Configuration............................................................................................103
Configuration.......................................................................................................................................104
MP-BGP with IPv6 adjacency & IPv6 prefixes..................................................................................104
MP-BGP with IPv4 adjacency & IPv6 prefixes..................................................................................106
BGP IPv6 Route Filtering on Cisco IOS.....................................................................................................110
Configuration.......................................................................................................................................110
Page 3 of 252
Prefix-List Filtering...........................................................................................................................111
Filter-List Filtering............................................................................................................................111
Route-Map Filtering.........................................................................................................................113
Order of Operation..............................................................................................................................113
How to configure IPv6 Redistribution RIPNG OSPFv3..............................................................................116
Troubleshooting IPv6 Redistribution...................................................................................................119
IPv6 Access-list on Cisco IOS...............................................................................................................122
Configuration.....................................................................................................................................123
OSPFv3 Authentication and Encryption...................................................................................................126
Configuration.......................................................................................................................................126
IPsec Authentication........................................................................................................................127
IPsec Encryption..............................................................................................................................131
IPv6 First Hop Security Features.........................................................................................................135
IPv6 RA Guard..........................................................................................................................................136
Configuration.......................................................................................................................................136
Host Policy.......................................................................................................................................137
Router Policy...................................................................................................................................140
Conclusion...........................................................................................................................................142
IPv6 DHCPv6 Guard.................................................................................................................................143
Configuration.......................................................................................................................................143
Basic Policy......................................................................................................................................144
Prefix Filtering..................................................................................................................................146
Link-Local Address Filtering.............................................................................................................147
Preference Filtering.........................................................................................................................148
Conclusion..........................................................................................................................................150
IPv6 ND Inspection..................................................................................................................................150
Configuration.......................................................................................................................................151
Static Binding...................................................................................................................................153
Policies.............................................................................................................................................154
Device Tracking................................................................................................................................156
Conclusion...........................................................................................................................................157
IPv6 Source Guard................................................................................................................................157
Configuration.....................................................................................................................................158
Page 4 of 252
Without Source Guard.....................................................................................................................160
With Source Guard..........................................................................................................................162
Conclusion..........................................................................................................................................165
IPv6 PACL (Port ACL)................................................................................................................................165
Configuration.......................................................................................................................................166
Conclusion...........................................................................................................................................168
How to configure IPv6 tunneling over IPv4.........................................................................................168
How to configure IPv6 Automatic 6to4 Tunneling..............................................................................174
Troubleshooting IPv6 Automatic 6to4 Tunnel.........................................................................................178
IPv6 6RD (Rapid Deployment).................................................................................................................183
6RD addressing and prefixes...............................................................................................................185
6RD Packet Encapsulation...................................................................................................................187
Within domain.................................................................................................................................187
Outside Domain...............................................................................................................................189
Configuration.......................................................................................................................................189
CE1...................................................................................................................................................191
CE2...................................................................................................................................................193
BR1..................................................................................................................................................193
Verification..........................................................................................................................................193
Traffic flows.....................................................................................................................................195
Outside Domain...............................................................................................................................196
Conclusion..........................................................................................................................................198
IPv6 ISATAP (Intra Site Automatic Tunnel Addressing Protocol).....................................................199
Configuration.....................................................................................................................................199
Headend..........................................................................................................................................201
Client...............................................................................................................................................201
Verification..........................................................................................................................................202
Headend..........................................................................................................................................202
Client...............................................................................................................................................202
Conclusion...........................................................................................................................................205
IPv6 over MPLS 6PE/6VPE..................................................................................................................205
Configuration.....................................................................................................................................205
6PE...................................................................................................................................................209
Page 5 of 252
Verification......................................................................................................................................211
6VPE................................................................................................................................................217
Verification......................................................................................................................................218
Conclusion..........................................................................................................................................225
IPv6 over IPv4 GRE with IPSec.................................................................................................................225
Configuration.......................................................................................................................................226
R1.....................................................................................................................................................226
R2.....................................................................................................................................................227
Verification..........................................................................................................................................228
Conclusion...........................................................................................................................................232
Cisco NAT64 Static Configuration.......................................................................................................232
Configuration.....................................................................................................................................232
Verification........................................................................................................................................234
Conclusion..........................................................................................................................................236
IPv6 NPTv6 (Network Prefix Translation)..........................................................................................237
Configuration.....................................................................................................................................238
Verification..........................................................................................................................................239
Conclusion...........................................................................................................................................242
IPv6 Multicast BSR and RP Example.........................................................................................................242
Page 6 of 252
IPv6
Course Description
IPv6 is the successor of IPv4 and the main reason we need it is because we are running out of
IPv4 address space. IPv4 uses 32-bit addresses and offered us about 4.3 billion addresses, IPv6
offers 128-bit addresses so we have a huge amount of available addresses. These lessons will
explain the basics of IPv6 and how to configure it on Cisco IOS routers.
Course Highlights
 Your struggle is over! All IPv6 Topics As Simple As Possible!
 Presented to you by instructor Rene Molenaar, CCIE #41726
 Breaking down of each complex networking topic and explained step-by-step
 Learn how to configure routers and switches
 The best IPv6 tutorials you will find online
Requirements
Make sure you are familiar with all IPv4 equivalent topics.
Course Schedule
 Unit 1: Introduction to IPv6
 Unit 2: IPv6 Routing
 Unit 3: IPv6 Security
 Unit 4: IPv6 Tunneling
 Unit 5: NAT
 Unit 6: IPv6 Multicast
Introduction to IPv6
In this lesson i’ll give you an introduction to IPv6 and you will learn the differences between
IPv4 and IPv6. Let’s start with a nice picture:
Page 7 of 252
This picture is old already but it shows you the reason why we need IPv6…we are running out of
IPv4 addresses!
So what happened to IPv4? What went wrong? We have 32-bits which gives us 4,294,467,295 IP
addresses. Remember our Class A, B and C ranges? When the Internet started you would get a
Class A, B or C network. Class C gives you a block of 256 IP addresses, a class B is 65.535 IP
addresses and a class A even 16,777,216 IP addresses. Large companies like Apple, Microsoft,
IBM and such got one or more Class A networks. Did they really need > 16 million IP
addresses? Many IP addresses were just wasted.
We started using VLSM (Variable Length Subnet Mask) so we could use any subnet mask we
like and create smaller subnets, we longer had to use the class A, B or C networks. We also
started using NAT and PAT so we can have many private IP addresses behind a single public IP
addresses.
Nevertheless the Internet has grown in a way nobody expected 20 years ago. Despite all our cool
tricks like VLSM and NAT/PAT we really need more IP addresses and that’s why we need IPv6.
What happened to IPv5? Good question…IP version 5 was used for an experimental project
called “Internet Stream Protocol”. It’s defined in a RFC if you are interested:
http://www.faqs.org/rfcs/rfc1819.html
Page 8 of 252
IPv6 has 128 bit addresses and has a much larger address space than 32-bit IPv4 which offered
us a bit more than 4 billion addresses. Keep in mind every additional bit doubles the number of
IP addresses…so we go from 4 billion to 8 billion, 16,32,64, etc. Keep doubling until you reach
128 bit. With 128 bits this is the largest value you can create:
 340,282,366,920,938,463,463,374,607,431,768,211,456
Can we even pronounce this? Let’s try this:
 340- undecillion
 282- decillion
 366- nonillion
 920- octillion
 938- septillion
 463- sextillion
 463- quintillion
 374- quadrillion
 607- trillion
 431- billion
 768- million
 211- thousand
 456
That’s mind boggling… This gives us enough IP addresses for networks on earth, the moon,
mars and the rest of the universe. To put this in perspective let’s put the entire IPv6 and IPv4
address space next to each other:
 IPv6: 340282366920938463463374607431768211456
 IPv4: 4294467295
Some other nice numbers: the entire IPv6 address space is 4294467295 times the size of the
complete IPv4 address space. Or if you like percentages, the entire IPv4 address space is only
0.000000000000000000000000001.26% of the entire IPv6 address space.
The main reason to start using IPv6 is that we need more addresses but it also offers some new
features:
 No Broadcast traffic: that’s right, we don’t use broadcasts anymore. We use multicast
instead. This means some protocols like ARP are replaced with other solutions.
 Stateless Autoconfiguration: this is like a “mini DHCP server”. Routers running IPv6 are
able to advertise the IPv6 prefix and gateway address to hosts so that they can
automatically configure themselves and get access outside of their own network.
 Address Renumbering: renumbering static IPv4 addresses on your network is a pain. If
you use stateless autoconfiguration for IPv6 then you can easily swap the current prefix
with another one.
Page 9 of 252
 Mobility: IPv6 has built-in support for mobile devices. Hosts will be able to move from
one network to another and keep their current IPv6 address.
 No NAT / PAT: we have so much IPv6 addresses that we don’t need NAT or PAT
anymore, every device in your network can have a public IPv6 address.
 IPsec: IPv6 has native support for IPsec, you don’t have to use it but it’s built-in the
protocol.
 Improved header: the IPv6 header is simpler and doesn’t require checksums. It also has
a flow label that is used to quickly see if certain packets belong to the same flow or not.
 Migration Tools: IPv4 and IPv6 are not compatible so we need migration tools. There
are multiple tunneling techniques that we can use to transport IPv6 over IPv4 networks
(or the other way around). Running IPv4 and IPv6 simultaneously is called “dual stack”.
What does an IPv6 address look like? We use a different format than IPv4:
X:X:X:X:X:X:X:X where X is a 16-bit hexadecimal field
We don’t use decimal numbers like for IPv4, we are using hexadecimal now. Here’s an example
of an actual IPv6 address:
2041:1234:140F:1122:AB91:564F:875B:131B
Now imagine you have to call one of your users or colleagues and ask him or her to ping this
IPv6 address when you are trying to troubleshoot something…sounds like fun right?
To make things a bit more convenient it’s possible to shorten IPv6 addresses which I discuss in
this lesson. Running a local DNS server is also a good idea. Remembering hostnames is easier
than these IPv6 addresses.
If you are unsure how hexadecimal numbers work, take a look here.
That’s all I have for now, I hope this introduction has given you an idea of why we need IPv6,
what the address looks like and some of the new features. In the next lessons we will cover
everything including addressing, routing protocols, tunneling and more.
Shortening IPv6 Addresses

IPv6 addresses are hexadecimal and since they are 128-bit, they are quite long. Imagine you have
to call a friend and ask him/her to ping the following address:
2041:0000:140F:0000:0000:0000:875B:131B
To make our lives a bit better, IPv6 addresses can be shortened. Let’s take a look at some
examples and I’ll show you how it works:
 Original: 2041:0000:140F:0000:0000:0000:875B:131B
Page 10 of 252
 Short: 2041:0000:140F::875B:131B
If there is a string of zeros then you can remove them once. In the example above I removed
the entire 0000:0000:0000 part. You can only do this once, your IPv6 device will fill up the
remaining space with zeros until it has a 128 bit address.
There is more however, the address can be shortened even more:
 Short: 2041:0000:140F::875B:131B
 Shorter: 2041:0:140F::875B:131B
If you have a “hextet” with 4 zeros then you can remove those and leave a single zero. Your IPv6
device will add the remaining 3 zeros.
When we talk about IPv4 addresses, we use the term “octet” to define a “block” of 8 bits. In
IPv6, there is no official term (yet) and there is an IETF draft that discusses the names to be
used. The official term for 4 hexadecimal values is “hexadectet”, this is hard to
remember/pronounce so the short form “hextet” will be used.
Leading zeros can also be removed, here’s another address to demonstrate this:
 Original: 2001:0001:0002:0003:0004:0005:0006:0007
 Short: 2001:1:2:3:4:5:6:7
By removing these zeros we get a nice short IPv6 address.
To summarize these rules:
 An entire string of zeros can be removed, you can only do this once.
 4 zeros can be removed, leaving only a single zero.
 Leading zeros can be removed.
How to find IPv6 Prefix

IPv4 addresses have a subnet mask but instead of typing something like 255.255.255.0 we use a
prefix length for IPv6. Here is an example of an IPv6 prefix:
2001:1111:2222:3333::/64
This is pretty much the same as using 192.168.1.1 /24. The number behind the / are the number
of bits that we use for the prefix. In the example above it means that 2001:1111:2222:3333 is the
prefix (64 bits) and everything behind it can be used for hosts.
Page 11 of 252
When calculating subnets for IPv4 we can use the subnet mask to determine the network address
and for IPv6 we can do something alike. For any given IPv6 address we can calculate what the
prefix is but it works a bit different.
Let me show you what I’m talking about, here’s an IPv6 address that could be assigned to a host:
2001:1234:5678:1234:5678:ABCD:EF12:1234/64
What part from this IPv6 address is the prefix and what part identifies the host?
Since we use a /64 it means that the first 64 bits are the prefix. Each hexadecimal character
represents 4 binary bits so that means that this part is the prefix:
2001:1234:5678:1234
This part has 16 hexadecimal characters. 16 x 4 means 64 bits. So that’s the prefix right there.
The rest of the IPv6 address identifies the host:
5678:ABCD:EF12:1234
So we figured out that “2001:1234:5678:1234” is the prefix part but writing it down like this is
not correct. To write down the prefix correctly we need to add zeros at the end of this prefix so
that it is a 128 bit address again and add the prefix length:
2001:1234:5678:1234:0000:0000:0000:0000/64 is a valid prefix but we can shorten it. This

string of zeros can be removed and replace by a single ::
2001:1234:5678:1234::/64
That’s the shortest way to write down the prefix. Let’s look at another example:
3211::1234:ABCD:5678:1010:CAFE/64
Page 12 of 252
Before we can see what the prefix is, we should write down the complete address as this one has
been shortened (see the :: ). Just add the zeros until we have a full 128 bit address again:
3211:0000:0000:1234:ABCD:5678:1010:CAFE/64
We still have a prefix length of 64 bits. A single hexadecimal character represents 4 binary bits,
so the first 16 hexadecimal characters are the prefix:
3211:0000:0000:1234
Now we can add zeros at the end to make it a 128 bit address again and add the prefix length:
3211:0000:0000:1234::/64
That’s a good looking prefix but we can make it a little shorter:
3211:0:0:1234::/64
4 zeroes in a row can be replaced by a single one, so “3211:0:0:1234::/64” is the shortest we can
make this prefix.
Depending on the prefix length it makes the calculations very easy or (very) difficult. In the
examples I just showed you both prefixes had a length of 64. What if I had a prefix length of /53
or something?
Each hexadecimal character represents 4 binary bits. When your prefix length is a multiple of 16
then it’s easy to calculate because 16 binary bits represent 4 hexadecimal characters.
Here’s an illustration:
So with a prefix length of 64 we have 4 “blocks” with 4 hexadecimal characters each which
makes it easy to calculate. When the prefix length is a multiple of 4 then it’s still not too bad
because the boundary will be a single hexadecimal character.
When the prefix length is not a multiple of 16 or 4 it means we have to do some binary
calculations. Let me give you an example!
2001:1234:abcd:5678:9877:3322:5541:aabb/53
This is our IPv6 address and I would like to know the prefix for this address. Where do I start?
First I have to determine in what “block” my 53rd bit is located:
Page 13 of 252
Somewhere in the blue block we will find the 53rd bit. To know what the prefix is we will have
to calculate those hexadecimal characters to binary:
We now have the block that contains the 53rd, this is where the boundary is between “prefix”
and “host”:
[teaser]
Now we will set the host bits to 0 so that only the prefix remains. Finally we calculate from
binary back to hexadecimal:
Put this block back into place and set all the other host bits to 0 as well:
We have now found our prefix! 2001:1234:abcd:5000::/53 is the answer. It’s not that bad to
calculate but you do have to get your hands dirty with binary…
IPv6 Address Types

IPv6 looks different than IPv4 but there are some similarities. For example we have unicast
addresses and we still have a “public” and “private” range. We use different names for these but
Page 14 of 252
the idea is the same. One of the differences is that IPv6 has some additional unicast address
types.
We still have multicast, same idea but we use different addresses. There are also some reserved
addresses that are similar to their IPv4 counterparts.
Something new is anycast, an address that can be assigned on multiple devices so that packets
are always routed to the closest destination. Also, broadcast traffic doesn’t exist in IPv6
anymore.
In this lesson we’ll take a look at all the different address types and I’ll explain what they look
like and how we use them.
Unicast
Unicast IPv6 addresses are similar to unicast IPv4 addresses. These are meant to configure on
one interface so that you can send and receive IPv6 packets. There are a number of different
unicast address types that we’ll discuss here.
Global Unicast
The global unicast IPv6 addresses are similar to IPv4 public addresses. These addresses can be
used on the Internet. The big difference with IPv4 is that we have so much address space that we
can use global unicast addresses on any device in the network.
Unique Local
Unique local addresses work like the IPv4 private addresses. You can use these addresses on
your own network if you don’t intend to connect to the Internet or if you plan to use IPv6 NAT.
The advantage of unique local addresses is that you don’t need to register at an authority to get
some address space. The FC00::/7 prefix is reserved for unique local addresses, however when
you implement this you have to set the L-bit to 1 which means that the first two digits will be
FD. Here’s an example:
Let’s discuss all the fields of the unique local address. The first 7 bits indicate that we have a
unique local address. 1111 110 in binary is FC in hexadecimal. However, the L bit (8th bit) has
to be set to 1 so we end up with 1111 1101 which is FD in hexadecimal.
Page 15 of 252
The global ID (40 bits) is something you can make up. Normally an ISP would choose a prefix
but now it’s up to you to think of something. What’s left is 16 bits that we can use for different
subnets. This gives us a 64-bit prefix, what’s left is 64 bits for the interface ID.
Let’s work on an example…let’s say that we have a LAN and we want to use unique local IPv6
addresses and we require 10 subnets:
 The prefix starts with FD.

 We have 40 bits for the global ID, each hexadecimal character represents 4 bits so we can pick
10 hexadecimal characters. Let’s use AB:1234:5678 as the global ID.
 Our first subnet will start with 0000.
Here’s what we’ll end up with:
FDAB:1234:5678:0000::/64 will be our first subnet. The other subnets could look like this:
 FDAB:1234:5678:0000::/64
 FDAB:1234:5678:0001::/64
 FDAB:1234:5678:0002::/64
 FDAB:1234:5678:0003::/64
 FDAB:1234:5678:0004::/64
 FDAB:1234:5678:0005::/64
 And so on…
If you are just messing around with IPv6 then you could use a simple global ID like
00:0000:0000 which is nice because you can shorten it to ::. For production networks, it’s better
to pick something that is truly unique. When you want to connect multiple sites that use unique
local addresses then you want to make sure you don’t have overlapping global IDs.
Link-Local
Link-local addresses are something new in IPv6. As the wording implies, these addresses only
work on the local link, we never route these addresses. These addresses are used to send and
receive IPv6 packets on a single subnet.
When you enable IPv6 on an interface then the device will automatically create a link-local
address. We use the link-local address for things like neighbor discovery (the replacement for
ARP) and as the next hop address for routes in your routing table. You will learn more about this
when you work through the static route and OSPFv3 lessons.
We use the FE80::/10 range for link-local addresses, this means that the first 10 bits are 1111
1110 10. Here’s what it looks like:
Page 16 of 252
The first 10 bits are always 1111 1110 10 which means that we start with FE80. Technically the
following are all valid link-local addresses:[teaser]
 FE8 – 1111 1110 1000

 FE9 – 1111 1110 1001
 FEA – 1111 1110 1010
 FEB – 1111 1110 1011
These link-local addresses however are automatically generated by the host which sets the 54
bits to zeroes. This means that normally you will only see link-local addresses that start with
FE80.
Site-Local
The site local range was originally meant to be the “private range” for IPv6. It has been
deprecated though and nowadays we use the unique local addresses instead. For these addresses
we used the FEC0::/10 range (1111 1110 11 in binary)
If you are interested why they gave up on the site local addresses then you can read RFC 3879
for the full story.
Unspecified
The 0:0:0:0:0:0:0:0 address is called the unspecified address, :: is the shortened version of this
address. It should never be configured on a host and is used to indicate that the host doesn’t have
any address.
Loopback
the 0:0:0:0:0:0:0:1 address is called the loopback address, the short version is ::1. IPv6 devices
can use this to send an IPv6 packet to themselves which is typically used for testing. It should
never be assigned to any physical interfaces. This address is the equivalent of IPv4’s 127.0.0.1
address.
Multicast
In IPv6 we use multicast for IPv6 (routing) protocols and for user traffic. We use the FF::/8
prefix for multicast traffic (1111 1111 in binary). Let’s take a look what the addresses look like:
Page 17 of 252
The first 8 bits indicates that we have a multicast address. The next 4 bits are used to set flags,
these are used for some special things like embedded RP. The scope bits are used to tell the
“scope” of this multicast traffic. You can use this to indicate that the multicast traffic should be
restricted to link-local, organization local or global (Internet).
Below you will find an overview with some of the most common IPv6 multicast addresses:
 FF02::1 – all nodes on local network segment.

 FF02::2 – all routers on local network segment.
 FF02::5 – all OSPFv3 routers.
 FF02::6 – all OSPFv3 DR routers.
 FF02::9 – RIPng routers
 FF02::A – EIGRP routers
If you look closely you can see some of these addresses are similar to their IPv4 multicast
counterparts. For example, in IPv4 we use 224.0.0.05 and 224.0.0.6 for OSPF while we use
FF02::5 and FF02::6 for ipv6. We use 224.0.0.9 for RIPv2 and FF02::9 for RIPng.
Anycast
The anycast address is new in IPv6. The same address can be assigned to multiple devices and
advertised in a routing protocol. When you send a packet to an anycast address then it will be
delivered to the closest interface. Something similar is possible in IPv4 but it was never
“officially” possible. There is no specifix prefix for anycast addresses. Any unicast address that
you use on more than one device is suddenly an anycast address. The only difference is that you
have to configure the device and tell that the address will be used for anycast.
IPv6 Address Assignment Example

In this lesson we’ll take a look how you can create IPv6 prefixes and subnets so that you can
configure your entire network with IPv6. We’ll start at the top where IANA (Internet Assigned
Numbers Authority) is responsible for the global coordination of the IPv4 and IPv6 address
space and move our way all the way to the bottom where we assign subnets and IPv6 addresses
to our routers, switches and VLANs.
IPv6 Global Unicast Prefix Assignments

IANA “owns” the entire IPv6 address space and they assign certain prefixes to the RIRs
(Regional Internet Registry). There are 5 RIRs at the moment:
Page 18 of 252
 AFRINIC: Africa
 APNIC: Asia/Pacific
 ARIN: North America
 LACNIC: Latin America and some Caribbean Islands
 RIPE NCC: Europe, Middle east and Central Asia
If you are interested, click here for an overview of all IPv6 prefix assignments by IANA.
When a large ISP (or large company) in North America wants IPv6 addresses then they will
contact ARIN who will assign them an IPv6 prefix if they meet all requirements. The ISP can
then assign prefixes to their customers.
Let’s take a look at some actual prefixes:
Page 19 of 252
 IANA is using the 2000::/3 prefix for global unicast address space.
 According to this list, RIPE NCC received prefix 2001:4000::/23 from IANA.
 A large ISP called Ziggo in The Netherlands receives prefix 2001:41f0::/32 from RIPE
NCC.
 The ISP assigns prefix 2001:41f0:4060::/48 to one of their customers.
Now it’s up to the customer what they want to do with their IPv6 prefix…
IPv6 Global Unicast Subnet Assignments

Our customer received prefix 2001:41f0:4060::/48 and they want to use it to configure IPv6 on
their entire network. Where do we start? Take a look at the image below:
Page 20 of 252
The 48-bit prefix that we received is typically called the global routing prefix or site prefix.
The interface ID is normally 64 bit which means we have 16 bits left to create subnets.
If I want I can steal some more bits from the Interface ID to create even more subnets but there’s
no need for this. Using 16 bits we can create 65.536 subnets …more than enough for most of us.
Let’s see what we can do for our customer:[teaser]
16 bits gives us 4 hexadecimal characters. All possible combinations that we can create with
those 4 hexadecimal characters are our possible subnets. Everything from 0000 to FFFF are valid
subnets:
 2001:41f0:4060:0000::/64
 2001:41f0:4060:0001::/64
 2001:41f0:4060:0002::/64
 2001:41f0:4060:0003::/64
 2001:41f0:4060:0004::/64
 2001:41f0:4060:0005::/64
 2001:41f0:4060:0006::/64
 2001:41f0:4060:0007::/64
 2001:41f0:4060:0008::/64
 2001:41f0:4060:0009::/64
 2001:41f0:4060:000A::/64
 2001:41f0:4060:000B::/64
 2001:41f0:4060:000C::/64
 2001:41f0:4060:000D::/64
 2001:41f0:4060:000E::/64
 2001:41f0:4060:000F::/64
 2001:41f0:4060:0010::/64
 2001:41f0:4060:0011::/64
 2001:41f0:4060:0012::/64
 2001:41f0:4060:0013::/64
 2001:41f0:4060:0014::/64
 And so on…
Now you know what subnets you can use, here’s an example of a small network where we use
some of these subnets:
Page 21 of 252
In the example above I used some numbers some make sense, for example on VLAN 10 we use
2001:41f0:4060:10::/64, another good option would be 2001:41f0:4060:A::/64 since the A in
hexadecimal equals 10 in decimal. For the VLANs it’s best to use a /64 so that you can use
autoconfiguration for hosts.
On the link between R1 and R2 I used a /64 but according to RFC 6164 you should use a /127 on
point-to-point links.
Each subnet will require an IPv6 address on the router that will be used as the default gateway.
The most simple solution is probably to use the first IPv6 address in the subnet. For example for
VLAN 20 you could use 2001:41f0:4060:20::1/64 or for VLAN 2 you could use
2001:41f0:4060:2::1/64.
Conclusion
I hope this lesson has helped to understand where IPv6 prefixes come from and how you can
create your own subnets for your network. There’s one more overview I want to share with you
that has some of the terminology:
Page 22 of 252
Name Assignment Example
Registry prefix IANA to RIR 2001:4000::/23
ISP prefix RIR to ISP 2001:41f0::/32
Global routing prefix or site prefix ISP to customer 2001:41f0:4060::/48
Subnet prefix Network engineer 2001:41f0:4060:1234::/64
IPv6 EUI-64 explained

EUI-64 (Extended Unique Identifier) is a method we can use to automatically configure IPv6
host addresses. An IPv6 device will use the MAC address of its interface to generate a unique
64-bit interface ID. However, a MAC address is 48 bit and the interface ID is 64 bit. What are
we going to do with the missing bits?
Here’s what we will do to fill the missing bits:
1. We take the MAC address and split it into two pieces.

2. We insert “FFFE” in between the two pieces so that we have a 64 bit value.
3. We invert the 7th bit of the interface ID.
So if my MAC address would be 1234.5678.ABCD then this is what the interface ID will
become:
Page 23 of 252
Above you see how we split the MAC address and put FFFE in the middle. It doesn’t include the
final step which is “inverting the 7th” bit. To do this you have to convert the first two
hexadecimal characters of the first byte to binary, lookup the 7th bit and invert it. This means that
if it’s a 0 you need to make it a 1, and if it’s a 1 it has to become a 0.
The 7th bit represents the universal unique bit. A “built in” MAC address will always have this
bit set to 0. When you change the MAC address this bit has to be set to 1. Normally people don’t
change the MAC addresses of their interfaces which means that EUI-64 will change the 7th bit
from 0 to 1 most of the time. Here’s what it looks like:
[teaser]
Page 24 of 252
We take the first two hexadecimal characters of the first byte which are “12” and convert those
back to binary. Then we invert the 7th bit from 1 to 0 and make it hexadecimal again. The EUI-64
interface ID will look like this:
Now you know how EUI-64 works, let’s see what it looks like on a router. I’ll use a Cisco IOS
router for this and use 2001:1234:5678:abcd::/64 as the prefix:
Router(config)#interface fastEthernet 0/0

Router(config-if)#ipv6 address 2001:1234:5678:abcd::/64 eui-64
In this I configured the router with the IPv6 prefix and I used EUI-64 at the end. This is how we
can automatically generate the interface ID using the mac address. Now take a look at the IPv6
address that it created:
Router#show interfaces fastEthernet 0/0 | include Hardware

Hardware is Gt96k FE, address is c200.185c.0000 (bia c200.185c.0000)
Router#show ipv6 interface fa0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C000:18FF:FE5C:0
No Virtual link-local address(es):
Global unicast address(es):
2001:1234:5678:ABCD:C000:18FF:FE5C:0, subnet is 2001:1234:5678:ABCD::/64
[EUI]
See the C000:18FF:FE5C:0 part above? That’s the MAC address that is split in 2, FFFE in the
middle and the “2” in “C200” of the MAC address has been inverted which is why it now shows
up as “C000”.
When you use EUI-64 on an interface that doesn’t have a MAC address then the router will
select the MAC address of the lowest numbered interface on the router.
IPv6 Summarization Example

Summarizing IPv6 prefixes is similar to IPv4 summarization, the big difference is that IPv6 uses
128 bit addresses compared to 32 bits for IPv4 and IPv6 uses hexadecimal addresses.
In this lesson, I’ll explain how to create IPv6 summaries and we’ll walk through some examples
together.
Example 1
Let’s start with a simple example:
 2001:DB8:1234:ABA2::/64
Page 25 of 252
 2001:DB8:1234:ABC3::/64
Let’s say we have to create a summary that includes the two prefixes above. Each hextet
represents 16 bits. The first three hextets are the same (2001:DB8:1234) so we have 16 + 16 + 16
= 48 bits that are the same so far. To find the other bits that are the same we only have to focus
on the last hextet:
 ABA2
 ABC3
We’ll have to convert these from hexadecimal to binary to see how many bits are the same:
ABA2 1010101110100010
ABC3 1010101111000011
I highlighted the bits in red that are the same, the first 9 bits. The remaining blue bits are
different. To get our summary address, we have to zero out the blue bits:
AB80 1010101110000000
When we calculate this from binary back to hexadecimal we get AB80. The first three hextets
are the same and in the 4th octet we have 9 bits that are the same. 48 + 9 = 57 bits. Our summary
address will be:
2001:DB8:1234:AB80::/57
That’s how you can create a summary address for IPv6.
Example 2
This time we have the following 3 prefixes:
 2001:DB8:0:1::/64
 2001:DB8:0:2::/64
 2001:DB8:0:3::/64
And our goal is to create the most optimal summary address. The first three hextets are the same
so that’s 16 + 16 + 16 = 48 bits that these prefixes have in common. For the remaining bits, we’ll
have to look at the 4th hextet in binary:
0001 0000000000000001
0002 0000000000000010
0003 0000000000000011
Page 26 of 252
Keep in mind that each hextet represents 16 bits. The first 14 bits are the same, to get the
summary address we have to zero out the blue bits:
0000 0000000000000000
When we calculate this from binary back to hexadecimal we get 0000. The first three hextets are
the same and in the 4th octet we have 14 bits that are the same. 48 + 14 = 62 bits. Our summary
address will be:[teaser]
2001:DB8::/62
Example 3
Let’s try one more:
 2001:DB8:0:7::/64
 2001:DB8:0:12::/64
Let’s see what the most optimal summary address is that has these two prefixes. The first three
hextets are the same so that’s 16 + 16 + 16 = 48 bits in common. Let’s look at the 4th hextet for
the remaining bits:
0007 0000000000000111
0012 0000000000010010
Be careful that you don’t accidently convert number 12 from decimal to binary. We are working
with hexadecimal values here! We have 11 bits that are the same, let’s zero out the remaining 5
bits:
0000 0000000000000000
We have 48 + 11 bits that are the same so our summary address will be:
2001:DB8::/59
IPv6 General Prefix

The upper 64 bits of an IPv6 prefix usually consists of a /48 global routing prefix (or site prefix)
and the remaining 12 bits are used for more specific prefixes (the subnet). This is explained in
detail in the following lesson:
IPv6 address assignment
Page 27 of 252
The IPv6 general (or generic) prefix feature lets you renumber a global prefix on your router or
switch. This is a simple but pretty useful feature.
For example, let’s say we have the following global prefix:
 2001:41f0:4060::/48
And we use the following specific prefixes:
 2001:41f0:4060:0001::/64
 2001:41f0:4060:0002::/64
 2001:41f0:4060:0003::/64
 2001:41f0:4060:0004::/64
You can configure these prefixes manually on your interfaces but once your global prefix
changes, you have to manually reconfigure your IPv6 addresses. With the IPv6 general prefix
feature, we can do this automatically.
Configuration
To demonstrate this, I’ll use a router with four interfaces. On each interface, I’ll use the global
prefix and specific prefixes from above.
We configure the global prefix with the ipv6 general-prefix command. You can use whatever
name you want, I’ll name mine “GLOBAL”:
R1(config)#ipv6 general-prefix GLOBAL 2001:41F0:4060::/48
On the interfaces, we configure an IPv6 address and refer to the general prefix. You have to
specify a full IPv6 address, the first 48 bits will be replaced by the general prefix. I’ll use zeroes
for the global prefix:
R1(config)#interface GigabitEthernet 0/1

R1(config-if)#ipv6 address GLOBAL ::1:0:0:0:1/64



Let’s see what prefixes we ended up with:
R1#show ipv6 interface | include 2001

2001:41F0:4060:1::1, subnet is 2001:41F0:4060:1::/64
Page 28 of 252
2001:41F0:4060:2::1, subnet is 2001:41F0:4060:2::/64
2001:41F0:4060:3::1, subnet is 2001:41F0:4060:3::/64
2001:41F0:4060:4::1, subnet is 2001:41F0:4060:4::/64
This is looking good. You can see we have four prefixes and the global prefix is
2001:41F0:4060.
Let’s see if we can change our global prefix without manually reconfiguring each interface. I’ll
use the ipv6 general prefix command again to use a different global prefix:[teaser]
R1(config)#ipv6 general-prefix GLOBAL 2001:41F0:4070::/48
Once you do this, you’ll have two global prefixes:
R1#show running-config | include general

ipv6 general-prefix GLOBAL 2001:41F0:4060::/48
Which means we’ll have two prefixes on each interface:
R1#show ipv6 interface GigabitEthernet 0/1 | include 2001

2001:41F0:4060:1::1, subnet is 2001:41F0:4060:1::/64
2001:41F0:4070:1::1, subnet is 2001:41F0:4070:1::/64
This can be useful. When you have verified that the old global prefix isn’t used anymore, we can
remove it:
R1(config)#no ipv6 general-prefix GLOBAL 2001:41F0:4060::/48
And it will be gone from all interfaces:
R1#show ipv6 interface | include 2001

2001:41F0:4070:1::1, subnet is 2001:41F0:4070:1::/64
2001:41F0:4070:2::1, subnet is 2001:41F0:4070:2::/64
2001:41F0:4070:3::1, subnet is 2001:41F0:4070:3::/64
2001:41F0:4070:4::1, subnet is 2001:41F0:4070:4::/64
That’s it!
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ip cef
!
interface GigabitEthernet0/1
ipv6 address GLOBAL ::1:0:0:0:1/64
!
Page 29 of 252
!
!
!
end
Conclusion
You have now learned how to use the IPv6 general prefix feature to automatically configure the
global prefix and renumber your interfaces if needed:
 You configure the global prefix with the ipv6 general-prefix command.
 On the interface level, you use the ipv6 address command and refer to the general-prefix.
You need to type in a complete IPv6 address and the first 48 bits will be replaced by the
general prefix.
 When you want to renumber, you add a new global prefix and use the same general
prefix name.
 Once you have verified the new prefixes work, you can remove the old global prefix from
your configuration.
IPv6 Solicited Node Multicast Address

Every device that uses an IPv6 address will also compute and join a solicited node multicast
group address. This address is required for IPv6 Neighbor Discovery which we use for layer two
address discovery.
All solicited node multicast group addresses start with FF02::1:FF /104:
 FF /8 is the IPv6 multicast range.

 FF02 /16 is the multicast link local scope.
Let’s take a look on a Cisco IOS router to see what these solicited node multicast group
addresses look like:
R1(config)#interface FastEthernet 0/0

R1(config-if)#ipv6 enable
I just enabled IPv6 on an interface, this causes the router to create a link-local IPv6 address. It
will also compute and join the solicited node multicast group address:
R1#show ipv6 interface FastEthernet 0/0

FastEthernet0/0 is up, line protocol ibs up
Page 30 of 252
IPv6 is enabled, link-local address is FE80::21D:A1FF:FE8B:36D0
No global unicast address is configured
Joined group address(es):
FF02::1
FF02::1:FF8B:36D0
Above you can see that the router joined FF02::1:FF8B:36D0. The last 6 hexadecimal characters
were copied from the link local address. Here’s a picture:
Above you can see the complete uncompressed solicited node multicast address.
I can configure multiple IPv6 addresses on the interface, if the last 6 hexadecimal characters are
similar then there is no need to join another multicast address. For example, let’s configure an
IPv6 unicast address:

R1(config-if)#ipv6 address 2001:DB8:1212:1212::/64 eui-64
I’ll use EUI-64 to generate the last 64 bits. Take a look at the joined group addresses:

2001:DB8:1212:1212:21D:A1FF:FE8B:36D0, subnet is 2001:DB8:1212:1212::/64
[EUI]
FF02::1
FF02::1:FF8B:36D0
The last 64 bits of the link local and unicast address are the same so the solicited node multicast
group address remains the same. If we configure an IPv6 address where the last 6 hexadecimal
characters are different then the router will join another multicast group. Let’s try that:[teaser]

R1(config-if)#ipv6 address 2001:DB8:1234:5678:1234:5678:1234:5678/64
Instead of using EUI-64 I’ll use make up an address myself. The router will now join an
additional multicast group:

Page 31 of 252
2001:DB8:1212:1212:21D:A1FF:FE8B:36D0, subnet is 2001:DB8:1212:1212::/64
[EUI]
2001:DB8:1234:5678:1234:5678:1234:5678, subnet is 2001:DB8:1234:5678::/64
FF02::1
FF02::1:FF34:5678
FF02::1:FF8B:36D0
Above you can see the router also joined the FF02::1:FF34:5678 solicited node multicast group
address.
You have now seen that an IPv6 device computes and joins a solicited node multicast group
address for each IPv6 address that you configure.
The big question remains: why and where do we use it?
I’ll answer this with some examples in the IPv6 Neighbor Discovery lesson.
IPv6 Neighbor Discovery Protocol on Cisco

Router
One of the differences between IPv4 and IPv6 is that we don’t use ARP (Address Resolution
Protocol) anymore. ND (Neighbor Discovery Protocol) will replace the functionality of ARP.
In this lesson we’ll take a look how ND works.
ND uses ICMP and solicited node multicast addresses to discover the layer 2 address of other
IPv6 hosts the same network (local link). It uses two messages to accomplish this:
 Neighbor solicitation message

 Neighbor advertisement message
Let’s take closer look at these two messages.
IPv6 Neighbor Solicitation Message
The neighbor solicitation message is used primarily to find the layer two address of another IPv6
address on the local link, it’s also used for DAD (Duplicated Address Detection). In this packet
the source address will be the source address of the host that is sending the neighbor solicitation,
the destination address will be the solicited node multicast address of the remote host. This
message also includes the layer two address of the host that is sending it. In the ICMP header of
this packet you will find a type value of 135.
Page 32 of 252
Using solicited node multicast addresses as the destination is far more efficient than IPv4’s ARP
requests that are broadcasted to all hosts.
Every IPV6 device will compute a solicited node multicast address by taking the multicast group
address (FF02::1:FF /104) and adding the last 6 hexadecimal characters from its IPv6 address. It
will then join this multicast group address and “listens” to it.
When one host wants to find the layer two address of another host, it will send the neighbor
solicitation to the remote host’s solicited node multicast address.It can calculate the solicited
node multicast address of the remote host since it knows about the multicast group address and it
knows the IPv6 address that it wants to reach.
The result will be that only the remote host will receive the neighbor solicitation. That’s far
more efficient than a broadcast that is received by everyone…
Neighbor solicitation messages are also used to check if a remote host is reachable. In this case, the
destination address will be the unicast address of the remote host.
IPv6 Neighbor Advertisement Message
Once the remote host receives the neighbor solicitation it will reply with the neighbor
advertisement message. The source address is the IPv6 address of the host and the destination
address is the IPv6 address of the remote host that sent the neighbor solicitation. The most
important part is that this message includes the layer two address of the host. The neighbor
advertisement message uses type 136 in the ICMPv6 packet header.
Page 33 of 252
Once R1 receives the neighbor advertisement, these two IPv6 hosts will be able to communicate
with each other.
Neighbor advertisement messages are also used when the layer two address of a host changes. When
this message is sent, the destination address will be the all-nodes multicast address.
Configuration
Now you have an idea how IPv6 neighbor discovery works. Let’s see what it looks like on some
real devices. I’ll also show you some wireshark captures. I will use these two routers for this
demonstration:
First we will configure some IPv6 addresses on our routers:
R1 & R2
(config)#interface FastEthernet 0/0
(config-if)#ipv6 enable
Using ipv6 enable is enough to generate some link local addresses which is all we need for this
exercise. Here are the IPv6 addresses that the routers created:
R1#show ipv6 interface FastEthernet 0/0 | include FE80

IPv6 is enabled, link-local address is FE80::C001:2FF:FE40:0 [TEN]
R2#show ipv6 interface FastEthernet 0/0 | include FE80
IPv6 is enabled, link-local address is FE80::C002:3FF:FEE4:0 [TEN]
To see the neighbor discovery in action I will enable a debug on both routers:[teaser]
R1 & R2
Page 34 of 252
#debug ipv6 nd
Let’s send a ping from R1 to R2:
R1#ping FE80::C002:3FF:FEE4:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::C002:3FF:FEE4:0, timeout is 2 seconds:
Packet sent with a source address of FE80::C001:2FF:FE40:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/19/60 ms
Now you will see the following debug messages:
R1#
ICMPv6-ND: DELETE -> INCMP: FE80::C002:3FF:FEE4:0
ICMPv6-ND: Sending NS for FE80::C002:3FF:FEE4:0 on FastEthernet0/0
ICMPv6-ND: Received NA for FE80::C002:3FF:FEE4:0 on FastEthernet0/0 from
FE80::C002:3FF:FEE4:0
ICMPv6-ND: Neighbour FE80::C002:3FF:FEE4:0 on FastEthernet0/0 : LLA
c202.03e4.0000
ICMPv6-ND: INCMP -> REACH: FE80::C002:3FF:FEE4:0
ICMPv6-ND: Received NS for FE80::C001:2FF:FE40:0 on FastEthernet0/0 from
FE80::C002:3FF:FEE4:0
ICMPv6-ND: Sending NA for FE80::C001:2FF:FE40:0 on FastEthernet0/0
First we see a line that includes INCMP, this indicates that the address resolution is in progress.
Next we see that R1 is sending the NS (neighbor solicitation) and receiving the NA (neighbor
advertisement). In the neighbor advertisement it finds the layer two address of R2
(c202.03e4.0000). The status jumps from INCMP to REACH since R1 now knows how to reach
R2. You can also see that R1 receives a neighbor solicitation from R2 and replies with the
neighbor advertisement. Here’s what it looks like on R2:
R2#
ICMPv6-ND: Received NS for FE80::C002:3FF:FEE4:0 on FastEthernet0/0 from
FE80::C001:2FF:FE40:0
ICMPv6-ND: DELETE -> INCMP: FE80::C001:2FF:FE40:0
ICMPv6-ND: Neighbour FE80::C001:2FF:FE40:0 on FastEthernet0/0 : LLA
c201.0240.0000
ICMPv6-ND: INCMP -> STALE: FE80::C001:2FF:FE40:0
ICMPv6-ND: Sending NA for FE80::C002:3FF:FEE4:0 on FastEthernet0/0
ICMPv6-ND: STALE -> DELAY: FE80::C001:2FF:FE40:0
ICMPv6-ND: DELAY -> PROBE: FE80::C001:2FF:FE40:0
ICMPv6-ND: Sending NS for FE80::C001:2FF:FE40:0 on FastEthernet0/0
ICMPv6-ND: Received NA for FE80::C001:2FF:FE40:0 on FastEthernet0/0 from
FE80::C001:2FF:FE40:0
ICMPv6-ND: PROBE -> REACH: FE80::C001:2FF:FE40:0
ICMPv6-ND: REACH -> STALE: FE80::C001:2FF:FE40:0
These debugs are interesting but they don’t show us the source and destination address that are in
use.
Page 35 of 252
Wireshark Captures
Let’s take a look at these messages in wireshark, this will show us the source and destination
addresses. Here’s the neighbor solicitation from R1 to R2:
Above you can see the source and destination MAC addresses. The source address is the MAC
address of R1 and the destination is a multicast MAC address. The source IPv6 address is the
link-local address of R1 and the destination is the solicited node multicast address of R2:
 FF02::1:FF /104 is the multicast group address.

 e4:0000 are the last 6 hexadecimal characters of the link-local address of R2
(FE80::C002:3FF:FEE4:0). This is compressed to e4:0.
As you can see the layer two destination address is a multicast address. When a switch receives this it
will flood it out all of its interfaces. That’s a bad idea since it defeats the purpose of our solicited node
multicast addresses. For this reason, we should enable MLD snooping on our switch.
Here’s the capture of R2 that sends the neighbor advertisement:
Page 36 of 252
You can see the source and destination MAC addresses of R2. The IPv6 addresses are the link-
local addresses of R1 and R2. You can also see the ICMPv6 type value of 136.
If you want to take a look for yourself then you can find the wireshark capture here:
IPv6 Neighbor Discovery
That’s all I have on IPv6 neighbor discovery.
Stateless autoconfiguration for IPv6

Stateless autoconfiguration for IPv6 is like a “mini-DHCP” server for IPv6. Routers running
IPv6 can give the prefix of the network and a gateway address to clients looking for an IPv6
address. IPv6 uses the NDP (Neighbor Discovery Protocol) and one of the things this protocol
offers is RS (Route Solicitation and (RA) Router Advertisement messages that help an IPv6
device to automatically configure an IPv6 address. Let’s take a look at a configuration example:
I’m going to use two routers to show you how stateless autoconfiguration works. R2 will have an
Page 37 of 252
IPv6 address and is going to send router advertisements. R1 will use this to configure it’s own
IPv6 address.
R2(config)#ipv6 unicast-routing
R2(config)#interface fastEthernet 0/0
R2(config-if)#ipv6 address 2001:1234::/64 eui-64
Besides configuring an IPv6 address we have to use the ipv6 unicast-routing command to make
R2 act like a router. Remember this command since you need it for routing protocols as well.

R1(config-if)#ipv6 address autoconfig
We need to enable ipv6 address autoconfig on R1 to make sure it generates its own IPv6
address.
R1#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
R2#debug ipv6 nd
We can use debug ipv6 nd to watch the whole process.

[teaser]
R2#
ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0
ICMPv6-ND: MTU = 1500
ICMPv6-ND: prefix = 2001:1234::/64 onlink autoconfig
Here you can see R2 sending the router advertisement with the prefix.
R1#
ICMPv6-ND: Received RA from FE80::CE0A:18FF:FE0E:0 on FastEthernet0/0
ICMPv6-ND: Autoconfiguring 2001:1234::CE09:18FF:FE0E:0 on FastEthernet0/0
This is R1 receiving the router advertisement and configuring its own IPv6 address.
R1#show ipv6 interface brief

FastEthernet0/0 [up/up]
FE80::CE09:18FF:FE0E:0
2001:1234::CE09:18FF:FE0E:0
And here is the proof that we have a fresh new IPv6 address on R1.
R1#show ipv6 routers

Router FE80::CE0A:18FF:FE0E:0 on FastEthernet0/0, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 msec, Retransmit time 0 msec
Prefix 2001:1234::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Page 38 of 252
You can also use the show ipv6 routers command to see all cached router advertisements. This
is a good example where you will see the link-local address of R2 instead of the global unicast
address.
Not bad right? If we can do this why do we still care about DHCPv6? Don’t forget DHCP can do
many more things than just giving out IPv6 addresses like:
 Registering hostnames of computers in DNS.

 Include a list of DNS or WINS servers.
 Include the IPv6 address of Callmanager (for VoIP phones) or a wireless LAN controller
(for lightweight access points).
DHCP is of course also available for IPv6 and is called DHCPv6. The big difference between
DHCP for IPv4 and DHCPv6 is that we don’t use broadcast traffic anymore. When an IPv6
device is looking for a DHCPv6 server it will send multicast packets to FF02::1:2. Routers will
forward these packets to DHCP servers.
hostname R2
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 address 2001:1234::/64 eui-64
!
end
hostname R1
!
!
ipv6 address autoconfig
!
end
Troubleshooting IPv6 Stateless

Autoconfiguration
Page 39 of 252
In the picture above we have two routers, R1 and R2. We only have IPv6 addresses and you can
see that in between R1 and R2 we have configured the 2001::/64 prefix. R1 has been configured
for stateless autoconfiguration but for some reason it’s not receiving an IPv6 address from R2.
Let’s find out what is wrong here shall we?
R1#show ipv6 interface fa0/0

IPv6 is enabled, link-local address is FE80::CE00:29FF:FE35:0
We can verify that the FastEthernet 0/0 interface is operational and that IPv6 has been enabled.
Let’s see if the interface is configured for stateless autoconfiguration:
R1#show ipv6 interface fa0/0 | include stateless

Hosts use stateless autoconfig for addresses.
We can see this is the case. At this moment we at least know that IPv6 has been enabled on R1
and that it is not receiving an IPv6 address through stateless Autoconfiguration. What is the next
step of our plan? Let’s see if R1 receives anything from R2:
R1#debug ipv6 nd
Stateless autoconfiguration is a part of neighbor discovery. We’ll enable a debug to see if

anything is going on. Let’s reset the interface:
R1(config)#interface fa0/0
R1(config-if)#shutdown
R1(config-if)#no shutdown
After a few seconds this is what we see:
R1#
ICMPv6-ND: Sending NS for FE80::CE00:29FF:FE35:0 on FastEthernet0/0
%LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
ICMPv6-ND: DAD: FE80::CE00:29FF:FE35:0 is unique.
ICMPv6-ND: Sending NA for FE80::CE00:29FF:FE35:0 on FastEthernet0/0
ICMPv6-ND: Address FE80::CE00:29FF:FE35:0/10 is up on FastEthernet0/0
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state
to up
ICMPv6-ND: Sending RS on FastEthernet0/0
In the debug we see that R1 is sending RS (Router Solicitation) messages. Unfortunately we are
not receiving any response to these messages so it seems that something is going on with R2.
Let’s check it out:
R2#show ipv6 interface fa0/0

IPv6 is enabled, link-local address is FE80::CE01:29FF:FE35:0
Page 40 of 252
2001::12:2, subnet is 2001::/64
We can verify that R2 has a working FastEthernet 0/0 interface and that IPv6 address 2001::12:2
has been configured.
We know that R2 has a working IPv6 address and there are no issues with the interface. What
prevents it from sending RA (Router Advertisements)? Configuring an IPv6 address isn’t enough
to enable IPv6 features like routing protocols or router advertisements. [teaser]We need to make
sure IPv6 unicast-routing is enabled. Let’s see if this is the case:
R2#show running-config | include unicast-routing
There’s maybe another show command to verify it but this time I’m checking the running-
configuration to see if IPv6 unicast-routing has been enabled, it seems to be disabled. Let’s
enable it:
Now here’s what you will see on the debug of R1:
R1#
ICMPv6-ND: Received RA from FE80::CE01:29FF:FE35:0 on FastEthernet0/0
ICMPv6-ND: Sending NS for 2001::CE00:29FF:FE35:0 on FastEthernet0/0
ICMPv6-ND: Autoconfiguring 2001::CE00:29FF:FE35:0 on FastEthernet0/0
ICMPv6-ND: DAD: 2001::CE00:29FF:FE35:0 is unique.
ICMPv6-ND: Sending NA for 2001::CE00:29FF:FE35:0 on FastEthernet0/0
ICMPv6-ND: Address 2001::CE00:29FF:FE35:0/64 is up on FastEthernet0/0
ICMPv6-ND: Received RA from FE80::CE01:29FF:FE35:0 on FastEthernet0/0
As soon as I enable unicast-routing on R2 you’ll see some debug information on R1. It receives
the router advertisement and it has configured itself with IPv6 address 2001::CE00:29FF:FE35:0.
You can see it here:

FE80::CE00:29FF:FE35:0
2001::CE00:29FF:FE35:0
Let’s try a quick ping to the other side:
R1#ping 2001::12:2

Sending 5, 100-byte ICMP Echos to 2001::12:2, timeout is 2 seconds:
!!!!!
Page 41 of 252
Problem solved!
Lesson learned: Make sure IPv6 unicast-routing is enabled if you want to use router
advertisements or IPv6 routing protocols.
IPv6 Router Advertisement Preference

In the IPv6 SLAAC (Stateless Autoconfiguration) lesson I explained how IPv6 routers send
router advertisements which hosts can use to receive the prefix on the subnet, configure their
own IPv6 address using EUI-64 and how they select the router as a default gateway.
What happens however when we have more than one router on the subnet? Which router
advertisement will our host then use? To figure this out, we’ll use the following topology:
Page 42 of 252
We have two routers, R1 and R2 who will send router advertisements. Our host will be
configured for SLAAC so that it will configure its own IPv6 address. With two router
advertisements, our host will have to make a decision which one to use.
Let’s start with the configuration.
Configuration
Page 43 of 252
First we will enable IPv6 unicast routing on R1 and R2, otherwise they won’t send any router
advertisements:
R1 & R2
(config)#ipv6 unicast-routing
Let’s configure a global unicast address on each router so that they can advertise a prefix in the
RA:

R1(config-if)#ipv6 address 2001:DB8:123:123::1/64
That’s all we have to do on the routers. Before we configure the host, let’s enable a debug so we
can see the router advertisements in real-time:
R1 & R2 & H1
#debug ipv6 nd
Now we will configure the host to use the router advertisements for autoconfiguration:
Host(config)#interface GigabitEthernet 0/1

Host(config-if)#ipv6 address autoconfig
As soon as you enable this command, the host will send a router solicitation:
H1#
ICMPv6-ND: (GigabitEthernet0/1) Sending RS
The routers will receive the router solicitation and will respond with a router advertisement:
R1#
ICMPv6-ND: (GigabitEthernet0/1) Sending solicited RA
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE8F:86C2) send RA to FF02::1
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE8F:86C2) Sending RA (1800) to
FF02::1
ICMPv6-ND: prefix 2001:DB8:123:123::/64 [LA] 2592000/604800
R2#
ICMPv6-ND: (GigabitEthernet0/1) Sending solicited RA
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) send RA to FF02::1
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Sending RA (1800) to
FF02::1
What does our host think of this?
H1#
Page 44 of 252
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RA
ICMPv6-ND: [default] New router interface context created/GigabitEthernet0/1
ICMPv6-ND: [default] New router interface context created/C645C24
ICMPv6-ND: [default] inserted router
FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1
ICMPv6-ND: [default] Select default router
ICMPv6-ND: [default] best rank is 811
ICMPv6-ND: [default] router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1 is new
best
ICMPv6-ND: [default] Selected new default router
ICMPv6-ND: [default] Install default to
ICMPv6-ND: Prefix : 2001:DB8:123:123::, Length: 64, Vld Lifetime: 2592000, Prf
Lifetime: 604800, PI Flags: C0
ICMPv6-ND: New on-link prefix 2001:DB8:123:123::/64 on
GigabitEthernet0/1/FE80::F816:3EFF:FE19:6D0, lifetime 2592000
ICMPv6-ND: Autoconfiguring 2001:DB8:123:123:F816:3EFF:FEDF:47FD on
GigabitEthernet0/1
Above you can see that it receives the RA from R2 first which is selected as the default router.
The host configures its own address with the prefix it receives. A few seconds later it receives
the RA from R1:
H1#
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE8F:86C2) Received RA
FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1
ICMPv6-ND: Update on-link prefix 2001:DB8:123:123::/64 on
GigabitEthernet0/1/FE80::F816:3EFF:FE8F:86C2, lifetime 2592000
Another way to verify that we received two router advertisements is by using the show ipv6
routers command:
H1#show ipv6 routers

Router FE80::F816:3EFF:FE19:6D0 on GigabitEthernet0/1, last update 1 min
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:123:123::/64 onlink autoconfig
Router FE80::F816:3EFF:FE8F:86C2 on GigabitEthernet0/1, last update 1 min
If you want to see which one was selected as the default then you need to add the
default parameter:
Page 45 of 252
H1#show ipv6 routers default
HomeAgentFlag=0, Preference=Medium, trustlevel = 0
Great, as you can see our host is using R2 as the default router. Why? all parameters in the router
advertisements from our routers are equal so there’s nothing in the RA that the host will use to
make a selection. It decided to use R2 since that’s the first RA that it received. We can
demonstrate this by shutting the interface on R2:

R2 will inform our host that it is leaving, you can see it in the debug:[teaser]
H1#
ICMPv6-ND: Packet contains no options
ICMPv6-ND: Validating ND packet options: valid
ICMPv6-ND: Packet contains no options
ICMPv6-ND: Zero lifetime, deleting
ICMPv6-ND: [default] Delete router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1
ICMPv6-ND: [default] router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1 no
longer best
ICMPv6-ND: [default] Free router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1
ICMPv6-ND: [default] router FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1 is
new best
FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1
Above you can see that our host receives the RA from R2, it will select R1 as the new default
router. We can also verify this with the show command we just used:
H1#show ipv6 routers default | include Router

R1 is now the new default router. Let’s enable R2 again:

The host will receive the fresh RA from R2:
H1#
ICMPv6-ND: Validating ND packet options: valid
Page 46 of 252
So does it select R2 as the new default router again? Let’s find out:

H1#show ipv6 routers default | include Router
R1 is still the default router even though we also received the router advertisement from R2.
What if we want to use one router as the preferred router?
This is possible with the preference setting. By default our Cisco IOS routers will advertise a
medium preference in their router advertisements:
H1#show ipv6 routers default | include Preference

HomeAgentFlag=0, Preference=Medium, trustlevel = 0
There are three levels we can select from though:
R1(config)#interface GigabitEthernet0/1
R2(config-if)#ipv6 nd router-preference ?
High High default router preference
Low Low default router preference
Medium Medium default router preference
Let’s change R2 so that it advertises a high preference. This should force our host to use R2 as
the default router:
R2(config-if)#ipv6 nd router-preference High
As soon as you configure this, it will trigger R2 to send a new RA:
R2#
ICMPv6-ND: (GigabitEthernet0/1) RA parameter change
Page 47 of 252
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) send RA to FF02::1
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Sending RA (1800) to
FF02::1
Once our host receives it, it will act upon it:
H1#
ICMPv6-ND: [default] router FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1 no
longer best
ICMPv6-ND: [default] router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1 is new
best
Above you can see that the host now prefers R2 as the new default router and installs a default
route for it.
hostname R1
!
ipv6 cef
!
ipv6 address 2001:DB8:123:123::1/64
!
end
hostname R2
!
ipv6 cef
!
ipv6 address 2001:DB8:123:123::2/64
ipv6 nd router-preference High
!
end
hostname H1
!
!
end
Page 48 of 252
Conclusion
When your IPv6 hosts receive multiple router advertisements, you probably want to decided
yourself which router advertisement will be used. By setting the preference, this can be
accomplished.
Although this is how IPv6 works, automatically accepting router advertisements is a security risk. If you
want to see what I’m talking about, take a look at the IPv6 RA guard lesson.
Cisco DHCPv6 Server Configuration

In this tutorial we’ll take a look at DHCPv6 so we can automatically assign IPv6 addresses to our
hosts. The functionality of DHCPv6 is the same as DHCP for IPv4 but there are some
differences. First of all, DHCPv6 supports two different methods:
 Stateful configuration
 Stateless configuration (also known as SLAAC…StateLess AutoConfiguration)
The stateful version of DHCPv6 is pretty much the same as for IPv4. Our DHCPv6 server will
assign IPv6 addresses to all DHCPv6 clients and it will keep track of the bindings. In short, the
DHCPv6 servers knows exactly what IPv6 address has been assigned to what host.
Stateless works a bit different…the DHCPv6 server does not assign IPv6 addresses to the
DHCPv6 clients, this is done through autoconfiguration. The DHCPv6 server is only used to
assign information that autoconfiguration doesn’t….stuff like a domain-name, multiple DNS
servers and all the other options that DHCP has to offer.
The other difference is the number of messages that DHCPv6 uses:
 Normal: 4 messages called solicit, advertise, request and reply.

 Rapid: 2 messages, only solicit and reply.
By default it uses normal mode, if you want the rapid mode you have to enable it on both the
DHCPv6 server and client.
You might be wondering why there is a normal and rapid mode, so did I…RFC 4039 says that
the rapid mode is useful in “high mobility” networks where clients come and go often. The
overhead of 4 messages might not be required so 2 messages is enough to do the job. If you have
multiple DHCPv6 servers (for redundancy) then you need to use the normal mode (4 messages).
Seeing the advantage of both modes might be fun for a tutorial in the future, for now…let’s start
with the basics and configure our DHCPv6 server!
DHCPv6 Server Configuration

Page 49 of 252
To demonstrate DHCPv6 I will use the following topology:
Our DHCPv6 router has two interfaces, the one connected to R1 will be used for stateful
DHCPv6 and the interface connected to R2 will be used for stateless. You can also see the
prefixes that I will use.
Before you can do anything with IPv6, make sure that unicast routing is enabled:
DHCPV6(config)#ipv6 unicast-routing
Now we can configure the DHCPv6 pools…
DHCPv6 Stateful Configuration
Let’s configure the stateful pool, it is similar to doing this for IPv4:
DHCPV6(config)#ipv6 dhcp pool STATEFUL

DHCPV6(config-dhcpv6)#address prefix 2001:1111:1111:1111::/64
DHCPV6(config-dhcpv6)#dns-server 2001:4860:4860::8888
DHCPV6(config-dhcpv6)#domain-name NETWORKLESSONS.LOCAL
The pool is called “STATEFUL” and besides the prefix I configured a DNS server (that’s google
DNS) and a domain name. To activate this, we have to make some changes to the interface:
DHCPV6(config)#interface FastEthernet 0/0
Page 50 of 252
DHCPV6(config-if)#ipv6 address 2001:1111:1111:1111::1/64
DHCPV6(config-if)#ipv6 dhcp server STATEFUL
DHCPV6(config-if)#ipv6 nd managed-config-flag
DHCPV6(config-if)#ipv6 nd prefix 2001:1111:1111:1111::/64 14400 14400 no-
autoconfig
On the interface you have to add the ipv6 dhcp server command and tell it what pool it has to
use. The ipv6 nd managed-config-flag sets a flag in the router advertisement that tells the hosts
that they could use DHCPv6. The last command that ends with no-autoconfig tells the hosts not
to use stateless configuration.
That’s all we have to do on the DHCPv6 server, let’s move on to the stateless configuration.
DHCPv6 Stateless Configuration
First we’ll make a pool:
DHCPV6(config)#ipv6 dhcp pool STATELESS

DHCPV6(config-dhcpv6)#dns-server 2001:4860:4860::8888
DHCPV6(config-dhcpv6)#domain-name NETWORKLESSONS.LOCAL
As you can see I didn’t configure a prefix…I don’t have to since autoconfiguration will be used
by the client to fetch the prefix. Let’s enable it on the interface:

DHCPV6(config-if)#ipv6 address 2001:2222:2222:2222::2/64
DHCPV6(config-if)#ipv6 dhcp server STATELESS
DHCPV6(config-if)#ipv6 nd other-config-flag
We use the same command to activate the pool on the interface but there is one extra item. The
ipv6 nd other-config-flag is required as it will inform clients through RA (Router
Advertisement) messages that they have to use DHCPv6 to receive extra information like the
domain name and DNS server after they used autoconfiguration.
That’s all we have to do on the server, you can view the DHCPv6 pools like this if you want:
DHCPV6#show ipv6 dhcp pool

DHCPv6 pool: STATEFUL
Address allocation prefix: 2001:1111:1111:1111::/64 valid 172800 preferred
86400 (0 in use, 0 conflicts)
DNS server: 2001:4860:4860::8888
Domain name: NETWORKLESSONS.LOCAL
Active clients: 0
DHCPv6 pool: STATELESS
DNS server: 2001:4860:4860::8888
Active clients: 0
You can see both pools, our stateful pool with the prefix and the stateless pool without. Before I
configure the clients, I will enable a debug so we can see some of the messages in realtime:
Page 51 of 252
DHCPV6#debug ipv6 dhcp
IPv6 DHCP debugging is on
Let’s configure the clients now…
DHCPv6 Client Configuration

R1 will be the stateful client and R2 is the stateless client, let’s do R1 first…
DHCPv6 Stateful Client Configuration
There are two things that we have to do, first you need to enable IPv6 on the interface and
secondly, tell it to get an IPv6 address through DHCP:

R1(config-if)#ipv6 address dhcp
Let’s see if it has an IPv6 address:

FE80::21D:A1FF:FE8B:36D0
2001:1111:1111:1111:255A:E159:32AF:5E42
That’s looking good, you can see that it has an IPv6 address with the 2001:1111:1111:1111::/64
prefix. There’s another nice command that shows us what else we received:
R1#show ipv6 dhcp interface FastEthernet 0/0

FastEthernet0/0 is in client mode
Prefix State is IDLE
Address State is OPEN
Renew for address will be sent in 11:59:10
List of known servers:
Reachable via address: FE80::216:C7FF:FEBE:EC8
DUID: 000300010016C7BE0EC8
Preference: 0
Configuration parameters:
IA NA: IA ID 0x00030001, T1 43200, T2 69120
Address: 2001:1111:1111:1111:255A:E159:32AF:5E42/128
preferred lifetime 86400, valid lifetime 172800
expires at Jul 19 2014 08:30 PM (172750 seconds)
DNS server: 2001:4860:4860::8888
Information refresh time: 0
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled
The show ipv6 dhcp interface command shows us what DNS and domain information we
received, this is looking good. Meanwhile you can see this on the server:
Page 52 of 252
DHCPV6#
IPv6 DHCP: Received SOLICIT from FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0
IPv6 DHCP: Using interface pool STATEFUL
IPv6 DHCP: Creating binding for FE80::21D:A1FF:FE8B:36D0 in pool STATEFUL
IPv6 DHCP: Binding for IA_NA 00030001 not found
IPv6 DHCP: Allocating IA_NA 00030001 in binding for FE80::21D:A1FF:FE8B:36D0
IPv6 DHCP: Looking up pool 2001:1111:1111:1111::/64 entry with username
'00030001001DA18B36D000030001'
IPv6 DHCP: Poolentry for user not found
IPv6 DHCP: Allocated new address 2001:1111:1111:1111:255A:E159:32AF:5E42
IPv6 DHCP: Allocating address 2001:1111:1111:1111:255A:E159:32AF:5E42 in
binding for FE80::21D:A1FF:FE8B:36D0, IAID 00030001
IPv6 DHCP: Updating binding address entry for address
2001:1111:1111:1111:255A:E159:32AF:5E42
IPv6 DHCP: Setting timer on 2001:1111:1111:1111:255A:E159:32AF:5E42 for 60
seconds
IPv6 DHCP: Source Address from SAS FE80::216:C7FF:FEBE:EC8
IPv6 DHCP: Sending ADVERTISE to FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0

IPv6 DHCP: Received REQUEST from FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0
'00030001001DA18B36D000030001'
IPv6 DHCP: Poolentry for user found
IPv6 DHCP: Found address 2001:1111:1111:1111:255A:E159:32AF:5E42 in binding
for FE80::21D:A1FF:FE8B:36D0, IAID 00030001
2001:1111:1111:1111:255A:E159:32AF:5E42
IPv6 DHCP: Setting timer on 2001:1111:1111:1111:255A:E159:32AF:5E42 for 172800
seconds
IPv6 DHCP: Sending REPLY to FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0
Above you can see the 4 messages (solicit, advertise, request and reply) because we are using
normal mode. Let’s switch the server and client to rapid mode so you can see the difference:
[teaser]

DHCPV6(config-if)#ipv6 dhcp server STATEFUL rapid-commit
We have to change this on the interface level, same for the client:

R1(config-if)#ipv6 address dhcp rapid-commit
This is what the debug looks like now:
DHCPV6#
IPv6 DHCP: Received SOLICIT from FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0
IPv6 DHCP: Creating binding for FE80::21D:A1FF:FE8B:36D0 in pool STATEFUL
IPv6 DHCP: Allocating IA_NA 00030001 in binding for FE80::21D:A1FF:FE8B:36D0
'00030001001DA18B36D000030001'
Page 53 of 252
IPv6 DHCP: Poolentry for user not found
IPv6 DHCP: Allocated new address 2001:1111:1111:1111:5D5B:C84C:9648:9D1F
IPv6 DHCP: Allocating address 2001:1111:1111:1111:5D5B:C84C:9648:9D1F in
binding for FE80::21D:A1FF:FE8B:36D0, IAID 00030001
2001:1111:1111:1111:5D5B:C84C:9648:9D1F
IPv6 DHCP: Setting timer on 2001:1111:1111:1111:5D5B:C84C:9648:9D1F for 172800
seconds
IPv6 DHCP: Sending REPLY to FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0
2 messages instead of 4, that’s it…you now have seen the difference between normal and rapid
mode. Let’s move on to the stateless client!
DHCPv6 Stateless Client Configuration
We already prepared the server so it’s just the client, this is what we do on R2:

This time I have to use the ipv6 address autoconfig command since we use autoconfiguration to
get an IPv6 address. Let’s see if that worked:

FE80::217:5AFF:FEED:7AF1
2001:2222:2222:2222:217:5AFF:FEED:7AF1
Great, we received an address. This is what the debug on the server looks like:
DHCPV6#
IPv6 DHCP: Add routes, pool STATELESS, idb FastEthernet0/1
IPv6 DHCP: Received INFORMATION-REQUEST from FE80::217:5AFF:FEED:7AF1 on
FastEthernet0/1
IPv6 DHCP: Using interface pool STATELESS
IPv6 DHCP: Sending REPLY to FE80::217:5AFF:FEED:7AF1 on FastEthernet0/1
It receives an information request which basically means that the clients wants to know about the
“extra” stuff that the DHCPv6 pool has to offer. In our example that’s the DNS server and the
domain name. Let’s check if the client received those:
R2#show ipv6 dhcp interface FastEthernet 0/0

FastEthernet0/1 is in client mode
Prefix State is IDLE (0)
Information refresh timer expires in 23:57:37
Address State is IDLE
Reachable via address: FE80::216:C7FF:FEBE:EC9
DUID: 000300010016C7BE0EC8
Page 54 of 252
Preference: 0
DNS server: 2001:4860:4860::8888
That’s good, it learned about the DNS server and the domain name. What does the pool look like
on the server?
DHCPV6#show ipv6 dhcp pool

DHCPv6 pool: STATEFUL
Address allocation prefix: 2001:1111:1111:1111::/64 valid 172800 preferred
86400 (1 in use, 0 conflicts)
DNS server: 2001:4860:4860::8888
Active clients: 1
DHCPv6 pool: STATELESS
DNS server: 2001:4860:4860::8888
Active clients: 0
This is a good example as it shows you that the DHCPv6 servers sees an active client for the
stateful pool but not for the stateless pool.
hostname DHCPV6
!
!
ipv6 dhcp pool STATEFUL
address prefix 2001:1111:1111:1111::/64
dns-server 2001:4860:4860::8888
domain-name NETWORKLESSONS.LOCAL
!
ipv6 dhcp pool STATELESS
dns-server 2001:4860:4860::8888
!
interface FastEthernet 0/0
ipv6 address 2001:1111:1111:1111::1/64
ipv6 dhcp server STATEFUL
ipv6 nd managed-config-flag
ipv6 nd prefix 2001:1111:1111:1111::/64 14400 14400 no-autoconfig
!
ipv6 address 2001:2222:2222:2222::2/64
ipv6 dhcp server STATELESS
ipv6 nd other-config-flag
!
end
Page 55 of 252
hostname R1
!
ipv6 enable
ipv6 address dhcp
!
end
hostname R2
!
ipv6 enable
!
end
And that’s the end of this tutorial! You have seen stateful and stateless configuration and the
difference between normal and rapid mode.
IPv6 DHCPv6 Prefix Delegation

The prefix delegation feature lets a DHCP server assign prefixes chosen from a global pool to
DHCP clients. The DHCP client can then configure an IPv6 address on its LAN interface using
the prefix it received. It will then send router advertisements including the prefix, allowing other
devices to use autoconfiguration to configure their own IPv6 addresses.
This feature can be useful in an ISP environment. Here’s an example:
Page 56 of 252
In the picture above we have an ISP that has the global prefix 2001:DB8:1100::/40 that it can
assign to customers. With the prefix delegation feature and DHCPv6, it automatically assigns
prefixes to its customers:
 Customer 1 receives 2001:DB8:1100::/48

 Customer 2 receives 2001:DB8:1101::/48
Each customer router configures an IPv6 address based on the prefix they received from the ISP
using the general prefix feature and advertises the specific prefix (subnet) to host devices in
router advertisements.
Host devices are then able to configure their own IPv6 address using the prefix in the router
advertisement and EUI-64.
Page 57 of 252
Configuration
Let’s take a look at the configuration. Here is the topology we’ll use:
ISP
Let’s start with the ISP router. We need to enable IPv6 unicast routing:
ISP(config)#ipv6 unicast-routing
The global prefix is configured with the ipv6 local pool command:
ISP(config)#ipv6 local pool GLOBAL_POOL 2001:DB8:1100::/40 48
Page 58 of 252
This tells the router that we have a pool called GLOBAL_POOL and that we can use the entire
2001:DB8:1100::/40 prefix. Each DHCP client, however, will receive a /48 prefix out of this
pool.
Now we need to configure the DHCP server:
ISP(config)#ipv6 dhcp pool CUSTOMERS

ISP(config-dhcpv6)#prefix-delegation pool GLOBAL_POOL
ISP(config-dhcpv6)#dns-server 2001:4860:4860::8888
ISP(config-dhcpv6)#dns-server 2001:4860:4860::8844
ISP(config-dhcpv6)#domain-name NETWORKLESSONS.LOCAL
I refer to the pool we just created and add some extra information like the google DNS servers
and a domain name. On the interface that connects to the customers, I configure an IPv6 address
that does not fall within the range of the global prefix (if you try, you get an error) and the DHCP
server needs to be activated on the interface:
ISP(config)#interface GigabitEthernet 0/1

ISP(config-if)#ipv6 address 2001:DB8:0:1::1/64
ISP(config-if)#ipv6 dhcp server CUSTOMERS
That completes the ISP router configuration.
Customer Routers
Let’s configure the customer routers.
C1
Make sure you enable IPv6 unicast routing:
C1(config)#ipv6 unicast-routing
The interface that connects to the ISP router will use DHCP client:
C1(config)#interface GigabitEthernet 0/1

C1(config-if)#ipv6 dhcp client pd ISP_PREFIX
C1(config-if)#ipv6 address autoconfig default
The prefix that we receive will be stored as ISP_PREFIX. We will use this on the interface that
connects to our hosts to configure an IPv6 address:

C1(config-if)#ipv6 address ISP_PREFIX ::1:0:0:0:1/64
In the IPv6 address command, I refer to our ISP_PREFIX so that the router starts the address
with that prefix. I’ll use a /64 prefix on this interface.
Page 59 of 252
C2
We can do the exact same thing on this router as we did on C1:
C2(config)#ipv6 unicast-routing

C2(config-if)#ipv6 dhcp client pd ISP_PREFIX
C2(config-if)#ipv6 address autoconfig default

C2(config-if)#ipv6 address ISP_PREFIX ::2:0:0:0:2/64
The only difference is that I use a different specific prefix (subnet) on this router.
Hosts
On each of our hosts, we use autoconfiguration:
H1(config)#interface GigabitEthernet 0/1

H1(config-if)#ipv6 address autoconfig
This completes our configuration.
Verification
Let’s verify our work!
ISP
Let’s take a closer look at our DHCP pool:
ISP#show ipv6 dhcp pool

DHCPv6 pool: CUSTOMERS
Prefix pool: GLOBAL_POOL
DNS server: 2001:4860:4860::8888
DNS server: 2001:4860:4860::8844
Active clients: 2
The output above tells us that we have two clients and that the ISP router uses the
GLOBAL_POOL for the prefix. Let’s take a closer look at those two DHCP clients:
Page 60 of 252
ISP#show ipv6 dhcp binding
Client: FE80::F816:3EFF:FEB8:F33E
DUID: 000300015E0000010000
Username : unassigned
VRF : default
Interface : GigabitEthernet0/1
IA PD: IA ID 0x00030001, T1 302400, T2 483840
Prefix: 2001:DB8:1100::/48
expires at Mar 22 2018 09:41 AM (2591328 seconds)
Client: FE80::F816:3EFF:FEC4:B7CB
DUID: 000300015E0000030000
VRF : default
Interface : GigabitEthernet0/1
IA PD: IA ID 0x00030001, T1 302400, T2 483840
Prefix: 2001:DB8:1101::/48
The output above is interesting as it tells us which prefixes the router assigned to the DHCP
clients.
Customers
Let’s take a look at those DHCP clients, the customer routers.
C1
Let’s take a look at the DHCP information from C1’s perspective:
C1#show ipv6 dhcp interface

GigabitEthernet0/1 is in client mode
Prefix State is OPEN
Renew will be sent in 3d11h
Reachable via address: FE80::F816:3EFF:FE00:EF72
DUID: 000300015E0000000000
Preference: 0
IA PD: IA ID 0x00030001, T1 302400, T2 483840
Prefix: 2001:DB8:1100::/48
DNS server: 2001:4860:4860::8888
DNS server: 2001:4860:4860::8844
Prefix name: ISP_PREFIX
Address Rapid-Commit: disable
Page 61 of 252
Above we see that we received our prefix from the ISP, including some other details like the
DNS servers and domain name. You can also see that this router named the prefix
“ISP_PREFIX”.
Here we can see the IPv6 address that C1 configured on its GigabitEthernet 0/1 interface:
C1#show ipv6 interface GigabitEthernet 0/1 | include 2001

2001:DB8:0:1:F816:3EFF:FEB8:F33E, subnet is 2001:DB8:0:1::/64
[EUI/CAL/PRE]
We can also verify that the router has stored the prefix it received from the ISP:
C1#show ipv6 general-prefix

IPv6 Prefix ISP_PREFIX, acquired via DHCP PD
2001:DB8:1100::/48 Valid lifetime 2591177, preferred lifetime 603977
GigabitEthernet0/2 (Address command)
Which is used to configure the GigabitEthernet 0/2 interface:

2001:DB8:1100:1::1, subnet is 2001:DB8:1100:1::/64 [CAL/PRE]
That’s all we need to check on C1.
C2
Let’s verify that C2 has received a prefix from the ISP:[teaser]
C2#show ipv6 dhcp interface

GigabitEthernet0/1 is in client mode
Prefix State is OPEN
Renew will be sent in 3d11h
Reachable via address: FE80::F816:3EFF:FE00:EF72
DUID: 000300015E0000000000
Preference: 0
IA PD: IA ID 0x00030001, T1 302400, T2 483840
Prefix: 2001:DB8:1101::/48
DNS server: 2001:4860:4860::8888
DNS server: 2001:4860:4860::8844
Prefix name: ISP_PREFIX
This is looking good. Here’s the IPv6 address that C2 configured on its GigabitEthernet0/1
interface:
Page 62 of 252
2001:DB8:0:1:F816:3EFF:FEC4:B7CB, subnet is 2001:DB8:0:1::/64
[EUI/CAL/PRE]
Let’s verify that it stored the prefix:
C2#show ipv6 general-prefix

IPv6 Prefix ISP_PREFIX, acquired via DHCP PD
2001:DB8:1101::/48 Valid lifetime 2591187, preferred lifetime 603987
GigabitEthernet0/2 (Address command)
And let’s make sure it uses the prefix to configure its GigabitEthernet0/2 interface:

2001:DB8:1101:2::2, subnet is 2001:DB8:1101:2::/64 [CAL/PRE]
This is looking good.
Hosts
Our hosts should configure themselves using the router advertisements they receive from the
customer routers. Let’s verify this:
H1#show ipv6 interface GigabitEthernet 0/1 | include 2001

2001:DB8:1100:1:F816:3EFF:FEDA:2B29, subnet is 2001:DB8:1100:1::/64
[EUI/CAL/PRE]
2001:DB8:1100:1:F816:3EFF:FE78:90D0, subnet is 2001:DB8:1100:1::/64
[EUI/CAL/PRE]
2001:DB8:1101:2:F816:3EFF:FE36:D153, subnet is 2001:DB8:1101:2::/64
[EUI/CAL/PRE]
2001:DB8:1101:2:F816:3EFF:FEAE:B242, subnet is 2001:DB8:1101:2::/64
[EUI/CAL/PRE]
That’s looking good. Each host has the correct prefix and was able to configure its own IPv6
address.
hostname C1
!
ipv6 cef
!
ipv6 address autoconfig default
ipv6 dhcp client pd ISP_PREFIX
!
ipv6 address ISP_PREFIX ::1:0:0:0:1/64
Page 63 of 252
!
end
hostname C2
!
ipv6 cef
!
ipv6 address autoconfig default
ipv6 dhcp client pd ISP_PREFIX
!
ipv6 address ISP_PREFIX ::2:0:0:0:2/64
!
end
hostname H1
!
!
end
hostname H2
!
!
end
hostname H3
!
!
end
hostname H4
!
!
end
hostname ISP
!
ipv6 cef
ipv6 dhcp pool CUSTOMERS
prefix-delegation pool GLOBAL_POOL
Page 64 of 252
dns-server 2001:4860:4860::8888
dns-server 2001:4860:4860::8844
!
no ip address
ipv6 address 2001:DB8:0:1::1/64
ipv6 dhcp server CUSTOMERS
!
ipv6 local pool GLOBAL_POOL 2001:DB8:1100::/40 48
!
end
Conclusion
You have now learned how the IPv6 DHCP prefix delegation feature works:
 How prefixes are automatically selected from a global pool and advertised through
DHCPv6.
 How the DHCP client automatically configures its LAN interface using the prefix it
received from the DHCP server.
 How the specific prefix is automatically advertised through router advertisements.
 How host devices configure their own IPv6 address using the router advertisement.
How to configure IPv6 Static Route

If you know how to configure a static route for IPv4 then you shouldn’t have any issues with
IPv6 static routes. The configuration and syntax are similar, there are only some minor
differences. In this lesson, I will show you how to configure all IPv6 static route types.
Configuration
To demonstrate this topology, I will use the following topology:
Page 65 of 252
R1 and R2 are connected with a serial link. R2 has a loopback interface with IPv6 addresss
2001:DB8:2:2::2/64. Let’s see if we can reach this address.
Static route for a prefix
Let’s start with a simple example where we create a static route for the prefix we want to reach:
2001:DB8:2:2::/64.
Static route for a prefix – outgoing interface
Just like with IPv4, it is possible to use an interface as the next hop. This will only work with
point-to-point interfaces:
R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0
Here’s what the routing table looks like:
R1#show ipv6 route static
S 2001:DB8:2:2::/64 [1/0]
via Serial0/0/0, directly connected
Let’s see if it works:
R1#ping 2001:DB8:2:2::2
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Our ping is working.
If you try this with a FastEthernet interface, you’ll see that the router will accept the command but the
ping won’t work. You can’t use this for multi-access interfaces.
Static route for a prefix – global unicast next hop
Instead of an outgoing interface, we can also specify the global unicast address as the next hop:
R1(config)#ipv6 route 2001:DB8:2:2::/64 2001:DB8:12:12::2
S 2001:DB8:2:2::/64 [1/0]
via 2001:DB8:12:12::2
Page 66 of 252
R1#ping 2001:DB8:2:2::2
!!!!!
No problem at all…
Instead of global unicast addresses, you can also use unique local addresses. These are the IPv6
equivalent of IPv4 private addresses.
Static route for a prefix – link-local next hop
One of the differences between IPv4 and IPv6 is that IPv6 generates a link-local address for each
interface. In fact, these link-local addresses are also used by routing protocols like RIPng,
EIGRP, OSPFv3, etc as the next hop addresses. Let’s see what the link-local address is of R2:
R2#show ipv6 interface Serial 0/0/0 | include link-local

IPv6 is enabled, link-local address is FE80::21C:F6FF:FE11:41F0
Let’s use this as the next hop address. When you use a global unicast address as the next hop,
your router will be able to look at the routing table and figure out what outgoing interface to use
to reach this global unicast address. With link local addresses, the router has no clue which
outgoing interface to use so you will have to specify both the outgoing interface and the link
local address:
R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0
S 2001:DB8:2:2::/64 [1/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
Just to be sure, let’s try a ping:
R1#ping 2001:DB8:2:2::2
!!!!!
No problems there.
Static default route
Just like IPv4, we can also create static default routes. A default route has only zeroes (::) and a /
0 prefix-length. This is the equivalent of 0.0.0.0/0 in IPv4. We can do this with an interface,
global unicast or link-local address. Let’s try all options!
Page 67 of 252
Static default route – outgoing interface
Let’s start with the outgoing interface first:
R1(config)#ipv6 route ::/0 Serial 0/0/0
Here’s the routing table:
S ::/0 [1/0]
Let’s try a quick ping:
R1#ping 2001:DB8:2:2::2
!!!!!
Static default route – global unicast next hop
Instead of an outgoing interface, let’s try a global unicast next hop address:
R1(config)#ipv6 route ::/0 2001:DB8:12:12::2
S ::/0 [1/0]
via 2001:DB8:12:12::2
R1#ping 2001:DB8:2:2::2
!!!!!
Time for the next option.
Static default route – link-local next hop
Let’s replace the global unicast next hop address with a link-local address:
R1(config)#ipv6 route ::/0 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0
Page 68 of 252
S ::/0 [1/0]
R1#ping 2001:DB8:2:2::2
!!!!!
Our ping is working.
Static host route
We can also create static routes for a single IPv6 address, this is called a static host route. These
examples are the same as the ones you have seen before but this time, we will create an entry for
2001:DB8:2:2::2/128 which is similar to using a /32 subnet mask in IPv4.
Static host route – outgoing interface
First we will try the outgoing interface:
R1(config)#ipv6 route 2001:DB8:2:2::2/128 Serial 0/0/0
Here is the routing table:
S 2001:DB8:2:2::2/128 [1/0]
R1#ping 2001:DB8:2:2::2
!!!!!
Static host route – global unicast next hop
Let’s try a global unicast address as the next hop:
R1(config)#ipv6 route 2001:DB8:2:2::2/128 2001:DB8:12:12::2
Page 69 of 252
S 2001:DB8:2:2::2/128 [1/0]
via 2001:DB8:12:12::2
And let’s try a quick ping:
R1#ping 2001:DB8:2:2::2
!!!!!
Static host route – link-local next hop
Last but not least, a link-local address as the next hop address:
R1(config)#ipv6 route 2001:DB8:2:2::2/128 Serial 0/0/0

FE80::21C:F6FF:FE11:41F0
Here’s R1’s routing table:
S 2001:DB8:2:2::2/128 [1/0]
Let’s try another ping:
R1#ping 2001:DB8:2:2::2
!!!!!
Static floating route
We can also configure floating static routes. To test this, I have to add another router:
Page 70 of 252
R3 is added to our topology and I configured the same loopback address
(2001:DB8:23:23::23/128) on both routers. R3 will be used as our main path to reach this
address. When the link is down we want to use R2.
Here’s the static route that is used to use R3 as the primary path:
R1(config)#ipv6 route 2001:DB8:23:23::/64 2001:DB8:13:13::3

Static floating route – outgoing interface
Let’s try the outgoing interface first. The static route looks like this:
R1(config)#ipv6 route 2001:DB8:23:23::/64 Serial 0/0/0 2
Note that at the end of the line above, I specified the administrative distance with a value of 2.
With both interfaces up, R1 will send all traffic to R3:
Page 71 of 252
S 2001:DB8:23:23::/64 [1/0]
via 2001:DB8:13:13::3
Above you can see that the default administrative distance is 1. Let’s shut the FastEthernet 0/0
interface to test our static floating route:

Let’s look at the routing table again:
S 2001:DB8:2:2::/64 [2/0]
The entry to R2 is now installed. You can also see the administrative distance value of two in the
routing table.
Static floating route – global unicast next hop
Instead of the outgoing interface, we can also use a global unicast address as the next hop:
R1(config)#ipv6 route 2001:DB8:2:2::/64 2001:DB8:12:12::2 2
The routing table will then look like this:
S 2001:DB8:2:2::/64 [2/0]
via 2001:DB8:12:12::2
Static floating route – link-local next hop
Or use a link-local address as the next hop:
R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0

2
S 2001:DB8:2:2::/64 [2/0]
Conclusion
Page 72 of 252
You have now learned how to configure the following IPv6 static routes:
 Static route for a prefix

 Static default route
 Static host route
 Static floating route
And how to do this with different next hop types:
 Outgoing interface (only for point-to-point interfaces)

 Global unicast address
 Link-local address
How to configure RIPNG on Cisco IOS

Router
RIPNG is the exact same protocol as RIP for IPv4 but it has been upgraded to support IPv6. In
this lesson i’ll demonstrate to you how to configure it on Cisco routers. Here’s the topology that
we’ll use:
Let’s use this topology to configure RIPNG. I’m going to create a loopback interface on each
router to advertise in RIPNG. Note that I don’t have any global unicast IPv6 addresses on the
FastEthernet interface because the RIPNG updates will be sent using the link-local addresses.
R1(config)#interface loopback 0
R1(config-if)#ipv6 address 2001::1/128
Don’t forget to enable IPv6 unicast routing otherwise no routing protocol will work for IPv6.

Loopback0 [up/up]
Page 73 of 252
2001::1
Loopback0 [up/up]
FE80::CE0A:18FF:FE0E:0
2001::2
After configuring the IPv6 addresses on the loopback interface you can see the global unicast
and the link-local IPv6 addresses. There is no link-local address on the FastEthernet interfaces
however.

Loopback0 [up/up]
2001::1
Loopback0 [up/up]
2001::2
Use the IPv6 enable command to generate a link-local address for the FastEthernet interfaces.
R1(config)#ipv6 router rip RIPNGTEST

R1(config-rtr)#exit
R1(config-if)#ipv6 rip RIPNGTEST enable
R1(config-if)#exit
R2(config)#ipv6 router rip RIPNGTEST
R2(config-rtr)#exit
R2(config-if)#exit
To enable RIPNG you first have to start the process with the IPV6 router rip command. You
have to give it a tag name and I called mine “RIPNGTEST”.
It doesn’t matter what tag name you choose and it doesn’t have to be the same on both routers.
Second step is to activate RIPNG on the interfaces you want by using the IPv6 rip enable
command. That’s not too bad right? No stinky network commands! Just enable it on the interface
and you are ready to go. The ipv6 rip enable command does two things:
[teaser]
Page 74 of 252
 Activate the prefix on the interface in RIPNG.
 Send RIPNG updates out of this interface.
R1#debug ipv6 rip

RIP Routing Protocol debugging is on
RIPng: Sending multicast update on FastEthernet0/0 for RIPNGTEST

src=FE80::CE09:18FF:FE0E:0
dst=FF02::9 (FastEthernet0/0)
sport=521, dport=521, length=32
command=2, version=1, mbz=0, #rte=1
tag=0, metric=1, prefix=2001::1/128
RIPng: Process RIPNGTEST received own response on Loopback0
RIPng: response received from FE80::CE0A:18FF:FE0E:0 on FastEthernet0/0 for
RIPNGTEST
src=FE80::CE0A:18FF:FE0E:0 (FastEthernet0/0)
dst=FF02::9
sport=521, dport=521, length=32
command=2, version=1, mbz=0, #rte=1
tag=0, metric=1, prefix=2001::2/128
Here’s part of the output of the debug IPv6 rip command. You can see that the link-local IPv6
addresses are used as source of the updates. The destination address is multicast FF02::9.
R1#show ipv6 route rip

IPv6 Routing Table - 4 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R 2001::2/128 [120/2]
via FE80::CE0A:18FF:FE0E:0, FastEthernet0/0
R 2001::1/128 [120/2]
via FE80::CE09:18FF:FE0E:0, FastEthernet0/0
A quick look at the routing table with the show IPv6 route command shows us that RIP has
learned about the networks.
hostname R2
!
!
interface loopback 0
ipv6 address 2001::2/128
Page 75 of 252
ipv6 rip RIPNGTEST enable
!
ipv6 enable
!
ipv6 router rip RIPNGTEST
!
end
hostname R1
!
!
!
ipv6 enable
!
ipv6 router rip RIPNGTEST
!
end
roubleshooting IPv6 RIPNG
In the picture above we have 2 routers, each router has a loopback interface and IPv6 addresses
have been configured on the loopback0 interfaces. RIPNG has been configured and we should
have connectivity between the two loopback0 interfaces. Unfortunately R1 is not learning about
network 2002::2/128. Let’s find out why!

Page 76 of 252
R1 hasn’t learned any RIPNG routes. What about R2?

R 1001::1/128 [120/2]
via FE80::CE00:4DFF:FE47:0, FastEthernet0/0
R2 has learned about the loopback0 interface behind R1. Let’s see if all interfaces are up and
running and configured for IPv6:

FE80::CE00:4DFF:FE47:0
2001:12::1
Loopback0 [up/up]
1001::1
2001:12::2
Loopback0 [up/up]
2002::2
All interfaces are configured for IPv6 and up and running, there are no issues here. Let’s check if
RIPNG is enabled on all interfaces:[teaser]
R1#show ipv6 protocols

IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip NEXTGEN"
Interfaces:
Loopback0
FastEthernet0/0
Redistribution:
None
Interfaces:
FastEthernet0/0
Redistribution:
None
We’ll use show ipv6 protocols to see if all prefixes are advertised. You can see that RIPNG is
not enabled on the loopback0 interface of R2, let’s fix that:
Page 77 of 252
R2(config-if)#ipv6 rip NEXTGEN enable
This is how we enable it. Let’s verify this:

Interfaces:
Loopback0
FastEthernet0/0
Redistribution:
None
Now we see that the loopback0 interface has joined RIPNG. Let’s check the routing table of R1
again:

R 2002::2/128 [120/2]
via FE80::CE01:4DFF:FE47:0, FastEthernet0/0
Now we see that 2002::2/128 is in the routing table of R1, problem solved!
Lesson learned: Make sure you activate RIPNG on all interfaces if they have prefixes that
you want to see advertised.
How to configure IPv6 EIGRP on Cisco IOS

Router
Cisco’s EIGRP is one of the routing protocols that is suitable for IPv6. Configuration is a bit
different and in this lesson I’ll demonstrate to you how to configure it. This is the topology we’ll
use:
Page 78 of 252
Note that I don’t have any global unicast IPv6 addresses on the FastEthernet interface because
the EIGRP updates will be sent using the link-local addresses.
Configuration
First we will enable routing for IPv6:
R1 & R2
And let’s configure some IPv6 addresses:
R1 & R2
(config)#interface GigabitEthernet 0/1
(config-if)#ipv6 enable
Enabling IPv6 on the Gigabit interfaces will generate an IPv6 link local address. The loopback
interfaces will have a global unicast address. Let’s verify our work:

GigabitEthernet0/1 [up/up]
FE80::F816:3EFF:FE7B:61CA
Loopback0 [up/up]
FE80::F816:3EFF:FEC5:1BD7
2001::1
GigabitEthernet0/1 [up/up]
FE80::F816:3EFF:FE8F:4F66
Loopback0 [up/up]
FE80::F816:3EFF:FED1:4100
2001::2
and the link-local IPv6 addresses.
This is how you enable EIGRP for IPv6:
Page 79 of 252
R1(config)#ipv6 router eigrp 1
R1(config-rtr)#router-id 1.1.1.1
R1(config-rtr)#no shutdown

R1(config-if)#ipv6 eigrp 1

First, you need to start EIGRP with the ipv6 router eigrp command. The number you see is the
autonomous system number and it has to match on both routers. Each EIGRP router needs a
router ID which is the highest IPv4 address on the router.
If you don’t have any IPv4 addresses you need to specify it yourself with the router-id
command. By default, the EIGRP process is in shutdown mode and you need to type no
shutdown to activate it.
Last step is to enable it on the interfaces with the ipv6 eigrp command. Let’s verify our
configuration:
[teaser]
R1#show ipv6 eigrp neighbors

EIGRP-IPv6 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q
Seq
(sec) (ms)
Cnt Num
0 Link-local address: Gi0/1 13 00:01:31 1586 5000 0
3
FE80::F816:3EFF:FE8F:4F66
R2#show ipv6 eigrp neighbors
EIGRP-IPv6 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q
Seq
(sec) (ms)
Cnt Num
0 Link-local address: Gi0/1 10 00:01:44 9 100 0
3
FE80::F816:3EFF:FE7B:61CA
Use show ipv6 eigrp neighbors to verify you have an adjacency.
R1#show ipv6 route eigrp
Page 80 of 252
IPv6 Routing Table - default - 3 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
a - Application
D 2001::2/128 [90/130816]
via FE80::F816:3EFF:FE8F:4F66, GigabitEthernet0/1
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
a - Application
D 2001::1/128 [90/130816]
via FE80::F816:3EFF:FE7B:61CA, GigabitEthernet0/1
Here we go…we have an EIGRP prefix in the routing table. That’s all there is to it!
hostname R2
!
!
ipv6 eigrp 1
!
interface GigabitEthernet 0/1
ipv6 enable
ipv6 eigrp 1
!
ipv6 router eigrp 1
router-id 2.2.2.2
no shutdown
!
end
hostname R1
!
!
ipv6 eigrp 1
Page 81 of 252
!
interface GigabitEthernet 0/1
ipv6 enable
ipv6 eigrp 1
!
ipv6 router eigrp 1
router-id 1.1.1.1
no shutdown
!
end
OSPFv2 vs OSPFv3
OSPFv2 and OSPFv3 are very similar. OSPFv3 still establishes neighbor adjacencies, has areas,
different network types, the same metrics, runs SPF, etc. There are however some differences.
OSPFv2 runs on top of IPv4 and since OSPFv3 runs on IPv6, some changes had to be made.
Here are some of the differences:
 Link-local addresses: OSPFv3 packets are sourced from link-local IPv6 addresses.
 Links, not networks: OSPFv3 uses the terminology links where we use networks in
OSPFv2.
 New LSA types: there are two new LSA types, and LSA type 1 and 2 have changed.
 Interface commands: OSPFv3 uses interface commands to enable it on the interface, we
don’t use the network command anymore as OSPFv2 does.
 OSPFv3 router ID: OSPFv3 is unable to set its own router ID like OSPFv2 does.
Instead, you have to manually configure the router ID. It is configured as a 32-bit value,
same as in OSPFv2.
 Multiple prefixes per interface: if you have multiple IPv6 prefixes on an interface then
OSPFv3 will advertise all of them.
 Flooding scope: OSPFv3 has a flooding scope for different LSAs.
 Multiple instances per link: You can run multiple OSPFv3 instances on a single link.
 Authentication: OSPFv3 doesn’t use plain text or MD5 authentication as OSPFv2 does.
Instead, it uses IPv6’s IPSec authentication.
 Prefixes in LSAs: OSPFv2 shows networks in LSAs as network + subnet mask, OSPFv3
shows prefixes as prefix + prefix length.
LSA Types
OSPFv3 has two new LSAs, and some of the LSA types have been renamed. Here is an
overview of all OSPFv2 and OSPFv3 LSA types:
OSPFv3 OSPFv2
LSA Type Code Name LSA Type Code Name
0x2001 Router LSA 1 Router LSA
Page 82 of 252
0x2002 Network LSA 2 Network LSA
0x2003 Inter-Area Prefix LSA 3 Network Summary LSA
0x2004 Inter-Area Router LSA 4 ASBR Summary LSA
0x4005 AS-External LSA 5 AS-External LSA
0x2006 Group Membership LSA 6 Group Membership LSA
0x2007 Type-7 LSA 7 NSSA External LSA
0x0008 Link LSA
0x2009 Intra-Area Prefix LSA
The LSA types are still the same except type 3 is now called the Inter-Area Prefix LSA and type
4 is called the Inter-Area router LSA. The last two types, the link LSA, and intra-area prefix LSA
are new to OSPFv3.
In OSPFv2, type 1 and type 2 LSAs are used for topology and network information. A single
LSA contains information about the topology and the networks that are used.
If you make a simple change, like changing the IP address on one of your routers then the
topology itself doesn’t change. In OSPFv2, a new type 1 LSA and perhaps a type 2 LSA have to
be flooded. Other routers that receive the new LSA(s) have to recalculate the SPT even
though the topology did not change.
In OSPFv3, they changed this by creating a separation between prefixes and the SPF tree. There
is no prefix information in LSA type 1 and 2, you only find topology adjacencies in these LSAs,
you don’t find any IPv6 prefixes in them. Prefixes are now advertised in type 9 LSAs and the
link-local addresses that are used for next hops are advertised in type 8 LSAs. Type 8 LSAs are
only flooded on the local link, type 9 LSAs are flooded within the area. The designers of
OSPFv3 could have included link-local addresses in type 9 LSAs but since these are only
required on the local link, it would be a waste of resources.
By separating the SPF tree and prefixes, OSPFv3 is more efficient. When the link-local address
on an interface changes, the router only has to flood an updated link LSA and intra-area-prefix
LSA. Since there are no changes to the topology, we don’t have to flood type 1 and 2 LSA(s).
Other routers won’t have to run SPF in this case.
Flooding Scope
In the table with LSA types above, you can see that the LSA types of OSPFv3 are hexadecimal
values. The first part defines the flooding scope of the LSA:
 0x0: the link-local scope that is used for the Link LSA, a new LSA type for OSPFv3.
 0x2: the area scope, used for LSAs that are flooded throughout a single area. This is used
for router, network, inter-area prefixes, inter-area router and intra-area prefix LSA types.
 0x4: the AS scope, used for LSAs that are flooded within the OSPFv3 routing domain,
used for external LSAs.[teaser]
Page 83 of 252
Headers
OSPFv2 and OSPFv3 use different headers. Here are some of the differences:
Field OSPFv3 OSPFv2

Header Size 16 bytes 24 bytes
Router & Area ID 32 bit 32 bit
Instance ID Yes No
Authentication IPSec plain text or MD5
The instance ID is a new field that can be used to run multiple OSPFv3 instances on a single
link. OSPFv3 routers will only become neighbors if the instance ID is the same, which is 0 by
default. This allows you to run OSPFv3 on a broadcast network and only form neighbor
adjacencies with specific neighbors that use the same instance ID.
Conclusion
This lesson should give you a quick overview of some of the differences between OSPFv2 and
OSPFv3. In other lessons, you will learn how to configure OSPFv3.
How to configure IPv6 OSPFv3 on Cisco IOS

Router
When we use OSPF for IPv4 we are using OSPFv2. OSPF has been updated for IPv6 and is now
called OSPFv3. These are two different routing protocols and in this lesson I’ll show you how to
configure OSPFv3 so that you can route IPv6 traffic. Here’s the topology we’ll use:
Let’s start with the configuration of the interfaces and the IPv6 addresses. We don’t have to
configure any global unicast IPv6 addresses on the FastEthernet interfaces because OSPFv3 uses
link-local addresses for the neighbor adjacency and sending LSAs.
Page 84 of 252
Don’t forget to enable IPv6 unicast routing otherwise no routing protocol will work for IPv6.

Loopback0 [up/up]
2001::1
Loopback0 [up/up]
2001::2
and the link-local IPv6 addresses. There is no link-local address on the FastEthernet interfaces
however so we’ll have to fix this:

Loopback0 [up/up]
2001::1
Loopback0 [up/up]
2001::2
Now we can configure OSPFv3:

[teaser]
R1(config)#ipv6 router ospf 1

R1(config-rtr)#exit
R1(config-if)#ipv6 ospf 1 area 0
R1(config-if)#exit
R2(config-rtr)#exit
Page 85 of 252
R2(config-if)#exit
Just like OSPFv2 you need to start a process and specify a process ID. For OSPFv3 we have to
use the ipv6 router ospf command. Just like EIGRP for IPv6 we need a router-ID if we don’t
have any IPv4 addresses configured on our router. Finally go to the interface and use the ipv6
ospf area command to enable OSPFv3 and select the correct area.
R1#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface

2.2.2.2 1 FULL/BDR 00:00:30 4 FastEthernet0/0

1.1.1.1 1 FULL/DR 00:00:39 4 FastEthernet0/0
Use show ipv6 ospf neighbor to see your neighbors. It’s funny to see the old IPv4 neighbor ID
even though OSPFv3 is IPv6-only.
R1#show ipv6 route ospf

U - Per-user Static route, M - MIPv6
D - EIGRP, EX - EIGRP external
O 2001::2/128 [110/10]
via FE80::C00F:1AFF:FEA7:0, FastEthernet0/0
U - Per-user Static route, M - MIPv6
D - EIGRP, EX - EIGRP external
O 2001::1/128 [110/10]
via FE80::C00E:1AFF:FEA7:0, FastEthernet0/0
In our routing table we find the fresh OSPFv3 route. That’s it! This is a fairly simple example
but it should help you to get going with OSPFv3 for IPv6.
hostname R2
!
!
Page 86 of 252
ipv6 ospf 1 area 0
!
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 2.2.2.2
!
end
hostname R1
!
!
ipv6 ospf 1 area 0
!
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 1.1.1.1
!
end
IPv6 OSPFv3 Default Route

Just like OSPF for IPv4, it is possible to advertise a default route in OSPFv3 for IPv6. In this
lesson, I’ll show you how to do this.
Configuration
We only need two routers for this example:
Page 87 of 252
R2 has a loopback interface with IPv6 address 2001:DB8:2:2::2/128. We won’t advertise this in
OSPFv3 directly but will reach it from R1 with a default route that is advertised by R2.
First, we have to enable IPv6 routing:
R1 & R2
Let’s configure some global unicast IPv6 addresses. We don’t need global unicast addresses for
OSPFv3 but we will need them if we want to send a ping from R1 to R2’s loopback address.

Let’s enable OSPFv3 on R1:


We do the same thing on R2, but also include the default route:

R2(config-rtr)#default-information originate always

Page 88 of 252
The default-information originate command is what advertises the default route, it’s the same
command that OSPFv2 for IPv4 uses.
The always parameter is required if you don’t have a default route in your own local routing table. If R2
had a default route pointing to another router, then you can remove the always parameter.
Verification
Let’s verify our work. First, let’s make sure our two routers are OSPFv3 neighbors:
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)

2.2.2.2 1 FULL/BDR 00:00:34 3
GigabitEthernet0/1
This seems to be the case. Let’s check if R1 has learned a default route from R2:
OE2 ::/0 [110/1], tag 1

via FE80::F816:3EFF:FE06:2CB2, GigabitEthernet0/1
Above you can see the default route. Note that it is advertised as an OSPF external type 2 route
with a default cost of 1. Let’s see if we can ping the loopback interface of R2:
R1#ping 2001:DB8:2:2::2
!!!!!
Our ping is working, which proves that our default route works.
hostname R1
!
ipv6 cef
!
no ip address
ipv6 address 2001:DB8:12:12::1/64
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 1.1.1.1
!
Page 89 of 252
end
hostname R2
!
ipv6 cef
!
interface Loopback0
no ip address
ipv6 address 2001:DB8:2:2::2/128
!
no ip address
ipv6 address 2001:DB8:12:12::2/64
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 2.2.2.2
default-information originate always
!
end
Conclusion
You have now learned how to configure an IPv6 OSPFv3 default route with the default-
information originate command. Keep in mind you need the always parameter if you don’t have
a default route in the routing table of the router that is going to advertise the default route. The
default route type is an external type 2 with a cost of 1.
OSPFv3 Prefix Suppression

Prefix Suppression, as explained in this OSPFv2 lesson is a method to get rid of transit prefixes.
Here’s a quick example:
Page 90 of 252
Above we have three routers running OSPFv3. H1 and H2 are host devices, and the only thing
we care about in this topology is having connectivity between these two hosts. This means R3
needs to know about prefix 2001:DB8:0:3::/64 and R3 about prefix 2001:DB8:0:1::/64.
We also have prefix 2001:DB8:0:12::/64 in between R1 and R2 and prefix 2001:DB8:0:23::/64

in between R2 and R3 but we don’t really need to have these prefixes in our routing tables, those
are only transit prefixes. Unlike OSPFv2 where you do have to configure IP addresses on your
transit links, OSPFv3 doesn’t need this. You only need link-local IPv6 addresses in order for
OSPFv3 to establish a neighbor adjacency so we could just remove these two prefixes.
However, if you do have configured transit prefixes on your routers and you have a reason to
keep them…you can still suppress them with prefix suppression.
Prefix suppression in OSPFv3 is much simpler than OSPFv2. In OSPFv2, prefixes are found in
the router (type 1) LSA and the network (type 2) LSA.
Page 91 of 252
OSPFv3 separates topology and prefix information. LSA type 1 and 2 are used for topology
information and the new link (type 8) LSA and intra area prefix (type 9) LSA contain addressing
information.
The link LSA associates a list of IPv6 addresses to a link and has a link-local flooding scope.
The intra area prefix LSA associates a list of IPv6 addresses with a router by referencing a router
LSA or with a broadcast/NBMA network by referencing a network LSA.
When the router refers a network LSA, the prefixes from the link LSA are copied into the intra
area prefix LSA by the DR.
To hide prefixes, OSPFv3 removes information from the link LSA and intra area prefix LSA.
Configuration
To demonstrate OSPFv3 prefix suppression, I use the following topology:
Page 92 of 252
In the topology above, each router has a loopback interface. The goal is that each router should
be able to ping any of the other loopback interfaces. I also added two transit prefixes:
 2001:DB8:0:123::/64 in between R1, R2 and R3

 2001:DB8:0:34::/64 in between R3 and R4
R1 and R2 will learn about 2001:DB8:0:34/64 and R4 will learn 2001:DB8:0:123::/64. Both
prefixes are unnecessary.
Since R3 and R4 are only connected to each other, this link has been configured as an OSPF
point-to-point network type.
Page 93 of 252
Want to take a look for yourself? Here you will find the startup configuration of each device.
hostname R1
!
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
ipv6 ospf 1 area 0
!
ipv6 address 2001:DB8:0:123::1/64
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 1.1.1.1
!
end
hostname R2
!
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:2:2::2/128
ipv6 ospf 1 area 0
!
ip address 10.255.2.72 255.255.0.0
!
ipv6 address 2001:DB8:0:123::2/64
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 2.2.2.2
!
end
hostname R3
!
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:3:3::3/128
ipv6 ospf 1 area 0
!
ipv6 address 2001:DB8:0:123::3/64
ipv6 enable
Page 94 of 252
ipv6 ospf 1 area 0
!
ipv6 address 2001:DB8:0:34::3/64
ipv6 enable
ipv6 ospf 1 area 0
ipv6 ospf network point-to-point
!
ipv6 router ospf 1
router-id 3.3.3.3
!
end
hostname R4
!
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:4:4::4/128
ipv6 ospf 1 area 0
!
ipv6 address 2001:DB8:0:34::4/64
ipv6 enable
ipv6 ospf 1 area 0
ipv6 ospf network point-to-point
!
ipv6 router ospf 1
router-id 4.4.4.4
!
end
Prefix Suppression Disabled
Prefix suppression is disabled by default. Let’s take a look at the routing tables of R1, R2, and
R4:
O 2001:DB8:0:34::/64 [110/2]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
O 2001:DB8:2:2::2/128 [110/1]
via FE80::F816:3EFF:FE2A:1133, GigabitEthernet0/1
O 2001:DB8:3:3::3/128 [110/1]
O 2001:DB8:4:4::4/128 [110/2]
O 2001:DB8:0:34::/64 [110/2]
O 2001:DB8:1:1::1/128 [110/1]
via FE80::F816:3EFF:FEC6:CDB1, GigabitEthernet0/1
O 2001:DB8:3:3::3/128 [110/1]
Page 95 of 252
O 2001:DB8:4:4::4/128 [110/2]
Above we see that R1 and R2 have learned 2001:DB8:0:34::/64. Here is R4:
O 2001:DB8:0:123::/64 [110/2]
O 2001:DB8:1:1::1/128 [110/2]
O 2001:DB8:2:2::2/128 [110/2]
O 2001:DB8:3:3::3/128 [110/1]
R4 has 2001:DB8:0:123::/64 in its routing table.
Link LSA
Prefix information is stored in the link LSA and the intra area prefix LSA. Let’s look at R3, our
DR (Designated Router) in this topology. First, we’ll take a look at the link LSA:
R3#show ipv6 ospf database link self-originate
Link (Type-8) Link States (Area 0)
LS age: 599
Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/2)
Link State ID: 4 (Interface ID)
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0xA820
Length: 56
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FE4A:6854
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:34::
Prefix Length: 64, Options: None
LS age: 599
Checksum: 0x9525
Length: 56
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEE3:9BA6
Page 96 of 252
Above we see the two transit prefixes. I highlighted the interesting part. Once prefix suppression
is enabled, this will be removed from the link LSA. Below is R4:
LS age: 646
Checksum: 0x4C21
Length: 56
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEAF:7D32
R4 shows information about 2001:DB8:0:34::/64. This information will be removed once prefix
suppression is enabled.
Intra Area Prefix LSA
Let’s look at the intra area prefix LSA. Let’s take a look at R3, our DR:
R3#show ipv6 ospf database prefix self-originate
Intra Area Prefix Link States (Area 0)
LS age: 614
LS Type: Intra-Area-Prefix-LSA
Link State ID: 0
Checksum: 0x54B5
Length: 64
Referenced LSA Type: 2001
Referenced Link State ID: 0
Referenced Advertising Router: 3.3.3.3
Prefix Address: 2001:DB8:3:3::3
Prefix Length: 128, Options: LA, Metric: 0
Page 97 of 252
Prefix Length: 64, Options: None, Metric: 1
LS age: 614
Link State ID: 3072
Checksum: 0xD0C2
Length: 44
Above we find information about 2001:DB8:0:34::/64 and 2001:DB8:0:123::/64. The

information I highlighted will be removed by prefix suppression. Let’s also take a look at R4:
LS age: 683
Link State ID: 0
Checksum: 0xB844
Length: 64
Once prefix suppression is enabled, you’ll see that the information about transit prefix
2001:DB8:0:34::/64 will be removed.
Prefix Suppression Enabled
Time to enable prefix suppression. I use the global command on all routers:
R1, R2, R3 & R4

(config)#ipv6 router ospf 1
(config-rtr)#prefix-suppression
That’s it.
Page 98 of 252
You can also enable prefix suppression with the interface command ipv6 ospf prefix-suppression.
Let’s start by checking the routing tables of R1, R2, and R4:[teaser]
O 2001:DB8:2:2::2/128 [110/1]
O 2001:DB8:3:3::3/128 [110/1]
O 2001:DB8:4:4::4/128 [110/2]
O 2001:DB8:1:1::1/128 [110/1]
via FE80::F816:3EFF:FEC6:CDB1, GigabitEthernet0/1
O 2001:DB8:3:3::3/128 [110/1]
O 2001:DB8:4:4::4/128 [110/2]
O 2001:DB8:1:1::1/128 [110/2]
O 2001:DB8:2:2::2/128 [110/2]
O 2001:DB8:3:3::3/128 [110/1]
As you can see above, information about the transit prefixes is gone.
Link LSA
So what has changed? To find out, we have to dive into the database again. Let’s start with R3:
LS age: 200
Checksum: 0xB27D
Length: 44
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FE4A:6854
LS age: 200
Page 99 of 252
Checksum: 0x30F
Length: 44
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEE3:9BA6
Above you can see that R3 has removed the transit prefixes. The number of prefixes now shows
0.
LS age: 253
Checksum: 0x567E
Length: 44
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEAF:7D32
Same thing on R4. Information about prefix 2001:DB8:0:34::/64 has been removed, and the
number of prefixes shows 0.
Prefix Intra Area LSA
Let’s check out the prefix intra area LSA that R3 (our DR) creates to see the changes:
LS age: 296
Link State ID: 0
Checksum: 0x73FE
Length: 52
Page 100 of 252

There is nothing here about 2001:DB8:0:34::/64 and 2001:DB8:0:123::/64 anymore.
Conclusion
You have now learned how OSPFv3 is able to suppress prefixes from the link LSA (type 8) and
the intra area prefix LSA (type 9).
Troubleshooting IPv6 OSPFv3 Neighbor

Adjacencies
In this lesson we’ll take a look at some OSPFv3 neighbor adjacency issues. Most of what you
learned about OSPFv3 for IPv4 also applies to OSPFv3. Let’s take a look at the first issue!
OSPFv3 Router ID
I will use the following topology:
In the topology above we have 2 routers and there’s only a single area. For some reason the two
routers are unable to become OSPF neighbors, up to us to find out why! Let’s check the
interfaces first:

FE80::CE00:1BFF:FE29:0
Page 101 of 252

IPv6 routing protocols use the link-local addresses for neighbor adjacency and next-hops. We
can see that both interfaces have a link-local IPv6 address and are active (up/up). Just in case,
let’s ping the other side just to be sure that we have connectivity:
R1#ping FE80::CE01:1BFF:FE29:0
Sending 5, 100-byte ICMP Echos to FE80::CE01:1BFF:FE29:0, timeout is 2
seconds:
Packet sent with a source address of FE80::CE00:1BFF:FE29:0
!!!!!
No issues there, let’s continue by checking OSPFv3:

IPv6 Routing Protocol is "ospf 1"
Interfaces (Area 0):
FastEthernet0/0
FastEthernet0/0
OSPFv3 is running on the FastEthernet0/0 interfaces of R1 and R2. No issues there, let’s check if
we have neighbors or not:

%OSPFv3: Router process 1 is INACTIVE, please configure a router-id
%OSPFv3: Router process 1 is INACTIVE, please configure a router-id
This command reveals it all. We find out that the router-id has not been configured. OSPFv3
requires an IPv4 address-style router-ID and we need to configure it ourselves. Let’s do that:
R1(config-rtr)#router-id ?
A.B.C.D OSPF router-id in IP address format
The router-ID has to be an IPv4 address format. I have no idea why they decided to do it this
way for OSPFv3 but my best guess is someone got a bit nostalgic. Anyway this fixes the issue:
R1# %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING

to FULL, Loading Done
Page 102 of 252

After configuring the router-ID we almost immediately see a message that the OSPFv3 neighbor
adjacency has been established. Let’s verify this:


Problem solved!
Lesson learned: Make sure you configure a router-ID for OSPFv3.
OSPFv3 Hello Packet Mismatch

Let’s look at another issue, same topology:
R1 and R2 are once again unable to form an OSPFv3 neighbor adjacency. Let’s check a couple
of things:

The interfaces and IPv6 addresses are fine. Let’s do a quick ping:
R1#ping FE80::CE01:1BFF:FE29:0
Page 103 of 252

Sending 5, 100-byte ICMP Echos to FE80::CE01:1BFF:FE29:0, timeout is 2
seconds:
Packet sent with a source address of FE80::CE00:1BFF:FE29:0
!!!!!
Pinging each other is no issue. Is OSPFv3 running?

FastEthernet0/0
FastEthernet0/0
OSPFv3 has been enabled on the interfaces, still we don’t have any neighbors:

Unfortunately we don’t have any neighbors. Let’s enable a debug:
R1#debug ipv6 ospf hello

OSPFv3 hello events debugging is on
Becoming OSPFv3 neighbors starts with a hello packet, let’s see what we discover:
R1# OSPFv3: Mismatched hello parameters from FE80::CE01:1BFF:FE29:0

OSPFv3: Dead R 36 C 40, Hello R 9 C 10
OSPFv3: Send hello to FF02::5 area 0 on FastEthernet0/0 from FE80::CE
There we go…we see that there is a mismatch in the hello parameters. R1 is configured to send
hello packets each 10 seconds and R2 is configured to send them every 9 seconds. The dead
timer also has a mismatch. Here’s what the timers look like:
R1#show ipv6 ospf 1 interface fa0/0 | include intervals

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
R2#show ipv6 ospf 1 interface fa0/0 | include intervals
We can verify the timers by using the show ipv6 ospf interface command. Let’s make sure they
match:
R2(config)#interface fa0/0
R2(config-if)#ipv6 ospf hello-interval 10
Page 104 of 252

Let’s change the hello timer back to 10 seconds, this also changes the dead timer interval. After a
few seconds you’ll see this:

That’s looking good, the routers have become OSPFv3 neighbors:


Another problem bites the dust!
Lesson Learned: OSPFv3 for IPv6 has the same requirements to form a neighbor
adjacency as OSPFv2 for IPv4. Apply your “IPv4 OSPF” knowledge to solve neighbor
adjacency issues.
OSPFv3 over Frame-Relay

Here’s something different for you. We are still working on troubleshooting OSPFv3 neighbor
adjacencies but we will use a different topology:
Page 105 of 252

In the scenario above we have a frame-relay setup. There’s a single PVC between R1 and R2. R1
has been configured to use 2001:12::1 and R2 is using 2001:12::2. For some reason the OSPFv3
neighbor adjacency is not working…let’s troubleshoot!
What’s the best place to start troubleshooting a problem like this? There are two options:
 Start in the middle of the OSI-model and dive into the OSPFv3 configuration right away.
 Start at the bottom of the OSI-model and check if the frame-relay configuration is
properly configured.
Personally I like a structured approach and start at the bottom of the OSI model and work my
way up. In this case that means we have to check if the interfaces are up, frame-relay
encapsulation has been configured, if the PVC is working, if we have a valid frame-relay map, if
we can ping each other and then move on to OSPFv3.
If you start at the bottom you’ll find the problem eventually but it might be a bit more time-
consuming sometimes. Just to try something different I’ll start in the middle of the OSI-model
this time and we’ll check the OSPFv3 configuration first:

I can confirm that there are no neighbor adjacencies. Let’s see if OSPFv3 is active:

Page 106 of 252

Serial0/0
Serial0/0
You can see that OSPFv3 has been enabled for the serial 0/0 interfaces. Let’s take a closer look
at the OSPFv3 configuration:[teaser]
R1#show ipv6 ospf interface serial 0/0

Serial0/0 is up, line protocol is up
Link Local Address FE80::9CD7:2EFF:FEF0:99FA, Interface ID 4
Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1, local address FE80::9CD7:2EFF:FEF0:99FA
No backup designated router on this network
R2#show ipv6 ospf interface serial 0/0
Serial0/0 is up, line protocol is up
Link Local Address FE80::9CD7:2EFF:FEF0:99FA, Interface ID 4
Area 0, Process ID 1, Instance ID 0, Router ID 2.2.2.2
Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 2.2.2.2, local address FE80::9CD7:2EFF:FEF0:99FA
No backup designated router on this network
This is something that is worth a closer look. The network type and timer intervals match. The
network type is “NON_BROADCAST” which means that we have to configure our neighbors
ourselves. Has this been done? Let’s take a look:

Nobody configured any neighbors otherwise they would show up in the output above. Let’s fix
this, first I’ll have to check what the link-local addresses are:

Serial0/0 [up/up]
FE80::9CD8:2EFF:FEF0:99FA
Serial0/0 [up/up]
FE80::9CD7:2EFF:FEF0:99FA
Here you can see the link-local addresses that we need to use. Let’s configure the neighbors:
R1(config)#interface serial 0/0

R1(config-if)#ipv6 ospf neighbor FE80::9CD7:2EFF:FEF0:99FA
Page 107 of 252

R2(config-if)#ipv6 ospf neighbor FE80::9CD8:2EFF:FEF0:99FA
This is how we configure the neighbors ourselves. Let’s see if this solves our problem:

N/A 0 ATTEMPT/DROTHER 00:01:00 0 Serial0/0

N/A 0 ATTEMPT/DROTHER 00:00:39 0 Serial0/0
Too bad…I want to see “FULL” but I’m only seeing “ATTEMPT” here. My OSPFv3
configuration looks fine to me so this would be a good moment to move further down the OSI
model. Let’s try a quick ping between the two routers:
R1#ping FE80::9CD7:2EFF:FEF0:99FA
Output Interface: Serial0/0
Sending 5, 100-byte ICMP Echos to FE80::9CD7:2EFF:FEF0:99FA, timeout is 2
seconds:
Packet sent with a source address of FE80::9CD8:2EFF:FEF0:99FA
.....
Success rate is 0 percent (0/5)
I’m unable to ping between the link-local addresses. Now I know that layer 3 of the OSI-model
is not working, let’s dive deeper…
R1#show frame-relay map

R2#show frame-relay map
There seems to be no frame-relay map. We need this in order to bind the DLCI to the IPv6
addresses. Normally Inverse ARP takes care of this but not this time. It’s probably disabled (or
the interface is not operational). Let’s check if the PVCs are active:
R1#show frame-relay pvc | include ACTIVE

DLCI = 102, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
R2#show frame-relay pvc | include ACTIVE
DLCI = 201, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
We’ll check if the PVC is operational and what the DLCI number is. It’s active on both sides and
you can see the DLCI numbers, let’s create some frame-relay maps:

R1(config-if)#frame-relay map ipv6 FE80::9CD7:2EFF:FEF0:99FA 102
R2(config-if)#frame-relay map ipv6 FE80::9CD8:2EFF:FEF0:99FA 201
I’ll map the link-local addresses to the DLCI numbers. After a few seconds we’ll see this:
Page 108 of 252

R1# %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from LOADING to
FULL, Loading Done
R2# %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0 from LOADING to
FULL, Loading Done
This is looking good! Let’s verify our work:

2.2.2.2 1 FULL/DR 00:01:47 4 Serial0/0

1.1.1.1 1 FULL/BDR 00:01:58 4 Serial0/0
Problem solved!
Lesson learned: Check the OSPFv3 network type and configure the neighbors using the
link-local addresses. Also make sure you have the correct frame-relay maps.
That’s all I have for now, keep in mind that most of what you know about OSPF (version 2) can
also be applied to troubleshooting OSPFv3.
Multiprotocol BGP (MP-BGP) Configuration

The normal version of BGP (Border Gateway Protocol) only supported IPv4 unicast prefixes.
Nowadays we use MP-BGP (Multiprotocol BGP) which supports different addresses:
 IPv4 unicast
 IPv4 multicast
 IPv6 unicast
 IPv6 multicast
MP-BGP is also used for MPLS VPN where we use MP-BGP to exchange the VPN labels. For
each different “address” type, MP-BGP uses a different address family.
To allow these new addresses, MBGP has some new features that the old BGP doesn’t have:
 Address Family Identifier (AFI): specifies the address family.

 Subsequent Address Family Identifier (SAFI): Has additional information for some address
families.
 Multiprotocol Reachable Network Layer Reachability Information (MP_UNREACH_NLRI): This
is an attribute used to transport networks that are unreachable.
 BGP Capabilities Advertisement: This is used by a BGP router to announce to the other BGP
router what capabilities it supports. MP-BGP and BGP-4 are compatible, the BGP-4 router can
ignore the messages that it doesn’t understand.
Page 109 of 252

Since MP-BGP supports IPv4 and IPv6 we have a couple of options. MP-BGP routers can
become neighbors using IPv4 addresses and exchange IPv6 prefixes or the other way around.
Let’s take a look at some configuration examples…
Configuration
MP-BGP with IPv6 adjacency & IPv6 prefixes
Let’s start with a simple example where we use IPv6 for the neighbor adjacency and exchange
some IPv6 prefixes. Here’s the topology I will use:
Here’s the configuration of R1:
R1(config)#router bgp 1
R1(config-router)#neighbor 2001:db8:0:12::2 remote-as 2
R1(config-router)#address-family ipv4
R1(config-router-af)#no neighbor 2001:db8:0:12::2 activate
R1(config-router-af)#exit
R1(config-router-af)#neighbor 2001:db8:0:12::2 activate
R1(config-router-af)#network 2001:db8::1/128
In the configuration above we first specify the remote neighbor. The address-family command is
used to change the IPv4 or IPv6 settings. I disable the IPv4 address-family and enabled IPv6.
Last but not least, we advertised the prefix on the loopback interface. The configuration of R2
looks similar:
R2(config-router-af)#no neighbor 2001:db8:0:12::1 activate
Page 110 of 252

R2(config-router-af)#exit
After awhile the neighbor adjacency will appear:
R1#
%BGP-5-ADJCHANGE: neighbor 2001:DB8:0:123::2 Up
Now let’s check the routing tables:
R1#show ipv6 route bgp

D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
B 2001:DB8::2/128 [20/0]
via FE80::217:5AFF:FEED:7AF0, FastEthernet0/0
R2#show ipv6 route bgp
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
B 2001:DB8::1/128 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
The routers learned each others prefixes…great! This example was pretty straight-forward but
you have now learned how MP-BGP uses different address families.
hostname R1
!
interface Loopback 0
ipv6 enable
ipv6 address 2001:DB8::1/128
!
interface fastEthernet0/0
ipv6 enable
ipv6 address 2001:DB8:0:12::1/64
!
router bgp 1
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::2 remote-as 2
!
Page 111 of 252

address-family ipv4
no neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8::1/128
neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
end
hostname R2
!
ipv6 enable
!
ipv6 enable
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8::2/128
exit-address-family
!
end
MP-BGP with IPv4 adjacency & IPv6 prefixes
let’s look at a more complex example, the routers will become neighbors through IPv4 but will
exchange IPv6 prefixes. I’ll use the same topology but with an IPv4 subnet in between:
Page 112 of 252

Here’s the configuration:
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R2(config-router)#neighbor 192.168.12.1 remote-as 1
Now we can configure the address-family for IPv6 unicast:
R1(config-router-af)#neighbor 192.168.12.2 activate
R2(config-router-af)#neighbor 192.168.12.1 activate
Once we enter the address-family IPv6 configuration there are two things we have to configure.
The prefix has to be advertised and we need to specify the neighbor. The prefixes on the
loopback interface should now be advertised. Let’s check it out:
R1#show ip bgp ipv6 unicast

BGP table version is 2, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-
external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path

*> 2001:DB8::1/128 :: 0 32768 i
* 2001:DB8::2/128 ::FFFF:192.168.12.2
0 0 2 i
Page 113 of 252

R2#show ip bgp ipv6 unicast
internal,

* 2001:DB8::1/128 ::FFFF:192.168.12.1
0 0 1 i
*> 2001:DB8::2/128 :: 0 32768 i
As you can see the routers have learned about each others prefixes. There’s one problem
though…we were able to exchange IPv6 prefixes but we only use IPv4 between R1 and R2,
there is no valid next hop address that we can use.
To fix this, we need to use some IPv6 addresses that we can use as the next hop. We’ll have to
configure a prefix between R1 and R2 for this:

R1(config-if)#ipv6 address 2001:db8:0:12::1/64
R2(config-if)#ipv6 address 2001:db8:0:12::2/64
Now we have IPv6 addresses that we can use as the next hop. We are using IPv4 for the neighbor
peering so the next hop doesn’t change automatically. We’ll have to use a route-map for this:
R1(config)#route-map IPV6_NEXT_HOP permit 10

R1(config-route-map)#set ipv6 next-hop 2001:db8:0:12::2
R1(config-router-af)#neighbor 192.168.12.2 route-map IPV6_NEXT_HOP in
R2(config)#route-map IPV6_NEXT_HOP permit 10
R2(config-route-map)#set ipv6 next-hop 2001:db8:0:12::1
R2(config-router-af)#neighbor 192.168.12.1 route-map IPV6_NEXT_HOP in
Both routers now change the next hop IPv6 address of incoming prefixes. Let’s reset BGP:
R1#clear ip bgp *
Take a look now:
R1#show ip bgp ipv6 unicast | begin 2001

*> 2001:DB8::1/128 :: 0 32768 i
*> 2001:DB8::2/128 2001:DB8:0:12::2
R2#show ip bgp ipv6 unicast | begin 2001
*> 2001:DB8::1/128 2001:DB8:0:12::1
Page 114 of 252

The next hop IPv6 addresses are now reachable so they can be installed in the routing table. The
downside of this solution is that we had to fix the next hop ourselves, the advantage however is
that we have a single BGP neighbor adjacency that can be used for the exchange of IPv4 and
IPv6 prefixes.
hostname R1
!
!
!
ipv6 enable
ip address 192.168.12.1 255.255.255.0
ipv6 address 2001:DB8:0:12::1/64
!
router bgp 1
neighbor 192.168.12.2 remote-as 2
address-family ipv6
network 2001:db8::1/128
neighbor 192.168.12.2 activate
neighbor 192.168.12.2 route-map IPV6_NEXT_HOP in
!
route-map IPV6_NEXT_HOP permit 10
set ipv6 next-hop 2001:DB8:0:12::2
!
end
hostname R2
!
!
!
ipv6 enable
ip address 192.168.12.2 255.255.255.0
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
address-family ipv6
network 2001:DB8::2/128
neighbor 192.168.12.1 route-map IPV6_NEXT_HOP in
!
route-map IPV6_NEXT_HOP permit 10
set ipv6 next-hop 2001:db8:0:12::1
!
end
Page 115 of 252

BGP IPv6 Route Filtering on Cisco IOS
Filtering IPv6 routes in BGP is similar to IPv4 filtering. There are 3 methods we can use:
 Prefix-list
 Filter-list
 Route-map
Each of these can be applied in- or outbound. I’ll explain how you can use these for filtering, this
is the topology I will use:
R1 and R2 are using IPv6 addresses and will use MP-BGP so that R1 can advertise some
prefixes on its loopback interfaces. All prefixes on the loopback interfaces are /64 subnets while
loopback3 has a /96 subnet.
Configuration
Let’s start with a basic MP-BGP configuration so that R1 and R2 become eBGP neighbors:
R1 & R2#
(config)ipv6 unicast-routing
R1(config-router)#bgp router-id 1.1.1.1
R1(config-router-af)#network 2001:db8:0:1::/64
R2(config-router)#bgp router-id 2.2.2.2
Let’s check if R2 has learned all prefixes:

Page 116 of 252
R2#show ipv6 route bgp | begin 2001
B 2001:DB8:0:1::/64 [20/0]
B 2001:DB8:0:11::/64 [20/0]
B 2001:DB8:0:111::/64 [20/0]
B 2001:DB8:0:1111::/96 [20/0]
There we go, everything is in the routing table. Now we can play with some of the filtering
options…
Prefix-List Filtering
Let’s start with the prefix-list. R1 is advertising one /96 subnet. Let’s see if we can configure R2
to filter this network:
R2(config)#ipv6 prefix-list SMALL_NETWORKS permit 2001::/16 le 64
This prefix-list checks the entire 2001::/16 range and permits subnets with a /64 or larger.
Anything smaller will be denied. Let’s activate it:
R2(config-router-af)#neighbor 2001:db8:0:12::1 prefix-list SMALL_NETWORKS in
We activate the prefix-list inbound on R2 for everything that we receive from R1. Let’s reset
BGP to speed things up:
R2#clear ip bgp *
Let’s check R2 to see if our prefix is gone:

B 2001:DB8:0:1::/64 [20/0]
B 2001:DB8:0:11::/64 [20/0]
B 2001:DB8:0:111::/64 [20/0]
Great, it has been filtered succesfully!
Filter-List Filtering
Let’s try the filter-list. We can use this to filter prefixes from certain autonomous systems.
Everything that R1 is advertising only has AS 1 in the AS path, I’ll configure AS prepending so
we have something to play with:
Page 117 of 252

R1(config)#ipv6 prefix-list FIRST_LOOPBACK permit 2001:db8:0:1::/64
R1(config)#route-map PREPEND permit 10

R1(config-route-map)#match ipv6 address prefix-list FIRST_LOOPBACK
R1(config-route-map)#set as-path prepend 11
R1(config)#route-map PREPEND permit 20
R1(config-router-af)#neighbor 2001:db8:0:12::2 route-map PREPEND out
The above configuration will make sure that whenever R1 advertises 2001:db8:0:1::/64 it will
add AS 11 to the AS path. Let’s verify this:
R2#show ip bgp all

For address family: IPv4 Unicast
For address family: IPv6 Unicast

internal,

*> 2001:DB8:0:1::/64
2001:DB8:0:12::1
0 0 1 11 i
*> 2001:DB8:0:11::/64
2001:DB8:0:12::1
0 0 1 i
*> 2001:DB8:0:111::/64
2001:DB8:0:12::1
0 0 1 i
For address family: IPv4 Multicast
Above you can see that 2001:DB8:0:1::/64 now has AS 11 in its AS path. Let’s configure a
filter-list on R2 to get rid of this network:
R2(config)#ip as-path access-list 11 permit ^1$
R2(config-router-af)#neighbor 2001:db8:0:12::1 filter-list 11 in
R2#clear ip bgp *
The as-path access-list above only permits prefixes from AS1, nothing else. We attach it inbound
to everything we receive from R1. This is the result:
Page 118 of 252

B 2001:DB8:0:11::/64 [20/0]
B 2001:DB8:0:111::/64 [20/0]
It’s gone from the routing table, mission accomplished.
Route-Map Filtering
Route-maps are really useful and can be used to match on many different things. I’ll use an IPv6
access-list in a route-map to filter 2001:DB8:0:11::/64:
R2(config)#ipv6 access-list THIRD_LOOPBACK

R2(config-ipv6-acl)#permit 2001:db8:0:11::/64 any
R2(config)#route-map MY_FILTER deny 10

R2(config-route-map)#match ipv6 address THIRD_LOOPBACK
R2(config-route-map)#exit
R2(config)#route-map MY_FILTER permit 20
R2(config-router-af)#neighbor 2001:db8:0:12::1 route-map MY_FILTER in
R2#clear ip bgp *
The configuration above has an access-list called “THIRD_LOOPBACK” that matches

2001:DB8:0:11::/64 and is denied in the route-map called “MY_FILTER”. Last but not least, we
apply it inbound on R2. Here’s the result:
R2#show ipv6 access-list

IPv6 access list THIRD_LOOPBACK
permit ipv6 2001:DB8:0:11::/64 any (1 match) sequence 10
B 2001:DB8:0:111::/64 [20/0]
The access-list tells us that it has a match and you can see it’s gone from the routing table.
Order of Operation
You have now seen how you can use a prefix-list, filter-list and route-map to filter IPv6 prefixes.
You can apply all of these at the same time if you want, I didn’t remove any of my previous
configurations when I was writing this lesson. Take a look at R2:
R2#show run | sec address-family ipv6

address-family ipv6
neighbor 2001:DB8:0:12::1 prefix-list SMALL_NETWORKS in
neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
neighbor 2001:DB8:0:12::1 filter-list 11 in
Page 119 of 252

On a production network you probably won’t use all of these at the same time. The route-map is
a popular choice since you can use it for pretty much anything, filtering and doing things like
prepending the AS path.
If you do activate all of these at the same time then you might want to know in what order the
router will process these filtering techniques. Here they are:
Inbound:
 Route-map
 Filter-List
 Prefix-List
Outbound:
 Prefix-List
 Filter-List
 Route-Map
Why do we care about this? Imagine you have an inbound route-map and prefix-list. If you
permitted a prefix in the prefix-list but denied it in the route-map then you will never see the
prefix in your BGP table since the route-map is processed before the prefix-list.
For outbound filtering it’s the other way around. If you permit something in the route-map but
denied it in a filter-list then it will never be advertised…the filter-list is processed before the
route-map for outbound updates.
Don’t make it too hard for yourself…it’s best to stick to using the route-map only since you can
attach prefix-lists and as-path access-lists to it.
hostname R1
!
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::1/64
!
interface Loopback0
ipv6 address 2001:DB8:0:1::1/64
!
interface Loopback1
ipv6 address 2001:DB8:0:11::1/64
!
interface Loopback2
ipv6 address 2001:DB8:0:111::1/64
!
interface Loopback3
ipv6 address 2001:DB8:0:1111::1/64
Page 120 of 252

!
router bgp 1
bgp router-id 1.1.1.1
!
address-family ipv4
neighbor 2001:DB8:0:12::2 route-map PREPEND out
exit-address-family
!
address-family ipv6
network 2001:DB8:0:1::/64
network 2001:DB8:0:11::/64
network 2001:DB8:0:111::/64
network 2001:DB8:0:1111::/96
neighbor 2001:DB8:0:12::2 route-map PREPEND out
exit-address-family
!
ipv6 prefix-list FIRST_LOOPBACK permit 2001:db8:0:1::/64
route-map PREPEND permit 10
match ipv6 address prefix-list FIRST_LOOPBACK
set as-path prepend 11
route-map PREPEND permit 20
!
end
hostname R2
!
!
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
!
address-family ipv4
exit-address-family
!
address-family ipv6
neighbor 2001:DB8:0:12::1 prefix-list SMALL_NETWORKS in
neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
neighbor 2001:DB8:0:12::1 filter-list 11 in
exit-address-family
!
ipv6 prefix-list SMALL_NETWORKS permit 2001::/16 le 64
!
ip as-path access-list 11 permit ^1$
!
ipv6 access-list THIRD_LOOPBACK
Page 121 of 252

permit 2001:db8:0:11::/64 any
!
route-map MY_FILTER deny 10
match ipv6 address THIRD_LOOPBACK
route-map MY_FILTER permit 20
!
end
How to configure IPv6 Redistribution

RIPNG OSPFv3
Redistribution for IPv6 is pretty much the same as for IPv4, the same rules apply. I want to show
you an example of IPv6 redistribution between RIPNG and OSPFv3. Here’s the topology that we
will use:
In the middle we have router R2 that will perform the redistribution between RIPNG and
OSPFv3. R1 and R3 have a loopback interface that will be advertised.
R1(config-if)#exit
R2(config-if)#exit
R3(config-if)#exit
Page 122 of 252

This is what we’ll start with. I’m using the loopbacks to have something to advertise in RIPNG
or OSPFv3. On the FastEthernet interfaces I only need a link-local IPv6 address.
R2(config)#ipv6 router rip RIPNG

R2(config-rtr)#exit
R2(config-if)#ipv6 rip RIPNG enable
R1(config-rtr)#exit
R1(config-if)#exit
I’m configuring RIPNG on R2 and R1 to get things going.

R3(config-rtr)#exit
R3(config-if)#interface loopback 0
R2(config-rtr)#exit
And this is what we need on R3 and R2 to get OSPFv3 working.

R2(config-rtr)#redistribute rip RIPNG
R2(config-rtr)#exit
R2(config-rtr)#redistribute ospf 1 metric 1
We use the redistribute command to exchange routing information between OSPFv3 and
RIPNG. This is all you have to do to redistribute everything.

R 2001::3/128 [120/2]
via FE80::CE04:19FF:FE67:0, FastEthernet0/0
Page 123 of 252

OE2 2001::1/128 [110/20]
via FE80::CE04:19FF:FE67:10, FastEthernet0/0
We can verify our configuration by looking at the routing tables. If you want you can be a bit
more specific with redistribution using route-maps:
[teaser]

R2(config-rtr)#redistribute ospf 1 route-map ONLYTHESE
R2(config-rtr)#exit
R2(config)#ipv6 prefix-list MYPREFIXES permit 2001::3/128
R2(config)#route-map ONLYTHESE permit 10

R2(config-route-map)#match ipv6 address prefix-list MYPREFIXES
Using a route-map and a prefix-list like in the example above I can select only the prefixes that I
want redistributed. This is a better solution than just redistributing everything.
hostname R2
!
!
ipv6 enable
ipv6 rip RIPNG enable
!
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router rip RIPNG
redistribute ospf 1 metric 1
redistribute ospf 1 route-map ONLYTHESE
!
ipv6 prefix-list MYPREFIXES permit 2001::3/128
!
route-map ONLYTHESE permit 10
match ipv6 address prefix-list MYPREFIXES
!
ipv6 router ospf 1
router-id 2.2.2.2
redistribute rip RIPNG
!
end
hostname R3
!
Page 124 of 252

!
ipv6 ospf 1 area 0
!
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 3.3.3.3
!
end
hostname R1
!
!
!
ipv6 enable
!
!
end
Troubleshooting IPv6 Redistribution

Redistribution for IPv6 is pretty similar to IPv4, the same rules and issues apply here. There is
however one issue that only applies to IPv6 redistribution which I will show you here. This is the
topology I will use:
Page 125 of 252

R1 and R2 are configured to use EIGRP, R2 and R3 use OSPF. R2 is redistributing between the
two routing protocols. The problem is that R1 is unable to reach 2001:0DB8:23:23::/64 and R3 is
unable to reach 2001:0DB8:12:12::/64. Everything else is reachable…
Let’s check some routing tables, see what we are dealing with:
EX 2001:DB8:3:3::3/128 [170/1757696]
via FE80::C002:17FF:FE28:0, FastEthernet0/0
R2#show ipv6 route
D 2001:DB8:1:1::1/128 [90/409600]
via FE80::C001:18FF:FEB0:0, FastEthernet0/0
O 2001:DB8:3:3::3/128 [110/10]
via FE80::C003:FFF:FE10:0, FastEthernet0/1
OE2 2001:DB8:1:1::1/128 [110/20]

Looking at these routing tables, we can see that R1 knows how to reach the loopback of R3 and
vice versa. Since we have something in the routing table, we know that the EIGRP and OSPF
neighbor adjacencies are working. There are a couple of reasons why we could miss something
in the routing table:
 Networks are not configured: Keep in mind that IPv6 routing protocols use their link-
local IPv6 addresses for the neighbor adjacency.
 Filtering: Route filtering could filter some of the prefixes.
 Redistribution: Configuration errors with redistribution could cause issues.
Page 126 of 252

Let’s check if those two networks are configured correctly, you could check the addresses or do
a quick ping:

FE80::C002:17FF:FE28:0
2001:DB8:12:12::2
FE80::C002:17FF:FE28:1
2001:DB8:23:23::2
R2#ping 2001:0DB8:12:12::1

!!!!!
R2#ping 2001:0DB8:23:23::3

!!!!!
It seems that these networks are configured and the pings are working. What about filtering?
Normally I’d like to use specific show commands but in this case, checking the EIGRP and
OSPF configs will be easier:
R1#show run | section ipv6 router

ipv6 router eigrp 12
router-id 1.1.1.1
no shutdown
ipv6 router eigrp 12
router-id 2.2.2.2
no shutdown
redistribute ospf 1 metric 1500 100 255 1 1500
ipv6 router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute eigrp 12
ipv6 router ospf 1
router-id 3.3.3.3
These configurations are pretty straight-forward. There are no filters and no route-maps attached
to the redistribution config, everything is looking good. So what’s the issue here?
Redistribution for IPv6 works a little bit different compared to IPv4. When you redistribute with
IPv4, all networks that are advertised in your routing protocols will be redistributed…that
includes the directly connected networks.
Page 127 of 252

With IPv6, networks that are directly connected and advertised in your routing protocols are
NOT redistributed by default…this is something we have to enable ourselves. Let me show
you what I mean:[teaser]

R2(config-rtr)#redistribute ospf 1 metric 1500 100 255 1 1500 include-
connected
R2(config-rtr)#redistribute eigrp 12 include-connected
We need to add the include-connected keyword when we want to redistribute the directly
connected networks that are advertised in our routing protocol. Let’s see the result of this:
EX 2001:DB8:3:3::3/128 [170/1757696]
EX 2001:DB8:23:23::/64 [170/1757696]
OE2 2001:DB8:1:1::1/128 [110/20]

OE2 2001:DB8:12:12::/64 [110/20]
R1 and R3 are now able to learn about the 2001:DB8:23:23::/64 and 2001:DB8:12:12::/64
networks…problem solved.
Lesson learned: IPv6 redistribution behaves a bit different than IPv4 redistribution.
IPv6 Access-list on Cisco IOS

As explained in my first tutorial that introduces access-lists, we can use access-lists for filtering
(blocking packets) or selecting traffic (for VPNs, NAT, etc).
This also applies to IPv6 access-lists which are very similar to IPv4 access-lists. There are two
important differences however:
 IPv4 access-lists can be standard or extended, numbered or named. IPv6 only has named
extended access-lists.
 IPv4 access-lists have an invisible implicit deny any at the bottom of every access-list.
IPv6 access-lists have three invisible statements at the bottom:
o permit icmp any any nd-na
o permit icmp any any nd-ns
o deny ipv6 any any
Page 128 of 252

The two permit statements are required for neighbor discovery which is an important protocol in
IPv6, it’s the replacement for ARP.
When you use a deny ipv6 any any at the bottom of your access-list, make sure you also add the
two permit statements for neighbor discovery just before the final statement or this traffic will be
dropped.
Having said that, let’s take a look at the configuration.
Configuration
For this demonstration we only need two routers:
I’ll use subnet 2001:DB8:0:12::/64 in between R1 and R2. To demonstrate the access-list, I’ll
create one inbound on R2 and we will try to filter some packets from R1. Let’s take a look at the
access-list:
R2(config)#ipv6 access-list ?
WORD User selected string identifying this access list
log-update Control access list log updates
As you can see above the only option is the named access-list. There’s also no option for
standard or extended access-list. Let’s create that access-list:
R2(config)#ipv6 access-list R1_TRAFFIC
I’ll call it “R1_TRAFFIC”. Here are our options when we create a statement:
R2(config-ipv6-acl)#permit ?
<0-255> An IPv6 protocol number
X:X:X:X::X/<0-128> IPv6 source prefix x:x::y/<z>
ahp Authentication Header Protocol
any Any source prefix
esp Encapsulation Security Payload
host A single source host
icmp Internet Control Message Protocol
ipv6 Any IPv6
pcp Payload Compression Protocol
sctp Streams Control Transmission Protocol
tcp Transmission Control Protocol
udp User Datagram Protocol
Page 129 of 252

This is similar to IPv4 access-lists. You can pick any protocol you like. Let’s see if we can
permit telnet traffic from R1 and deny everything else:[teaser]
R2(config-ipv6-acl)#permit tcp ?
X:X:X:X::X/<0-128> IPv6 source prefix x:x::y/<z>
any Any source prefix
host A single source host
Let’s permit telnet traffic from R1:
R2(config-ipv6-acl)#permit tcp host 2001:db8:0:12::1 ?

X:X:X:X::X/ IPv6 destination prefix x:x::y/
any Any destination prefix
eq Match only packets on a given port number
gt Match only packets with a greater port number
host A single destination host
lt Match only packets with a lower port number
neq Match only packets not on a given port number
range Match only packets in the range of port numbers
After specifying the source IP I also have to select the destination IP, let’s do that:
R2(config-ipv6-acl)#permit tcp host 2001:db8:0:12::1 any eq 23
This should permit telnet traffic from R1. Let’s take a look at our access-list:
R2#show access-lists
IPv6 access list R1_TRAFFIC
permit tcp host 2001:DB8:0:12::1 any eq telnet sequence 10
Above you see our statement. One cosmetic difference with IPv4 access-lists is that the sequence
number is behind the statement. Let’s apply this access-list on the interface:

R2(config-if)#ipv6 traffic-filter R1_TRAFFIC in
Instead of using the access-group command you have to use the ipv6 traffic-filter command.
R1#telnet 2001:db8:0:12::2
Trying 2001:DB8:0:12::2 ... Open
R1 is able to telnet to R2. Let’s see if we find any matches on our access-list:
R2#show access-lists
IPv6 access list R1_TRAFFIC
permit tcp host 2001:DB8:0:12::1 any eq telnet (10 matches) sequence 10
There we go, we see it matches the access-list. Anything else should be dropped…let’s try a
simple ping:
Page 130 of 252

R1#ping 2001:db8:0:12::2
AAAAA
The AAAAAs that you see above indicate that the destination is administratively unreachable, it
means that an access-list is dropping our packets.
Usually, this output indicates that an access list is blocking traffic. For security reasons it might
be a bad idea to tell someone that traffic has been dropped. If you want you can disable this:

R2(config-if)#no ipv6 unreachables
Use the no ipv6 unreachables command to disable this. When we send another ping now you
will see this:
R1#ping 2001:db8:0:12::2
.....
R2 is no longer informing R1 that the packets have been dropped. That’s all I have for now, have
fun configuring IPv6 access-lists.
hostname R1
!
!
no ip address
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname R2
!
!
no ip address
ipv6 address 2001:DB8:0:12::2/64
no ipv6 unreachables
ipv6 traffic-filter R1_TRAFFIC in
!
ipv6 access-list R1_TRAFFIC
Page 131 of 252

permit tcp host 2001:DB8:0:12::1 any eq telnet
!
end
You can also add an IPv6 access-list on a switchport (L2) interface with the PACL.
OSPFv3 Authentication and Encryption

OSPFv3 doesn’t have an authentication field in its header like OSPFv2 does, instead it relies on
IPsec to get the job done.
IPsec supports two encapsulation types. The first one is AH (Authentication Header) which as
the name implies, authenticates the header. The other encapsulation type is ESP (Encapsulating
Security Payload) which encrypts packets. We can use both for OSPFv3 so besides
authentication, encryption is also a possibility.
In this lesson I’ll show you how to configure both options.
Configuration
We will use the following topology for this:
We only need two routers for this demonstration. I will only use the link-local IPv6 addresses on
these two routers. Let’s enable OSPFv3:
R1 & R2#
(config-if)#ipv6 ospf 1 area 0
Page 132 of 252

Now we can play with authentication…
IPsec Authentication
To get started we have to use the ipv6 ospf authentication command:

R1(config-if)#ipv6 ospf authentication ?
ipsec Use IPsec authentication
null Use no authentication
Since we want authentication, we’ll select ipsec:
R1(config-if)#ipv6 ospf authentication ipsec ?

spi Set the SPI (Security Parameters Index)
First we have to choose a SPI. You can pick any number you like but it has to match on both
routers. Let’s pick the lowest available number (256):
R1(config-if)#ipv6 ospf authentication ipsec spi 256 ?

md5 Use MD5 authentication
sha1 Use SHA-1 authentication
Now we can choose what authentication we would like, MD5 or SHA1. SHA1 is more secure so
let’s select that:
R1(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 ?

0 The key is not encrypted (plain text)
7 The key is encrypted
Hex-string SHA-1 key (40 chars)
Now we have to type in a key string ourselves. Normally IPsec uses IKE (Internet Key
Exchange) for the security association between two devices. However since we can have
multiple OSPFv3 neighbors on a single segment we can’t use IKE and we’ll have to use a static
key instead.
For this example I will use an online SHA1 generator to generate a key but for a production
network you really should use a safer method to generate a key. Let’s enter that key:

R1(config-if)#ipv6 ospf authentication ipsec spi 256 sha1
A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
As soon as you do this the OSPFv3 neighbor adjacency will drop so let’s copy and paste the
same line on R2:

R2(config-if)#ipv6 ospf authentication ipsec spi 256 sha1
Page 133 of 252

That should do the job.
It’s also possible to configure authentication for the entire area. If you want this you’ll have to use the
area 0 authentication command under the OSPFv3 process.
let’s verify our work:
R1#show ipv6 ospf interface FastEthernet 0/0 | include auth

SHA-1 authentication SPI 256, secure socket UP (errors: 0)
SHA-1 authentication SPI 256, secure socket UP (errors: 0)
If you look at the OSPF specific information on the interface then you can see that authentication
has been enabled. Since we are using IPsec, you can also check the security associations:
R1#show crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: (none), local addr ::
IPsecv6 policy name: OSPFv3-1-256

IPsecv6-created ACL name: FastEthernet0/0-ipsecv6-ACL
protected vrf: (none)

local ident (addr/mask/prot/port): (FE80::/10/89/0)
remote ident (addr/mask/prot/port): (::/0/89/0)
current_peer :: port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 50, #pkts encrypt: 50, #pkts digest: 50
#pkts decaps: 31, #pkts decrypt: 31, #pkts verify: 31
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: ::,

remote crypto endpt.: ::
path mtu 1500, ipv6 mtu 1500, ipv6 mtu idb FastEthernet0/0
current outbound spi: 0x100(256)
PFS (Y/N): N, DH group: none
inbound esp sas:
inbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 2001, flow_id: NETGX:1, sibling_flags 80000001, crypto map:
(none)
no sa timing
replay detection support: N
Status: ACTIVE
inbound pcp sas:
Page 134 of 252

outbound esp sas:
outbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
(none)
no sa timing
Status: ACTIVE
outbound pcp sas:
Above you can see our SPI number and that we are using SHA authentication. There’s one more
useful command:
R1#show crypto ipsec policy

Crypto IPsec client security policy data
Policy name: OSPFv3-1-256

Policy refcount: 1
Inbound AH SPI: 256 (0x100)
Outbound AH SPI: 256 (0x100)
Inbound AH Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
Outbound AH Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
Transform set: ah-sha-hmac
This gives us a nice overview with our authentication method, SPI and keys. If you are
interested, here’s a wireshark capture of our authenticated OSPFv3 packets:
Page 135 of 252

Above you can see the authentication header. If you want to take a look for yourself then you can
find the capture file here.
hostname R1
!
!
ipv6 enable
ipv6 ospf 1 area 0
Page 136 of 252

ipv6 ospf authentication ipsec spi 256 sha1
!
ipv6 router ospf 1
router-id 1.1.1.1
!
end
hostname R2
!
!
ipv6 enable
ipv6 ospf 1 area 0
ipv6 ospf authentication ipsec spi 256 sha1
!
ipv6 router ospf 1
router-id 2.2.2.2
!
end
IPsec Encryption
Let’s take a look at the second method, using IPsec ESP to authenticate and encrypt OSPFv3
traffic. Let’s get rid of the current IPsec AH configuration:
R1 & R2#
(config-if)no ipv6 ospf authentication ipsec spi 256 sha1
Now we can enable ESP, there’s a different command we have to use:[teaser]
R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp ?

3des Use 3DES encryption
aes-cbc Use AES-CBC encryption
des Use DES encryption
null ESP with no encryption
This time you have to use the ipv6 ospf encryption command. You still have to select the SPI
number and above you can see the options for ESP. Let’s select AES since it’s the most secure
encryption method:
R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc ?

128 Use 128 bit key
192 Use 192 bit key
256 Use 256 bit key
We get to select the size of our key. Let’s go for 256-bit:
R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256 ?
Page 137 of 252

0 The key is not encrypted (plain text)
7 The key is encrypted
Hex-string 256bit key (64 chars)
Now we have to enter the 256-bit key ourselves. For this example I used this website to generate
one but for a production network it’s probably best to use something a bit more secure. Let’s
enter our key:
R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256

FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85B sha1
Once you enter the encryption key you also have to specify the authentication algorithm and key.
Just like the previous example I used SHA1 for this. Let’s copy and paste this entire line to R2 as
well:

R2(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256
Let’s verify our work:

AES-CBC-256 encryption SHA-1 auth SPI 256, secure socket UP (errors: 0)
Here we can see that we are using AES for encryption ahd SHA1 for authentication. Let’s check
our IPsec SA:
interface: FastEthernet0/0
Crypto map tag: (none), local addr FE80::21D:A1FF:FE8B:36D0
IPsecv6 policy name: OSPFv3-1-256

IPsecv6-created ACL name: FastEthernet0/0-ipsecv6-ACL

local ident (addr/mask/prot/port): (FE80::/10/89/0)
remote ident (addr/mask/prot/port): (::/0/89/0)
current_peer :: port 500
local crypto endpt.: FE80::21D:A1FF:FE8B:36D0,

remote crypto endpt.: ::
path mtu 1500, ipv6 mtu 1500, ipv6 mtu idb FastEthernet0/0
Page 138 of 252

inbound esp sas:

spi: 0x100(256)
transform: esp-256-aes esp-sha-hmac ,
(none)
no sa timing
IV size: 0 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:

spi: 0x100(256)
transform: esp-256-aes esp-sha-hmac ,
(none)
no sa timing
IV size: 0 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Above you can see that some packets have been encrypted / decrypted and that we are using
IPsec ESP / AH. If you only want a quick overview, take a look below:
R1#show crypto ipsec policy

Crypto IPsec client security policy data
Policy name: OSPFv3-1-256

Policy refcount: 1
Inbound ESP SPI: 256 (0x100)
Outbound ESP SPI: 256 (0x100)
Inbound ESP Auth Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
Outbound ESP Auth Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
Inbound ESP Cipher Key:
FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85B
Outbound ESP Cipher Key:
FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85B
Transform set: esp-256-aes esp-sha-hmac
Let me also show you a Wireshark capture of some encrypted OSPFv3 traffic:
Page 139 of 252

If you want to take a look for yourself, you can get this capture file here.
hostname R1
!
!
ipv6 enable
ipv6 ospf 1 area 0
Page 140 of 252

ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256
!
ipv6 router ospf 1
router-id 1.1.1.1
!
end
hostname R2
!
!
ipv6 enable
ipv6 ospf 1 area 0
ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256
!
ipv6 router ospf 1
router-id 2.2.2.2
!
end
IPv6 First Hop Security Features

IPv6 FHS (First Hop Security) are different features that secure IPv6 on L2 links.
First “hop” might make you think about the first router but that’s not the case. These are all
switch features, in particular, the switch that sits between your end devices and the first router.
Here are the First Hop Security features you need to know for the CCIE R&S written 400-101
exam:
 RA Guard: any device on the network can transmit router advertisements and hosts don’t
care where it comes from. They will happily accept anything. With RA guard, you can
filter router advertisements. You can create a simple policy where you only accept RAs
on certain interfaces or you can inspect RAs and permit them only when they match
certain criteria.
 DHCPv6 Guard: similar to DHCP snooping for IPv4. We inspect DHCP packets and only
permit them from trusted interfaces. You can also create policies where you only accept
DHCP packets for certain prefixes or preference levels.
 ND Inspection: the switch inspects NS (Neighbor Solicitation) and NA (Neighbor
Advertisement) messages and stores them in the IPv6 binding table. The switch can then
drop any spoofed NS/NA messages.
Page 141 of 252

 Source Guard: the switch filters all packets where the source address is not found in the
IPv6 binding table. This helps against spoofing attacks where the source address is not
found in the IPv6 binding table.
IPv6 RA Guard
Router advertisements can be used by hosts to automatically configure their own IPv6 address
and set a default route using the information they see in the RA. In the IPv6 router advertisement
preference lesson, I explained how IPv6 hosts behave when they receive multiple router
advertisements.
Hosts automatically select a router advertisement and they don’t care where it came from.
This is how it was meant to be but it does introduce a security risk since any device can send
router advertisements and your hosts will happily accept it. An attacker can send rogue router
advertisements to redirect the traffic, or you can send so many RAs that it causes a DOS since
your hosts will be too busy configuring their IPv6 prefixes.
The IPv6 RA guard feature can filter router advertisements and runs on switches. This can be
as simple as “don’t allow RAs on this interface” or complex with policies where router
advertisements are only permitted when it matches certain criteria.
In this lesson, I’ll show you how to use the IPV6 RA guard feature to block a malicious host and
how to use a policy to permit router advertisements from a legitimate router, but only when it
matches certain criteria.
Configuration
Here is the topology we’ll use:
Page 142 of 252

R1 is our legitimate router that will send RAs. H1 is some IPv6 host that autoconfigures itself
with SLAAC, H2 is our attacker who is going to send rogue router advertisements.
Let’s configure R1 so that it sends router advertisements. To do that, we need to enable unicast
routing:
And we’ll configure an IPv6 address so that it includes a prefix in the RAs:
R1(config)#interface GigabitEthernet0/1
Our host is going to use SLAAC and sets a default route to the router:

H1(config-if)#ipv6 address autoconfig default
Host Policy
Let’s see how our host reacts to the router advertisement from R1:

Router FE80::211:21FF:FE4E:D1C1 on GigabitEthernet0/1, last update 0 min
Page 143 of 252

H1 receives the RA. Let’s see if it uses this router as its default gateway:
H1#show ipv6 route static
S ::/0 [2/0]
via FE80::211:21FF:FE4E:D1C1, GigabitEthernet0/1
Above, we see the default route that points to R1. Let’s see what happens when we try to mess
around with this.
Let’s configure H2 so that it also sends RAs and to make it interesting, I’ll set the router
preference to high:
H2(config)#ipv6 unicast-routing
H2(config-if)#ipv6 address 2001:DB8:BAD:BAD::2/64
H2(config-if)#ipv6 nd router-preference high
Here’s what we see on R1:

Router FE80::211:BBFF:FE0B:3641 on GigabitEthernet0/1, last update 2 min
HomeAgentFlag=0, Preference=High
Prefix 2001:DB8:BAD:BAD::/64 onlink autoconfig
H1 sees the RA, autoconfigures an IPv6 address with the 2001:DB8:BAD:BAD::/64 prefix and
also uses H2 as a default route:
H1#show ipv6 route static
S ::/0 [2/0]
via FE80::211:BBFF:FE0B:3641, GigabitEthernet0/1
That’s pretty bad…H2 just hijacked all outgoing traffic from H1.
Let’s prevent this from happening. On my switch, I’ll create a new RA guard policy called hosts
where the device role is “host”:
SW1(config)#ipv6 nd raguard policy HOSTS
Page 144 of 252

SW1(config-nd-raguard)#device-role host
With the host device role, all RAs and router redirect messages will be blocked. We need to
enable this policy on the interface:
SW1(config)#interface GigabitEthernet 0/2

SW1(config-if)#ipv6 nd raguard attach-policy HOSTS
The policy that I just created doesn’t have any criteria, except for the device-role but “host” is the
default. I also could have used the ipv6 nd raguard command on the interface without any parameters
and the end result would be the same. When we look at the router policy, you’ll see how you can add
criteria.
Here’s how you can verify which policies you have activated on what interfaces:
SW1#show ipv6 nd raguard policy HOSTS

Policy HOSTS configuration:
device-role host
Policy HOSTS is applied on the following targets:
Target Type Policy Feature Target range
Gi0/2 PORT HOSTS RA guard vlan all
Let’s see it in action though. We’ll enable a debug on H2 so we can see when it sends a router
advertisement:
H2#debug ipv6 nd
And on the switch we’ll enable RA guard debugging:
SW1#debug ipv6 snooping raguard

IPv6 snooping - RA guard debugging is on
After a few seconds, we’ll see that H2 sends a router advertisement:
H2#
ICMPv6-ND: Sending RA from FE80::211:BBFF:FE0B:3641 to FF02::1 on
GigabitEthernet0/1
ICMPv6-ND: prefix = 2001:DB8:BAD:BAD::/64 onlink autoconfig
ICMPv6-ND: 2592000/604800 (valid/preferred)
Our switch will block this RA:
SW1#
SISF[RAG]: Gi0/2 vlan 123 RA Guard setting sec level to GUARD
SISF[RAG]: Gi0/2 vlan 123 RA received by RA guard on Gi0/2 from
FE80::211:BBFF:FE0B:3641
SISF[RAG]: Gi0/2 vlan 123 option 1 : ND_OPT_SOURCE_LINKADDR
SISF[RAG]: Gi0/2 vlan 123 option 3 : ND_OPT_PREFIX_INFORMATION
SISF[RAG]: Gi0/2 vlan 123 option 5 : ND_OPT_MTU
SISF[RAG]: Gi0/2 vlan 123 !Not a router port: all router messages disallowed
Page 145 of 252

SISF[RAG]: Gi0/2 vlan 123 ! DROP ROUTER-ADVERT src FE80::211:BBFF:FE0B:3641
dst FF02::1 reason = 3
The debug output is nice and clean. Since this is not a router port, all router advertisements are
dropped. Besides the debug command, there is also a show command that tells you the number
of drops:
SW1#show ipv6 snooping counters interface GigabitEthernet 0/2

Received messages on Gi0/2:
Protocol Protocol message
NDP RA[3]
DHCPv6
Bridged messages from Gi0/2:

NDP
DHCPv6
Dropped messages on Gi0/2:

Feature Protocol Msg [Total dropped]
RA guard NDP RA [3]
reason: Message unauthorized on port [3]
This is a good feature to block rogue RAs. I should have implemented this before H1 received
the first RA though:

Router FE80::211:BBFF:FE0B:3641 on GigabitEthernet0/1, last update 8 min
HomeAgentFlag=0, Preference=High
Prefix 2001:DB8:BAD:BAD::/64 onlink autoconfig
We can still see the RA from H2 because it has a lifetime of 1800 seconds. Eventually, it will
timeout and disappear but until then, it will be used by H1.
Router Policy
What about the router policy? We didn’t have to configure anything to permit RAs from R1.
What we can do, is create a policy called ROUTERS with some restrictions that define what R1
can or cannot put in its RAs:[teaser]
SW1(config)#ipv6 nd raguard policy ROUTERS

SW1(config-nd-raguard)#device-role router
SW1(config-nd-raguard)#?
Page 146 of 252

IPv6 RA guard policy configuration mode:
default Set a command to its defaults
device-role Sets the role of the device attached to the port
exit Exit from RA guard policy configuration mode
hop-limit Enable verification of the advertised Hop count limit
managed-config-flag Enable verification of the advertised M flag
match Match a particular prefix-list or access-list
no Negate a command or set its defaults
other-config-flag Enable verification of the advertised O flag
router-preference Enable verification of the advertised Router Preference
flag
trusted-port Setup trusted port
You can set a couple of restrictions. Let’s try something simple, right now R1 only advertises a
single prefix (2001:DB8:0:1::/64). Let’s configure the switch so that only this prefix is permitted.
Once R1 adds another prefix in its RA, it will be denied.
Let’s create a prefix-list:
SW1(config)#ipv6 prefix-list MY_PREFIX permit 2001:DB8:0:1::/64
Under the RA guard policy, we add the prefix-list:
SW1(config)#ipv6 nd raguard policy ROUTERS

SW1(config-nd-raguard)#match ra prefix-list MY_PREFIX
Activate it on the interface that connects to R1:

SW1(config-if)#ipv6 nd raguard attach-policy ROUTERS
And we’ll add a second IPv6 address on R1:

R1(config-if)#ipv6 address 2001:DB8:11::1/64
Let’s enable a debug on R1 so we can see when it sends RAs:
R1#debug ipv6 nd
After a few seconds you’ll see the RA that R1 advertises:
R1#
ICMPv6-ND: Request to send RA for FE80::211:21FF:FE4E:D1C1
ICMPv6-ND: Sending RA from FE80::211:21FF:FE4E:D1C1 to FF02::1 on
GigabitEthernet0/1
ICMPv6-ND: prefix = 2001:DB8:0:1::/64 onlink autoconfig
ICMPv6-ND: prefix = 2001:DB8:11::/64 onlink autoconfig
Page 147 of 252

It has the two prefixes. Here’s what SW1 thinks of it:
SW1#
SISF[RAG]: Gi0/3 vlan 123 RA Guard setting sec level to GUARD
SISF[RAG]: Gi0/3 vlan 123 RA received by RA guard on Gi0/3 from
FE80::211:21FF:FE4E:D1C1
SISF[RAG]: Gi0/3 vlan 123 option 1 : ND_OPT_SOURCE_LINKADDR
SISF[RAG]: Gi0/3 vlan 123 option 3 : ND_OPT_PREFIX_INFORMATION
SISF[RAG]: Gi0/3 vlan 123 option 5 : ND_OPT_MTU
SISF[RAG]: Gi0/3 vlan 123 RA with prefix option 2001:DB8:0:1:: len 64
SISF[RAG]: Gi0/3 vlan 123 RA with prefix option 2001:DB8:11:: len 64
SISF[RAG]: Gi0/3 vlan 123 !RA prefix not in prefix-list
SISF[RAG]: Gi0/3 vlan 123 ! DROP ROUTER-ADVERT src FE80::211:21FF:FE4E:D1C1
dst FF02::1 reason = 5
SW1 doesn’t see 2001:DB8:11::/64 in the prefix-list and denies the entire router advertisement.
Let’s look at some show commands. Here’s how we can see the policy is active:
SW1#show ipv6 nd raguard policy ROUTERS

Policy ROUTERS configuration:
device-role router
match ra prefix-list MY_PREFIX
Policy ROUTERS is applied on the following targets:
Gi0/3 PORT ROUTERS RA guard vlan all
And the show ipv6 snooping command tells us why certain RAs are dropped:
SW1#show ipv6 snooping counters interface GigabitEthernet 0/3

Received messages on Gi0/3:
NDP RA[2]
DHCPv6
Bridged messages from Gi0/3:

NDP
DHCPv6
Dropped messages on Gi0/3:

Feature Protocol Msg [Total dropped]
RA guard NDP RA [2]
reason: Unauthorized prefix in prefix list [2]
That’s all there is to it.
Conclusion
You have now learned how to use the IPv6 RA Guard feature to prevent rogue / malicious router
advertisements:
Page 148 of 252

 IPv6 hosts that use SLAAC accept any router advertisements and configure their own IPv6
address (and default route).
 You can activate RA guard on a switch with or without policies:
o If you don’t use a policy then the default device role is “host” which means that all RAs
are blocked.
o Policies allow you to permit RAs but only when they match certain criteria, for example,
a specific prefix.
IPv6 DHCPv6 Guard

IPv6 DHCPv6 Guard is one of the IPv6 FHS (First Hop Security) mechanisms and is very
similar to IPv4 DHCP snooping.
This feature inspects DHCPv6 messages between a DHCPv6 server and DHCPv6 client (or relay
agent) and blocks DHCPv6 reply and advertisements from (rogue) DHCPv6 servers. DHCPv6
messages from clients or relay agents to a DHCPv6 server are not affected.
In this lesson, I’ll show you how to configure IPv6 DHCPv6 guard.
Configuration
Page 149 of 252

We have four devices:
 R1 is our legitimate DHCPv6 server.

 R2 is a rogue DHCPv6 server.
 H1 is a DHCPv6 client.
 SW1 is where we configure IPv6 DHCPv6 guard.
Basic Policy
We’ll start with a simple example where we configure R1 as a DHCPv6 server and block the
rogue DHCPv6 server with a DHCPv6 guard policy.
Let’s configure R1 as a DHCPv6 server:
R1(config)#ipv6 dhcp pool MY_POOL

R1(config-dhcpv6)#address prefix 2001:DB8:0:1::/64

R1(config-if)#ipv6 dhcp server MY_POOL
R1 is a simple DHCPv6 server, I only advertise a prefix and that’s it. Let’s configure H1 as a
DHCPv6 client:
H1(config)#interface FastEthernet 0/0

H1(config-if)#ipv6 enable
H1(config-if)#ipv6 address dhcp
Let’s see if H1 gets an IPv6 address:
R1#show ipv6 dhcp binding

Client: FE80::217:5AFF:FEED:7AF0
DUID: 0003000100175AED7AF0
IA NA: IA ID 0x00030001, T1 43200, T2 69120
Address: 2001:DB8:0:1:ED29:C746:E04B:5784
expires at Apr 27 2018 01:47 PM (172704 seconds)
H1#show ipv6 interface brief | include 2001
2001:DB8:0:1:ED29:C746:E04B:5784
Excellent. Let’s configure a DHCPv6 guard policy so that this setup is protected. I need to create
two policies, one for the DHCPv6 server, another one for the DHCPv6 client:
SW1(config)#ipv6 dhcp guard policy DHCP_SERVER

SW1(config-dhcp-guard)#device-role server
SW1(config)#ipv6 dhcp guard policy DHCP_CLIENT
SW1(config-dhcp-guard)#device-role client
Page 150 of 252

Right now, my policies are empty and I only set the device role. Client is the default role so you
don’t have to configure it. For the sake of completeness, I did it anyway.
Let’s attach the DHCP_SERVER policy to the interface that connects to R1 and the
DHCP_CLIENT policy to the correct interfaces:

SW1(config-if)#ipv6 dhcp guard attach-policy DHCP_SERVER
SW1(config)#interface range GigabitEthernet 0/2 - 3

SW1(config-if-range)#ipv6 dhcp guard attach-policy DHCP_CLIENT
We can verify our configuration with the following command:
SW1#show ipv6 dhcp guard policy

Dhcp guard policy: DHCP_CLIENT
Device Role: dhcp client
Target: Gi0/2 Gi0/3
Dhcp guard policy: DHCP_SERVER

Device Role: dhcp server
Target: Gi0/1
Max Preference: 255
Min Preference: 0
This gives a nice overview of the policies and to which interfaces we attached them. Let’s see if
it works though…
To test this, I’ll shut the interface of R1:

And we’ll configure a DHCPv6 server on our rogue DHCPv6 server:
R2(config)#ipv6 dhcp pool ROGUE_POOL

R2(config-dhcpv6)#address prefix 2001:DB8:BAD:C0DE::/64

R2(config-if)#ipv6 dhcp server ROGUE_POOL
Before we request another IPv6 address on the host, let’s enable a debug on SW1 so that we can
see everything in action:
SW1#debug ipv6 snooping dhcp-guard

IPv6 snooping - DHCP Guard debugging is on
Now reset the DHCPv6 client:
Page 151 of 252

H1#clear ipv6 dhcp client FastEthernet 0/0
This is what you’ll see on the switch:
SW1#
SISF[DHG]: Gi0/3 vlan 1 DHCP Client message for role dhcp client - Permit
SISF[DHG]: Gi0/2 vlan 1 DHCP Server message for role dhcp client - Deny
In the output above, you can see that the DHCPv6 client messages are permitted but the
DHCPv6 server messages are dropped because we shouldn’t receive those on a “client”
interface.
Prefix Filtering
Anything else we can do? First, let’s get rid of the rogue DHCPv6 server and enable the
legitimate DHCPv6 server:

H2(config-if)#shutdown
Let’s take a closer look at the DHCP_SERVER policy we created:[teaser]

SW1(config-dhcp-guard)#?
IPv6 dhcp guard policy configuration mode:
exit Exit from DHCP Guard policy configuration mode
match dhcp filtering
preference dhcp server advertised preference filter
trusted-port This is a trusted port (no policing)
There are a bunch of options we can choose from. Right now, we permit any DHCP server as
long as it’s connected to the GigabitEthernet 0/1 interface. One of the things we can do is filter
on items inside the DHCP messages. For example, the prefix.
Let’s change our policy so that only the 2001:DB8:0:1::/64 prefix is permitted. First, we create a
prefix-list:
SW1(config)#ipv6 prefix-list PREFIX permit 2001:DB8:0:1::/64 le 128
Then add it to our policy:

SW1(config-dhcp-guard)#match reply prefix-list PREFIX
Let’s test it by adding a second prefix to the DHCPv6 pool:
Page 152 of 252

R1(config)#ipv6 dhcp pool MY_POOL
R1(config-dhcpv6)#address prefix 2001:DB8:0:2::/64
And renew the DHCPv6 client:
Here’s what you’ll see on SW1:
SW1#
SISF[DHG]: Gi0/1 vlan 1 DHCP Server Reply Msg dropped due to non-authorized
prefix 2001:DB8:0:2:2978:8D67:66D1:DD4E
The DHCPv6 server reply message is dropped because there’s a prefix that is not in our prefix-
list. We can fix this by adding the second prefix to the prefix-list:
SW1(config)#ipv6 prefix-list PREFIX permit 2001:DB8:0:2::/64 le 128
This fixes the problem and our host will have two IPv6 addresses, one from each prefix:
H1#show ipv6 interface brief

FE80::216:C7FF:FEBE:EC8
2001:DB8:0:1:5836:8930:74A2:BCC7
2001:DB8:0:2:6DA4:C76A:4792:DDE6
Great!
Link-Local Address Filtering
We can also filter the source link-local address of the DHCPv6 server. Let’s see what address it
uses:
R1#show ipv6 interface brief | include FE80

FE80::21D:A1FF:FE8B:36D0
We’ll add this address to our policy. First, I create an access-list:
SW1(config)#ipv6 access-list R1_LINK_LOCAL

SW1(config-ipv6-acl)#permit ipv6 host FE80::21D:A1FF:FE8B:36D0 any
And then add it to the DHCP_SERVER policy:

SW1(config-dhcp-guard)#match server access-list R1_LINK_LOCAL
Let’s test this by changing the link-local address of R1:

R1(config-if)#ipv6 address FE80::21D:A1FF:FE8B:36D1 link-local
Page 153 of 252

And clear the DHCPv6 client again:
Here’s what happens on SW1:
SW1#
SISF[DHG]: Gi0/1 vlan 1 DHCP Server Advertise Msg dropped due to non-
authorized source FE80::21D:A1FF:FE8B:36D1
Nice, it works. the DHCPv6 server message is dropped because the link-local address does not
match. Let’s fix it:

R1(config-if)#no ipv6 address FE80::21D:A1FF:FE8B:36D1 link-local
That’s it.
Preference Filtering
The last option is preference filtering. The preference option is set by DHCPv6 servers. DHCPv6
clients then build a list of all potential DHCPv6 servers by collecting the advertise messages
from the servers. The client then selects one of the DHCPv6 servers based on the preference.
Let’s change R1 so that it adds a preference value:

R1(config-if)#ipv6 dhcp server MY_POOL preference 150
I can now filter based on this value in the policy:

SW1(config-dhcp-guard)#preference min 110
SW1(config-dhcp-guard)#preference max 120
Let’s clear the DHCP client:
And we get this message on SW1:
SW1#
SISF[DHG]: Gi0/1 vlan 1 DHCP Server Advertise Msg dropped the preference
exceeds max preference: 150>120
The preference exceeds 120 so the DHCPv6 message is dropped. Let’s fix it:

R1(config-if)#ipv6 dhcp server MY_POOL preference 115
Page 154 of 252

SW1 will now accept it:
SW1#
SISF[DHG]: Gi0/1 vlan 1 DHCP Server Advertise Msg valid preference: max
120>115>110 min
That’s all there is to it.
hostname R1
!
ip cef
!
ipv6 cef
ipv6 dhcp pool MY_POOL
address prefix 2001:DB8:0:1::/64
!
ipv6 enable
ipv6 dhcp server MY_POOL preference 115
!
end
hostname R2
!
ip cef
!
ipv6 cef
ipv6 dhcp pool ROGUE_POOL
address prefix 2001:DB8:BAD:C0DE::/64
!
ipv6 enable
ipv6 dhcp server ROGUE_POOL
!
end
hostname H1
!
ip cef
!
ipv6 address dhcp
ipv6 enable
!
end
Page 155 of 252

hostname SW1
!
ipv6 dhcp guard policy DHCP_CLIENT
ipv6 dhcp guard policy DHCP_SERVER
device-role server
match server access-list R1_LINK_LOCAL
match reply prefix-list PREFIX
preference max 120
preference min 110
!
ipv6 dhcp guard attach-policy DHCP_SERVER
!
ipv6 dhcp guard attach-policy DHCP_CLIENT
!
ipv6 dhcp guard attach-policy DHCP_CLIENT
!
ipv6 prefix-list PREFIX seq 5 permit 2001:DB8:0:1::/64 le 128
ipv6 prefix-list PREFIX seq 10 permit 2001:DB8:0:2::/64 le 128
!
ipv6 access-list R1_LINK_LOCAL
permit ipv6 host FE80::21D:A1FF:FE8B:36D0 any
!
end
Conclusion
You have now learned how the IPv6 DHCPv6 Guard feature protects your DHCP clients.
 We inspect DHCPv6 messages between clients and the server and block DHCPv6
reply/advertisement packets from the DHCPv6 server.
 DHCPv6 messages from clients are left alone.
 Globally you create two policies, one for the DHCPv6 server and one for the DHCPv6
clients.
 Policies are assigned to the correct interfaces.
 There are three advanced filtering options:
o Prefix: check the prefix that a DHCPv6 server advertises.
o Link-local address: check the source address of a DHCPv6 server.
o Preference: check the preference that the DHCPv6 server advertises.
IPv6 ND Inspection
IPv6 ND Inspection is one of the IPv6 first-hop security features. It creates a binding table that is
based on NS (Neighbor Solicitation) and NA (Neighbor Advertisement) messages. The switch
then uses this table to check any future NS/NA messages. When the IPv6-LLA combination does
Page 156 of 252

not match, it drops the message. This only applies to NS/NA messages, it doesn’t drop any actual
data packets that have a spoofed IPv6 or MAC address.
Configuration
To demonstrate ND inspection, we’ll use the following topology:
H1 and H2 are two legitimate devices with IPv6 addresses. I will use R3 to spoof an IPv6
address, SW1 is where we configure ND inspection.
Enabling this is very simple if you want to get started. You can do it with a single command:
SW1(config)#interface range gi0/1 - 2

SW1(config-if-range)#ipv6 nd inspection
Let’s send a ping from R1 to R2 to generate some ND/NA messages:
R1#ping 2001:DB8:0:12::2
!!!!!
Page 157 of 252

Now let’s take a look at SW1:
SW1#show ipv6 neighbors binding

Binding Table has 4 entries, 4 dynamic
Codes: L - Local, S - Static, ND - Neighbor Discovery, DH - DHCP, PKT - Other
Packet, API - API created
Preflevel flags (prlvl):
0001:MAC and LLA match 0002:Orig trunk 0004:Orig access
0008:Orig trusted trunk 0010:Orig trusted access 0020:DHCP assigned
0040:Cga authenticated 0080:Cert authenticated 0100:Statically assigned
IPv6 address Link-Layer addr Interface vlan

prlvl age state Time left
ND FE80::21D:A1FF:FE8B:36D0 001D.A18B.36D0 Gi0/1 1
0005 4s REACHABLE 301 s
ND FE80::217:5AFF:FEED:7AF0 0017.5AED.7AF0 Gi0/2 1
ND 2001:DB8:0:12::2 0017.5AED.7AF0 Gi0/2 1
ND 2001:DB8:0:12::1 001D.A18B.36D0 Gi0/1 1
Above, we see four entries in the binding table. Two for R1 and two for R2. The binding table
got populated by ND, you can see that the binding table can also be populated by other options
like DHCP.
Let’s see what happens when we try to spoof an IPv6 address of R2 on R3. I’ll disable DAD
(Duplicate Address Detection) first:
R3(config-if)#ipv6 nd dad attempts 0
Now we’ll copy the IPv6 link-local address of R2 to R3:

R3(config-if)#ipv6 address FE80::217:5AFF:FEED:7AF0 link-local
Let’s do a ping from the spoofed link-local address of R3 to the link-local address of R1 to
trigger some ND/NA messages:
R3#ping FE80::21D:A1FF:FE8B:36D0 source FE80::217:5AFF:FEED:7AF0 repeat 1
This is what we get on SW1:
SW1#
%SISF-4-PAK_DROP: Message dropped A=FE80::217:5AFF:FEED:7AF0 G=- V=123 I=Gi0/3
P=NDP::RA Reason=More trusted entry exists
The switch drops the ND from R3 since we already have an entry from R2 in our binding table.
The binding table works with a “first come, first served” logic. Since we already have an entry
from R2, we don’t accept the ND from R3 for the spoofed address.
Page 158 of 252

Static Binding
If you want, you could make the spoofed address of R3 work. Let’s take another look at the
binding table:
SW1#show ipv6 neighbors binding | begin Pref

The binding table has different preference levels. The lowest preference level is a MAC and LLA
match. The highest preference level is a static binding. Since the binding table is used for some
other features, understanding it is important. Let me show you how to create a static binding for
R3. Here’s the MAC address of R3:
R3#show interfaces FastEthernet 0/0 | include bia

Hardware is MV96340 Ethernet, address is 0016.c7be.0ec8 (bia 0016.c7be.0ec8)
Let’s create a static binding:
SW1(config)#ipv6 neighbor binding vlan 1 FE80::217:5AFF:FEED:7AF0 interface

GigabitEthernet 0/3 0016.c7be.0ec8
This shows up in our binding table:


0005 6mn STALE 87780 s
S FE80::217:5AFF:FEED:7AF0 0016.C7BE.0EC8 Gi0/3 1
ND 2001:DB8:0:12::2 0017.5AED.7AF0 Gi0/2 1
0005 10mn STALE 88122 s
ND 2001:DB8:0:12::1 001D.A18B.36D0 Gi0/1 1
0005 10mn STALE 89190 s
Above, you can see the static binding. ND/NA messages from R3 are now accepted:
R3#ping FE80::21D:A1FF:FE8B:36D0 source FE80::217:5AFF:FEED:7AF0 repeat 1

Page 159 of 252

Sending 1, 100-byte ICMP Echos to FE80::21D:A1FF:FE8B:36D0, timeout is 2
seconds:
Packet sent with a source address of FE80::217:5AFF:FEED:7AF0%FastEthernet0/0
!
Let’s get rid of R3 and clean up the policy before we continue:

SW1(config)#ipv6 neighbor binding vlan 1 FE80::217:5AFF:FEED:7AF0 interface
GigabitEthernet 0/3 0016.c7be.0ec8
Policies
So far, we activated ND inspection with a single command and it worked out of the box. You can
also customize it with policies. Let’s create a policy and look at the different options:
SW1(config)#ipv6 nd inspection policy MY_POLICY

SW1(config-nd-inspection)#?
IPv6 NDP inspection policy configuration mode:
drop-unsecure drop unsecure (3971) messages
exit Exit from NDP inspection policy configuration mode
limit Specifies a limit
sec-level Specifies a minimum sec-level
tracking Override default tracking behavior
trusted-port setup trusted port
validate specific validation
There are quite some options, let’s walk through them. We’ll start with device-role:[teaser]
SW1(config-nd-inspection)#device-role ?
host Attached device is a host (default)
monitor Attached device is a monitor/sniffer
router Attached device is a router
switch Attached device is a switch
Host seems to be the default but to be honest, I have no idea what the difference between these
options is. It’s not documented anywhere on the Cisco website. Let’s leave it at the default.
drop-unsecure should be left alone. It’s for CGA (Cryptographically Generated Address) which
are IPv6 addresses where the interface ID is generated by calculating a cryptographic one-way
hash from a public key and auxiliary parameters. This is used for the Secure Neighbor Discovery
(SEND) protocol.
We can set a limit to the number of address bindings per interface:
SW1(config-nd-inspection)#limit ?
address-count Configure maximum address per port
Page 160 of 252

Keep in mind that you will always have at least two addresses for a host/router. One link-local
address and one global unicast address. Let’s set it to two:
SW1(config-nd-inspection)#limit address-count 2
sec-level should also be left alone, this command is like drop-unsecure related to SEND.
Tracking is an interesting feature. The switch will periodically send an NS to the IPv6 addresses
in the binding table to check if it’s still there. The switch does this to remove stale entries so it
doesn’t have to store them forever. It also helps when you move a device from one switch
interface to another interface, the switch can quickly update its binding table by sending an NS.
Let’s give this a try, I’ll set tracking to 10 seconds:
SW1(config-nd-inspection)#tracking enable reachable-lifetime 10
The NS the switch sends is interesting. Our switch is an L2 device and we don’t have any IPv6
addresses nor enabled unicast routing on the switch. What will the source be?
I’ll show you in a bit when we activate this policy.
trusted-port lets the switch accept any ND/NA messages on an interface.
Once you have configured the policy, you can activate it on an interface or VLAN. I’ll enable it
on the interfaces that connect to R1 and R2:
SW1(config)#interface range gi0/1 - 2

SW1(config-if-range)#ipv6 nd inspection attach-policy MY_POLICY
There are a couple of show commands you can use to see the policy:
SW1#show ipv6 nd inspection policy MY_POLICY

Policy MY_POLICY configuration:
device-role host
limit address-count 2
tracking enable reachable-lifetime 10
Policy MY_POLICY is applied on the following targets:
Gi0/1 PORT MY_POLICY NDP inspection vlan all
Gi0/2 PORT MY_POLICY NDP inspection vlan all
This gives us a nice overview of our policy and where we activated it. You can also see which
packets were inspected by the switch with the following command:
SW1#show ipv6 snooping capture-policy

HW Policy DB:
HW Policy 0000001F #targets:2
Target Gi0/1 type 0 handle 1
Target Gi0/2 type 0 handle 2
Target DB:
Page 161 of 252

HW Target Gi0/1 HW policy signature 0000001F policies#:1 rules#:5 sig
0000001F
SW policy MY_POLICY feature NDP inspection
Rule RS Protocol ICMPV6 mask 00000004 action PUNT match 133

#feat:1
feature NDP inspection
Rule RA Protocol ICMPV6 mask 00000008 action PUNT match 134
#feat:1
Rule NS Protocol ICMPV6 mask 00000001 action PUNT match 135
#feat:1
Rule NA Protocol ICMPV6 mask 00000002 action PUNT match 136
#feat:1
Rule REDIR Protocol ICMPV6 mask 00000010 action PUNT match 137
#feat:1
HW Target Gi0/2 HW policy signature 0000001F policies#:1 rules#:5 sig
0000001F
SW policy MY_POLICY feature NDP inspection
Rule RS Protocol ICMPV6 mask 00000004 action PUNT match 133

#feat:1
Rule RA Protocol ICMPV6 mask 00000008 action PUNT match 134
#feat:1
Rule NS Protocol ICMPV6 mask 00000001 action PUNT match 135
#feat:1
Rule NA Protocol ICMPV6 mask 00000002 action PUNT match 136
#feat:1
Rule REDIR Protocol ICMPV6 mask 00000010 action PUNT match 137
#feat:1
Above, you can see that some packets were inspected (PUNT) because of ND inspection.
Device Tracking
Because of our policy, the switch sends NS messages every 10 seconds. Take a look at this
capture:
Page 162 of 252

IPv6 ND Inspection tracking unspecified
Our switch doesn’t have any IPv6 addresses so it uses the IPv6 unspecified address as the source
for the NS. If you configure the switch with a link-local address then that address becomes the
source.
Conclusion
You have now learned how IPv6 ND inspection tracks ND/NA messages and how it builds the
binding table with IPv6-LLA bindings. We use this binding table to block any spoofed messages.
IPv6 Source Guard

IPv6 Source Guard is one of the IPv6 FHS (First Hop Security) features. It filters inbound traffic
on L2 switch ports that are not in the IPv6 binding table. The binding table stores the following
information:
Page 163 of 252

 IPv6 address
 MAC address
 VLAN
 Interface ID
Source Guard only looks at information found in the binding table, and it doesn’t fill the binding
table. You need another feature like ND inspection or IPv6 snooping to do this. You can fill the
binding table with information from:
 DHCP
 NDP (Neighbor Discovery Protocol)
 Static binding
When source guard denies traffic because it is not found in the binding table, it notifies the IPv6
address glean feature. This feature can query a DHCP server or uses IPv6 ND (Neighbor
Discovery) to find the missing information, if possible.
Configuration
In this lesson, we will take a look at Source Guard in action. This is the topology I use:
Page 164 of 252

Let me explain this topology:
 H1 is a legitimate host and receives an IPv6 address through DHCP.

 H2 is an attacker that tries to perform a DoS attack on S1.
 R1 is our DHCP server.
 S1 is a server that is under attack by H2.
 SW1 is where we configure IPv6 Source Guard.
hostname H1
!
Page 165 of 252

ipv6 address dhcp
ipv6 enable
!
end
hostname R1
!
ipv6 cef
!
ipv6 address 2001:DB8:0:12::F/64
ipv6 dhcp server MY_POOL
!
end
hostname S1
!
ipv6 cef
!
ipv6 address 2001:DB8:0:4::4/64
!
ipv6 route ::/0 2001:DB8:0:4::F
!
end
Without Source Guard
Let’s get started. In our first scenario, I will show you how H2 can attack S1 when we don’t use
Source Guard.
Let’s check if R1 has assigned an IPv6 address through DHCP to H1:
R1#show ipv6 dhcp binding

Client: FE80::217:5AFF:FEED:7AF0
DUID: 0003000100175AED7AF0
IA NA: IA ID 0x00030001, T1 43200, T2 69120
Address: 2001:DB8:0:12:FC57:49F8:6AA5:1448
expires at Aug 08 2018 01:45 PM (172342 seconds)
H1#show ipv6 interface brief | include 2001
2001:DB8:0:12:FC57:49F8:6AA5:1448
We verify that H1 has an IPv6 address. Let’s make sure it can reach S1:
H1#ping 2001:DB8:0:4::4
Page 166 of 252

!!!!!
Let’s take a look at S1:
S1#show ipv6 neighbors

IPv6 Address Age Link-layer Addr State Interface
FE80::21D:A1FF:FE8B:36D1 6 001d.a18b.36d1 STALE Fa0/0
2001:DB8:0:4::F 6 001d.a18b.36d1 STALE Fa0/0
S1 knows two neighbors with the same MAC address. Both addresses belong to R1.
Let’s see how we can attack S1 from H2. On H2, I enable IPv6 so that I get a link-local address
and so that H2 knows how to get to other subnets through R1. I also configure a couple of fake
IPv6 addresses that belong to the 2001:DB8:0:4::/64 subnet:

H2(config-if)#ipv6 enable
H2(config-if)#ipv6 address 2001:DB8:0:4::100/128
Let’s send a couple of pings from H2 to S1 from each fake IPv6 address:
H2#ping 2001:DB8:0:4::4 source 2001:DB8:0:4::100 timeout 0 repeat 1

You have to be quick but when you look at the IPv6 neighbors of S1, you see these entries:

FE80::21D:A1FF:FE8B:36D1 0 001d.a18b.36d1 REACH Fa0/0
2001:DB8:0:4::F 3 001d.a18b.36d1 STALE Fa0/0
2001:DB8:0:4::101 0 - INCMP Fa0/0
2001:DB8:0:4::100 0 - INCMP Fa0/0
2001:DB8:0:4::102 0 - INCMP Fa0/0
2001:DB8:0:4::103 0 - INCMP Fa0/0
S1 wants to know the MAC addresses of these IPv6 addresses but since nobody on the
2001:DB8:0:4::/64 subnet answers, it never gets a reply.
When S1 does not get a reply it deletes the entry in a few seconds. My four pings won’t do any
harm but a script that generates random IPv6 addresses non-stop will.
Page 167 of 252

With Source Guard
Let’s see if we can put a stop to this. Before I can play with Source Guard, I need to have a
binding table with some entries. A quick way to do this is to enable IPv6 snooping.
IPv6 Snooping
IPv6 snooping tracks DHCP and ND packets so it’s a nice way to get entries in our binding table.
Let’s create a snooping policy:
SW1(config)#ipv6 snooping policy SNOOPING

SW1(config-ipv6-snooping)#security-level glean
I change the security level to glean because I only want to use snooping to get information into
the binding table. If you don’t change the policy, IPv6 snooping will also activate RA guard.
Let’s activate the snooping policy on all interfaces:

SW1(config-if-range)#ipv6 snooping attach-policy SNOOPING
Let’s clear the IPv6 address on H1 so that IPv6 snooping can see the DHCP packets:
SW1 now has some entries in the binding table:


ND FE80::217:5AFF:FEED:7AF0 0017.5AED.7AF0 Gi0/2 1
DH 2001:DB8:0:12:20A8:D970:FA26:4403 0017.5AED.7AF0 Gi0/2 1
0024 7s REACHABLE 298 s(164185 s)
We see two neighbor discovery entries and one DHCP entry. We now have everything we need
to test Source Guard.[teaser]
Page 168 of 252

Source Guard
Let’s create a new policy:
SW1(config)#ipv6 source-guard policy SOURCE_GUARD
There a couple of options to choose from:
SW1(config-sisf-sourceguard)#?
IPv6 sourceguard policy configuration mode:
deny Block data traffic
exit Exit from sourceguard policy configuration mode
permit Allow data traffic
Let’s take a look at the deny option:
SW1(config-sisf-sourceguard)#deny ?
global-autoconf Drop data traffic from global autoconfigued addresses
When we enable this, the switch will block all static IPv6 addresses. IPv6 addresses through
DHCP are permitted since those are in the binding table. Let’s add this to our policy:
SW1(config-sisf-sourceguard)#deny global-autoconf
Let’s activate the policy on the interfaces that connect to H1 and H2:

SW1(config-if-range)#ipv6 source-guard attach-policy SOURCE_GUARD
Let’s try our attack from H2 again:

Nothing shows up on S1 anymore:

FE80::21D:A1FF:FE8B:36D1 29 001d.a18b.36d1 STALE Fa0/0
2001:DB8:0:4::F 33 001d.a18b.36d1 STALE Fa0/0
Those packets from H2 are filtered by SW1.
I tried to do a debug on SW1 that shows that packets are dropped because of Source Guard but couldn’t
find any debug that produces this output. I used a Cisco Catalyst 3560 running IOS version 15.0(2)SE11
Page 169 of 252

for this lesson. You can test it by enabling debug ipv6 packet on S1. If you found something, let me
know.
does the ping from H1 still work?
H1#ping 2001:DB8:0:4::4 repeat 1

!
This ping still works because the IPv6 address on H1 is in our binding table.
hostname H1
!
ipv6 address dhcp
ipv6 enable
!
end
hostname H2
!
ipv6 address 2001:DB8:0:4::100/128
ipv6 address 2001:DB8:0:4::101/128
ipv6 address 2001:DB8:0:4::102/128
ipv6 address 2001:DB8:0:4::103/128
ipv6 enable
!
end
hostname R1
!
ipv6 cef
!
ipv6 dhcp server MY_POOL
!
!
end
hostname S1
!
Page 170 of 252

ipv6 cef
!
ipv6 address 2001:DB8:0:4::4/64
!
ipv6 route ::/0 2001:DB8:0:4::F
!
end
hostname SW1
!
ipv6 snooping policy SNOOPING
security-level glean
!
ipv6 source-guard policy SOURCE_GUARD
deny global-autoconf
!
ipv6 snooping attach-policy SNOOPING
!
ipv6 source-guard attach-policy SOURCE_GUARD
!
ipv6 source-guard attach-policy SOURCE_GUARD
!
end
Conclusion
You have now learned how IPv6 Source Guard works:
 Filters inbound packets on L2 switchport when there is no matching entry in the binding
table.
 Does not enter information in the binding table, you need another feature like ND
inspection or IPv6 snooping for this.
 When traffic is denied, it notifies the IPv6 address glean feature. It tries to find the
missing information by querying a DHCP server or by using IPv6 ND.
IPv6 PACL (Port ACL)

The IPv6 PACL (Port Access Control List) is basically a regular IPv6 access-list that is applied
to a switchport (L2 interface). They only work inbound.
Page 171 of 252

Configuration
Let’s look at quick example. Here’s the topology we’ll use:
We will use R1 and R2 to generate some IPv6 traffic and on SW1 we’ll configure the PACL.
Let’s configure some IPv6 addresses on R1 and R2:
R1(config)#interface FastEthernet f0/0

Let’s enable HTTP server so that we have something to connect to:
R2(config)#ip http server
Without an ACL, I can connect to the telnet server (enabled by default) and the HTTP server:
R1#telnet 2001:DB8:0:12::2
Trying 2001:DB8:0:12::2 ... Open
R1#telnet 2001:DB8:0:12::2 80
Trying 2001:DB8:0:12::2, 80 ... Open
Let’s create an access-list that denies telnet traffic and permits everything else:
SW1(config)#ipv6 access-list NO_TELNET

SW1(config-ipv6-acl)#deny tcp any host 2001:DB8:0:12::2 eq 23
SW1(config-ipv6-acl)#permit ipv6 any any
We can see the access-list we created with the show ipv6 access-list command:
SW1#show ipv6 access-list

IPv6 access list NO_TELNET
deny tcp any host 2001:DB8:0:12::2 eq telnet sequence 10
permit ipv6 any any sequence 20
You can also use show access-list without “ipv6” and it will show up.
Let’s activate the access-list on the GigabitEthernet 0/1 interface that connects to R1:
Page 172 of 252

SW1(config-if)#ipv6 traffic-filter NO_TELNET in
Now, from R1 I’ll try to connect to the telnet and HTTP server on R2:
R1#telnet 2001:DB8:0:12::2
Trying 2001:DB8:0:12::2 ...
% Connection timed out; remote host not responding
R1#telnet 2001:DB8:0:12::2 80
Trying 2001:DB8:0:12::2, 80 ... Open
As you can see, telnet traffic is no longer permitted.
Unfortunately, hits don’t show in the access-list:
SW1#show ipv6 access-list

IPv6 access list NO_TELNET
deny tcp any host 2001:DB8:0:12::2 eq telnet sequence 10
permit ipv6 any any sequence 20
There is the debug ipv6 access-list command but it doesn’t seem to work for PACLs, it
only works when you apply an access-list to a routed (L3) interface.
hostname R1
!
ip cef
!
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname R2
!
ip cef
!
ipv6 address 2001:DB8:0:12::2/64
!
ip http server
!
end
hostname SW1
!
ipv6 traffic-filter NO_TELNET in
!
!
Page 173 of 252

ipv6 access-list NO_TELNET
deny tcp any host 2001:DB8:0:12::2 eq telnet
permit ipv6 any any
!
end
Conclusion
You have now learned how to configure the IPv6 PACL (Port ACL) on a Cisco switch. I hope
you enjoyed this lesson. If you have any questions feel free to leave a comment!
How to configure IPv6 tunneling over IPv4

Since IPv4 and IPv6 are not compatible with each other we need some migration strategies. One
technique that we can use is tunneling. Basically it means that we encapsulate IPv6 packets into
IPv4 packets (or the other way around) so that it can be routed. In this lesson I’ll show you how
to configure IPv6 static tunneling over an IPv4 network, there are two methods:
 Manual tunnels
 GRE (Generic Routing Encapsulation) tunnels
Both tunnel types are very similar with just minor differences. Both support IPv6 IGPs through
the tunnel interface and forwarding of multicast traffic. The manual tunnels refer to RFC 4213
which defines how to encapsulate IPv6 packets in IPv4. GRE is a generic encapsulation type that
rides on top of IPv4 and isn’t only for IPv6. It can carry many different protocols and if you ever
configured an IPSEC VPN with IGPs running through it you had to use GRE.
Let’s continue by looking at some examples and how to configure the static point-to-point IPv6
tunnels.
Page 174 of 252

This is the topology we’ll be using. Three routers are running IPv4. R1 and R3 also run IPv6 and
we want connectivity between them without adding IPv6 support on R2.
R1(config-if)#exit
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R2(config-if)#exit
R3(config-if)#exit
First we’ll fix the IPv4 and IPv6 addresses on the interfaces. Next step is to create a tunnel
interface between R1 and R3. They need to be able to reach each other through IPv4.
R1(config-if)#exit
R1(config)#router eigrp 123
R1(config-router)#no auto-summary
R1(config-router)#network 192.168.12.0
Page 175 of 252

R3(config-if)#exit
I’ll create a new loopback interface on R1 and R3. I’ll use these loopback interfaces to establish
a tunnel interface between the two routers. I could also use physical interfaces but they can go
down. Whenever a physical interface goes down our IGP (EIGRP in this example) could find
another path (if there is another path).
R1(config)#interface tunnel 0
R1(config-if)#tunnel source loopback 1
R1(config-if)#tunnel destination 3.3.3.3
R1(config-if)#tunnel mode ipv6ip
R3(config-if)#tunnel source loopback 1
This is how we configure a tunnel interface. By default a tunnel interface is always GRE so by
using the tunnel mode ipv6ip command I changed it to a “manual” tunnel per RFC 4213. You
can also configure the tunnel interface between the physical interfaces but I like to use loopback
interfaces. This will make sure that when a physical interface fails your IGP will try to find
another route to the loopback interface of your neighbor.
[teaser]
R1#show interfaces tunnel 0

Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 1.1.1.1 (Loopback1), destination 3.3.3.3
Tunnel protocol/transport IPv6/IP
Hardware is Tunnel
Keepalive not set
Tunnel protocol/transport IPv6/IP
Page 176 of 252

Use the show interfaces tunnel command to check if the tunnel is working. You can see mine is
up and the encapsulation type is TUNNEL. At this moment our tunnel is working but we have
some things left to do.
R1(config-rtr)#exit
R1(config-if)#exit
R3(config-rtr)#exit
R3(config-if)#exit
I enabled RIPNG (could have chosen OSPFv3 or EIGRP as well) on the loopback0 and tunnel0
interface. You can see I also added an IPv6 address on the tunnel0 interfaces. We don’t need any
IPv4 addresses on our tunnel0 interfaces.

R 2001::3/128 [120/2]
via FE80::303:303, Tunnel0
R 2001::1/128 [120/2]
via FE80::101:101, Tunnel0
You can see both routers learned about each other IPv6 networks.
R1#ping 2001::3 source loopback 0

Sending 5, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Page 177 of 252

A quick ping proves us that we have connectivity.
That’s all you have to do to create a manual tunnel and encapsulate IPv6 packets in IPv4 packets.
Not that bad right? How about GRE?
R1(config-if)#tunnel mode gre ip
Use tunnel mode gre ip or type no tunnel mode ipv6ip so it switches back to the default
(GRE).

Hardware is Tunnel
Keepalive not set
Tunnel protocol/transport GRE/IP
It looks pretty much the same except it now says GRE. The only difference between GRE and
the manual tunnel is that GRE has a higher MTU by default and there’s something with the link-
local IPv6 address of the tunnel interface:
 The link-local address for the GRE tunnel is created with EUI-64 and takes the lowest
numbered interface’s MAC address.
 The link-local address for the manual tunnel is FE80::/96 + 32 bits from tunnel source
IPv4 address.
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router eigrp 123
no auto-summary
network 192.168.12.0
network 192.168.23.0
!
end
Page 178 of 252

hostname R3
!
!
!
ip address 3.3.3.3 255.255.255.0
!
ip address 192.168.23.3 255.255.255.0
!
interface tunnel 0
tunnel source loopback 1
tunnel destination 1.1.1.1
tunnel mode ipv6ip
tunnel mode gre ip
!
router eigrp 123
no auto-summary
network 192.168.23.0
network 3.3.3.0
!
!
ipv6 general-prefix MYPREFIX 6to4 fastEthernet 0/0
!
end
hostname R1
!
!
!
ip address 1.1.1.1 255.255.255.0
!
ip address 192.168.12.1 255.255.255.0
!
interface tunnel 0
tunnel source loopback 1
tunnel mode ipv6ip
tunnel mode gre ip
!
router eigrp 123
no auto-summary
network 192.168.12.0
Page 179 of 252

network 1.1.1.0
!
!
!
end
How to configure IPv6 Automatic 6to4

Tunneling
Dynamic multipoint IPv6 tunnels are another migration technique we can use. It’s called
dynamic because we don’t have to specify the end-point IPv4 address ourselves but its being
automatically determined. The downside of multipoint IPv6 tunnels is that they don’t support
IPv6 IGPs. You have to use static routes or BGP.
There are two different flavors:
 Automatic 6to4
 ISATAP
Let’s dive in the automatic 6to4 tunnel to see how it works. We don’t configure the IPv4 end-
point address ourselves but instead the IPv4 end-point address will be wrapped in the IPv6
destination address. Our IPv4 address is only 32-bit so it’s easy to fit it in a 128-bit IPv6 address
right?
The 2002::/16 range has been reserved to use for tunneling. This IPv6 address space is only for
tunneling and will never be used for IPv6 global unicast addresses. If we start with the 2002::/16
prefix we create a /48 prefix for each tunnel end-point. What we have to do is take the IPv4
address of the end-point and convert it into hexadecimal as bits 17 to 48.
The second step is that we can create subnets from /48 up to /64 prefixes for all the subnets
behind the end-point.
Here’s a graphical overview. 2002::/16 is the range we can use for the tunnels. The second part is
the IPv4 end-point address converted to hexadecimal. Up to /64 we can use to create subnets.
C0A8:1703 converts to IPv4 address 192.168.23.3. Do you have trouble calculating from hex to
binary/decimal and vice versa?
Page 180 of 252

R3(config)#ipv6 general-prefix MYPREFIX 6to4 fastEthernet 0/0
R3#show ipv6 general-prefix

IPv6 Prefix MYPREFIX, acquired via 6to4
2002:C0A8:1703::/48
There is a neat trick on Cisco routers that can do the work for you. First you have to configure an
IPv4 address on an interface and then use the ipv6 general-prefix command. It will convert the
IPv4 address in hexadecimal and give you the correct IPv6 tunnel prefix with the show ipv6
general-prefix command. I’m not sure if this is available on the CCNP ROUTE exam but it’s
nice to know anyway! Let’s take a look at an actual configuration of automatic 6to4 tunneling,
this is the topology:
Let’s look at another example and configure automatic tunneling. The idea is that I don’t want to
configure a tunnel destination on R1 nor R3…it should be created dynamically!
We’ll start with the configuration of the interfaces and IPv4 / IPv6 addresses:
R1(config-if)#exit
R2(config-if)#exit
Page 181 of 252

R3(config-if)#exit
Next step is to configure routing so that we have reachability in IPv4:

We will use the FastEthernet0/0 interfaces to build the tunnel. Since the tunnel is created
automatically we need to know the IPv6 equivalent of the IPv4 addresses:

2002:C0A8:C01::/48
2002:C0A8:1703::/48
[teaser]
This time I’m going to use the IP addresses on the FastEthernet0/0 interfaces to build the tunnel.
Since the tunnel is created automatically we need to know the IPv6 equivalent of the IPv4
addresses.
R1(config-if)#ipv6 address 2002:C0A8:C01::1/64
R1(config-if)#tunnel source fastEthernet 0/0
R1(config-if)#tunnel mode ipv6ip 6to4
R3(config-if)#ipv6 address 2002:C0A8:1703::3/64
R3(config-if)#tunnel source fastEthernet 0/0
R3(config-if)#tunnel mode ipv6ip 6to4
Let me walk you through this configuration: The tunnel interface has an IPv6 address that starts
with 2002: and then the IPv4 address in hex:
 Router R1: 192.168.12.1 – C0A8:C01

 Router R3: 192.168.23.3 – C0A8:1703
Page 182 of 252

The tunnel is sourced from the FastEthernet interface (I could have used a loopback as well) and
there is no destination. That’s why we need the tunnel mode ipv6ip 6to4 command for. It tells
the router to get the IPv4 address from the IPv6 address.
Are we done? Well almost. The tunnel configuration is OK but we still have to tell our routers
how to reach the loopback0 interfaces. It’s impossible to run an IGP on dynamic tunnel
interfaces so we can use static routes or BGP. I’m going to use static routes.
R1(config)#ipv6 route 2001::3/128 2002:C0A8:1703::3

R1(config)#ipv6 route 2002::/16 tunnel 0
R3(config)#ipv6 route 2001::1/128 2002:C0A8:C01::1
R3(config)#ipv6 route 2002::/16 tunnel 0
The first static route we need to tell our routers how to reach the loopback0 interface of the other
side. It points to the IPv6 address which has the IPv4 address in hex in it. The routers will have
to do recursive routing to find an entry for 2002:: which is why we need the second static route.
Since 2002::/16 is reserved for tunneling I’m creating a static that points directly to our tunnel0
interface.
R1#ping 2001::3 source loopback 0

Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds:
!!!!!
A quick ping shows we can reach the loopback0 interface of the other side! That’s how it is
done. If you have any more questions please leave a comment.
hostname R2
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router eigrp 123
no auto-summary
network 192.168.12.0
network 192.168.23.0
!
end
hostname R3
!
Page 183 of 252

!
ip address 192.168.23.3 255.255.255.0
!
interface tunnel 0
ipv6 address 2002:C0A8:1703::3/64
tunnel source fastEthernet 0/0
tunnel mode ipv6ip 6to4
!
router eigrp 123
no auto-summary
network 192.168.23.0
network 3.3.3.0
!
!
ipv6 route 2001::1/128 2002:C0A8:C01::1
ipv6 route 2002::/16 tunnel 0
!
end
hostname R1
!
!
ip address 192.168.12.1 255.255.255.0
!
interface tunnel 0
ipv6 address 2002:C0A8:C01::1/64
tunnel source fastEthernet 0/0
!
router eigrp 123
no auto-summary
network 192.168.12.0
network 1.1.1.0
!
!
ipv6 route 2001::3/128 2002:C0A8:1703::3
ipv6 route 2002::/16 tunnel 0
!
end
Troubleshooting IPv6 Automatic 6to4 Tunnel

In this lesson we’ll take a look how to troubleshoot an automatic IPv6 6to4 tunnel. Take a look at
the following topology:
Page 184 of 252

This scenario requires some more explanation. R1 and R3 each have a loopback0 interface with
an IPv6 prefix on it. The FastEthernet interfaces of R1, R2 and R3 only have IPv4 addresses. The
network engineer that designed this topology created an automatic 6to4 tunnel to establish
connectivity between the two IPv6 networks. Of course this is not working so we’ll have some
fixing to do.
I’ll show you the tunnel configuration from the running-config:
R1#show running-config | begin Tunnel0

interface Tunnel0
no ip address
no ip redirects
ipv6 address 2002:A0A:A01::1/64
tunnel source FastEthernet0/0
R3#show running-config | begin Tunnel0
interface Tunnel0
no ip address
no ip redirects
ipv6 address 2002:A14:1403::3/64
Above you can see the tunnel interfaces, they have been configured for 6to4 tunneling and
there’s an IPv6 address on each tunnel. Let’s see if the tunnel works:
R1#ping 2001:1::3

Page 185 of 252

.....
R3#ping 2001:1::1

.....
A quick ping shows us that we can’t ping the IPv6 addresses on the loopback interfaces. So
where should we start troubleshooting? Let’s check if R1 and R3 are able to reach each other:
R1#ping 192.168.23.3 source fastEthernet 0/0

Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1
!!!!!
The tunnel 0 interfaces are sourced from the FastEthernet 0/0 interfaces of R1 and R3. By
sending a ping from R1 to R3 between the FastEthernet 0/0 interfaces I know that IPv4 routing is
not the issue. Let’s take a closer look at the IPv6 addresses:

Loopback0 [up/up]
FE80::CE09:25FF:FEB0:0
2001:1::1
Tunnel0 [up/up]
FE80::C0A8:C01
2002:A0A:A01::1
Loopback0 [up/up]
FE80::CE0B:25FF:FEB0:0
2001:1::3
Tunnel0 [up/up]
FE80::C0A8:1703
2002:A14:1403::3
Taking a quick look at the interfaces tells us that the IPv6 addresses on the loopback 0 interfaces
have been configured correctly and that the interfaces are up and running. You can also see the
IPv6 addresses on the tunnel 0 interfaces. What do the 2002:A0A:A01::1 and 2002:A14:1403::3
addresses mean?
Keep in mind that the tunnel mode is automatic 6to4. The “automatic” part means that the tunnel
destination IP is not configured statically but within the IPv6 address. 2002::/16 is the range that
is reserved for tunnels. Let’s see if we can ping these tunnel IPv6 addresses:
R1#ping 2002:A14:1403::3
Page 186 of 252

Sending 5, 100-byte ICMP Echos to 2002:A14:1403::3, timeout is 2 seconds:
.....
R3#ping 2002:A0A:A01::1

Sending 5, 100-byte ICMP Echos to 2002:A0A:A01::1, timeout is 2 seconds:
.....
We are unable to ping the IPv6 addresses on the tunnel 0 interfaces. This could mean that
2002:A0A:A01::1 and 2002:A14:1403::3 are not correct or that my routing is not working.
The tunnel should be built between IP address 192.168.12.1 and 192.168.23.3. If you want you
can manually calculate from decimal to hexadecimal but there’s an easier method! Here’s how:
R1(config)#ipv6 general-prefix IAMLAZY 6to4 fastEthernet 0/0
We can let our router do the calculation from decimal to hexadecimal for us. Here’s the result:

IPv6 Prefix IAMLAZY, acquired via 6to4
2002:C0A8:C01::/48
There you go, the IPv6 address should be in this range 2002:C0A8:C01/48 so
2002:A0A:A01::1/64 on R1 is incorrect. Let’s fix it:
R1(config-if)#no ipv6 address 2002:A0A:A01::1/64
R1(config-if)#ipv6 address 2002:C0A8:C01::1/64
We’ll remove the old IPv6 address and configure a new one in the 2002:C0A8:C01/48 range.
Let’s see if the address on R3 is correct as well:
R3(config)#ipv6 general-prefix IAMLAZY 6to4 FastEthernet 0/0
Here’s the result:

IPv6 Prefix IAMLAZY, acquired via 6to4
2002:C0A8:1703::/48
The correct prefix is 2002:C0A8:1703::/48 so 2002:A14:1403::3 is not going to work. Let’s fix
it:
R3(config-if)#no ipv6 address 2002:A14:1403::3/64

R3(config-if)#ipv6 address 2002:C0A8:1703::3/64
Page 187 of 252

We’ll remove the IPv6 address and configure another one that falls within the 2002:A14:1403::3
range.
Now we know that the IPv6 addresses on the tunnel 0 interfaces are correct. Next step is to check
our routing to see if R1 and R3 know how to reach each other’s IPv6 addresses. Let’s check the
routing tables:
R1#show ipv6 route

LC 2001:1::1/128 [0/0]
via ::, Loopback0
S 2001:1::3/128 [1/0]
via 2002:A14:1403::3
S 2002::/16 [1/0]
via ::, Tunnel0
C 2002:C0A8:C01::/64 [0/0]
via ::, Tunnel0
L 2002:C0A8:C01::1/128 [0/0]
via ::, Tunnel0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
There are two static routes here. The 2001:1::3/128 points to the loopback 0 interface of R3 but
the next hop IPv6 address is 2002:A14:1403::3. This next hop is incorrect so we’ll have to
change it. The static route for 2002::/16 to the tunnel 0 interface is fine. This prefix is reserved
for tunneling and we need it because the router will do a recursive routing looking when it tries
to reach 2001:1::3/128. Let’s fix it:[teaser]
R1(config)#no ipv6 route 2001:1::3/128 2002:A14:1403::3

R1(config)#ipv6 route 2001:1::3/128 2002:C0A8:1703::3
We’ll remove the old static route and create a new one with the correct next hop. Let’s check R3
as well:
R3#show ipv6 route

S 2001:1::1/128 [1/0]
via 2002:A0A:A01::1
LC 2001:1::3/128 [0/0]
via ::, Loopback0
S 2002::/16 [1/0]
Page 188 of 252

via ::, Tunnel0
C 2002:C0A8:1703::/64 [0/0]
via ::, Tunnel0
L 2002:C0A8:1703::3/128 [0/0]
via ::, Tunnel0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
R3 has the same issue. The static route with 2002::/16 to the tunnel0 interface is fine but
2001:1::1/128 has the old (and wrong) next hop. Time to fix it:
R3(config)#no ipv6 route 2001:1::1/128 2002:A0A:A01::1

R3(config)#ipv6 route 2001:1::1/128 2002:C0A8:C01::1
After making these changes, let’s see if there is connectivity between R1 and R3:
R3#ping 2001:1::1 source loopback 0

Packet sent with a source address of 2001:1::3
!!!!!
There we go! A ping between the loopback 0 interfaces of R1 and R3 proves that they know how
to reach each other’s prefixes…problem solved!
Lesson learned: Make sure you use the correct 6to4 tunnel IPv6 addresses and correct
routes.
IPv6 6RD (Rapid Deployment)

IPv6 6RD (Rapid Deployment) is an IPv6 tunneling technique, similar to 6to4 tunneling. It is
stateless and encapsulates IPv6 packets into IPv4 packets.
6to4 tunneling has some limitations which are why ISPs never really implemented it:
 Packets from native IPv6 hosts have to traverse a 6to4 relay router so that IPv6 packets can be
encapsulated in IPv4 packets. On the Internet, however, there is no guarantee that those
packets are routed towards a relay.
 6to4 tunneling uses the 2002::/16 prefix. Every ISP that offers 6to4 tunneling advertises the
2002::/16 prefix, the downside of this is that an ISP might receive traffic destined for other ISPs
that also offer 6to4 tunneling. We can either relay or drop those packets. Dropping means we
blackhole traffic, relaying it means we process traffic from both our customers and customers
from other ISPs. It’s difficult to guarantee a certain quality of service for the ISP’s customers.
Page 189 of 252

6RD builds upon the 6to4 tunneling mechanism and gets rid of its biggest weakness, the use of
the 2002::/16 prefix. Instead, each ISP will use a unique IPv6 prefix that belongs to the ISP.
This has the following advantages:
 All 6RD hosts are reachable from all native IPv6 hosts that can reach the ISP IPv6 network.
 The relay belongs to the ISP and only does 6to4 tunneling for the customers of the ISP so they
are completely responsible for the quality of service.
 Reduced scope for anonymous traffic attacks that are possible with 6to4 RFC3964 since the ISP
now only processes traffic from its own customers.
Let’s look at a global overview of how 6RD works:
The ISP has an internal IPv4 network. Each customer has a CE router (Customer Equipment),
sometimes called the RG (Residential Gateway) with an IPv4 address on the WAN side. On the
LAN, we can have IPv4 and IPv6 hosts. When an IPv6 host transmits a packet, the CE router
encapsulates the IPv6 packet in an IPv4 packet and depending on the destination, it is transferred
to another CE router or the BR (Border Relay) router of the ISP.
The border relay router has an IPv4 address on the ISP network side and provides connectivity
between the CE routers and the IPv6 Internet. When it receives an IPv6 packet that is
encapsulated in an IPv4 packet from one of the CEs, it de-encapsulates the packet and forwards
it to the IPv6 internet.
6RD is stateless so packets don’t have to go through the same border relay router. For high
availability and load balancing reasons, we can add more than one border relay router. Each
Page 190 of 252
border relay router needs to be configured with the same IPv4 address (anycast) so that CE
routers are routed to the closest border relay.
6RD addressing and prefixes

Let’s take a closer look at how IPv6 packets are encapsulated in IPv4.
To make 6RD work, we need three things:
 An IPv6 prefix and prefix length that the ISP wants to use for 6RD.
 Embedded IPv4 address in the IPv6 prefix.
 6RD border relay IPv4 address.
The ISP decides on all these items. They select an IPv6 prefix and prefix length that they want to
use for 6RD, and the IPv4 addresses that the CE routers and BRs should get.
We know that a CE router can get its IPv4 address from a DHCP server but what about the IPv6
prefix, prefix length, and the 6RD border relay IPv4 address? We can push those values using
three different options:
 TR-069: this is a protocol for remote management of customer equipment (CE) connected
devices.
 DHCP option 212
 PPP IPCP option
Here’s an example of DHCP option 212:
Let me explain these fields:
 Option 6RD: this defines the DHCP option value, 212 for 6RD.
 Option Length: the length of this option in bytes. With one BR (border relay) IPv4 address, it’s
22 bytes.
 IPv4 Mask Length: the number of bits that all CE router IPv4 addresses have in common. I’ll
explain why we need this in a bit when we look at the 6RD prefix in detail.
 6RD prefix length: as the name implies, the prefix length of our 6RD prefix in bits.
 6RD prefix: the prefix that the ISP wants to use for 6RD.
Page 191 of 252

 6RD BR IPv4 address(es): the IPv4 address(es) of one or more BRs. You can also use the same
IPv4 address (anycast) on all BRs.
When the CE knows its IPv4 address, the 6RD prefix, and the prefix length then it has all the
information it needs to build the complete customer IPv6 prefix. The format looks like this:
Let me explain these fields:
 6RD prefix: this is the prefix that the ISP uses for 6RD.
 IPv4 address: the IPv4 address of the CE is embedded in the IPv6 prefix.
 Subnet: these bits can be used to create multiple subnets for each customer.
 Interface ID: the last 64 bits are used to create a unique ID for each host.
The default allocation of IPv6 prefixes is 32 bits and an IPv4 address is also 32 bits. This means
that an ISP could only assign a single 64-bit prefix to each customer if it decides to include the
entire 32-bit IPv4 address in the prefix.
For example, let’s say the 6RD prefix is 2001:DB8::/32 and a CE has IPv4 address 192.168.1.1.
192.168.1.1 in hexadecimal is C0A8:0101 so our customer 6RD prefix then looks like this:
There are no bits left to create multiple subnets. If you only want to assign a single 6RD prefix to
each customer then this is no problem but if you want your customer to get more than one prefix,
we’ll have to do something about it.
Each ISP only owns a small part of the entire IPv4 address space so there is no need to include
the entire IPv4 address. For example, let’s say we have a small ISP that only uses the
192.168.1.0/24 address space for CEs. There is no need to include the 192.168.1. subnet in the
prefix, since the first 24 bits are always the same. We only need to include the 8 host bits that are
unique to each CE. If the CE router knows the BR IPv4 address and the common bits, then we
only include our unique host part of the IPv4 address and save bits for subnets.
Page 192 of 252

Here’s an example:
Above we see that we only included the 8 host bits so have 24 bits left we can use for subnets.
This allows our customer to create 2^24 = 16777216 subnets.
6RD Packet Encapsulation

We have seen how CE routers generate their customer IPv6 6RD prefix, now let’s take a look at
how the encapsulation works. There are two options:
 Within domain: IPv6 traffic from one CE router to another CE router.

 Outside domain: IPv6 traffic from one CE router to an IPv6 host outside of the ISP network.
Let’s take a closer look at both options.
Within domain
This is traffic that is destined for one of the CE routers within the ISP domain. This could be
traffic from one CE to another CE, or from a native IPv6 host on the Internet destined for a CE
router. Let’s look at an example where we have traffic from one CE router to another CE router:
Page 193 of 252

The ISP uses the 192.168.1.0/24 subnet and each router has an IPv4 address. Behind each CE
router, we have a host with an IPv6 address:
 H1: 2001:DB8:100:10::1
 H2: 2001:DB8:200:10::1
H2 sends an IPv6 packet destined for H1. Here’s what the encapsulated IPv6 packet looks like:
The router checks for the destination and compares it with the ISP 6RD prefix (2001:DB8::/32)
that I highlighted in red. When there is a match, the destination IPv4 address host bits are derived
from the IPv6 destination address.
Page 194 of 252

Outside Domain
Let’s look at an example where H1 wants to send an IPv6 packet to a destination outside of the
ISP network:
Here’s the encapsulated packet:
This packet is destined for 2001:4860:4860::8888 (Google DNS server). The CE router checks if
the destination matches the ISP 6RD prefix (2001:DB8::/32) but since there is no match, it enters
the IPv4 address of the BR as the destination.
Configuration
Now you have an idea of how 6RD works, let’s see it in action. I will use the following topology
to demonstrate this:
Page 195 of 252

Page 196 of 252

hostname BR1
!
ip cef
!
interface Loopback0
ipv6 address 2001:4860:4860::8888/128
!
ip address 192.168.1.3 255.255.255.0
!
end
hostname CE1
!
ip cef
!
ip address 192.168.1.1 255.255.255.0
!
end
hostname CE2
!
ip cef
!
ip address 192.168.1.2 255.255.255.0
!
end
We have a small ISP network with one BR and two CE routers. This ISP uses 2001:DB8::/32 as
the RD6 prefix. All routers are connected to IPv4 network 192.168.1.0/24 with their
GigabitEthernet 0/1 interfaces.[teaser]
The BR has a loopback interface with IPv6 address 2001:4860:4860::8888/128, we use this
address to simulate the IPv6 internet.
Each CE router has a loopback interface that represents a LAN of the customer.
Cisco IOS does not support DHCP option 212 so I manually configured the IPv4 addresses and I
will manually configure the RD6 prefix, prefix length, and BR IPv4 address.
CE1
Let me walk you through the configuration of the first CE router.
First, we need to enable IPv6 unicast routing or the static routes that I’ll add later won’t work:
CE1(config)#ipv6 unicast-routing
Page 197 of 252

We will create a general prefix that we can refer to by name that is based on a tunnel interface
(that we’ll create next):
CE1(config)#ipv6 general-prefix ISP_RD6_PREFIX 6rd Tunnel 0
Let’s create that tunnel. Let’s make sure it has an IPv6 link-local address (required for routing):
CE1(config)#interface Tunnel 0
CE1(config-if)#ipv6 enable
The source of the tunnel is the GigabitEthernet 0/1 interface:
CE1(config-if)#tunnel source GigabitEthernet 0/1
The tunnel mode is 6RD:
CE1(config-if)#tunnel mode ipv6ip 6rd
We also specify the prefix-length of our IPv4 network so that we don’t have to include the entire
32-bit IPv4 address in the IPv6 prefix:
CE1(config-if)#tunnel 6rd ipv4 prefix-len 24
I’ll specify the ISP RD6 prefix that we use:
CE1(config-if)#tunnel 6rd prefix 2001:DB8::/32
And the BR IPv4 address if we want to reach hosts on the IPv6 Internet:
CE1(config-if)#tunnel 6rd br 192.168.1.3
To simulate a prefix on a LAN, I’ll use a loopback interface. I need to think of a prefix so I’ll use
“10” as my prefix number. We can refer to the general prefix we created previously:
CE1(config)#interface Loopback 0
CE1(config-if)#ipv6 address ISP_RD6_PREFIX ::10:0:0:0:1/64
We also need to configure some routing. We need one static route for the 2001:DB8::/32 prefix
that points to the tunnel interface and we need a default route that points to the BR. The IPv6
address I specify has the IPv4 address of the BR embedded:
CE1(config)#ipv6 route 2001:DB8::/32 Tunnel 0

CE1(config)#ipv6 route ::/0 2001:DB8:300::
That completes our CE2 configuration.
Page 198 of 252

CE2
The CE2 router is the same as CE1. Here is the entire configuration:
CE2(config)#ipv6 general-prefix ISP_RD6_PREFIX 6rd Tunnel 0
CE2(config)#interface Tunnel 0
CE2(config-if)#ipv6 enable
CE2(config-if)#tunnel source GigabitEthernet 0/1
CE2(config-if)#tunnel mode ipv6ip 6rd
CE2(config-if)#tunnel 6rd ipv4 prefix-len 24
CE2(config-if)#tunnel 6rd prefix 2001:DB8::/32
CE2(config-if)#tunnel 6rd br 192.168.1.3
CE2(config)#interface loopback 0
CE2(config-if)#ipv6 address ISP_RD6_PREFIX ::10:0:0:0:1/64
CE2(config)#ipv6 route 2001:DB8::/32 Tunnel 0

CE2(config)#ipv6 route ::/0 2001:DB8:300::
That’s it.
BR1
The configuration of the BR is similar to the CE routers:
BR(config)#ipv6 unicast-routing
BR(config)#interface Tunnel 0
BR(config)#ipv6 enable
BR(config-if)#tunnel source GigabitEthernet 0/1
BR(config-if)#tunnel mode ipv6ip 6rd
BR(config-if)#tunnel 6rd ipv4 prefix-len 24
BR(config-if)#tunnel 6rd prefix 2001:DB8::/32
BR(config)#ipv6 route 2001:DB8::/32 Tunnel 0
I only need a static route for the 2001:DB8::/32 prefix that points to the tunnel.
Verification
Let’s verify our work. The show tunnel 6rd command gives me a lot of useful information:
CE1#show tunnel 6rd

Interface Tunnel0:
Tunnel Source: 192.168.1.1
6RD: Operational, V6 Prefix: 2001:DB8::/32
V4 Prefix, Length: 24, Value: 192.168.1.0
V4 Suffix, Length: 0, Value: 0.0.0.0
Border Relay address: 192.168.1.3
Page 199 of 252

General Prefix: 2001:DB8:100::/40
CE2#show tunnel 6rd
Interface Tunnel0:
Border Relay address: 192.168.1.3
BR#show tunnel 6rd
Interface Tunnel0:
On each router, we see the ISP RD6 prefix, the IPv4 network address and prefix length, and the
prefix that the router can use (shows as the general prefix). This prefix has the IPv4 address
embedded. Above, you also see the IPv4 suffix which I did not configure. You can use this so
your routers agree on using the same tail portion of the IPv4 address. For example, you
could use something like 0.0.0.0/8 which means that the IPv4 address of a router always ends
with .1. You can use this to reduce the number of host bits in the IPv6 prefix, allowing you to
create even more subnets.
Let’s take a look at the IPv6 addresses that are generated on the loopback interfaces of the CE
routers:
CE1#show ipv6 interface loopback 0 | include 2001

2001:DB8:100:10::1, subnet is 2001:DB8:100:10::/64
CE2#show ipv6 interface loopback 0 | include 2001
2001:DB8:200:10::1, subnet is 2001:DB8:200:10:/64
This is looking good, each CE router has an IPv6 address:
 CE1:
o 2001:DB8 is the ISP RD6 prefix
o :100 is the embedded IPv4 address (.1)
o :10 is the subnet
o The interface ID is ::1.
 CE2:
o 2001:DB8 is the ISP RD6 prefix
o :200 is the embedded IPv4 address (.2)
o :10 is the subnet
o The interface ID is ::1
Each CE router has two static routes:
CE1#show ipv6 route static
S ::/0 [1/0]
Page 200 of 252

via 2001:DB8:300::
S 2001:DB8::/32 [1/0]
via Tunnel0, directly connected
CE2#show ipv6 route static
S ::/0 [1/0]
via 2001:DB8:300::
S 2001:DB8::/32 [1/0]
One static route for 2001:DB8::/32 that points to the tunnel interface and a default route that
points to the BR.
The BR has a single static route for the 2001:DB8::/32 prefix:
BR#show ipv6 route static
S 2001:DB8::/32 [1/0]
This allows the BR to reach the CE routers.
Traffic flows
Let’s send some traffic between CE routers and from a CE router to a BR or vice versa.
Within Domain
We’ll start with traffic within the domain. I’ll send a ping from CE1 to CE2:
CE1#ping 2001:DB8:200:10::1 source 2001:DB8:100:10::1

Packet sent with a source address of 2001:DB8:100:10::1
!!!!!
Here’s what this ping looks like in Wireshark:
IPv6 6RD CE-CE ICMP
You can see the IPv4 addresses and the encapsulated IPv6 packet.
Page 201 of 252

Outside Domain
How about traffic from a CE router to the IPv6 Internet? Let’s try a ping from CE1 to
2001:4860:4860::8888 (Google DNS, configured on the loopback of the BR):
CE1#ping 2001:4860:4860::8888 source 2001:DB8:100:10::1

Sending 5, 100-byte ICMP Echos to 2001:4860:4860::8888, timeout is 2 seconds:
!!!!!
My ping works, here’s the encapsulated packet:
IPv6 6RD CE-BR ICMP
Above, you can see that the destination address is 192.168.1.3 (BR).
For the sake of completeness, let’s try a ping with traffic that originated from an IPv6 host on the
IPv6 internet to one of the CE routers. I’ll use the loopback of the BR for this:
BR#ping 2001:DB8:100:10::1 source 2001:4860:4860::8888

Packet sent with a source address of 2001:4860:4860::8888
!!!!!
The ping works. Here’s the encapsulated packet:
IPv6 6RD BR-CE ICMP
The packet is sourced from the BR (192.168.1.3) and destined for CE1 (192.168.1.1).
Page 202 of 252

That’s all there is to it!
hostname BR1
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:4860:4860::8888/128
!
interface Tunnel0
ipv6 enable
tunnel source GigabitEthernet0/1
tunnel mode ipv6ip 6rd
tunnel 6rd ipv4 prefix-len 24
tunnel 6rd prefix 2001:DB8::/32
!
ip address 192.168.1.3 255.255.255.0
!
ipv6 route 2001:DB8::/32 Tunnel0
!
end
hostname CE1
!
ip cef
ipv6 general-prefix ISP_RD6_PREFIX 6rd Tunnel0
ipv6 cef
!
interface Loopback0
ipv6 address ISP_RD6_PREFIX ::10:0:0:0:1/64
!
interface Tunnel0
ipv6 enable
tunnel 6rd br 192.168.1.3
!
ip address 192.168.1.1 255.255.255.0
!
ipv6 route ::/0 2001:DB8:300::
!
end
hostname CE2
Page 203 of 252

!
ip cef
ipv6 general-prefix ISP_RD6_PREFIX 6rd Tunnel0
ipv6 cef
!
interface Loopback0
ipv6 address ISP_RD6_PREFIX ::10:0:0:0:1/64
!
interface Tunnel0
ipv6 enable
tunnel 6rd br 192.168.1.3
!
ip address 192.168.1.2 255.255.255.0
!
ipv6 route ::/0 2001:DB8:300::
!
end
Conclusion
In this lesson, you have learned about IPv6 6RD:
 6RD (Rapid Deployment) is similar to 6to4 tunneling, a stateless tunneling protocol that
encapsulates IPv6 packets in IPv4 packets.
 6RD overcomes the issues that 6to4 tunneling has by replacing the 2002::/16 prefix with
a unique global IPv6 prefix for each ISP.
 We use two routers:
o CE (Customer Equipment) routers (also called residential gateways) with IPv4 on
the WAN side and IPv4/IPv6 on the LAN side.
o BR (Border Router) with IPv4 on the ISP side and connected to the IPv6 Internet.
 To make 6RD work we need three things:
o IPv6 prefix and prefix length
o Embedded IPv4 address in the IPv6 prefix
o Border relay router IPv4 address on the CE routers.
 The ISP decides on the values above and they can be exchanged with CE routers through:
o TR-069
o DHCP option 212
o PPP IPCP
 The IPv4 address is embedded in the IPv6 prefix
 We don’t have to embed the entire 32-bit IPv4 address, the common (network) bits can
be removed so that the saved bits can be used for customer subnets.
Page 204 of 252

 Routers look at the IPv6 destination:
o When the IPv6 destination matches the IPv6 prefix, it’s considered within domain
traffic and the router extracts the IPv4 address from the IPv6 address, setting it to
the IPv4 destination address.
o When the IPv6 destination does not match the IPv6 prefix, it’s considered outside
domain traffic and we set the IPv4 address of the BR as the destination.
IPv6 ISATAP (Intra Site Automatic Tunnel

Addressing Protocol)
ISATAP (Intra Site Automatic Tunnel Addressing Protocol) is an IPv6 tunneling technique that
allows you to connect IPv6 over an IPv4 network, similar to the automatic 6to4 tunnel.
On your IPv4 network, you can configure one of your routers as an IPv6 “headend” ISATAP
router that your IPv6 hosts can connect to. The IPv4 source address of the ISATAP clients and
router is embedded in the IPv6 address so that each device knows how to get to the other side of
the IPv4 network.
Here’s what the IPv6 address looks like:
The first 64 bits are for the prefix, and you can pick anything you like. Global unicast, link-local
addresses, both are possible. The next 64 bits are divided into two parts:
 0000:5EFe: this is a reserved UOI value which indicates that this is an ISATAP address.
 the remaining 32 bits embed the IPv4 address, in hexadecimal.
ISATAP was designed for intra site, in other words…within your site, not between sites.
However, nothing is stopping you from running this between sites.
It is easy to configure, and many clients support ISATAP, including any recent Windows or
Linux OS. You can configure the tunnel destination address manually or add it to a DNS server
so that it’s easy to find.
One disadvantage of ISATAP is that it does not support IPv6 multicast. This means you won’t be
able to run routing protocols like OSPFv3 or EIGRP.
Page 205 of 252

Configuration
Cisco IOS supports both the ISATAP client and headend router. In this lesson, I use the
following topology:
R1 is the ISATAP client, R3 is the headend router. We will use 2001:DB8:13:13::/64 as the
prefix on the tunnel interface. I use OSPFv2 so that R1 and R3 are able to reach each other
through IPv4. R3 also has a loopback interface with an IPv6 address, something we can try to
ping from R1.
hostname R1
!
ip cef
!
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
Page 206 of 252

router-id 2.2.2.2
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
!
end
hostname R3
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:3:3::3/128
!
ip address 192.168.23.3 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
network 192.168.23.0 0.0.0.255 area 0
!
end
Headend
Let’s start with the headend router. First, we need to enable IPv6 unicast routing:
Now we can focus on the tunnel interface:
R3(config)#interface Tunnel 0
R3(config-if)#ipv6 address 2001:db8:13:13::/64 eui-64
R3(config-if)#no ipv6 nd suppress-ra
R3(config-if)#tunnel source FastEthernet0/0
R3(config-if)#tunnel mode ipv6ip isatap
I configure the 2001:DB8:13:13::/64 prefix and let the router configure the last 64 bits using
EUI-64. You’ll see in a bit what address we end up with. By default, the router will not send
router advertisements on the tunnel interface which is why we need to add the no ipv6 and
suppress-ra command,
Client
Let’s configure our client:
R1(config-if)#tunnel source FastEthernet 0/0
Page 207 of 252

The tunnel interface is configured to configure its IPv6 address automatically. The tunnel source
is our FastEthernet 0/0 interface and the destination is the IPv4 address of R3.
Verification
Let’s see if our configuration works. I’ll start with the headend router…
Headend
Let’s take a look at our tunnel interface:
R3#show ipv6 interface Tunnel 0

IPv6 is enabled, link-local address is FE80::5EFE:C0A8:1703
2001:DB8:13:13:0:5EFE:C0A8:1703, subnet is 2001:DB8:13:13::/64 [EUI]
FF02::1
FF02::2
FF02::1:FFA8:1703
MTU is 1480 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is not supported
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses.
Above, we see a couple of interesting things:
 Both the link-local and global unicast prefix have the 0000:5EFE: bits that indicate that this is an
ISATAP address.
 Our IPv6 addresses end with C0A8:1703.
 We can verify that this router is sending router advertisements.
Below you can see the decimal IPv4 address that is embedded in the IPv6 address:
Decimal 192 168 23 3
Binary 11000000 10101000 00010111 00000011
Hexadecimal C0 A8 17 03
Client
Let’s take a look at our client:
R1#show ipv6 interface Tunnel 0
Page 208 of 252

IPv6 is enabled, link-local address is FE80::C0A8:C01
2001:DB8:13:13::C0A8:C01, subnet is 2001:DB8:13:13::/64 [PRE]
valid lifetime 2591842 preferred lifetime 604642
FF02::1
FF02::2
FF02::1:FFA8:C01
MTU is 1480 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Default router is FE80::5EFE:C0A8:1703 on Tunnel0
Above, we see two interesting items:[teaser]
 The IPv6 prefix that starts with 2001:DB8:13:13::/64

 Both the link-local and global unicast address have the IPv4 source address embedded
 Our headend router has become the default router.
Here’s the decimal IPv4 address that is embedded in the IPv6 address:
Decimal 192 168 12 1
Binary 11000000 10101000 00001100 00000001
Hexadecimal C0 A8 0C 01
Our client has an IPv6 global unicast address and a default route. Let’s try a quick ping to
2001:DB8:3:3::3, the address on the loopback interface of R3:
R1#ping 2001:db8:3:3::3

!!!!!
This proves that our tunnel is working and that our client can use the default route. That’s all
there is to it!
hostname R1
!
ip cef
!
interface Tunnel0
Page 209 of 252

no ip address
tunnel mode ipv6ip
!
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname R2
!
ip cef
!
ip address 192.168.12.2 255.255.255.0
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
router-id 2.2.2.2
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
!
end
hostname R3
!
ip cef
!
!
interface Loopback0
ipv6 address 2001:DB8:3:3::3/128
!
interface Tunnel0
ipv6 address 2001:DB8:13:13::/64 eui-64
no ipv6 nd suppress-ra
tunnel mode ipv6ip isatap
!
ip address 192.168.23.3 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
network 192.168.23.0 0.0.0.255 area 0
Page 210 of 252

!
end
Conclusion
You have now learned how ISATAP allows you to tunnel IPv6 traffic over your IPv4 network
automatically and how to configure a client and headend router on Cisco IOS.
IPv6 over MPLS 6PE/6VPE

6PE and 6VPE allow us to run IPv6 over an IPv4-only MPLS core where we use dual stack
PE routers.
On the PE routers, we use MP-BGP to exchange IPv6 prefixes and the LSP (Label Switched
Path) is based on IPv4. This allows service providers to offer IPv6 to their customers without
making major changes to the core of their MPLS network.
To achieve this, a small modification to MP-BGP was needed. The LSP between the PE routers
is based on IPv4 so the next hop addresses are IPv4 addresses. When a PE router advertises an
IPv6 prefix through MP-BGP to another PE router, it embeds the IPv4 address in the IPv6 next
hop address so that a PE router knows which IPv4 address (and thus which label) to use to get to
the other PE router.
 6PE uses the global IPv6 routing table on the PE routers.

 6VPE uses VRFs on the PE routers (MPLS VPN).
In this lesson, I’ll show you how to configure 6PE and 6VPE.
Configuration
Here is the topology we will use:
Page 211 of 252

Above, we have a service provider in AS234 with two PE routers and one P router, the MPLS
core is based on IPv4. The SP has a customer that is ready to use IPv6. On each CE router, there
Page 212 of 252

is a loopback with an IPv6 address. Between the PE-CE routers, we are going to use MP-BGP to
advertise those IPv6 prefixes so that we have connectivity between CE1 and CE2.
hostname CE1
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
ip address 10.255.1.147 255.255.0.0
!
ipv6 address 2001:DB8:0:45::5/64
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
Page 213 of 252

hostname PE1
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ipv6 address 2001:DB8:0:12::2/64
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
neighbor 4.4.4.4 update-source Loopback0
!
end
hostname PE2
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ipv6 address 2001:DB8:0:45::4/64
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
end
With the configuration above, I have an LSP between PE1 and PE2. These two PE routers are
MP-BGP neighbors:
Page 214 of 252

PE1#show ip bgp summary
BGP router identifier 2.2.2.2, local AS number 234
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down

State/PfxRcd
4.4.4.4 4 234 65 65 1 0 0 00:55:23
0
PE2#show ip bgp summary
BGP router identifier 4.4.4.4, local AS number 234
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down

State/PfxRcd
2.2.2.2 4 234 66 66 1 0 0 00:55:59
0
We can see the transport labels that are used between PE1 (2.2.2.2) and PE2 (4.4.4.4):
PE1#show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 3.3.3.3/32 0 Gi0/2 192.168.23.3
17 Pop Label 192.168.34.0/24 0 Gi0/2 192.168.23.3
18 17 4.4.4.4/32 0 Gi0/2 192.168.23.3
P#show mpls forwarding-table
16 Pop Label 2.2.2.2/32 8361 Gi0/1 192.168.23.2
17 Pop Label 4.4.4.4/32 8415 Gi0/2 192.168.34.4
PE2#show mpls forwarding-table
16 Pop Label 3.3.3.3/32 0 Gi0/2 192.168.34.3
17 16 2.2.2.2/32 0 Gi0/2 192.168.34.3
18 Pop Label 192.168.23.0/24 0 Gi0/2 192.168.34.3
Now let’s see if we can get IPv6 traffic over this network.
6PE
Let’s start with 6PE, this is where we use the global IPV6 routing table on the PE routers.
PE Routers
Let’s start with PE1. There are a couple of things I need to do:
 Configure the CE1 router as a neighbor.

 Activate the CE1 router under the IPv6 address-family.
 Activate the PE2 router under the IPv6 address-family.
 Send labels for IPv6 prefixes to the PE2 router.
Page 215 of 252

Let’s configure all of this:
PE1(config)#ipv6 unicast-routing
PE1(config)#router bgp 234

PE1(config-router)#neighbor 2001:DB8:0:12::1 remote-as 1
PE1(config-router)#address-family ipv6
PE1(config-router-af)#neighbor 2001:DB8:0:12::1 activate
PE1(config-router-af)#neighbor 4.4.4.4 activate
PE1(config-router-af)#neighbor 4.4.4.4 send-label
On the PE2 router, we do the exact same thing:

PE2(config-router)#neighbor 2001:DB8:0:45::5 remote-as 5
PE2(config-router)#address-family ipv6
PE2(config-router-af)#neighbor 2.2.2.2 send-label
This completes the configuration of the PE routers.
CE Routers
The configuration of the CE routers is pretty straightforward. We configure MP-BGP for IPv6
and advertise the IPv6 prefix on the loopback interface. Let’s start with CE1:
CE1(config)#router bgp 1
CE1(config-router)#bgp router-id 1.1.1.1
CE1(config-router)#neighbor 2001:DB8:0:12::2 remote-as 234
CE1(config-router)#address-family ipv6
CE1(config-router-af)#neighbor 2001:DB8:0:12::2 activate
CE1(config-router-af)#network 2001:DB8:1:1::1/128
The configuration of CE2 is the same as CE1:
That completes our configuration.
Page 216 of 252

Verification
Let’s verify our work. Let’s start with the PE routers to see if MP-BGP has exchanged any
prefixes:
PE1#show bgp ipv6 unicast

internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
RPKI validation codes: V valid, I invalid, N Not found

*> 2001:DB8:1:1::1/128
2001:DB8:0:12::1
0 0 1 i
*>i 2001:DB8:5:5::5/128
::FFFF:4.4.4.4 0 100 0 5 i
We see two entries on the PE router. The 2001:DB8:1:1::1/128 prefix we learned from CE1 and
the 2001:DB8:5:5::5/128 prefix we learned from PE2. Take a good look at the next hop address
for that second prefix, it has IPv4 address 4.4.4.4 embedded in it.
4.4.4.4 is the IPv4 address on the loopback of the PE2 router which is used for our LSP. This is
how the PE1 router is able to figure out what LSP to use if it wants to reach
2001:DB8:5:5::5/128.
Let’s take a closer look at this prefix:
PE1#show bgp ipv6 unicast 2001:DB8:5:5::5/128

BGP routing table entry for 2001:DB8:5:5::5/128, version 6
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
5
::FFFF:4.4.4.4 (metric 3) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
mpls labels in/out nolabel/19
rx pathid: 0, tx pathid: 0x0
Above, we see the next hop again but also the VPN label (19) that is used to reach this prefix.
You can also use the show bgp ipv6 unicast labels command to see the labels that are used:
PE1#show bgp ipv6 unicast labels

Network Next Hop In label/Out label
2001:DB8:1:1::1/128
2001:DB8:0:12::1
19/nolabel
2001:DB8:5:5::5/128
Page 217 of 252

::FFFF:4.4.4.4 nolabel/19
With 6PE, prefixes are installed in the global IPv6 routing table. Let’s take a look:
PE1#show ipv6 route bgp

B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FEEA:B8E3, GigabitEthernet0/1
B 2001:DB8:5:5::5/128 [200/0]
via 4.4.4.4%default, indirectly connected
Above, we see the two prefixes in the global IPv6 routing table. Let’s take a look at the PE2
router:
PE2#show bgp ipv6 unicast

internal,

*>i 2001:DB8:1:1::1/128
::FFFF:2.2.2.2 0 100 0 1 i
*> 2001:DB8:5:5::5/128
2001:DB8:0:45::5
0 0 5 i
PE2 uses ::FFFF:2:2:2:2 as the next hop address for 2001:DB8:1:1::1/128. That’s the IPv4
address on the loopback interface of the PE1 router, that is used for the LSP.
Let’s take a closer look at the 2001:DB8:1:1::1/128 prefix:
PE2#show bgp ipv6 unicast 2001:DB8:1:1::1/128

BGP routing table entry for 2001:DB8:1:1::1/128, version 3
Paths: (1 available, best #1, table default)
3
Refresh Epoch 1
1
::FFFF:2.2.2.2 (metric 3) from 2.2.2.2 (2.2.2.2)
Above, we see the VPN label (19) that is used.
PE2#show bgp ipv6 unicast labels

2001:DB8:1:1::1/128
Page 218 of 252

2001:DB8:5:5::5/128
2001:DB8:0:45::5
19/nolabel
Let’s check the global routing table:
PE2#show ipv6 route bgp

B 2001:DB8:1:1::1/128 [200/0]
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FEC3:25CB, GigabitEthernet0/1
The PE routers look good, everything we need is there. Let’s take a look at the CE routers:
CE1#show ipv6 route bgp
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FE44:53EA, GigabitEthernet0/1
B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FE4C:A56C, GigabitEthernet0/1
Each CE router has a BGP route. Let’s see if we can ping from one loopback interface to
another:

!!!!!
Our ping is successful, if we want to see the labels then we can use a traceroute:
CE1#traceroute
Protocol [ip]: ipv6
Target IPv6 address: 2001:DB8:5:5::5
Source address: 2001:DB8:1:1::1
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]: 1
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [0]:
Tracing the route to 2001:DB8:5:5::5
1 2001:DB8:0:12::2 7 msec
Page 219 of 252

2 ::FFFF:192.168.23.3 [MPLS: Labels 17/19 Exp 0] 12 msec
3 2001:DB8:0:45::4 [MPLS: Label 19 Exp 0] 9 msec
4 2001:DB8:0:45::5 8 msec
This is looking good. We see the VPN label (19) and the transport label (17) in this output.
hostname CE1
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
ip address 10.255.1.146 255.255.0.0
!
ipv6 address 2001:DB8:0:12::1/64
ipv6 enable
!
router bgp 1
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8:1:1::1/128
exit-address-family
!
end
hostname CE2
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
ipv6 address 2001:DB8:0:45::5/64
!
router bgp 5
Page 220 of 252

!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8:5:5::5/128
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
ip cef
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ipv6 address 2001:DB8:0:12::2/64
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
Page 221 of 252

!
address-family ipv4
exit-address-family
!
address-family ipv6
neighbor 4.4.4.4 send-label
exit-address-family
!
end
hostname PE2
!
ip cef
ipv6 cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
ipv6 address 2001:DB8:0:45::4/64
!
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
address-family ipv6
neighbor 2.2.2.2 send-label
exit-address-family
!
end
Page 222 of 252

6VPE
Now let’s try the 6VPE configuration. I’ll use the same startup configuration I showed in the
beginning of this lesson.
PE Routers
6VPE uses VRFs so that’s the first thing I am going to configure. We’ll create a VRF called
“CUSTOMER” and use RD 1:1:
PE1(config)#vrf definition CUSTOMER

PE1(config-vrf)#rd 1:1
PE1(config-vrf)#address-family ipv6
PE1(config-vrf-af)#route-target both 1:1
PE1(config)#interface GigabitEthernet 0/1

PE1(config-if)#vrf forwarding CUSTOMER
PE1(config-if)#ipv6 address 2001:DB8:0:12::2/64
Make sure IPv6 unicast routing is enabled before you configure MP-BGP:
Now we can configure MP-BGP. I need to enable the VPNv6 address family and activate the
PE2 router. We also need to configure the CE router as a neighbor under the VRF:[teaser]

PE1(config-router)#address-family vpnv6
PE1(config-router-af)#neighbor 4.4.4.4 send-community extended
PE1(config-router)#address-family ipv6 vrf CUSTOMER

PE1(config-router-af)#neighbor 2001:DB8:0:12::1 remote-as 1
Unlike the 6PE configuration, we don’t need to add the “send-label” command since this is
already the default for the VPN address-families. Let’s configure the same on the PE2 router:
PE2(config)#vrf definition CUSTOMER

PE2(config-vrf)#rd 1:1
PE2(config-vrf)#address-family ipv6
PE2(config-vrf-af)#route-target both 1:1
PE2(config)#interface GigabitEthernet 0/1

PE2(config-if)#vrf forwarding CUSTOMER
PE2(config-if)#ipv6 address 2001:DB8:0:45::4/64
Page 223 of 252

PE2(config-router)#address-family vpnv6
PE2(config-router-af)#neighbor 2.2.2.2 send-community extended
PE2(config-router)#address-family ipv6 vrf CUSTOMER

PE2(config-router-af)#neighbor 2001:DB8:0:45::5 remote-as 5
This completes the configuration of the PE routers.
CE Routers
The CE routers use the same configuration as for 6PE. We need to enable IPv6 unicast routing,
enable MP-BGP, become neighbors with the PE router, and advertise the prefix on the loopback:
We do the same thing on the CE2 router:
That’s all we need.
Verification
Let’s verify our work. Let’s start with the VRFs:
PE1#show vrf ipv6 CUSTOMER

Name Default RD Protocols
Interfaces
CUSTOMER 1:1 ipv6 Gi0/1
PE2#show vrf ipv6 CUSTOMER
Name Default RD Protocols
Interfaces
CUSTOMER 1:1 ipv6 Gi0/1
Page 224 of 252

We can see that the VRFs support IPv6 and that the GigabitEthernet 0/1 interfaces use our VRF
CUSTOMER.
Let’s see if the PE routers have anything in the BGP table for the VRF:
PE1#show bgp vpnv6 unicast vrf CUSTOMER

internal,

Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*> 2001:DB8:1:1::1/128
2001:DB8:0:12::1
0 0 1 i
*>i 2001:DB8:5:5::5/128
::FFFF:4.4.4.4 0 100 0 5 i
The output above is similar to what we have seen with the 6PE configuration. The difference is
that we now see the RD that is included with the prefix. The PE1 router uses 4.4.4.4 as the next
hop to reach 2001:DB8:5:5::5/128.
Here’s the output of PE2:
PE2#show bgp vpnv6 unicast vrf CUSTOMER

internal,

Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*>i 2001:DB8:1:1::1/128
::FFFF:2.2.2.2 0 100 0 1 i
*> 2001:DB8:5:5::5/128
2001:DB8:0:45::5
0 0 5 i
PE2 uses 2.2.2.2 as the next hop to reach 2001:DB8:1:1::1/128.
Let’s take a closer look at those prefixes, see what labels we find:
PE1#show bgp vpnv6 unicast vrf CUSTOMER 2001:DB8:5:5::5/128

BGP routing table entry for [1:1]2001:DB8:5:5::5/128, version 9
Paths: (1 available, best #1, table CUSTOMER)
Page 225 of 252

2
Refresh Epoch 1
5
::FFFF:4.4.4.4 (metric 3) (via default) from 4.4.4.4 (4.4.4.4)
Extended Community: RT:1:1
PE1 uses VPN label 19 for 2001:DB8:5:5::5/128. Here’s PE2:
PE2#show bgp vpnv6 unicast vrf CUSTOMER 2001:DB8:1:1::1/128

BGP routing table entry for [1:1]2001:DB8:1:1::1/128, version 8
Paths: (1 available, best #1, table CUSTOMER)
2
Refresh Epoch 1
1
::FFFF:2.2.2.2 (metric 3) (via default) from 2.2.2.2 (2.2.2.2)
Extended Community: RT:1:1
PE2 uses VPN label 19 to reach 2001:DB8:1:1::1/128. You can also use the show bgp vpnv6
unicast all labels command to get a quick overview:
PE1#show bgp vpnv6 unicast all labels

Route Distinguisher: 1:1 (CUSTOMER)
2001:DB8:1:1::1/128
2001:DB8:0:12::1
19/nolabel
2001:DB8:5:5::5/128
PE2#show bgp vpnv6 unicast all labels
Route Distinguisher: 1:1 (CUSTOMER)
2001:DB8:1:1::1/128
2001:DB8:5:5::5/128
2001:DB8:0:45::5
19/nolabel
Let’s take a look at the routing tables for the CUSTOMER VRF to see if the prefixes got
installed:
PE1#show ipv6 route vrf CUSTOMER bgp
B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FE75:5CA5, GigabitEthernet0/1
B 2001:DB8:5:5::5/128 [200/0]
PE2#show ipv6 route vrf CUSTOMER bgp
Page 226 of 252

B 2001:DB8:1:1::1/128 [200/0]
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FE7A:CAE2, GigabitEthernet0/1
The PE routing tables are filled with the IPv6 prefixes. Let’s check the CE routers:
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FE77:CDEB, GigabitEthernet0/1
B 2001:DB8:1:1::1/128 [20/0]
via FE80::F816:3EFF:FE7F:A9E, GigabitEthernet0/1
The CE routers have learned each other’s prefix. Let’s try a quick ping:

!!!!!
That’s looking good. Here’s a Wireshark capture of an ICMP request from CE1 to CE2:
IPv6 over MPLS 6VPE
We can also see the labels with a traceroute:
CE1#traceroute
Protocol [ip]: ipv6
Target IPv6 address: 2001:DB8:5:5::5
Source address: 2001:DB8:1:1::1
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]: 1
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Page 227 of 252

Port Number [0]:
Tracing the route to 2001:DB8:5:5::5
1 2001:DB8:0:12::2 6 msec
2 ::FFFF:192.168.23.3 [MPLS: Labels 17/19 Exp 0] 11 msec
3 2001:DB8:0:45::4 [MPLS: Label 19 Exp 0] 7 msec
4 2001:DB8:0:45::5 12 msec
This is looking good, we see VPN label 19 and transport label 17.
hostname CE1
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
ip address 10.255.1.152 255.255.0.0
!
ipv6 address 2001:DB8:0:12::1/64
!
router bgp 1
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8:1:1::1/128
exit-address-family
!
end
hostname CE2
!
ip cef
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
ipv6 address 2001:DB8:0:45::5/64
Page 228 of 252

!
router bgp 5
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001:DB8:5:5::5/128
exit-address-family
!
end
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
ip address 192.168.23.3 255.255.255.0
!
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname PE1
!
vrf definition CUSTOMER
rd 1:1
!
address-family ipv6
route-target export 1:1
route-target import 1:1
exit-address-family
!
ip cef
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
Page 229 of 252

vrf forwarding CUSTOMER
ipv6 address 2001:DB8:0:12::2/64
!
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
mpls ldp autoconfig
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
address-family vpnv6
neighbor 4.4.4.4 send-community extended
exit-address-family
!
address-family ipv6 vrf CUSTOMER
exit-address-family
!
end
hostname PE2
!
vrf definition CUSTOMER
rd 1:1
!
address-family ipv6
route-target export 1:1
route-target import 1:1
exit-address-family
!
ip cef
ipv6 cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
vrf forwarding CUSTOMER
ipv6 address 2001:DB8:0:45::4/64
!
ip address 192.168.34.4 255.255.255.0
Page 230 of 252

!
router ospf 1
mpls ldp autoconfig
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
!
router bgp 234
!
address-family ipv4
exit-address-family
!
address-family vpnv6
neighbor 2.2.2.2 send-community extended
exit-address-family
!
address-family ipv6 vrf CUSTOMER
exit-address-family
!
end
Conclusion
You have now learned how you can run IPv6 over an IPv4-only MPLS core with 6PE and 6VPE:
 The core of the MPLS network is IPv4-only.

 The PE routers are dual stack.
 6PE uses the global IPv6 routing table.
 6VPE uses VRFs.
 How to configure both 6PE and 6VPE.
 How to verify 6PE and 6VPE.
IPv6 over IPv4 GRE with IPSec

IPV6 over IPV4 GRE with IPSec allows us to securely transport IPv6 unicast and multicast
packets over an IPv4 network. We use GRE to tunnel all IPv6 packets since IPSec does not
support multicast. We do use IPSec to encrypt the entire GRE tunnel.
In this lesson, I’ll show you how to configure a GRE tunnel between two routers, encrypt it with
IPSec, and run OSPFv3 to prove that we can transmit both IPv6 unicast and multicast packets.
Page 231 of 252

Configuration
I only need two routers to demonstrate this. R1 and R2 use IPv4 addresses on the Gigabit
interfaces. Each router has a loopback interface with an IPv6 address that we will advertise in
OSPFv3.
R1
Let’s start with R1. First, we’ll enable IPv6 unicast routing:
Now we can create the tunnel interface:
R1(config-if)#tunnel source GigabitEthernet 0/1
The tunnel mode is “gre ip”. I added an IPv6 unicast address even though technically we don’t
need it (OSPFv3 uses link-local addresses for the neighbor adjacency). But, it gives us an easy to
remember IPv6 address that we can use to quickly test our tunnel.
Let’s encrypt the GRE tunnel. We need an ISAKMP policy:
R1(config)#crypto isakmp policy 10

R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#hash md5
R1(config-isakmp)#group 2
R1(config-isakmp)#encryption aes
Page 232 of 252

Let’s configure a pre-shared key:
R1(config)#crypto isakmp key R1_R2_KEY address 192.168.12.2
We need a transform-set:
R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET ah-sha-hmac esp-aes
And an access-list that defines the traffic that we want to encrypt. We are going to encrypt all
GRE traffic:
R1(config)#ip access-list extended R1_R2_GRE

R1(config-ext-nacl)#permit gre host 192.168.12.1 host 192.168.12.2
Last but not least, we need a crypto map that pulls everything together and we activate it on the
physical interface:
R1(config)#crypto map MY_CRYPTO_MAP 10 ipsec-isakmp

R1(config-crypto-map)#set peer 192.168.12.2
R1(config-crypto-map)#set transform-set MY_TRANSFORM_SET
R1(config-crypto-map)#match address R1_R2_GRE

R1(config-if)#crypto map MY_CRYPTO_MAP
That completes the tunnel and IPSec configuration. Let’s add OSPFv3 to advertise the prefixes
on the loopback and tunnel interface:

R1(config)#interface Loopback 0
R1(config-if)#ipv6 ospf 1 area 0/code>
That’s all we need.
R2
We configure the exact same thing on R2:
R2(config-if)#tunnel source GigabitEthernet 0/1
Page 233 of 252

R2(config)#crypto isakmp policy 10
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#hash md5
R2(config-isakmp)#group 2
R2(config-isakmp)#encryption aes
R2(config-isakmp)#exit
R2(config)#crypto isakmp key R1_R2_KEY address 192.168.12.1
R2(config)#crypto ipsec transform-set MY_TRANSFORM_SET ah-sha-hmac esp-aes
R2(config)#ip access-list extended R1_R2_GRE

R2(config-ext-nacl)#permit gre host 192.168.12.2 host 192.168.12.1
R2(config)#crypto map MY_CRYPTO_MAP 10 ipsec-isakmp

R2(config-crypto-map)#set peer 192.168.12.1
R2(config-crypto-map)#set transform-set MY_TRANSFORM_SET
R2(config-crypto-map)#match address R1_R2_GRE
R
R2(config-if)#crypto map MY_CRYPTO_MAP

R2(config)#interface Loopback 0
That’s it.
Verification
Let’s verify our work. First, I’ll do a quick ping using the IPv6 addresses on the tunnel
interfaces:[teaser]
R1#ping 2001:DB8:0:12::2
!!!!!
The ping is working which at least proves that the tunnel interfaces are up and running. Let’s
take a closer look at the tunnel:
R1#show interfaces Tunnel 0

Hardware is Tunnel
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
Page 234 of 252

Keepalive not set
Tunnel linestate evaluation up
Tunnel source 192.168.12.1 (GigabitEthernet0/1), destination 192.168.12.2
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with GigabitEthernet0/1
Set of tunnels with source GigabitEthernet0/1, 1 member (includes
iterators), on interface
Tunnel protocol/transport GRE/IP
[output omitted]
The tunnel is up and the tunnel mode is GRE/IP. Let’s check if we have an IPSec phase 1
security association:
R1#show crypto isakmp sa

IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.12.2 192.168.12.1 QM_IDLE 1001 ACTIVE
This is looking good. Let’s take a look at IPSec phase 2 and see if any packets are encrypted or
not:
interface: GigabitEthernet0/1
Crypto map tag: MY_CRYPTO_MAP, local addr 192.168.12.1

local ident (addr/mask/prot/port): (192.168.12.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (192.168.12.2/255.255.255.255/47/0)
current_peer 192.168.12.2 port 500
local crypto endpt.: 192.168.12.1, remote crypto endpt.: 192.168.12.2

plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb
GigabitEthernet0/1
[output omitted]
Above, we see number 47 which is the protocol number for GRE. We also see that packets are
encrypted and decrypted so this is looking good. Let’s check if there is an OSPFv3 neighbor
adjacency:
Page 235 of 252

2.2.2.2 0 FULL/ - 00:00:32 9 Tunnel0
R1 sees R2 as a neighbor, which tells us that multicast packets over the GRE tunnel are working.
Let’s see what we have in the IPv6 routing tables:
O 2001:DB8:2:2::2/128 [110/1000]
via FE80::5C00:FF:FE01:0, Tunnel0
O 2001:DB8:1:1::1/128 [110/1000]
via FE80::5C00:FF:FE00:0, Tunnel0
Our routers have learned about the IPv6 addresses of each other’s loopback interfaces. Let’s try a
quick ping:
R1#ping 2001:DB8:2:2::2 source 2001:DB8:1:1::1

!!!!!
We are able to ping from one loopback to another.
hostname R1
!
ip cef
ipv6 cef
!
crypto isakmp policy 10
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key R1_R2_KEY address 192.168.12.2
!
crypto ipsec transform-set MY_TRANSFORM_SET ah-sha-hmac esp-aes
mode tunnel
!
crypto map MY_CRYPTO_MAP 10 ipsec-isakmp
set peer 192.168.12.2
set transform-set MY_TRANSFORM_SET
match address R1_R2_GRE
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
ipv6 ospf 1 area 0
Page 236 of 252

!
interface Tunnel0
ipv6 address 2001:DB8:0:12::1/64
ipv6 ospf 1 area 0
!
ip address 192.168.12.1 255.255.255.0
crypto map MY_CRYPTO_MAP
!
ip access-list extended R1_R2_GRE
permit gre host 192.168.12.1 host 192.168.12.2
!
ipv6 router ospf 1
router-id 1.1.1.1
!
end
hostname R2
!
ip cef
ipv6 cef
!
crypto isakmp policy 10
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key R1_R2_KEY address 192.168.12.1
!
crypto ipsec transform-set MY_TRANSFORM_SET ah-sha-hmac esp-aes
mode tunnel
!
crypto map MY_CRYPTO_MAP 10 ipsec-isakmp
set peer 192.168.12.1
set transform-set MY_TRANSFORM_SET
match address R1_R2_GRE
!
interface Loopback0
ipv6 address 2001:DB8:2:2::2/128
ipv6 ospf 1 area 0
!
interface Tunnel0
ipv6 address 2001:DB8:0:12::2/64
ipv6 ospf 1 area 0
!
ip address 192.168.12.2 255.255.255.0
crypto map MY_CRYPTO_MAP
!
ip access-list extended R1_R2_GRE
permit gre host 192.168.12.2 host 192.168.12.1
Page 237 of 252

!
ipv6 router ospf 1
router-id 2.2.2.2
!
end
Conclusion
You have now learned how to run IPv6 over an IPv4 network with GRE and IPSec. I hope you
enjoyed this lesson. If you have any questions feel free to leave a comment!
Cisco NAT64 Static Configuration

In this lesson we’ll take a look how to configure NAT64 so that an IPv4 host can communicate
with an IPv6 host. Here’s the topology I will use:
On the left side we have R1 where we use IPv4, on the right side we use R3 which only uses
IPv6.
R2 in the middle will be configured for static NAT64 so that these two routers can communicate
with each other.
NAT64 is a bit more complicated than “regular” NAT that you know from IPv4. When we use
IPv4 NAT for internet connectivity then you only need to translate the source address, with
NAT64 we have to translate everything.
When we send a packet from R1 to R3, what destination address will we use? R1 only
understands IPv4 and R3 only understands IPv6.
To make this work, R1 needs to think it’s talking to an IPv4 address and R3 needs to think it’s
talking with an IPv6 address. We’ll need some “mapping” between addresses and protocols on
our NAT64 router.
Let’s take a look how it works…
Configuration
I will configure everything from scratch, let’s start with the interfaces:
Page 238 of 252


That’s all we need. R2 will require unicast routing or it won’t do any NAT64 at all:
R3 will require a default route to R2, you’ll see why when we configure NAT64:
R3(config)#ipv6 route ::/0 2001:DB8:2323:2323::2
Before we configure NAT64, let’s do a quick test to make sure R2 can reach both routers:
R2#ping 192.168.12.1
!!!!!
R2#ping 2001:DB8:2323:2323::3
!!!!!
So far so good, now we can enable NAT64. First we have to enable it on the interfaces:

R2(config-if)#nat64 enable
R2(config-if)#nat64 enable
Once you enable this you will see a syslog message that tells us that a virtual interface has been
created:
%LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up
Now we can configure the actual translation rules. We will use a fake IPv4 address that R1 can
use as its destination and a fake IPv6 address that R3 can use as its destination.
IANA has allocated prefix 64:FF9B::/96 for NAT64 translations. When R2 receives anything
that starts with this prefix then it will be processed by NAT64. We can use this prefix or we can
use another one, I’ll show you how to choose your own prefix:
R2(config)#nat64 prefix stateful 3001::/96
Page 239 of 252

Now we can use prefix 3001::/96 for our translation.
Let’s configure the actual translation rule:[teaser]
R2(config)#nat64 v6v4 static 2001:DB8:2323:2323::3 192.168.12.3
This tells R2 that whenever we receive an IPv4 packet with destination address 192.168.12.3 that
it has to be translated and forwarded to 2001:DB8:2323:2323::3. Let’s see if this works…
Verification
Before I try some pings, let’s enable a debug. This allows us to see what source and destination
addresses are used:
R1#debug ip icmp
ICMP packet debugging is on
R3#debug ipv6 icmp
ICMP Packet debugging is on
Now let’s send a ping from R1 to our fake IPv4 destination address:
R1#ping 192.168.12.3
!!!!!
Great it’s working, the debugs tell us what addresses were used:
R1#
ICMP: echo reply rcvd, src 192.168.12.3, dst 192.168.12.1, topology BASE, dscp
0 topoid 0
R1 thinks it received a packet from 192.168.12.3. What about R3?
R3#
ICMPv6: Received echo request, Src=3001::C0A8:C01, Dst=2001:DB8:2323:2323::3
ICMPv6: Sent echo reply, Src=2001:DB8:2323:2323::3, Dst=3001::C0A8:C01
R3 thinks it’s talking with 3001::C0A8:C01. Where did this address come from? The first part
looks familiar, that’s the 3001::/96 prefix that we configured. The last part is the IPv4 address of
R1 in hexadecimal:
 C0 = 192
 A8 = 168
 C = 12
 1=1
Page 240 of 252

In case you are wondering, this works in both directions:
R3#ping 3001::C0A8:C01
Sending 5, 100-byte ICMP Echos to 3001::C0A8:C01, timeout is 2 seconds:
!!!!!
We can also use some show commands on R2 to verify things:
R2#show nat64 mappings static
Static mappings configured: 1
Direction Protocol Address (Port, if any)

Non-key Address (Port, if any)
RG ID Mapping ID Is Valid
v6v4 --- 2001:DB8:2323:2323::3

192.168.12.3
0 0 FALSE
Above you can see what we have configured. The next show command is a bit more interesting:
R2#show nat64 statistics

NAT64 Statistics
Total active translations: 1 (1 static, 0 dynamic; 0 extended)

Sessions found: 90
Sessions created: 13
Expired translations: 13
Global Stats:
Packets translated (IPv4 -> IPv6)
Stateless: 0
Stateful: 63
MAP-T: 0
Stateless: 0
Stateful: 40
MAP-T: 0
Interface Statistics
FastEthernet0/0 (IPv4 configured, IPv6 not configured):
Stateless: 0
Stateful: 63
MAP-T: 0
Stateless: 0
Stateful: 0
MAP-T: 0
Packets dropped: 0
FastEthernet1/0 (IPv4 not configured, IPv6 configured):
Stateless: 0
Page 241 of 252

Stateful: 0
MAP-T: 0
Stateless: 0
Stateful: 40
MAP-T: 0
Packets dropped: 10
Dynamic Mapping Statistics
v6v4
Limit Statistics
The output above shows us how many translations were done and in what direction. The last
show command is the most interesting one:
R2#show nat64 translations
Proto Original IPv4 Translated IPv4

Translated IPv6 Original IPv6
----------------------------------------------------------------------------
--- --- ---

192.168.12.3 2001:db8:2323:2323::3
icmp 192.168.12.1:15 [3001::c0a8:c01]:15
192.168.12.3:15 [2001:db8:2323:2323::3]:15
Total number of translations: 2
Above you can see the dynamically created 3001::C0A8:C01 address that was created.
Conclusion
NAT64 can be pretty complex and this is one of those “last resort” methods. You should
probably always use dual stack and/or tunneling instead of trying to translate entire protocols.
hostname R1
!
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
end
hostname R2
!
!
Page 242 of 252

ip address 192.168.12.2 255.255.255.0
negotiation auto
nat64 enable
!
no ip address
negotiation auto
nat64 enable
ipv6 address 2001:DB8:2323:2323::2/64
!
nat64 prefix stateful 3001::/96
nat64 v6v4 static 2001:DB8:2323:2323::3 192.168.12.3
!
end
hostname R3
!
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:2323:2323::3/64
!
ipv6 route ::/0 2001:DB8:2323:2323::2
!
end
IPv6 NPTv6 (Network Prefix Translation)

NPTv6 stands for Network Prefix Translation and like NAT it allows the translation of IPv6.
The difference, however, is that NPTv6 only translates prefixes. It doesn’t translate the host
address, there is no “overload” like NAT where you can have multiple source addresses behind a
single address. It’s a simple 1:1 translation for prefixes.
There are plenty of global IPv6 addresses so why would you want to use NPTv6? Here are two
reasons:
 Address independence: you don’t have to change your IPv6 prefixes on your local
network when your global IPv6 prefix changes. On the other hand, IPv6 renumbering is
not so bad compared to IPv4.
 ULAs (Unique Local Addresses): NPTv6 translates the prefix in your ULAs to a global
prefix that is routable on the Internet.
 Access-lists: Your host has two IPv6 addresses and only one of them is permitted through
some firewall. Your host won’t know which source address is permitted through the
firewall so by using NPTv6, you can translate the address to a prefix that is permitted
through the firewall.
Page 243 of 252

Configuration
Let’s see how we configure NPTv6. I’ll use this topology:
What do we have?
 H1 is a host on our internal network.

 NPTv6 is the router where we configure NPTv6.
 H3 is some host on the Internet.
The 2001:DB8:0:2::/64 prefix on the loopback 0 interface of NPTv6 is the global prefix that we
want to translate to.
I pre-configured my devices with IPv6 addresses and static routes so that we have reachability
between H1 and H3.
hostname H1
!
ipv6 cef
!
ipv6 address 2001:DB8:0:12::1/64
!
ipv6 route ::/0 2001:DB8:0:12::2
!
end
hostname H3
!
ipv6 cef
!
ipv6 address 2001:DB8:0:23::3/64
!
Page 244 of 252

ipv6 route ::/0 2001:DB8:0:23::2
!
end
hostname NPTV6
!
!
interface Loopback0
ipv6 address 2001:DB8:0:2::2/64
!
interface GigabitEthernet2
ipv6 address 2001:DB8:0:12::2/64
!
ipv6 address 2001:DB8:0:23::2/64
!
end
Let’s get started. We first need to define the inside and outside interfaces:
NPTV6(config)#interface GigabitEthernet 2
NPTV6(config-if)#nat66 inside
NPTV6(config)#interface GigabitEthernet 3
NPTV6(config-if)#nat66 outside
The second (and last) thing to do is to tell the router what the inside and outside prefixes are:
NPTV6(config)#nat66 prefix inside 2001:DB8:0:12::/64 outside 2001:DB8:0:2::/64
The inside prefix is the link that we use between H1 and NPTv6, the outside prefix is the one on
the loopback 0 interface. That’s all we have to configure.
Verification
There are only two show commands. Here’s the first one:
NPTV6#show nat66 prefix
Prefixes configured: 1
NAT66 Prefixes
Id: 1 Inside 2001:DB8:0:12::/64 Outside 2001:DB8:0:2::/64
This shows us the prefixes that we configured. Let’s try a quick ping from H1:
H1#ping 2001:DB8:0:23::3
Page 245 of 252

!!!!!
The ping works but it doesn’t tell me if the prefix is translated. There’s another command for
that:[teaser]
NPTV6#show nat66 statistics

NAT66 Statistics
Global Stats:
Packets translated (In -> Out)
: 5
Packets translated (Out -> In)
: 5
Interface Statistics
GigabitEthernet2 (IPv4 configured, IPv6 configured):
: 0
: 0
Packets dropped: 0
GigabitEthernet3 (IPv4 configured, IPv6 configured):
: 0
: 0
Packets dropped: 0
This tells us that 5 inbound and outbound packets have been translated. To see it in action, it’s
best to look at the actual packets with a capture:
IPv6 NPTv6
Page 246 of 252

Above, we see the packet from H1 to H3 where 2001:DB8:0:12::1/64 got translated to
2001:DB8:0:2::1/64.
Why did I use a loopback with a prefix instead of prefix 2001:DB8:0:23::/64 (the link between NPTv6 and
H3)? I tried this the first time but it doesn’t work because H3 will do a neighbor solicitation for
2001:DB8:0:23::1/64 (the translated address). Since nobody responds to that address, the ping fails.
hostname H1
!
ipv6 cef
!
ipv6 address 2001:DB8:0:12::1/64
!
ipv6 route ::/0 2001:DB8:0:12::2
!
end
hostname H3
!
ipv6 cef
!
ipv6 address 2001:DB8:0:23::3/64
!
ipv6 route ::/0 2001:DB8:0:23::2
!
end
hostname NPTV6
!
!
interface Loopback0
ipv6 address 2001:DB8:0:2::2/64
!
nat66 inside
ipv6 address 2001:DB8:0:12::2/64
!
nat66 outside
ipv6 address 2001:DB8:0:23::2/64
!
nat66 prefix inside 2001:DB8:0:12::/64 outside 2001:DB8:0:2::/64
!
end
Page 247 of 252

This is how we verify it works.
Conclusion
You have now learned how to translate the IPv6 prefix by using NPTv6. If you want more detail,
you can always check out RFC 6296
IPv6 Multicast BSR and RP Example

Multicast for IPv6 can be configured using static RPs, BSR or embedded RP. In this example I
want to show you how to configure IPv6 multicast using BSR. This is the topology that I will
use:
Above we have 3 routers. R1 will be the receiver of the multicast stream, R2 will be the BSR and
R3 will be the RP. First we’ll have to do our homework and configure all IPv6 addresses on the
interfaces:
R1(config-if)#ipv6 address 2001:12::1/64
R2(config-if)#exit
R2(config-if)#exit R2(config)#interface loopback 0 R2(config-if)#ipv6 address
2001::2/128
R3(config-if)#exit
Page 248 of 252

With the IPv6 addresses up and running we can configure EIGRP to advertise the loopback
interfaces of R2/R3 and the 2001:12::/64 network between R1/R2:

R2(config-if)#exit
R2(config-if)#exit
R3(config-if)#exit
Because I don’t have any IPv4 addresses I have to configure an EIGRP router ID myself. With
the configuration above the 2001:12::/64, 2001::2/128 and 2001::3/128 networks should be
reachable from any router. Now we can continue with our multicast setup:
R1,R2 & R3:

(config)#ipv6 multicast-routing
First enable multicast routing for IPv6 or we are going nowhere. Next step is to configure the RP
and BSR:
R3(config)#ipv6 pim bsr candidate rp 2001::3
Use the ipv6 pim bsr candidate rp command to advertise R3 as the Rendezvous Point…
R2(config)#ipv6 pim bsr candidate bsr 2001::2
And R2 as the BSR…now we’ll configure R1 to join a multicast group, I’ll use FF07::7 for this
example:

R1(config-if)#ipv6 mld join-group FF07::7
Let’s see if R2 has found the RP:
Page 249 of 252

R2#show ipv6 pim bsr rp-cache
PIMv2 BSR C-RP Cache
BSR Candidate RP Cache
Group(s) FF00::/8, RP count 1

RP 2001::3 SM
Priority 192, Holdtime 150
Uptime: 00:00:06, expires: 00:02:23
R2 sees R3 as the RP for the entire multicast group range. We can also take a look at the
multicast routing table:
R2#show ipv6 mroute

Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF07::7), 00:03:53/never, RP 2001::3, flags: SCJ

Incoming interface: FastEthernet0/1
RPF nbr: FE80::C006:23FF:FE22:0
Immediate Outgoing interface list:
FastEthernet0/0, Forward, 00:03:53/never
Above we see that R2 built a (*,G) entry for FF07::7 towards the RP. Let’s generate some
multicast traffic to see if it reaches R1:
R3#ping ff07::7
Sending 5, 100-byte ICMP Echos to FF07::7, timeout is 2 seconds:
Reply to request 0 received from 2001:12::1, 8 ms

5 multicast replies and 0 errors.
There we go…R3 receives a reply from R1.
hostname R1
!
ipv6 cef
!
Page 250 of 252

no ip address
ipv6 address 2001:12::1/64
ipv6 eigrp 1
ipv6 mld join-group FF07::7
!
ipv6 router eigrp 1
eigrp router-id 1.1.1.1
!
end
hostname R2
!
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 eigrp 1
!
no ip address
ipv6 enable
ipv6 eigrp 1
!
no ip address
ipv6 enable
ipv6 eigrp 1
!
no ip address
ipv6 enable
ipv6 eigrp 1
!
ipv6 pim bsr candidate bsr 2001::2
ipv6 router eigrp 1
!
end
Page 251 of 252

hostname R3
!
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 eigrp 1
!
no ip address
ipv6 enable
ipv6 eigrp 1
!
ipv6 pim bsr candidate rp 2001::3
ipv6 router eigrp 1
!
end
Page 252 of 252

IPv 6

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IPv 6

Caricato da

Copyright:

Formati disponibili

Table of Contents

Can we even pronounce this? Let’s try this:

X:X:X:X:X:X:X:X where X is a 16-bit hexadecimal field

Shortening IPv6 Addresses

There is more however, the address can be shortened even more:

By removing these zeros we get a nice short IPv6 address.

To summarize these rules:

How to find IPv6 Prefix

2001:1234:5678:1234:0000:0000:0000:0000/64 is a valid prefix but we can shorten it. This

That’s a good looking prefix but we can make it a little shorter:

First I have to determine in what “block” my 53rd bit is located:

IPv6 Address Types

 The prefix starts with FD.

Here’s what we’ll end up with:

 FE8 – 1111 1110 1000

 FF02::1 – all nodes on local network segment.

IPv6 Address Assignment Example

IPv6 Global Unicast Prefix Assignments

Let’s take a look at some actual prefixes:

IPv6 Global Unicast Subnet Assignments

IPv6 EUI-64 explained

Here’s what we will do to fill the missing bits:

1. We take the MAC address and split it into two pieces.

Router(config)#interface fastEthernet 0/0

Router#show interfaces fastEthernet 0/0 | include Hardware

IPv6 Summarization Example

That’s how you can create a summary address for IPv6.

IPv6 General Prefix

IPv6 address assignment

For example, let’s say we have the following global prefix:

And we use the following specific prefixes:

R1(config)#ipv6 general-prefix GLOBAL 2001:41F0:4060::/48

R1(config)#interface GigabitEthernet 0/1

R1(config)#interface GigabitEthernet 0/2

R1(config)#interface GigabitEthernet 0/3

R1(config)#interface GigabitEthernet 0/4

Let’s see what prefixes we ended up with:

R1#show ipv6 interface | include 2001

R1(config)#ipv6 general-prefix GLOBAL 2001:41F0:4070::/48

Once you do this, you’ll have two global prefixes:

R1#show running-config | include general

Which means we’ll have two prefixes on each interface:

R1#show ipv6 interface GigabitEthernet 0/1 | include 2001

R1(config)#no ipv6 general-prefix GLOBAL 2001:41F0:4060::/48

And it will be gone from all interfaces:

R1#show ipv6 interface | include 2001

IPv6 Solicited Node Multicast Address

 FF /8 is the IPv6 multicast range.

R1(config)#interface FastEthernet 0/0

R1#show ipv6 interface FastEthernet 0/0

R1(config)#interface FastEthernet 0/0

R1#show ipv6 interface FastEthernet 0/0

R1(config)#interface FastEthernet 0/0

R1#show ipv6 interface FastEthernet 0/0

The big question remains: why and where do we use it?

IPv6 Neighbor Discovery Protocol on Cisco

 Neighbor solicitation message

Let’s take closer look at these two messages.

IPv6 Neighbor Solicitation Message

IPv6 Neighbor Advertisement Message

First we will configure some IPv6 addresses on our routers:

R1#show ipv6 interface FastEthernet 0/0 | include FE80

Let’s send a ping from R1 to R2: