Professional Documents
Culture Documents
IPv 6
IPv 6
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
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:
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.
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.
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
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.
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::/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
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?
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…
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:
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]
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:
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.
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.
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…
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
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:
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:
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.
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
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
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.
2001:41f0:4060::/48
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”:
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:
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]
This can be useful. When you have verified that the old global prefix isn’t used anymore, we can
remove it:
That’s it!
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ip cef
ipv6 general-prefix GLOBAL 2001:41F0:4070::/48
!
interface GigabitEthernet0/1
ipv6 address GLOBAL ::1:0:0:0:1/64
!
interface GigabitEthernet0/2
ipv6 address GLOBAL ::2:0:0:0:1/64
Page 29 of 252
!
interface GigabitEthernet0/3
ipv6 address GLOBAL ::3:0:0:0:1/64
!
interface GigabitEthernet0/4
ipv6 address GLOBAL ::4:0:0:0:1/64
!
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.
All solicited node multicast group addresses start with FF02::1:FF /104:
Let’s take a look on a Cisco IOS router to see what these solicited node multicast group
addresses look like:
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:
Page 30 of 252
IPv6 is enabled, link-local address is FE80::21D:A1FF:FE8B:36D0
No Virtual link-local address(es):
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:
I’ll use EUI-64 to generate the last 64 bits. Take a look at the joined group addresses:
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]
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
No Virtual link-local address(es):
Global unicast address(es):
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
Joined group address(es):
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.
I’ll answer this with some examples in the IPv6 Neighbor Discovery lesson.
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:
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.
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:
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:
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
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
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:
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.
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:
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.
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
ICMP Neighbor Discovery events debugging is on
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.
And here is the proof that we have a fresh new IPv6 address on R1.
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:
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R2
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 address 2001:1234::/64 eui-64
!
end
hostname R1
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 address autoconfig
!
end
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?
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:
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
ICMP Neighbor Discovery events debugging is on
R1(config)#interface fa0/0
R1(config-if)#shutdown
R1(config-if)#no shutdown
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
ICMPv6-ND: Sending RS on FastEthernet0/0
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:
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:
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:
R2(config)#ipv6 unicast-routing
R1#
ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0
ICMPv6-ND: MTU = 1500
ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0
ICMPv6-ND: MTU = 1500
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:
R1#ping 2001::12:2
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.
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.
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:
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
ICMP Neighbor Discovery events debugging is on
Now we will configure the host to use the router advertisements for autoconfiguration:
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: MTU = 1500
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
ICMPv6-ND: MTU = 1500
ICMPv6-ND: prefix 2001:DB8:123:123::/64 [LA] 2592000/604800
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
FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1
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
ICMPv6-ND: [default] New router interface context created/C645C24
ICMPv6-ND: [default] inserted router
FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1
ICMPv6-ND: [default] Select default router
ICMPv6-ND: [default] best rank is 811
ICMPv6-ND: Prefix : 2001:DB8:123:123::, Length: 64, Vld Lifetime: 2592000, Prf
Lifetime: 604800, PI Flags: C0
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:
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
Router FE80::F816:3EFF:FE19:6D0 on GigabitEthernet0/1, last update 1 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium, trustlevel = 0
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:123:123::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
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: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RA
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] Select default router
ICMPv6-ND: [default] best rank is 811
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
ICMPv6-ND: [default] Selected new default router
ICMPv6-ND: [default] Install default to
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#
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RA
ICMPv6-ND: Validating ND packet options: valid
Page 46 of 252
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: Prefix : 2001:DB8:123:123::, Length: 64, Vld Lifetime: 2592000, Prf
Lifetime: 604800, PI Flags: C0
So does it select R2 as the new default router again? Let’s find out:
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:
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#
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
ICMPv6-ND: MTU = 1500
ICMPv6-ND: prefix 2001:DB8:123:123::/64 [LA] 2592000/604800
H1#
ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RA
ICMPv6-ND: [default] Select default router
ICMPv6-ND: [default] best rank is 819
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
ICMPv6-ND: [default] Selected new default router
ICMPv6-ND: [default] Install default to
FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1
Above you can see that the host now prefers R2 as the new default router and installs a default
route for it.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:123:123::1/64
!
end
hostname R2
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:123:123::2/64
ipv6 nd router-preference High
!
end
hostname H1
!
interface GigabitEthernet0/1
ipv6 address autoconfig
!
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.
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.
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!
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
Let’s configure the stateful pool, it is similar to doing this for IPv4:
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:
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.
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:
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:
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
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:
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:
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
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]
We have to change this on the interface level, same for the client:
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: 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'
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
IPv6 DHCP: Updating binding address entry for address
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: Source Address from SAS FE80::216:C7FF:FEBE:EC8
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!
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:
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: Source Address from SAS FE80::216:C7FF:FEBE:EC9
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:
Page 54 of 252
Preference: 0
Configuration parameters:
DNS server: 2001:4860:4860::8888
Domain name: NETWORKLESSONS.LOCAL
Information refresh time: 0
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled
That’s good, it learned about the DNS server and the domain name. What does the pool look like
on the server?
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname DHCPV6
!
ipv6 unicast-routing
!
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
domain-name NETWORKLESSONS.LOCAL
!
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
!
interface FastEthernet 0/1
ipv6 address 2001:2222:2222:2222::2/64
ipv6 dhcp server STATELESS
ipv6 nd other-config-flag
!
end
Page 55 of 252
hostname R1
!
interface FastEthernet 0/0
ipv6 enable
ipv6 address dhcp
!
end
hostname R2
!
interface FastEthernet 0/0
ipv6 enable
ipv6 address autoconfig
!
end
And that’s the end of this tutorial! You have seen stateful and stateless configuration and the
difference between normal and rapid mode.
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:
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
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.
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:
Customer Routers
C1
C1(config)#ipv6 unicast-routing
The interface that connects to the ISP router will use DHCP client:
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:
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
C2(config)#ipv6 unicast-routing
The only difference is that I use a different specific prefix (subnet) on this router.
Hosts
Verification
Let’s verify our work!
ISP
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
preferred lifetime 604800, valid lifetime 2592000
expires at Mar 22 2018 09:41 AM (2591328 seconds)
Client: FE80::F816:3EFF:FEC4:B7CB
DUID: 000300015E0000030000
Username : unassigned
VRF : default
Interface : GigabitEthernet0/1
IA PD: IA ID 0x00030001, T1 302400, T2 483840
Prefix: 2001:DB8:1101::/48
preferred lifetime 604800, valid lifetime 2592000
expires at Mar 22 2018 09:43 AM (2591430 seconds)
The output above is interesting as it tells us which prefixes the router assigned to the DHCP
clients.
Customers
C1
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:
We can also verify that the router has stored the prefix it received from the ISP:
C2
This is looking good. Here’s the IPv6 address that C2 configured on its GigabitEthernet0/1
interface:
Page 62 of 252
C2#show ipv6 interface GigabitEthernet 0/1 | include 2001
2001:DB8:0:1:F816:3EFF:FEC4:B7CB, subnet is 2001:DB8:0:1::/64
[EUI/CAL/PRE]
And let’s make sure it uses the prefix to configure its GigabitEthernet0/2 interface:
Hosts
Our hosts should configure themselves using the router advertisements they receive from the
customer routers. Let’s verify this:
That’s looking good. Each host has the correct prefix and was able to configure its own IPv6
address.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname C1
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address autoconfig default
ipv6 dhcp client pd ISP_PREFIX
!
interface GigabitEthernet0/2
ipv6 address ISP_PREFIX ::1:0:0:0:1/64
Page 63 of 252
!
end
hostname C2
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address autoconfig default
ipv6 dhcp client pd ISP_PREFIX
!
interface GigabitEthernet0/2
ipv6 address ISP_PREFIX ::2:0:0:0:2/64
!
end
hostname H1
!
interface GigabitEthernet0/1
ipv6 address autoconfig
!
end
hostname H2
!
interface GigabitEthernet0/1
ipv6 address autoconfig
!
end
hostname H3
!
interface GigabitEthernet0/1
ipv6 address autoconfig
!
end
hostname H4
!
interface GigabitEthernet0/1
ipv6 address autoconfig
!
end
hostname ISP
!
ipv6 unicast-routing
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
domain-name NETWORKLESSONS.LOCAL
!
interface GigabitEthernet0/1
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.
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.
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.
Just like with IPv4, it is possible to use an interface as the next hop. This will only work with
point-to-point interfaces:
S 2001:DB8:2:2::/64 [1/0]
via Serial0/0/0, directly connected
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
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.
Instead of an outgoing interface, we can also specify the global unicast address as the next hop:
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
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.
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:
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:
S 2001:DB8:2:2::/64 [1/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
No problems there.
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
S ::/0 [1/0]
via Serial0/0/0, directly connected
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
Static default route – global unicast next hop
Instead of an outgoing interface, let’s try a global unicast next hop address:
S ::/0 [1/0]
via 2001:DB8:12:12::2
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
Let’s replace the global unicast next hop address with a link-local address:
Page 68 of 252
R1#show ipv6 route static
S ::/0 [1/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
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.
S 2001:DB8:2:2::2/128 [1/0]
via Serial0/0/0, directly connected
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
Static host route – global unicast next hop
Page 69 of 252
S 2001:DB8:2:2::2/128 [1/0]
via 2001:DB8:12:12::2
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
Static host route – link-local next hop
Last but not least, a link-local address as the next hop address:
S 2001:DB8:2:2::2/128 [1/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
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:
Let’s try the outgoing interface first. The static route looks like this:
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
R1#show ipv6 route static
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:
S 2001:DB8:2:2::/64 [2/0]
via Serial0/0/0, directly connected
The entry to R2 is now installed. You can also see the administrative distance value of two in the
routing table.
Instead of the outgoing interface, we can also use a global unicast address as the next hop:
S 2001:DB8:2:2::/64 [2/0]
via 2001:DB8:12:12::2
Static floating route – link-local next hop
S 2001:DB8:2:2::/64 [2/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
Conclusion
Page 72 of 252
You have now learned how to configure the following IPv6 static routes:
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)#ipv6 unicast-routing
R1(config)#interface loopback 0
R1(config-if)#ipv6 address 2001::1/128
R2(config)#ipv6 unicast-routing
R2(config)#interface loopback 0
R2(config-if)#ipv6 address 2001::2/128
Don’t forget to enable IPv6 unicast routing otherwise no routing protocol will work for IPv6.
Page 73 of 252
2001::1
R2#show ipv6 interface brief
FastEthernet0/0 [up/up]
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.
Use the IPv6 enable command to generate a link-local address for the FastEthernet interfaces.
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.
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.
A quick look at the routing table with the show IPv6 route command shows us that RIP has
learned about the networks.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R2
!
ipv6 unicast-routing
!
interface loopback 0
ipv6 address 2001::2/128
Page 75 of 252
ipv6 rip RIPNGTEST enable
!
interface fastEthernet 0/0
ipv6 enable
ipv6 rip RIPNGTEST enable
!
ipv6 router rip RIPNGTEST
!
end
hostname R1
!
ipv6 unicast-routing
!
interface loopback 0
ipv6 address 2001::1/128
ipv6 rip RIPNGTEST enable
!
interface fastEthernet 0/0
ipv6 enable
ipv6 rip RIPNGTEST enable
!
ipv6 router rip RIPNGTEST
!
end
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?
R2 has learned about the loopback0 interface behind R1. Let’s see if all interfaces are up and
running and configured for IPv6:
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]
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)#interface loopback 0
R2(config-if)#ipv6 rip NEXTGEN enable
Now we see that the loopback0 interface has joined RIPNG. Let’s check the routing table of R1
again:
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.
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
(config)#ipv6 unicast-routing
R1 & R2
(config)#interface GigabitEthernet 0/1
(config-if)#ipv6 enable
R1(config)#interface loopback 0
R1(config-if)#ipv6 address 2001::1/128
R2(config)#interface loopback 0
R2(config-if)#ipv6 address 2001::2/128
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:
After configuring the IPv6 addresses on the loopback interface you can see the global unicast
and the link-local IPv6 addresses.
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)#interface loopback 0
R1(config-if)#ipv6 eigrp 1
R2(config)#ipv6 router eigrp 1
R2(config-rtr)#router-id 2.2.2.2
R2(config-rtr)#no shutdown
R2(config)#interface loopback 0
R2(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]
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
R2#show ipv6 route eigrp
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::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!
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R2
!
ipv6 unicast-routing
!
interface loopback 0
ipv6 address 2001::2/128
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 unicast-routing
!
interface loopback 0
ipv6 address 2001::1/128
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.
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:
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.
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.
R1(config)#ipv6 unicast-routing
Page 84 of 252
R1(config)#interface loopback 0
R1(config-if)#ipv6 address 2001::1/128
R2(config)#ipv6 unicast-routing
R2(config)#interface loopback 0
R2(config-if)#ipv6 address 2001::2/128
Don’t forget to enable IPv6 unicast routing otherwise no routing protocol will work for IPv6.
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 so we’ll have to fix this:
Page 85 of 252
R2(config)#interface fastEthernet 0/0
R2(config-if)#ipv6 ospf 1 area 0
R2(config-if)#exit
R2(config)#interface loopback 0
R2(config-if)#ipv6 ospf 1 area 0
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.
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.
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R2
!
ipv6 unicast-routing
!
Page 86 of 252
interface loopback 0
ipv6 address 2001::2/128
ipv6 ospf 1 area 0
!
interface fastEthernet 0/0
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 2.2.2.2
!
end
hostname R1
!
ipv6 unicast-routing
!
interface loopback 0
ipv6 address 2001::1/128
ipv6 ospf 1 area 0
!
interface fastEthernet 0/0
ipv6 enable
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 1.1.1.1
!
end
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.
R1 & R2
(config)#ipv6 unicast-routing
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.
R2(config)#interface loopback 0
R2(config-if)#ipv6 address 2001:DB8:2:2::2/128
We do the same thing on R2, but also include the default route:
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:
This seems to be the case. Let’s check if R1 has learned a default route from R2:
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/18 ms
Our ping is working, which proves that our default route works.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
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 unicast-routing
ipv6 cef
!
interface Loopback0
no ip address
ipv6 address 2001:DB8:2:2::2/128
!
interface GigabitEthernet0/1
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.
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.
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:
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 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
ipv6 ospf 1 area 0
!
interface GigabitEthernet0/1
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 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:2:2::2/128
ipv6 ospf 1 area 0
!
interface GigabitEthernet0/0
ip address 10.255.2.72 255.255.0.0
!
interface GigabitEthernet0/1
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 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:3:3::3/128
ipv6 ospf 1 area 0
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:123::3/64
ipv6 enable
Page 94 of 252
ipv6 ospf 1 area 0
!
interface GigabitEthernet0/2
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 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:4:4::4/128
ipv6 ospf 1 area 0
!
interface GigabitEthernet0/1
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]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
O 2001:DB8:4:4::4/128 [110/2]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
R2#show ipv6 route ospf
O 2001:DB8:0:34::/64 [110/2]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
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
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
O 2001:DB8:4:4::4/128 [110/2]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
O 2001:DB8:0:123::/64 [110/2]
via FE80::F816:3EFF:FE4A:6854, GigabitEthernet0/1
O 2001:DB8:1:1::1/128 [110/2]
via FE80::F816:3EFF:FE4A:6854, GigabitEthernet0/1
O 2001:DB8:2:2::2/128 [110/2]
via FE80::F816:3EFF:FE4A:6854, GigabitEthernet0/1
O 2001:DB8:3:3::3/128 [110/1]
via FE80::F816:3EFF:FE4A:6854, GigabitEthernet0/1
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:
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
Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/1)
Link State ID: 3 (Interface ID)
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0x9525
Length: 56
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEE3:9BA6
Page 96 of 252
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:123::
Prefix Length: 64, Options: None
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
Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/1)
Link State ID: 3 (Interface ID)
Advertising Router: 4.4.4.4
LS Seq Number: 80000003
Checksum: 0x4C21
Length: 56
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEAF:7D32
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:34::
Prefix Length: 64, Options: None
R4 shows information about 2001:DB8:0:34::/64. This information will be removed once prefix
suppression is enabled.
Let’s look at the intra area prefix LSA. Let’s take a look at R3, our DR:
LS age: 614
LS Type: Intra-Area-Prefix-LSA
Link State ID: 0
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x54B5
Length: 64
Referenced LSA Type: 2001
Referenced Link State ID: 0
Referenced Advertising Router: 3.3.3.3
Number of Prefixes: 2
Prefix Address: 2001:DB8:3:3::3
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:0:34::
Page 97 of 252
Prefix Length: 64, Options: None, Metric: 1
LS age: 614
LS Type: Intra-Area-Prefix-LSA
Link State ID: 3072
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xD0C2
Length: 44
Referenced LSA Type: 2002
Referenced Link State ID: 3
Referenced Advertising Router: 3.3.3.3
Number of Prefixes: 1
Prefix Address: 2001:DB8:0:123::
Prefix Length: 64, Options: None, Metric: 0
LS age: 683
LS Type: Intra-Area-Prefix-LSA
Link State ID: 0
Advertising Router: 4.4.4.4
LS Seq Number: 80000004
Checksum: 0xB844
Length: 64
Referenced LSA Type: 2001
Referenced Link State ID: 0
Referenced Advertising Router: 4.4.4.4
Number of Prefixes: 2
Prefix Address: 2001:DB8:4:4::4
Prefix Length: 128, Options: LA, Metric: 0
Prefix Address: 2001:DB8:0:34::
Prefix Length: 64, Options: None, Metric: 1
Once prefix suppression is enabled, you’ll see that the information about transit prefix
2001:DB8:0:34::/64 will be removed.
Time to enable prefix suppression. I use the global command on all routers:
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]
via FE80::F816:3EFF:FE2A:1133, GigabitEthernet0/1
O 2001:DB8:3:3::3/128 [110/1]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
O 2001:DB8:4:4::4/128 [110/2]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
R2#show ipv6 route ospf
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]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
O 2001:DB8:4:4::4/128 [110/2]
via FE80::F816:3EFF:FEE3:9BA6, GigabitEthernet0/1
R4#show ipv6 route ospf
O 2001:DB8:1:1::1/128 [110/2]
via FE80::F816:3EFF:FE4A:6854, GigabitEthernet0/1
O 2001:DB8:2:2::2/128 [110/2]
via FE80::F816:3EFF:FE4A:6854, GigabitEthernet0/1
O 2001:DB8:3:3::3/128 [110/1]
via FE80::F816:3EFF:FE4A:6854, GigabitEthernet0/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
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: 80000004
Checksum: 0xB27D
Length: 44
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FE4A:6854
Number of Prefixes: 0
LS age: 200
Page 99 of 252
Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/1)
Link State ID: 3 (Interface ID)
Advertising Router: 3.3.3.3
LS Seq Number: 80000004
Checksum: 0x30F
Length: 44
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEE3:9BA6
Number of Prefixes: 0
Above you can see that R3 has removed the transit prefixes. The number of prefixes now shows
0.
LS age: 253
Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)
LS Type: Link-LSA (Interface: GigabitEthernet0/1)
Link State ID: 3 (Interface ID)
Advertising Router: 4.4.4.4
LS Seq Number: 80000004
Checksum: 0x567E
Length: 44
Router Priority: 1
Link Local Address: FE80::F816:3EFF:FEAF:7D32
Number of Prefixes: 0
Same thing on R4. Information about prefix 2001:DB8:0:34::/64 has been removed, and the
number of prefixes shows 0.
Let’s check out the prefix intra area LSA that R3 (our DR) creates to see the changes:
LS age: 296
LS Type: Intra-Area-Prefix-LSA
Link State ID: 0
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0x73FE
Length: 52
Referenced LSA Type: 2001
Referenced Link State ID: 0
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).
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:
R1#ping FE80::CE01:1BFF:FE29:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
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
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/4/8 ms
OSPFv3 is running on the FastEthernet0/0 interfaces of R1 and R2. No issues there, let’s check if
we have neighbors or not:
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
R1(config-rtr)#router-id 1.1.1.1
R2(config)#ipv6 router ospf 1
R2(config-rtr)#router-id 2.2.2.2
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:
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!
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
Output Interface: FastEthernet0/0
OSPFv3 has been enabled on the interfaces, still we don’t have any neighbors:
Becoming OSPFv3 neighbors starts with a hello packet, let’s see what we discover:
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:
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
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.
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:
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]
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:
Here you can see the link-local addresses that we need to use. Let’s configure the neighbors:
This is how we configure the neighbors ourselves. Let’s see if this solves our problem:
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
Type escape sequence to abort.
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…
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:
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:
I’ll map the link-local addresses to the DLCI numbers. After a few seconds we’ll see this:
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.
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:
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:
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)#address-family ipv6
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 bgp 2
R2(config-router)#neighbor 2001:db8:0:12::1 remote-as 1
R2(config-router)#address-family ipv4
R2(config-router-af)#no neighbor 2001:db8:0:12::1 activate
R1#
%BGP-5-ADJCHANGE: neighbor 2001:DB8:0:123::2 Up
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.
Want to take a look for yourself? Here you will find the configuration of each device.
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
!
hostname R2
!
interface Loopback 0
ipv6 enable
ipv6 address 2001:DB8::2/128
!
interface fastEthernet0/0
ipv6 enable
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::1 remote-as 1
!
address-family ipv4
no neighbor 2001:DB8:0:12::1 activate
exit-address-family
!
address-family ipv6
network 2001:DB8::2/128
neighbor 2001:DB8:0:12::1 activate
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:
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R2(config)#router bgp 2
R2(config-router)#neighbor 192.168.12.1 remote-as 1
R1(config)#router bgp 1
R1(config-router)#address-family ipv6
R1(config-router-af)#network 2001:db8::1/128
R1(config-router-af)#neighbor 192.168.12.2 activate
R2(config)#router bgp 2
R2(config-router)#address-family ipv6
R2(config-router-af)#network 2001:db8::2/128
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:
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:
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:
Both routers now change the next hop IPv6 address of incoming prefixes. Let’s reset BGP:
R1#clear ip bgp *
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
!
interface Loopback 0
ipv6 address 2001:DB8::1/128
!
interface fastEthernet0/0
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 unicast-routing
!
interface Loopback 0
ipv6 address 2001:DB8::2/128
!
interface fastEthernet0/0
ipv6 enable
ip address 192.168.12.2 255.255.255.0
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
neighbor 192.168.12.1 remote-as 1
address-family ipv6
network 2001:DB8::2/128
neighbor 192.168.12.1 activate
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
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 1
R1(config-router)#bgp router-id 1.1.1.1
R1(config-router)#neighbor 2001:db8:0:12::2 remote-as 2
R1(config-router)#address-family ipv6
R1(config-router-af)#neighbor 2001:db8:0:12::2 activate
R1(config-router-af)#network 2001:db8:0:1::/64
R1(config-router-af)#network 2001:db8:0:11::/64
R1(config-router-af)#network 2001:db8:0:111::/64
R1(config-router-af)#network 2001:db8:0:1111::/96
R2(config)#router bgp 2
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#neighbor 2001:db8:0:12::1 remote-as 1
R2(config-router)#address-family ipv6
R2(config-router-af)#neighbor 2001:db8:0:12::1 activate
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:
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 bgp 2
R2(config-router)#address-family ipv6
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 *
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:
R1(config)#router bgp 1
R1(config-router)#address-family ipv6
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:
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)#router bgp 2
R2(config-router)#address-family ipv6
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:
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)#router bgp 2
R2(config-router-af)#neighbor 2001:db8:0:12::1 route-map MY_FILTER in
R2#clear ip bgp *
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:
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
!
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
hostname R2
!
ipv6 unicast-routing
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::1 remote-as 1
!
address-family ipv4
no neighbor 2001:DB8:0:12::1 activate
exit-address-family
!
address-family ipv6
neighbor 2001:DB8:0:12::1 activate
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
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)#ipv6 unicast-routing
R1(config)#interface loopback 0
R1(config-if)#ipv6 address 2001::1/128
R1(config-if)#exit
R1(config)#interface fastEthernet 0/0
R1(config-if)#ipv6 enable
R2(config)#ipv6 unicast-routing
R2(config)#interface fastEthernet 0/0
R2(config-if)#ipv6 enable
R2(config-if)#exit
R2(config)#interface fastEthernet 1/0
R2(config-if)#ipv6 enable
R3(config)#ipv6 unicast-routing
R3(config)#interface loopback 0
R3(config-if)#ipv6 address 2001::3/128
R3(config-if)#exit
R3(config)#interface fastEthernet 0/0
R3(config-if)#ipv6 enable
We use the redistribute command to exchange routing information between OSPFv3 and
RIPNG. This is all you have to do to redistribute everything.
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]
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R2
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 enable
ipv6 rip RIPNG enable
!
interface fastEthernet 1/0
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
!
ipv6 unicast-routing
hostname R1
!
ipv6 unicast-routing
!
interface loopback 0
ipv6 address 2001::1/128
ipv6 rip RIPNG enable
!
interface fastEthernet 0/0
ipv6 enable
ipv6 rip RIPNG enable
!
ipv6 router rip RIPNG
!
end
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
R3#show ipv6 route ospf
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.
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:
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.
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]
via FE80::C002:17FF:FE28:0, FastEthernet0/0
EX 2001:DB8:23:23::/64 [170/1757696]
via FE80::C002:17FF:FE28:0, FastEthernet0/0
R3#show ipv6 route ospf
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.
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
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.
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:
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
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
After specifying the source IP I also have to select the destination IP, let’s do that:
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:
Instead of using the access-group command you have to use the ipv6 traffic-filter command.
Let’s see if it works:
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:
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:
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:12::2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
!
interface FastEthernet0/0
no ip address
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname R2
!
ipv6 unicast-routing
!
interface FastEthernet0/0
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
You can also add an IPv6 access-list on a switchport (L2) interface with the PACL.
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.
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)#interface FastEthernet 0/0
(config-if)#ipv6 ospf 1 area 0
IPsec Authentication
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):
Now we can choose what authentication we would like, MD5 or SHA1. SHA1 is more secure so
let’s select that:
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:
As soon as you do this the OSPFv3 neighbor adjacency will drop so let’s copy and paste the
same line on R2:
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.
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:
interface: FastEthernet0/0
Crypto map tag: (none), local addr ::
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
outbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 2002, flow_id: NETGX:2, sibling_flags 80000001, crypto map:
(none)
no sa timing
replay detection support: N
Status: ACTIVE
Above you can see our SPI number and that we are using SHA authentication. There’s one more
useful command:
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:
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 enable
ipv6 ospf 1 area 0
hostname R2
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 enable
ipv6 ospf 1 area 0
ipv6 ospf authentication ipsec spi 256 sha1
A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
!
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)#interface FastEthernet 0/0
(config-if)no ipv6 ospf authentication ipsec spi 256 sha1
A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
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:
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:
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:
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
inbound ah sas:
outbound ah 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:
Let me also show you a Wireshark capture of some encrypted OSPFv3 traffic:
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 enable
ipv6 ospf 1 area 0
hostname R2
!
ipv6 unicast-routing
!
interface fastEthernet 0/0
ipv6 enable
ipv6 ospf 1 area 0
ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256
FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85B sha1
A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1
!
ipv6 router ospf 1
router-id 2.2.2.2
!
end
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.
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:
Let’s configure R1 so that it sends router advertisements. To do that, we need to enable unicast
routing:
R1(config)#ipv6 unicast-routing
And we’ll configure an IPv6 address so that it includes a prefix in the RAs:
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ipv6 address 2001:DB8:0:1::1/64
Our host is going to use SLAAC and sets a default route to the router:
Let’s see how our host reacts to the router advertisement from R1:
H1 receives the RA. Let’s see if it uses this router as its default gateway:
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)#interface GigabitEthernet 0/1
H2(config-if)#ipv6 address 2001:DB8:BAD:BAD::2/64
H2(config-if)#ipv6 nd router-preference high
H1 sees the RA, autoconfigures an IPv6 address with the 2001:DB8:BAD:BAD::/64 prefix and
also uses H2 as a default route:
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”:
With the host device role, all RAs and router redirect messages will be blocked. We need to
enable this policy on the interface:
Here’s how you can verify which policies you have activated on what interfaces:
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
ICMP Neighbor Discovery events debugging is on
H2#
ICMPv6-ND: Sending RA from FE80::211:BBFF:FE0B:3641 to FF02::1 on
GigabitEthernet0/1
ICMPv6-ND: MTU = 1504
ICMPv6-ND: prefix = 2001:DB8:BAD:BAD::/64 onlink autoconfig
ICMPv6-ND: 2592000/604800 (valid/preferred)
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
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:
This is a good feature to block rogue RAs. I should have implemented this before H1 received
the first RA though:
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]
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.
R1#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
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: MTU = 1504
ICMPv6-ND: prefix = 2001:DB8:0:1::/64 onlink autoconfig
ICMPv6-ND: 2592000/604800 (valid/preferred)
ICMPv6-ND: prefix = 2001:DB8:11::/64 onlink autoconfig
ICMPv6-ND: 2592000/604800 (valid/preferred)
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:
And the show ipv6 snooping command tells us why certain RAs are dropped:
Conclusion
You have now learned how to use the IPv6 RA Guard feature to prevent rogue / malicious router
advertisements:
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
Here is the topology we’ll use:
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.
R1(config)#ipv6 unicast-routing
R1 is a simple DHCPv6 server, I only advertise a prefix and that’s it. Let’s configure H1 as a
DHCPv6 client:
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:
Let’s attach the DHCP_SERVER policy to the interface that connects to R1 and the
DHCP_CLIENT policy to the correct interfaces:
This gives a nice overview of the policies and to which interfaces we attached them. Let’s see if
it works though…
R2(config)#ipv6 unicast-routing
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#
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:
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#
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:
This fixes the problem and our host will have two IPv6 addresses, one from each prefix:
Great!
We can also filter the source link-local address of the DHCPv6 server. Let’s see what address it
uses:
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:
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.
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:
SW1#
SISF[DHG]: Gi0/1 vlan 1 DHCP Server Advertise Msg valid preference: max
120>115>110 min
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ip cef
!
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool MY_POOL
address prefix 2001:DB8:0:1::/64
address prefix 2001:DB8:0:2::/64
!
interface FastEthernet0/0
ipv6 enable
ipv6 dhcp server MY_POOL preference 115
!
end
hostname R2
!
ip cef
!
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool ROGUE_POOL
address prefix 2001:DB8:BAD:C0DE::/64
!
interface FastEthernet0/0
ipv6 enable
ipv6 dhcp server ROGUE_POOL
!
end
hostname H1
!
ip cef
!
interface FastEthernet0/0
ipv6 address dhcp
ipv6 enable
!
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
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:
R1#ping 2001:DB8:0:12::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:12::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms
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:
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:
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.
If you want, you could make the spoofed address of R3 work. Let’s take another look at the
binding table:
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:
Above, you can see the static binding. ND/NA messages from R3 are now accepted:
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:
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.
SW1(config-nd-inspection)#limit ?
address-count Configure maximum address per port
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.
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?
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:
There are a couple of show commands you can use to see the policy:
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:
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:
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.
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:
Want to take a look for yourself? Here you will find the startup configuration of each device.
hostname H1
!
hostname R1
!
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool MY_POOL
address prefix 2001:DB8:0:12::/64
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::F/64
ipv6 dhcp server MY_POOL
!
end
hostname S1
!
ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/0
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.
We verify that H1 has an IPv6 address. Let’s make sure it can reach S1:
H1#ping 2001:DB8:0:4::4
Type escape sequence to abort.
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:
Let’s send a couple of pings from H2 to S1 from each fake IPv6 address:
You have to be quick but when you look at the IPv6 neighbors of S1, you see these entries:
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.
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:
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 clear the IPv6 address on H1 so that IPv6 snooping can see the DHCP packets:
We see two neighbor discovery entries and one DHCP entry. We now have everything we need
to test Source Guard.[teaser]
SW1(config-sisf-sourceguard)#?
IPv6 sourceguard policy configuration mode:
default Set a command to its defaults
deny Block data traffic
exit Exit from sourceguard policy configuration mode
no Negate a command or set its defaults
permit Allow data traffic
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:
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
This ping still works because the IPv6 address on H1 is in our binding table.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname H1
!
interface FastEthernet0/0
ipv6 address dhcp
ipv6 enable
!
end
hostname H2
!
interface FastEthernet0/0
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 unicast-routing
ipv6 cef
ipv6 dhcp pool MY_POOL
address prefix 2001:DB8:0:12::/64
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::F/64
ipv6 dhcp server MY_POOL
!
interface FastEthernet0/1
ipv6 address 2001:DB8:0:4::F/64
!
end
hostname S1
!
hostname SW1
!
ipv6 snooping policy SNOOPING
security-level glean
!
ipv6 source-guard policy SOURCE_GUARD
deny global-autoconf
!
interface GigabitEthernet0/1
ipv6 snooping attach-policy SNOOPING
!
interface GigabitEthernet0/2
ipv6 snooping attach-policy SNOOPING
ipv6 source-guard attach-policy SOURCE_GUARD
!
interface GigabitEthernet0/3
ipv6 snooping attach-policy SNOOPING
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.
We will use R1 and R2 to generate some IPv6 traffic and on SW1 we’ll configure the PACL.
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:
We can see the access-list we created with the show ipv6 access-list command:
Let’s activate the access-list on the GigabitEthernet 0/1 interface that connects to R1:
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
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ip cef
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname R2
!
ip cef
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::2/64
!
ip http server
!
end
hostname SW1
!
interface GigabitEthernet0/1
ipv6 traffic-filter NO_TELNET in
!
interface GigabitEthernet0/2
!
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!
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.
R1(config)#interface loopback 0
R1(config-if)#ipv6 address 2001::1/128
R1(config-if)#exit
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R2(config)#interface fastEthernet 0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#exit
R2(config)#interface fastEthernet 1/0
R2(config-if)#ip address 192.168.23.2 255.255.255.0
R3(config)#interface fastEthernet 0/0
R3(config-if)#ip address 192.168.23.3 255.255.255.0
R3(config-if)#exit
R3(config)#interface loopback 0
R3(config-if)#ipv6 address 2001::3/128
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)#interface loopback 1
R1(config-if)#ip address 1.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#router eigrp 123
R1(config-router)#no auto-summary
R1(config-router)#network 192.168.12.0
R1(config-router)#network 1.1.1.0
R2(config)#router eigrp 123
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)#interface tunnel 0
R3(config-if)#tunnel source loopback 1
R3(config-if)#tunnel destination 1.1.1.1
R3(config-if)#tunnel mode ipv6ip
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(config)#ipv6 unicast-routing
R1(config)#ipv6 router rip RIPNG
R1(config-rtr)#exit
R1(config)#interface loopback 0
R1(config-if)#ipv6 rip RIPNG enable
R1(config-if)#exit
R1(config)#interface tunnel 0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 rip RIPNG enable
R3(config)#ipv6 unicast-routing
R3(config)#ipv6 router rip RIPNG
R3(config-rtr)#exit
R3(config)#interface loopback 0
R3(config-if)#ipv6 rip RIPNG enable
R3(config-if)#exit
R3(config)#interface tunnel 0
R3(config-if)#ipv6 enable
R3(config-if)#ipv6 rip RIPNG enable
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.
You can see both routers learned about each other IPv6 networks.
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)#interface tunnel 0
R1(config-if)#tunnel mode gre ip
R3(config)#interface tunnel 0
R3(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).
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R2
!
interface fastEthernet 0/0
ip address 192.168.12.2 255.255.255.0
!
interface fastEthernet 1/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 R1
!
ipv6 unicast-routing
!
interface loopback 0
ipv6 address 2001::1/128
ipv6 rip RIPNG enable
!
interface loopback 1
ip address 1.1.1.1 255.255.255.0
!
interface fastEthernet 0/0
ip address 192.168.12.1 255.255.255.0
!
interface tunnel 0
tunnel source loopback 1
tunnel destination 3.3.3.3
tunnel mode ipv6ip
tunnel mode gre ip
ipv6 rip RIPNG enable
!
router eigrp 123
no auto-summary
network 192.168.12.0
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?
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)#interface loopback 0
R1(config-if)#ipv6 address 2001::1/128
R1(config-if)#exit
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R2(config)#interface fastEthernet 0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#exit
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:
[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)#interface tunnel 0
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)#interface tunnel 0
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:
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.
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.
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R2
!
interface fastEthernet 0/0
ip address 192.168.12.2 255.255.255.0
!
interface fastEthernet 1/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
!
hostname R1
!
interface loopback 0
ipv6 address 2001::1/128
!
interface fastEthernet 0/0
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
tunnel mode ipv6ip 6to4
!
router eigrp 123
no auto-summary
network 192.168.12.0
network 1.1.1.0
!
ipv6 general-prefix MYPREFIX 6to4 fastEthernet 0/0
!
ipv6 route 2001::3/128 2002:C0A8:1703::3
ipv6 route 2002::/16 tunnel 0
!
end
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
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:
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:
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
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:
We can let our router do the calculation from decimal to hexadecimal for us. Here’s the result:
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)#interface tunnel 0
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:
The correct prefix is 2002:C0A8:1703::/48 so 2002:A14:1403::3 is not going to work. Let’s fix
it:
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:
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]
We’ll remove the old static route and create a new one with the correct next hop. Let’s check R3
as well:
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:
After making these changes, let’s see if there is connectivity between R1 and R3:
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.
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.
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.
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.
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
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.
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:
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.
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.
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:
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.
Let’s look at an example where H1 wants to send an IPv6 packet to a destination outside of the
ISP network:
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:
hostname CE1
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
!
end
hostname CE2
!
ip cef
!
interface GigabitEthernet0/1
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
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
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
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:
And the BR IPv4 address if we want to reach hosts on the IPv6 Internet:
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:
The CE2 router is the same as CE1. Here is the entire configuration:
CE2(config)#ipv6 unicast-routing
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
That’s it.
BR1
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
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:
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:
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
S ::/0 [1/0]
S ::/0 [1/0]
via 2001:DB8:300::
S 2001:DB8::/32 [1/0]
via Tunnel0, directly connected
One static route for 2001:DB8::/32 that points to the tunnel interface and a default route that
points to the BR.
S 2001:DB8::/32 [1/0]
via Tunnel0, directly connected
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:
You can see the IPv4 addresses and the encapsulated IPv6 packet.
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):
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:
The packet is sourced from the BR (192.168.1.3) and destined for CE1 (192.168.1.1).
Want to take a look for yourself? Here you will find the configuration of each device.
hostname BR1
!
ip cef
ipv6 unicast-routing
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
!
interface GigabitEthernet0/1
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 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address ISP_RD6_PREFIX ::10:0:0:0:1/64
!
interface Tunnel0
ipv6 enable
tunnel source GigabitEthernet0/1
tunnel mode ipv6ip 6rd
tunnel 6rd ipv4 prefix-len 24
tunnel 6rd prefix 2001:DB8::/32
tunnel 6rd br 192.168.1.3
!
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
!
ipv6 route 2001:DB8::/32 Tunnel0
ipv6 route ::/0 2001:DB8:300::
!
end
hostname CE2
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.
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.
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.
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.
Want to take a look for yourself? Here you will find the startup configuration of each device.
hostname R1
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname R2
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
interface FastEthernet1/0
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
hostname R3
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:3:3::3/128
!
interface FastEthernet0/0
ip address 192.168.23.3 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
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:
R3(config)#ipv6 unicast-routing
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
R1(config)#interface Tunnel 0
R1(config-if)#ipv6 address autoconfig
R1(config-if)#tunnel source FastEthernet 0/0
R1(config-if)#tunnel destination 192.168.23.3
R1(config-if)#tunnel mode ipv6ip
Verification
Let’s see if our configuration works. I’ll start with the headend router…
Headend
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:
Hexadecimal C0 A8 17 03
Client
Here’s the decimal IPv4 address that is embedded in the IPv6 address:
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!
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ip cef
!
interface Tunnel0
hostname R2
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
interface FastEthernet1/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
!
ipv6 unicast-routing
!
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 source FastEthernet0/0
tunnel mode ipv6ip isatap
!
interface FastEthernet0/0
ip address 192.168.23.3 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 192.168.23.0 0.0.0.255 area 0
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.
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.
In this lesson, I’ll show you how to configure 6PE and 6VPE.
Configuration
Here is the topology we will use:
Want to take a look for yourself? Here you will find the startup configuration of each device.
hostname CE1
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:12::1/64
!
end
hostname CE2
!
ip cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
interface GigabitEthernet0/0
ip address 10.255.1.147 255.255.0.0
!
interface GigabitEthernet0/1
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
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
!
interface GigabitEthernet0/2
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 PE2
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:45::4/64
!
interface GigabitEthernet0/2
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
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 234
neighbor 2.2.2.2 update-source Loopback0
!
end
With the configuration above, I have an LSP between PE1 and PE2. These two PE routers are
MP-BGP neighbors:
We can see the transport labels that are used between PE1 (2.2.2.2) and PE2 (4.4.4.4):
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:
PE1(config)#ipv6 unicast-routing
PE2(config)#ipv6 unicast-routing
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)#ipv6 unicast-routing
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
CE2(config)#ipv6 unicast-routing
CE2(config)#router bgp 5
CE2(config-router)#bgp router-id 5.5.5.5
CE2(config-router)#neighbor 2001:DB8:0:45::4 remote-as 234
CE2(config-router)#address-family ipv6
CE2(config-router-af)#neighbor 2001:DB8:0:45::4 activate
CE2(config-router-af)#network 2001:DB8:5:5::5/128
Let’s verify our work. Let’s start with the PE routers to see if MP-BGP has exchanged any
prefixes:
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.
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:
With 6PE, prefixes are installed in the global IPv6 routing table. Let’s take a look:
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 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.
B 2001:DB8:1:1::1/128 [200/0]
via 2.2.2.2%default, indirectly connected
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:
B 2001:DB8:5:5::5/128 [20/0]
via FE80::F816:3EFF:FE44:53EA, GigabitEthernet0/1
CE2#show ipv6 route bgp
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]:
Type escape sequence to abort.
Tracing the route to 2001:DB8:5:5::5
1 2001:DB8:0:12::2 7 msec
This is looking good. We see the VPN label (19) and the transport label (17) in this output.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname CE1
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
interface GigabitEthernet0/0
ip address 10.255.1.146 255.255.0.0
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:12::1/64
ipv6 enable
!
router bgp 1
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::2 remote-as 234
!
address-family ipv4
no neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8:1:1::1/128
neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
end
hostname CE2
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:45::5/64
!
router bgp 5
bgp router-id 5.5.5.5
bgp log-neighbor-changes
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
!
interface GigabitEthernet0/2
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 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:12::2/64
!
interface GigabitEthernet0/2
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
hostname PE2
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:45::4/64
!
interface GigabitEthernet0/2
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
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 234
neighbor 2.2.2.2 update-source Loopback0
neighbor 2001:DB8:0:45::5 remote-as 5
!
address-family ipv4
neighbor 2.2.2.2 activate
no neighbor 2001:DB8:0:45::5 activate
exit-address-family
!
address-family ipv6
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-label
neighbor 2001:DB8:0:45::5 activate
exit-address-family
!
end
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:
Make sure IPv6 unicast routing is enabled before you configure MP-BGP:
PE1(config)#ipv6 unicast-routing
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]
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)#ipv6 unicast-routing
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:
CE1(config)#ipv6 unicast-routing
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
CE2(config)#ipv6 unicast-routing
CE2(config)#router bgp 5
CE2(config-router)#bgp router-id 5.5.5.5
CE2(config-router)#neighbor 2001:DB8:0:45::4 remote-as 234
CE2(config-router)#address-family ipv6
CE2(config-router-af)#neighbor 2001:DB8:0:45::4 activate
CE2(config-router-af)#network 2001:DB8:5:5::5/128
Verification
Let’s see if the PE routers have anything in the BGP table for the VRF:
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.
Let’s take a closer look at those prefixes, see what labels we find:
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:
Let’s take a look at the routing tables for the CUSTOMER VRF to see if the prefixes got
installed:
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]
via 4.4.4.4%default, indirectly connected
PE2#show ipv6 route vrf CUSTOMER bgp
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
CE2#show ipv6 route bgp
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:
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]:
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname CE1
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:1::1/128
!
interface GigabitEthernet0/0
ip address 10.255.1.152 255.255.0.0
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:12::1/64
!
router bgp 1
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::2 remote-as 234
!
address-family ipv4
neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8:1:1::1/128
neighbor 2001:DB8:0:12::2 activate
exit-address-family
!
end
hostname CE2
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:5:5::5/128
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:45::5/64
hostname P
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
!
interface GigabitEthernet0/2
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 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
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 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/1
vrf forwarding CUSTOMER
ipv6 address 2001:DB8:0:45::4/64
!
interface GigabitEthernet0/2
ip address 192.168.34.4 255.255.255.0
Conclusion
You have now learned how you can run IPv6 over an IPv4-only MPLS core with 6PE and 6VPE:
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.
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:
R1(config)#ipv6 unicast-routing
R1(config)#interface Tunnel 0
R1(config-if)#ipv6 address 2001:DB8:0:12::1/64
R1(config-if)#tunnel mode gre ip
R1(config-if)#tunnel source GigabitEthernet 0/1
R1(config-if)#tunnel destination 192.168.12.2
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.
We need a transform-set:
And an access-list that defines the traffic that we want to encrypt. We are going to encrypt all
GRE traffic:
Last but not least, we need a crypto map that pulls everything together and we activate it on the
physical interface:
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
R1(config)#interface Tunnel 0
R1(config-if)#ipv6 ospf 1 area 0/code>
R2
R2(config)#ipv6 unicast-routing
R2(config)#interface Tunnel 0
R2(config-if)#ipv6 address 2001:DB8:0:12::2/64
R2(config-if)#tunnel mode gre ip
R2(config-if)#tunnel source GigabitEthernet 0/1
R2(config-if)#tunnel destination 192.168.12.1
R2(config)#interface Loopback 0
R2(config-if)#ipv6 ospf 1 area 0
R2(config)#interface Tunnel 0
R2(config-if)#ipv6 ospf 1 area 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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:12::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 18/20/23 ms
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:
The tunnel is up and the tunnel mode is GRE/IP. Let’s check if we have an IPSec phase 1
security association:
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
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:
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
R2#show ipv6 route ospf
IPv6 Routing Table - default - 5 entries
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:
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ip cef
ipv6 unicast-routing
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
hostname R2
!
ip cef
ipv6 unicast-routing
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
tunnel source GigabitEthernet0/1
tunnel destination 192.168.12.1
!
interface GigabitEthernet0/1
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
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!
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.
Configuration
I will configure everything from scratch, let’s start with the interfaces:
That’s all we need. R2 will require unicast routing or it won’t do any NAT64 at all:
R2(config)#ipv6 unicast-routing
R3 will require a default route to R2, you’ll see why when we configure NAT64:
Before we configure NAT64, let’s do a quick test to make sure R2 can reach both routers:
R2#ping 192.168.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms
R2#ping 2001:DB8:2323:2323::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2323:2323::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms
So far so good, now we can enable NAT64. First we have to enable it on the interfaces:
Once you enable this you will see a syslog message that tells us that a virtual interface has been
created:
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:
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/16 ms
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
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
R3#ping 3001::C0A8:C01
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3001::C0A8:C01, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Above you can see what we have configured. The next show command is a bit more interesting:
Interface Statistics
FastEthernet0/0 (IPv4 configured, IPv6 not configured):
Packets translated (IPv4 -> IPv6)
Stateless: 0
Stateful: 63
MAP-T: 0
Packets translated (IPv6 -> IPv4)
Stateless: 0
Stateful: 0
MAP-T: 0
Packets dropped: 0
FastEthernet1/0 (IPv4 not configured, IPv6 configured):
Packets translated (IPv4 -> IPv6)
Stateless: 0
The output above shows us how many translations were done and in what direction. The last
show command is the most interesting one:
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
end
hostname R2
!
ipv6 unicast-routing
!
interface FastEthernet0/0
hostname R3
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:2323:2323::3/64
!
ipv6 route ::/0 2001:DB8:2323:2323::2
!
end
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.
What do we have?
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.
Want to take a look for yourself? Here you will find the startup configuration of each device.
hostname H1
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:12::1/64
!
ipv6 route ::/0 2001:DB8:0:12::2
!
end
hostname H3
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:23::3/64
!
hostname NPTV6
!
ipv6 unicast-routing
!
interface Loopback0
ipv6 address 2001:DB8:0:2::2/64
!
interface GigabitEthernet2
ipv6 address 2001:DB8:0:12::2/64
!
interface GigabitEthernet3
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:
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:
Prefixes configured: 1
NAT66 Prefixes
This shows us the prefixes that we configured. Let’s try a quick ping from H1:
H1#ping 2001:DB8:0:23::3
Type escape sequence to abort.
The ping works but it doesn’t tell me if the prefix is translated. There’s another command for
that:[teaser]
Global Stats:
Packets translated (In -> Out)
: 5
Packets translated (Out -> In)
: 5
Interface Statistics
GigabitEthernet2 (IPv4 configured, IPv6 configured):
Packets translated (In -> Out)
: 0
Packets translated (Out -> In)
: 0
Packets dropped: 0
GigabitEthernet3 (IPv4 configured, IPv6 configured):
Packets translated (In -> Out)
: 0
Packets translated (Out -> In)
: 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
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.
Want to take a look for yourself? Here you will find the configuration of each device.
hostname H1
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:12::1/64
!
ipv6 route ::/0 2001:DB8:0:12::2
!
end
hostname H3
!
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet0/1
ipv6 address 2001:DB8:0:23::3/64
!
ipv6 route ::/0 2001:DB8:0:23::2
!
end
hostname NPTV6
!
ipv6 unicast-routing
!
interface Loopback0
ipv6 address 2001:DB8:0:2::2/64
!
interface GigabitEthernet2
nat66 inside
ipv6 address 2001:DB8:0:12::2/64
!
interface GigabitEthernet3
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
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
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)#ipv6 unicast-routing
R1(config)#interface fastEthernet 0/0
R1(config-if)#ipv6 address 2001:12::1/64
R2(config)#ipv6 unicast-routing
R2(config)#interface fastEthernet 0/0
R2(config-if)#ipv6 enable
R2(config-if)#exit
R2(config)#interface fastEthernet 1/1
R2(config-if)#ipv6 enable
R2(config-if)#exit R2(config)#interface loopback 0 R2(config-if)#ipv6 address
2001::2/128
R3(config)#ipv6 unicast-routing
R3(config)#interface fastEthernet 0/0
R3(config-if)#ipv6 enable
R3(config-if)#exit
R3(config)#interface loopback 0
R3(config-if)#ipv6 address 2001::3/128
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:
First enable multicast routing for IPv6 or we are going nowhere. Next step is to configure the RP
and BSR:
Use the ipv6 pim bsr candidate rp command to advertise R3 as the Rendezvous Point…
And R2 as the BSR…now we’ll configure R1 to join a multicast group, I’ll use FF07::7 for this
example:
R2 sees R3 as the RP for the entire multicast group range. We can also take a look at the
multicast routing table:
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
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF07::7, timeout is 2 seconds:
Packet sent with a source address of 2001::3
Want to take a look for yourself? Here you will find the configuration of each device.
hostname R1
!
ipv6 unicast-routing
ipv6 cef
!
hostname R2
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 address 2001::2/128
ipv6 eigrp 1
!
interface FastEthernet0/0
no ip address
ipv6 enable
ipv6 eigrp 1
!
interface FastEthernet0/1
no ip address
ipv6 enable
ipv6 eigrp 1
!
interface FastEthernet1/1
no ip address
ipv6 enable
ipv6 eigrp 1
!
ipv6 pim bsr candidate bsr 2001::2
ipv6 router eigrp 1
eigrp router-id 2.2.2.2
!
end