Fred explainsi pv6-v2-alpha

First Release Draft

Understanding
IPv6
Book 1
IPv6 Fundamentals
IPv6 Addressing
IPv6 Header
ICMPv6
IPv6 Neighbor Discovery
IPv6 Nodes Tables
IPv6 Services

© Fred Bovy EIRL - IPv6 For Life! 2012

About the Book

Author's
Presentation

have finally hit the tipping point for IPv6, given that all of the
IPv4 addresses ran out in February. It’s time for everyone to
realize, before companies and individuals lose their competitive
edge, that IPv6 is fast becoming a requirement that will enable
the Next Generation Internet.

My name is Fred Bovy, CCIE #3013, and I have been in the
Networking industry for more than 20 years, focused primarily
on IPv6 and Service Provider issues for about 10 years.

About  
Understanding IPv6

In 1999 I joined CISCO as a Network Consultant. My initial long
term project involved helping a Service Provider and an
enterprise deploy brand new MPLS-VPN backbones. Since
then, I have been hooked, and have developed an expertise on
this subject. I later joined the CISCO IPv6 IOS Engineering
Team as a dev-tester. For more than 3 years, I had been
focusing on 6PE and 6VPE testing. During that time, I
developed many TCL scripts to tests 6PE and 6VPE
functionalities, routing and switching performance, scalability,
High Availability, all the supported network design like Internet
Access models, Carrier’s Carrier or Hub and Spoke and more. I
also got deeply involved in testing Netflow for IPv6 and SEND.
In 2009 I resumed teaching, keeping the focus on IPv6 with a
special attention on the transition to IPv6. I believe that we

I have written this book to help anyone who have to design,
configure and troubleshoot IPv6 Networks because this is the
experience I have built in my life of IPv6 Tester, Consultant and
Trainer and also from my 20+ (almost 25) years of IP and
CISCO Routers.
In this first book I will cover the Fundamentals. Next books will
be about Routing Protocols, Transition To IPv6, Multicast,
Security and more...
The book must be used with the IPv6 TUTORIAL that can be
found from http://www.fredbovy.com.

1

Understanding IPv6

1.Tribute to CISCO and to the USA!
IPv6 is more than a Job to me, it is a hobby and a
philosophy, it is a Community. It is open and everybody
is welcome to bring something !
 
IPv6 was designed about 20 years ago by people who
thought that the Internet should be for everybody and
not only for the lucky ones who can get a Class A or
whatever IPv4 block... It was designed to support ALL
applications for EVERYONE! ! 12 years ago I decided to
join the community of people who are building the new
Internet for everyone and for the new applications that
IPv6 enables!
I joined the CISCO IPv6 IOS Engineering Team to help
the development of 6PE and 6VPE for about 3 years
then Netﬂow for IPv6 and ﬁnally SeND and related IPv6
Security for about 3 years.
I would like to thanks Eric Levy-Abegnoly who was my
IPv6 Team Leader and mentor (with Luc Revardel) who
ii

designed and developed 6PE, 6VPE, SeND and more,
Ole Troan, another Great IPv6 Team Leader who
designed most of the IPv6 IOS Code, Benoit Lourdelet
who is the IPv6 Product manager, Patrick Grossetete
before him and many other great CISCO people I have
been working with. I learned so much with them. I was a
CCIE and a CCSI when I joined CISCO but I learned
more about the Networks during the 10 years working
for CISCO that all I had learned before. Special thanks
to Jim Guichard (my first mentor who was going with
me to the customers for my first 6 months within
CISCO), Peter Psenak (who was the NSA Engineer for
EQUANT before me and also helped me a lot during the
transition. He is now one of the best OSPF Engineer
WorldWide. Networks are transparent for him.), Arjen
Boers (The multicast man who hired me with
Valerio), JP Vasseur (CISCO Fellow Guru who
worked with me on the MPLS-TE Fast Re-Route
project for EQUANT and such a nice guy !), Francois
Le Faucheur (Another Brain, the Architects of QoS
in MPLS Network who invented DiffServ-TE, QoS
Models in MPLS Networks), Robert Hanzl (The
Customer support Engineer who helped me on my

first crysis with customer and then became an MPLS
Team Leader), Robert Rasczuk (The MPLS
Deployment Egnineer who helped me on my first big
crysis with a Customer facing a major Backbone
instability), Luc Revardel (who teached me the
basics of IPv6 Testing Automation), Greg Boland,
Steve Glaus, Mandy Mac Diarmid, Mado Bourgoin
and all my managers who helped me to focus on my
work starting with Valerio Muzzolini, Serge Dupouy,
Nick Gale.... And all the good guys and girls that I
am forgetting, who are the CISCO Assets.
These 10 years were the best school, university,
experience and also human values, not only
technical...
This was not only a matter of knowledge and people, it
was also a way to manage the people that I had never
found in any French Companies or International not
managed by American. During my interviews when I got
hired, someone asked me what I was expecting from my
management. I answered support to keep me focused
on my technical job and I was correct! This was typically
what I found with all my managers with an exception of
iii

the French SE (Pre Sales) Manager I got when I joined
the Account Team to help the customer validation
process for free as this was normally a service charged
to the customer. But except this one, I only got great
managers who always supported me when I was a
Network Consulting and a Software Engineer. I was
always supported to focus on my job and don't have to
care about the political cases that the French really
enjoy in most big Companies. I had the beneﬁt of
working for a big Company but at the same time I was
so free to organize my work and received award every
time I was doing something good that I had the feeling to
work for my own Company. First time that I was also
working for a Company where the Technical skills were
considered and you did not have to become a (often
bad) manager when you were good in your Technical
role as a reward! At last I found people like me, people
working like me! Working for CISCO was my best
experience in my carreer.

working as Fast Lane IPv6 Course Subject Matter
Expert and other CISCO partners or for myself as well.

After CISCO I resumed my trainer and consultant life
and started to teach what I have learned with my CISCO
masters and more! I am a self-employed IPv6 Expert
iv

IPv6 Fundamentals

1
 

This is the base for all the
IPv6 lessons, the most
important chapters to
understand IPv6. To help
you for this Module Study, 
you can use the
FUNDAMENTALS
TUTORIAL from  
http://fredbovy.com

Module 1

IPv6 Fundamentals
TOPICS
1. Introduction to IPv6
2. IPv6 Addressing Basics
3. IPv6 Header

1.IPv6 Fundamentals
IPv6 cannot be understood if the Fundamentals are not. That's
why the first Module of this book is essential.
You can find some help in the "IPv6 For Life!" Tutorial from the
home page: http://www.fredbovy.com.  
This Tutorial has several Chapter for the Fundamental Module: 
Fundamentals #1. Introduction and IPv6 Addressing 
Fundamentals #2. More about IPv6 Addressing. ICMPv6 and
an Intro about Neighbor Discovery 
Fundamentals #3. DHCPv6, DNS, MOBILE IPV6 and derived
applications

4. ICMPv6 Basics and Supported Applications
Our first Chapter will introduce all the basic concepts of IPv6.

5. Neighbor Discovery
6. IPv6 Nodes Tables
7. IPv6 Services
1. Support of Management tools
2. Support of DNS
3. DHCPv6
4. Mobile IPv6 and derived Applications NEMO,
MANET, PMIPv6
5. The Multihoming issue

Then we will study the IPv6 Addressing which is the main
reason why IPv6 was developed, to provide an addressing
which will match the requirements of the Internet the next
century.
There was a day one missed requirement which was the
Multihoming requirement. This should have been managed by
the IPv6 Stack as a service like Mobile IPv6 but the Engineers
just missed to address this issue which is still not completely
resolveld with a long term solution commonly accepted.

6

The next Chapter will be about IPv6 header, the long
addresses, the Extension Headers and other interesting
improvement for more efficiency.
Then ICMPv6 basics, quite close to IPv4 and more interesting,
the Neighbor Discovery Protocol which is described in two
separate RFCs. Many solutions are provided by ND like
Autoconfiguration or Router Discovery and more.
Finally we will describe all the most important Services which
are not implemented for all platforms. Linux being the best
platform to test and support all the IPv6 Services.

This is a Free Certification andthe principle to get it based on
achievements is a good principle.
2.2.Hurricane Electric
Hurricane Electric propose a very challenging Certification with
Multiple levels up to Sage Level.
Each step required both theory and practical exercise.
You need to have a host connected to the Internet to do the
proposed exercised and validate that you were able to provide
the correct answers.
This is Free and very interesting Certification.

2.IPv6 Certifications
2.1.IPv6 Forum Certification

2.3.CISCO CCIE Routing & Switching
Cisco has one main 5 days training course and a derivated
training from this one I have designed for CISCO which is
aimed at the SP Market.

There are many Certifications at the IPv6 Forum with 2 levels,
Silver and Gold for Engineer and Trainer. The Trainer is more
Advanced than the Engineers.
For the moment, all you need is to apply on the IPv6 Forum
Web Server and provide a few proof of Achievements to get
Certified.

7

Introduction to IPv6

2

IPv6 was published at the
end of the 90s to replace
IPv4 which was no more
matching the Internet
needs for about 10 years
already even if NAT
permitted to IPv4 to last
until now while TCP/IP
important concepts were
broken at the same time!

Module 2

Introduction to IPv6

1.Hystory
IPv4 was developed in the 80s for a Military Network with a few
thousands hosts maximum by the DoD of the USA.
There was no need for Security as it was a Private Network in
the DoD Buildings, no need for Autoconfiguration or Mobility
and many things which

The Need For A New Protocol For The Internet
1. Hystory
2. IPv4 Address depletion and NAT
3. The Market Needs: Cable, Mobile and more
4. Transition Richness
5. What are the IPv6 improvements?

IPv4 Addresses were widely distributed until they were no more
enough for everyone. In the early 90s, IPv4 Address depletion
started to be a problem.

1.1.OSI Protocols
The first serious candidate to replace TCP/IP was the OSI Protocols. The Open Systems Interconnection (OSI) protocols are
a family of information exchange standards developed jointly by
the ISO and the ITU-T starting in 1977.
OSI defined a Layered Model with 7 Layers while TCP/IP just
had 5 since OSI Layers 5, 6 and 7 were actually managed by
the TCP/IP Application Layer.
OSI Protocols was providing a Datagram Service like IP called
Connectionless Network Service (CLNS) with an address up to
20 bytes (160 bits) long.

9

Its Routing Protocol, ISIS, very close to OSPF immediately interested many Service Providers since it was an Integrated Routing Protocol which could support IPv4 as well (RFC1195). Actually it was more SP Oriented and could support much more routers in the same Area. It is also a much easier protocol to Troubleshoot. A simple look at its Database will convince any Network Engineer in 5 minutes.
Digital Equipment thought that OSI will replace IPv4 and DecNET Phase V was actually OSI Protocols.

1.2.ATM and Frame-relay
But at the same time the convergence of Data and Voice Networks had started since the middle of the 80s and we were looking for a Network which could manage both Real Time (Voice,
Video) and Non-Real Time data with multiple levels of Precedence as IPv4 was already doing. Some people were working
very hard for a converged Network and they came up with a
new protocol call ATM (Asynchronous Transfer Mode).
ATM could manage any kind of Traffic: Voice, Video, Business
Data, Bulk Data. ATM was really a Network Scientist Protocol
Architecture, its routing protocol PNNI was able to react in
Real-Time to any change in the Network to find paths which
could match any Class of Service Traffic.

ATM was based on 53 bytes cells at the Physical Level for
Real-Time and Non Real-Time traffic to be interleaved.
ATM was designed for 155 Mbps Sonet SDH Fiber links minimum and this was not really widely available at this time. Also,
the ASICS to manage the 53 Bytes Cells were not yet available
or very expensive as it was not made at a sufficient large scale
to get a reasonable price. So, an interim technology was also
created to transport Data and Voice while ATM was growing.
This was Frame-Relay, a stripped down version of X.25 with
PVC only. SVCs came later but they were never has popular as
PVC.
In the mid 90s ATM was the only serious candidate to support
these converged Networks and VoIP was not an Option in the
Networking Business World.
At the end of the 90s, most people realized that ATM will not
scale with MultiGigabit Links which were arriving slowly. Also,
some ATM Protocols like LAN Emulations collapsed under traffic as the Node dedicated to replicate the Broadcast and Multicast was too much solicited. ATM which was great on the paper proved to be not scalable, complex and expensive solution
and VoIP came back as a viable solution.
But all this work made for ATM was not thrashed and many protocols built for ATM are still in use in many solutions. A lot of of

10

the QoS, a protocol like NHRP which was developed for ATM
Classical IP is now used for CISCO DMVPN.

1.3.MPLS
And also, the idea to replace a long address by a label which
was already used by the old X.25, then ATM networks gave the
idea of replacing the IPv4 header with a short label! Epsilon's IP
Switching, Cisco's tag switching and many other Vendors provided such a solution with an initial motivation was to make
faster routers.
Then CISCO also saw that with Tag Switching it was possible to
add some services which were not possible with IP like TagVPN. Tag-VPN permitted to provide each connected customer
with a Virtual Private Network having its own IPv4 Addresses.
Tag-VPN was based on Multi-Protocol BGP Extension with a
new BGP vpnv4 address family as it was adding a 32 bit prefixe
to the the IPv4 address, call a Route Distinguisher (RD) for the
BGP prefix to be unique in the Service Provider Backbone BGP
Table.
In addition to the RD, an Extended Community BGP Attribute
was added to the BGP Prefix before it was advertized to a remote BGP Router. This Extended Attribute was then used to recognize a prefix and import it into the Customer Virtual Routing
Table.

The Benefits of Tag-VPN on the previous Layer 3 VPN based
on IP were that:
The Backbone routers (P) did not have to know any of the the
Customers Route. Only the BGP Next-Hop, the exit point host
route for each Provider Edge (PE) Router which was connecting to the Customer Edge (CE) Router was enough.
Before Tag-VPN, in the SP Point of Presence, each Customers needed to have a dedicated router which was importing all
the BGP Routes with a given Community Attribute. With TagVPN. the same PE could be shared by all the customers. Each
customer having its own Virtual Route.
Customers could have overlapping address without any problem.
The provisoning and the management of the VPN were very
much simplified.
Traffic Engineering was another great service of Tag-VPN allowing the SP to use more than the Best Route Links in their backbone yo use all the available Bandwidth of the Core.
Tag-Switching was then standardised by the IETF to MPLS,
So in the late 90s and in the early y2k, most Service Providers
were upgrading their backbone to MPLS!

11

1.4. IPv6
Later, in the early Y2Ks when IPv6 became the next Version approved by the IETF and more and more requested by the Customers, CISCO reply was to provide an IPv6 Service over IPv4/
MPLS without any need to upgrade the backbone.
They invented 6PE designed and developed in the South of
France from an Architecture (RFC) of Francois Le Faucheur
and other companies and then designed and coded by Eric
Levy-Abegnoly.
In the early y2k, the ﬁrst large scale IPv6 offers from SPs were
mostly brought by 6PE in Asia and in the USA.
Later came 6VPE which was actually 6PE in the VRF allowing
the customers to have a dual-stack VPN supporting both IPv4
and IPv6.
We will cover 6PE and 6VPE later with all details...

2. IPv4 Address Depletion
As we have seen earlier, the IPv4 address Depletion tarted to
be a problem in the 90s and while some people were working
on new protocols to replace IPv4, some others were working on
a workaround to keep on working longer with IPv4.

They came up with NAT and Private Addresses (RFC1918). Before RFC1918, some people were already doing some private
addressing but it was at their own risk if they were choosing an
address already in use and the could need one day to join like
for instance 7.0.0.0/8 or 9.0.0.0/8. One of these was used in my
company in the early 90s with Proxies to reach the Internet for
http or ftp protocols.
Now with RFC1918, some block were reserved for private addressing and NATPT aka PAT, it was possible to use one Public
Address for a whole building or all the PCs of a Residential
user.
Let's take a shortcut and call NAT: NAT, NATPT or PAT.
NAT immediately solved the problem for many years but at the
same time it killed some concepts which made the popularity of
the Internet like the End-to-End Addressing or peer to peer capabilities.
In the 90s, this was the time for Downsizing and Client-Server
Applications. Many companies moved to TCP/IP for this reason.
Downsizing was the migration of Applications from Mainframes
to Servers running on RISC Workstations, Mini Computers (AS/
400) or even PCs and PS/2s.

12

Client-Server Applications was the migration from hierarchical
Applications runnning on a Mainframe and accessed by dumb
terminals to Applications on Servers
accessed by smart Clients, mostly micro computers or Unix Plaforms, PCs
F IGURE 2.1 IPv4
Addresses
or RISC based.

Depletion
To keep on working with NAT now we
have to provision a Public Address for
each server and configure a Static
NAT Translation for each Server. This
can become tedious when you have a
lot of servers to manage. And we cannot save anymore address still each
server requires a Public Address.

tion but when you look into it you find that it actually cost a fortune in hidden cost and thousands of lines of code to support it!
To support Voice application, Skype workaround is to use a
Server in the middle of your connection and your Smartphone
must send keepalive on a regular basis to keep the NAT States
up draining you batteries.

F IGURE 2.2 HE IPv4 Addresses depletion#
#
#
#
#
#
#
#
#

#

NAT introduced many states in the IP
Network which was a datagram besteffort model and this has many Architectural Implications. Just make a
search in the IETF Server for all the
RFCs about NAT or PAT or NAPT and
you will find more than 80 documents
explaining the li;itations, how to workaround NAT to support most of the
Network Applications.
NAT seems an easy and cheap solu13

Skype make it with the cost of a server and keepalives but
many voice applications are still impossible because of NAT!

vices and new applications which requires more and more addresses and even more and more ports (Ajax)!

A 10.0.0/8 block looks a big block for the needs of most companies, but it is still to small for some very large companies or
some Service Providers. That's why the Cable SPs requested
that DOCSIS 3.0 supports IPv6!

The Cable Networks Operators have requested that the last
DOCSIS Cable standard MUST support IPv6.

Today even with the use of NAT we are now running out of IPv4
Addresses in most region of the World!

And even if the Service Provider was running NAT a second
time in the SP Backbone to share an IPv4 Address among multiple Customers (NAT444) this could not give enough addresses
to match the need of all the emerging countries, the need for
more than one IPv4 address per user. We must now supports
plenty of new connected devices which were not existing in the
90s: Smartphones, iPAD, and so on...
So today the question is no more if we need to move ot IPv6
but when!

3.The Current Market Needs
We have seen that IPv4 even with double NAT could not provide enough addresses for all the Emerging Countries, new de-

Voice Applications suffer more and more from the NAT limitations and Mobile IPv6 or Proxy Mobile IPv6 can bring solutions
impossible to solve for IPv4.
We need autonomous devices which not only do autoconﬁguration but also can form Networks dynamically after they automatically discover neighbors. This is Wireless Sensors Networks
(6LowPAN) applications.

4.Transition Richness
Since the IPv6 introduction, tools for a soft transition were provided. They have evolved with the time and the demand.
In 1996, IPv6 was shipped with dual-stack and static tunnels.
You can ﬁnd a Video: 
http://bit.ly/Lqahj0
And a Presentation: 
http://slidesha.re/GQuwo3
While the Internet is still growing very fast with more connected
devices every day, the available IPv4 addresses declined and
14

F IGURE 2.4 Maximize the few remaining Public IPv4
Addresses: NAT444 (CGN or LSN)

F IGURE 2.3 Transition Summary

TransitionTools - Deployment

NAT44
(CGN/LSN)

NAT44

172.19.0.0 -> 10.0.0.0

10.0.0.0 -> 202.45.3.0

NAT64

2010

IPv4
Internet

IETF Taipei 82 – Nov 2011

Time

DS-Lite

Deployed

2007

NAT444
DS-Lite
dIVI-pd
dIVI

IPv4 in IPv6
Tunnels

6RD

NAT464

dIVI-pd

A+P

Testing

6PE

2003

IPv6 in IPv4
Tunnels

6BONE †

ISP Control
RFC 1918
172.16.0.0/12

172.17.0.0/12

6VPE

172.19.0.0/12

NAT44

ISP
IPv4 Private
Network
10.0.0.0/8

NAT44

1996

Standardization
Dual-Stack
6in4 NAT-PT

© 2011 Fred Bovy EIRL. IPv6 For Life!. fred@fredbovy.com

6to4

6RD
6VPE

6PE

NAT64 dIVI-pd
NAT444
DS-Lite A+P

172.18.0.0/12

Transition to IPv6—5

NAT444 is a simple and efﬁcient way to share the few remaining
addresses but it also breaks a bit more functionalitites than NAT44.
This will be discussed in all details in the Next Volume in the Transition
to IPv6 Module about NAT444.

IANA is completely depleted since February 2011. As IPv6 is
now implemented for more than 15 years and available on most
Operating Systems and Network vendors, most Service Providers and even more companies have not yet switched to the
next generation Internet protocol. As a consequence we still

need to buy some time to allow a smooth transition to IPv6. It is
planned that we will need to support mixed IPv4 and IPv6 network

15

F IGURE 2.5 Tunneling of IPv4 in IPv6 & LSN: DS-Lite

DS-Lite

IPv4 traffc is tunneled to the AFTR where Address is Xlated
IPv6 talks with IPv6 natively thru the IPv6 Internet.

AFTR Decapsulates IPv4 packet and NAT occurs
10.1.1.1
199.3.4.1

IPv4 PC
10.1.1.1.1/24

IPv4 RFC1918
10.1.1.0/24

if Dest= 2001:451a:340f:9873:f00d:bad:cafe:1
OUT of Domain 2001:db8::/32,
send to the BR to be switched out to the IPv6 Internet via the BR

IPv6 thru IPv4
(no MPLS): 6RD
IPv6
Internet

IPv4 Internet

BE4 encapsulates IPv4 packet in IPv6 and sends it to the AFTR
DS-Lite
Be4

F IGURE 2.6 Tunneling of IPv6 in IPv4: 6RD

IPv6 Internet

6RD
2001:db8:678:d300::/56
Residential Gateways
NAT44

IPv6 Server

IPv6
CU#2

2001:341f::1:57/64
2001:341f::/32

2001:db8:678::1/64
(SLAAC)

Here we show DS-Lite.
As an alternative we could use 4RD instead.
B4 node encapsulates IPv4 in IPv6.
AFTR decapsulates if needed and translate IP source address with a public address

Clearly, maximum performances, security and other beneﬁts we
can think about running IPv6 will be achieved when transition
will be over.
During transition we will need to compromise features, performances and security for the beneﬁt of supporting old
IPv4 nodes and applications.
We have to address the four following problems:
✴ To Support a maximum of new IPv4 customers with the
few remaining IPv4 Public Addresses. 

IPv6 Server

2001:db8:678:2100::/64

2001:db8:678::1

IPv6
Internet

6RD
Border Relay
[LSN]

DS-Lite
AFTR

IPv6 Internet
or SP core

IPv4 Internet

2001:db8:678:2100::/56
IPv4 RFC1918
10.1.1.0/24
and IPv6
2001:db8:678:d340:98:22ac:f9:1

IPv6 Traffc:

When neighbor is in the same 2001:db8::/32 domain, encapsulate
in IPv4 and send to the neighbor otherwise send to the closest BR
(anycast) for forwarding via the Internet.

if Dest= 2001:db8:678:2100:f00d:bad:cafe:1
IN Domain 2001:db8::/32,
Encapsulate the IPv6 packet in IPv4.
Dest Ipv4 is address of the Neighbor

IPv4 Traffc:

NAT then send it out to the IPv4 Internet.
Can be double NATted by the BR

This implies more sharing of the remaining addresses. 
The current solutions to address this problem are the Stateful
Carrier Grade NAT (CGN) aka Large Scale NAT (LSN) and the
Stateless dIVI-pd or A+P Solutions. See Figure 2.4
✴SPs with IPv4 Backbones need to provide IPv6 Access to
the IPv6 Internet or among IPv6 customers. 
This is based on 6PE or 6VPE for MPLS/IPv4 or 6RD for IPv4
Backbone. See Figure 2.6

16

✴SPs with IPv6 Backbone need to provide IPv4 Access to
the IPv4 Internet or among IPv4 Customers. 
This is based on DS-Lite or 4RD based Solutions. See Figure
2.5
✴To Provide access to IPv4 Resources for IPv6 ONLY Customers. 
This is based on Address Family Translators with NAT64 and
DNS64 currently the best solutions. These translators permit

F IGURE 2.7 Stateless NAT64
Web Server
IPv4
NAT64

SYN 192.0.2.1
SYN+ACK

IPv6

SYN
64:ff9b::c0:201

+A
SYN
h2.exemple.com ?

✴With Stateless it is a One-to-One translation using a reserved
IPv6 preﬁx.
✴With Stateful NAT64, multiple IPv4 address can be translated
to one IPv6 addresses.
There is a Stateless implementation on Linux called TAYGA.
They say on theire Web site that to get a stateful NAT64 one
just need to combine their TAYGA with a Statefull NAT44 also
available on Linux.
This will be more developed in the next book with a module or a
full book about Translation to IPv6. There are so much possibilies and so much technologies being tested that if we really
want to cover all the experience which are currently or lately performed.

IPv4

CK

DNS

DNS64
h2.exemple.com ?
A: 192.0.2.1

AAAA
64:ff9b::c0:201
© 2012 Frédéric Bovy EIRL. IPv6 For Life!

to translate IPv6 to IPv4 packets originating from the IPv6
side.

17

5.What are the IPv6 improvements?
5.1. 128 bits Addresses

The very large IPv6 address space supports a total of 2128
(about 3.4×1038) addresses - or approximately 5×1028
(roughly 295) addresses for each of the roughly 6.5 billion
(6.5×109) people alive today. In a different perspective, this is
252 addresses for every observable star in the known universe.

IPv6 addresses - how many is that in numbers?
IPv6 is our Word of the Day today. The big difference between it
andIPv4 is the increase in address space. IPv4 addresses are
32 bits; IPv6 addresses are 128 bits. That’s a lot more, for sure,
but what does it look like in numbers? What could we compare
it to in real-world terms?
DevDevin did the math:
How many IP addresses does IPv6 support? Well, without
knowing the exact implementation details, we can get a rough
estimate based on the fact that it uses 128 bits. So 2 to the
power of 128 ends up being
340,282,366,920,938,000,000,000,000,000,000,000,000
unique IP addresses.
How do you say that, though? 340 trillion, 282 billion, 366 million, 920 thousand, 938 — followed by 24 zeroes. There’s no
short way to say it in numbers without resorting to math.
Here’s how Wikipedia expresses it:

Steve Leibson takes a shot at putting it in real world terms. It’s
big — grains of sand don’t even enter into it. No, he’s got to
take it to the atomic level. Here’s his conclusion:
So we could assign an IPv6 address to EVERY ATOM ON
THE SURFACE OF THE EARTH, and still have enough addresses left to do another 100+ earths. It isn’t remotely
likely that we’ll run out of IPV6 addresses at any time in the
future.
5.2. Extension Headers
In IPv4 we had a limited amount of Option which could not provide for any new Extension. In IPv6 we have Extension Headers instead. These Extension Headers can be daisy chained so
it is now possible to put as many Option as we want in an IPv6
packet to support any new IPv6 Level Applications.
The ﬁrst great example of what we can do with Extension Headers is Mobile IPv6 and all derived applications: Mobile router
(NEMO), MANET, Wireless Sensors Networks (6LowPAN),

18

PMIPv6. As we can tweak Addresses at the Network Layer it becomes transparent for the Transport or Application Level.
5.3. More Efficient Packets Switching
No more Header Checksum in IPv6. This field has been completely removed.
Header aligned on 64 bits for more efficient access.
Routers are no more responsible for fragmentation. If fragmentation must be done, it must be done by the source. The fragmentation information are no more carried in each packet but in
an Extension Header if needed.

19

IPv6 Addresses

3

IPv6 Addresses are not
only much bigger than IPv4
but there are multiple sort
of addresses to address
different needs, allow
autoconﬁguration and
more. IPv6 nodes have
more than one Routing
Table as well.

Module 3

IPv6 Addresses

TOPICS

1.Introduction
IPv6 not only make longer addresses but also makes a better
use of addresses and how to manage it. For instance if you
have a small LAN without any routers, the workstations will be
able to pick up an address automatically which will only be valid
on this LAN (Link-local) and will permit the Node to be automatically configured with a local address. Then if a router comes up,
new prefixes will be advertized by the router and the Workstation will automatically configure addresses derived from these
prefixes. Most important things are:

1. IPv6 Addresses Introduction
2. What does 128 bits represent?
3. IPv6 Unicast Addresses
1. Global Unicast Addresses
2. Unique Local Addresses
3. Link-Local Addresses
4. Special Addresses
4. Anycast Addresses
5. Multicast Addresses

There is no more Broadcast, only Multicast!
Link-Local addresses only valid on the link where it is configured. This leads to the concept of Zone. This Link-local address
belongs to a zone with its own routing table.
Anycast Addresses which is an address to the nearest Service. This was already existing in IPv4 but now it is fully managed.
Routers are discovered Automatically
ARP has been dramatically improved in the Neighbor Discovery protocol. There is no more just a TImeout for the MAC to IP
Address cache but the Neighbors are Managed in the cache by
a Finite State Machine. Useless entries of dead neighbors are
21

cleared when a Timer expires a a few probes are sent to the
neighbor (About 35 seconds with default).
The concept of zone is also important in IPv6. For the moment it mostly applies to Multicast and Link-local Addresses but
it could be used to creat VPN still each zone has its own Routing Table (Please see RFC4007 "Scoped Zone Architecture" for
more details).
See RFC4291 for IPv6 Address Architecture

2.What does 128 bit represent?
 
We could assign an IPv6 address to EVERY ATOM ON THE
SURFACE OF THE EARTH, and still have enough
addresses left to do another 100+ earths.
It isn’t remotely likely that we’ll run out of IPV6 addresses at any
time in the future!
So we must change the way we design networks and stop
trying to save IP Addresses!
We must give large blocks when needed as wasting IPv6
Addresses is not to use the huge amount of available
address to make scalable Networks rather than saving
each single bit of Address! Wasting Addresses does not
mean the same thing in IPv6 than IPv4!

3.How to write an IPv6 Address?
The 128 bits Address is written as 8 16 bits digits written in
Hexa and separated by colon :.
Leading zeros can be ignored. You can write: 
2001:db8:1:459d:f123:98ab:d0:e1 
instead of: 
2001:0db8:0001:459d:f123:98ab:00d0:00e1.
Once in the address you can replace a long list of zeroes with
double colons :: 
You can write: 
2001:db8::1 
instead of: 
2001:db8:0:0:0:0:0:1
The IPv6 Addresses are:
Unicast: One to One
Global Unicast Addresses (Public) 
Unique Local Addresses (Private) 
Link-Local Address  
Special addresses: loopback, unspeciﬁed, IPv4 Mapped
Anycast: One to Any
Multicast: One to Many
22

4.IPv6 Unicast Addresses
4.1. Global Unicast Addresses (Public)
The Global Unicast Addresses are similar to the Public IPv4
addresses and are routable in the IPv6 Internet.

Global Unicast Addresses 0010 or 2000::/3. Then you have a
prefix matching a Regional Internet Registry, a RIR and then
the part of the Address which address the Customer. The most
common prefixes are typically a /48 Prefix for each site. This
may seems overkilled but we do not waste addresses if we use
them. We waste them if we don't!
2001:db8::/16 is reserved for documentation and labs!

In the Internet 2000::/3 (binary 0010) is reserved by IANA
for global unicast address. You will find more details on the
Internet here and RFC4291 for IPv6 Address Architecture:
http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unica
st-address-assignments.xml
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-re
gistry.xml
As the Global Routing Prefix contains the IANA prefix for Global Unicast Adddress, a prefix which identifies the Regional Internet Registries (RIPE in
Europe for instance) and eventually another prefix which identifies the ISP: 

4.1.2.

These bits can be used by the customer to address many subnets for each site. We may find that using a /48 prefix for each
site may be a waste of Addresses with our IPv4 reflexes but this
is actually the other ways around as we have so many addresses available that would be wasting address if we were trying to save addresses instead of using them generously to maximize the scalability of the addressing and allow easy growing of
the sites.
4.1.3.

IPv6 addresses are made of 128 bits but we still find the same 3 parts that we
have in an IPv4 Address:

4.1.1.

Global Routing Prefix

The Subnets bits

The Interface ID

The Interface ID is similar to the IPv4 Host Address. It is used
to identify the Host itself.
4.1.3.1.

EUI-64 or Modified EUI-64

An ISP Customer Prefix used to route the Packet to the Customer. This Prefix itself is built of a common prefix for all the
23

This address is generally derived from the Interface MAC Address which is 48 bit. 0xFFFFE is added in the middle of the
MAC address to make a 64 bits address:

4.1.3.3.

Manually Configured

On Routers or some servers it may be better to assign static addresses instead of EUI or Random Interface ID.
For instance, in a Datacenter your router HSRPv6 Group could
be 2001:db8:a01::1 and you may configure a static default
route on all your Servers.
You make sure that your system will not waste anytime or receive any Rogue information!

In this example, the MAC Address is 00-90-59-02-E0-F9.
The EUI-64 Address will be: 90:59ff:ff02:e0f9 
And the Modified EUI-64 Address will be: 290:59ff:fe02:e0f9

4.2. Unique Local Addresses (Private. RFC4193)
The ULA are Private Unicast Addresses not routable on the
Internet.

For the Modified EUI-64 address X=1 which means that the address is a Locally Administratively Managed Address.
4.1.3.2.

Temporary Random Prefix (RFC4941)

As NAT is no more used and the Interface ID of a Laptop may
not change, a user may be tracked by its address. To avoid this
possible problem it is possible to use Random Temporary Interface ID and change it everyday!

The big benefits of ULA other RFC1918 in IPv4 is that you have
40 bits to make your Prefix Unique. So in case one day you

This is configurable on all the available platforms (Windows,
MAC OS, Linux).
24

need to merge two Private Networks using ULA Addresses you
may not have to renumber your Network.

not, the IPv6 Interface is disabled. The interface could be used
for other protocols but not IPv6!

Actually there are two kinds of ULA, the Locally Managed and
the Centrally Managed. If you make a Reservation and use the
Centrally Managed Addresses, there is absolutely no risk of
finding a duplicate subnet. With Locally Managed, the risk exist.

IPv6 Link-local addresses are only valid on the interface where
they are configured. If you have many interfaces on a host or a
router, it is no problem to use the same address for all the
interfaces.

You can make a reservation at this URL: 
http://www.sixxs.net/tools/grh/ula/

They all start with the prefix fe80::/10.

At the beginning of IPv6 they were no ULA but a prefix for
site-local addresses: fec0::/10. But with this approach we had
the same problem that with RFC1928 IPv4 Addresses so this
prefix is no more reserved for Site-Local Addresses which are
deprecated and replaced by ULA.
To access the Internet from ULA Address you may need
Proxies. For instance if your internal Servers only need http or
ftp access to the Internet for SW Updates at night, ULA + Proxy
may be the right approach.

When you are using a Link-local address in a command, you
must specify the Outgoing interface by its name or its index with
the % sign in between like: 
fe80::34f:a011:2:d78%FastEthernet1 on Cisco Router or 
fe80::34f:a011:2:d78%15 on Microsoft Windows, 15 is the
interface index.
In IPv4 it is similar to the 169.254.0.0/16 address (RFC 3927).

4.3. Link-local Addresses
Link-local Addresses are the Only Mandatories Addresses for
each interface. When an IPv6 interface is coming up, the first
step is to validate that its Link-local address is unique (Valid). If

All the Next Hop but recursive static or BGP routes use a
Link-local address.

4.4. Special Addresses
4.4.1.Unspecified Address is ::/0
25

The Uspecified is only use as a source address whe n a node is
booting and it is verifying its Link-local Address.

4.4.4.Encapsulation of IPv6 in Ethernet
IPv6 Protocol is 0x86dd

A router MUST NOT route a packet with an unspecified source
address.

4.4.2.Loopback Address is ::1
The loopback Address is a Link-local address to the node itself.
It must not be assigned to any physicall interface. It is similar to
the IPv4 127.0.0.1 address.

4.4.3.IPv4 Mapped Address
This is used when you need to code an IPv4 address in the
IPv6 format. For instance with 6PE or 6VPE, the destination
IPv6 Address will have the Egress PE IPv4 Loopback interface.
This is illegal for BGP to advertize a destination with a next hop
of another Address Family. So the Next Hop is coded as an
IPv4 Mapped Address.

5. IPv6 Anycast Addresses
This is a one to any addressing.
Anycast Addresses are like duplicated Unicast Addresses. The
goal os to find the neares server implementing a function.
It was already existing in IPv4 for the DNS Root Servers. We
have only 13 addresses which represents more than 200
physical servers.
In IPv4 it was also used by Anycast RP to find the nearest RP
in a redundant RP mode using MSDP to make the RPs
communicate each other.

You got 80 bit set to 0, then 16 bits set to ffff and then the 32
bits of your IPv4 address:  
0:0:0:0:0:ffff:<32 bits IPv4 Address>

These addresses do not have any reserved prefix so you
cannot recognize an Anycast Address from a Unicast.

If the next hop was 192.9.0.1 it would be coded: 
::ffff:192.9.0.1 or 
::ffff:c009:1

6. IPv6 Multicast Addresses
This is a one to many addressing.
26

There is no Broadcast in IPv6 only Multicast. But you have an
address for all IPv6 nodes (ff02::1) as in IPv4 an address for all
IPv4 node (224.0.0.1). The prefix ff02:: is reserved just like
224.0.0.x for IPv4.
Multicast Addresses are used like in IPv4, when a source needs
to send a packet to a Group of Receivers.

The Flags are used for Embedded RP Address. This is new in
IPv6 and allow the RP Address to be embedded in the Group
Address. We will study the Flags when we will cover the
Multicast in detail.

ff05::1:3 All DHCP Servers. Site-local Scope (used by Relays) 
ff02::2 All IPv6 Routers. Link-local Scope 
ff02::5 All IPv6 OSPFv3 Routers. Link-local Scope 
ff02::6 All IPv6 OSPFv3 DR Routers. Link-local Scope 
ff02::9 All IPv6 RIPng Routers. Link-local Scope 
ff02::A All IPv6 EIGRP Routers. Link-local Scope
Only the Link-local Scope are automatically filtered and not
forwarded by Routers. All the others Scope must be
implemented with ACLs.
For each unicast or anycast address configured, the IPv6 node
automatically configure a Solicited Node Multicast Address
derived address. This address is setup with a common
Multicast Prefix and the last 24 bits of the Unicast Address.

The Scope is also new in IPv6 and allow to set the Scope of
the Multicast Group:
1 is Node Local 
2 is Link-local scope. Example:ff02::1 
4 is Admin-local 
5 is Site-local 
8 is Organization-local 
E is a Global Group

Example:
Unicast Address 
2001:DB8:DC28::FC57:D4C8:1FFF
Solicited Node Multicast Prefix 
FF02:0:0:0:0:1:FF

Example: 
ff02::1:2 All DHCP Servers and Relay. Link-local Scope 
27

Solicited-node multicast address  
FF02:0:0:0:0:1:FFC8:1FFF

F IGURE 3.2

IPv6 Global Unicast Address Format (RFC 3587)

6.1. Encapsulation of IPv6 in Ethernet

Initial Format

6.2.

Provider . n bits

64 .n bits

Host. 64 bits

Global Routing Prefix

Subnet ID

Interface ID

IETF assigned 001 for Global Unicast, 2620::/12 assigned to American
Registry for Internet Numbers
3

9 bits

36 bits

16 Bits

Host. 64 bits

00
1

ARIN

RIR or ISP

Subnet ID

Interface ID

RFC 2374: Aggregatable Global Unicast Address Structure

F IGURE 3.1 Address Plan Example

Public Topology

Site Topology

Interface Identifier

3

13

8

24

16

64 bits

FP

TLA ID

RES

NLA ID

SLA ID

Interface ID

© Frédéric Bovy - October 2011 - 37

7.IPv6 Address Plan Example
2001:db8:abcd::/48 has been assigned for the USA offices of
this company.  
Each Regional largest office aggregates the traffic for the area
as a /52 route. In the address 2001:db8:abcd:9000::/52, 9
identifies the West Coast. 
Each office has a /56 prefix. In the address
2001:db8:abcd:9100::/56, 91 identifies San Francisco Office. 
Then 2001:db8:abcd:9101::/64 may be the first LAN in SF.

8.The Multihoming Issue
28

8.1. IPv6 Addressing Hierarchy
Having an addresss 4 times bigger, the IPv6 designers didn't
Cust1
21ae:db8:1::/48

ISP1
21ae:db8::/32

RIR1
21ae::/8

Cust2
21ae:db9:1::/48

ISP2
IANA

21ae:db9::/32

2000::/3

Cust3
2001:db8:1::/48

Cust4

ISP3

RIR2
2001::/8

2001:db8::/32

2001:db8:2::/48

want to need 4 times more memory! So they designed a model
to maximize Aggregation.
IANA has allocated the block 2000::/3 for Global Unicast
Addresses. Then in your address you will have a Prefix which
identifies each Regional Internet Registry: RIPE-NCC, ARIN,
APNIC, AfricNIC, LACNIC. And a Prefix for each SP
The end user does not own a Prefix and if he changes of SP he
will have to renumber its Network with a new Prefix.

The goal is to maximize route Aggregation allowing each SP to
summarize all its client with one or a few Prefixes. This is what
we call Provider Assigned (PA) Prefixes.

8.2. Multihoming Issue and solutions
This works very well as long as a customer does not want to
use more than one SP for Redundancy or other reasons like
best price in different regions of the world for instance.
In this case, the customer will have to deal with multiple
Prefixes. This is not a problem again as any IPv6 interface can
be configured with multiple Prefixes.
The problem is for resiliency and load-balancing.
29

There is a Flash animations which explains this issue very
clearly, just use the URL:

8.3. Provider Independant Addresses

http://www.fredbovy.com/Tutorial/Multihoming/run-local/Main.swf

The best solution which may be expensive in some region is
the Provider Indendant (PI) Prefixes.

This actually comes from my Free On-Line Tutorial
Fundamentals #2.

They are available since 2009 and we can see that the number
of IPv6 prefixes has started to increased tremendously since

F IGURE 3.4 Provider-Independant Address

F IGURE 3.3 Provider-Assigned Address

ISP1

ISP2

ISP1
2001::db8::/32
2001:db8:1::/48

2001:db8:1::/48
2001:db8:66::/48

2001:db9::/32
2001:db9:100::/48
2001:db8:1::/48

ISP2
2001:db8:100::/48
2001:db8:66::/48

2001:db8:100::/48

2001:db8:66::/48
2001:db8:1::/48

2001:db9:100::/48
2001:db8:1::/48

2001:db8:1::/48
2001:db8:100::/48
2001:db8:66::/48

2001:db9:100::/48

this date. First because there was no solution to this problem
before and then because we cannot Aggregate the PI PRefix
since it punch a hole in the summary address for each SP
where it does not fall into one of its summary and must be
advertised independantly.
30

F IGURE 3.5 Provider-Assigned Fault_tolerance (1/3)

  Dest thru ISP2 is no longer reachable

  Better route from ISP2

  The session fails

  A session is started
ISP1

F IGURE 3.6 PA Preferred path failed (2/3)

ISP2

ISP1

ISP2

2001:db8:1::/48

2001:db9:100::/48

2001:db8:1::/48

2001:db9:100::/
48
2001:db9:100:99:42:345F:1:1/64
2001:db8:1:99:42:345F:1:1/64

Each node has 2 addresses derived from the block of each of the 2
providers.
If the customers uses more SP it will be more addresses to manage by
each Workstation.
The routing provide a best route or if the routes have equal metric, it is
load-balanced per-destination.#

2001:db9:100:99:42:345F:1:1/64
2001:db8:1:99:42:345F:1:1/64

If the right hand SP fails or aany of its upstream neighbor fails, the
session must be restarted with the left hand SP router.
Then the people who were logged to an aplication will have to login
again in most cases.
This conﬁguration provides no load-sharing, no redundancy as a new
session will require a new login for most applicatioin.
THIS IS THE IPv6 DAY #1 BIG MISSING FEATURE!!!
A Protocol like Shim6 or HIP should have been part of IPv6 just like
Mobile IPv6 which was a much bigger problem to tackle!
Solutioin is PI Address but we have seen that the Routing Table of the
routers have started to grow exponentially in 2009 when PI Addresses
were introduced.
31

In this case your RIR will allocates a Prefix to the end-user who
is authorized to advertize its own prefix to multiple SPs. Below
is an Example 2001:678:e01::/48 has been assigned to this
company and the same prefix is advertized to SP ACME and
ABC! So each of thes SP will have to aadvertize this Prefix in
the IPv6 Internet if it does not fall under the summaries of each
SP.
It is seen as a short term solution as a long term solution should
permit maximum aggregation and must be managed by Hosts
or Routers.

F IGURE 3.7 PA A new path must be set. User MUST
relogin in most cases (3/3)
8.4. Other Solutions

  A new session must be started

ISP1

ISP2

2001:db8:1::/48
2001:db9:100::/48
2001:db9:100:99:42:345F:1:1/64
2001:db8:1:99:42:345F:1:1/64

There are some host based and routers based solutions to solve this
problem without loosing the maximum Aggregation of the PA Prefixes.
Some solutions are host based like shim6 or HIP which also managed
Mobility and some others are managed by the routers like LISP.
"The basic idea behind the Loc/ID split is that the current Internet routing
and addressing architecture combines two functions: Routing Locators
(RLOCs), which describe how a device is attached to the network, and
Endpoint Identifiers (EIDs), which define "who" the device is, in a single
numbering space, the IP address. Proponents of the Loc/ID split argue
that this "overloading" of functions makes it virtually impossible to build
32

an efficient routing system without forcing unacceptable constraints on
end-system use of addresses. Splitting these functions apart by using
different numbering spaces for EIDs and RLOCs yields several
advantages, including improved scalability of the routing system through
greater aggregation of RLOCs. To achieve this aggregation, we must
allocate RLOCs in a way that is congruent with the topology of the
network ("Rekhter's Law"). Today's "provider-allocated" IP address space
is an example of such an allocation scheme. EIDs, on the other hand,
are typically allocated along organizational boundaries. Because the
network topology and organizational hierarchies are rarely congruent, it
is difficult (if not impossible) to make a single numbering space efficiently
serve both purposes without imposing unacceptable constraints (such as
requiring renumbering upon provider changes) on the use of that space.
LISP, as a specific instance of the Loc/ID split, aims to decouple location
and identity. This decoupling will facilitate improved aggregation of the
RLOC space, implement persistent identity in the EID space, and, in
some cases, increase the security and efficiency of network mobility."
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_lisp.html

33

IPv6 Headers

4

The IPv6 headers is a
simplified and more flexible
header than IPv4. It has
much longer addresses,
less fields, no more header
checksum and Extension
Headers can be daisy
chained.

Module 4

IPv6 Header

1.IPv6 vs IPv4 Headers
F IGURE 4.1 IPv4 Header

TOPIC
1. IPv6 header compared to IPv4
2. Path MTU Discovery
3. More Flexibility with the Extension Headers

F IGURE 4.2 IPv6 Header

4. MAC Address Encapsulation

35

No more Fragmentation fields (Fragment ID, Frag Offset, Flags). Fragmentation is no longer performed by Routers
but only the source of the Traffic and an Extension Header will
be used for the Fragmentation information
# No more Header Checksum as it was redundant with the
Link Layer and Transport Checksum
# Other fields have been renamed with more explicit names
like Hop Limit instead of TTL,
# The Traffic Class used instead of ToS/Precedence but
still transport a DSCP for QoS
#

IPv6 Addresses are 4 times larger.

# The Protocol field is replaced with Next Header as now
the Headers can be daisy chained to add several options to a
packet!
# A new field pretty much unused so far: the Flow Label. It
should be used to identify a flow with the Source and Destination Addresses. It is not used for two reasons:
1) There is no common agreement to use it in a standard way.
2) People are scared that a non default Flow Label (0) would give
an information to hackers about the sensitive traffic!

#

2.Path MTU Discovery
Fragmentation is expensive as it consumes resource on the
Router or the Host which fragment the packet and it also consumes resources on the destination host which reassemble the
packets.
Some Firewall or NAT devices do the reassembly as they need
the information contained in the first fragment like the Port numbers.
Fragmentation is also a very easy to initiate DoS Attacks as a
station sending traffic requiring a lot of Fragmentation or Reassembly can kill this station overwhelming its CPU!
So Fragmentation is avoided in IPv4 already systematically for
all TCP Traffic with a protocol call Path MTU Discovery!
The principle is that the station starts sending at the maximum
MTU and every time a Router cannot route the packet because
of MTU it drops the packet rather than fragmenting and sends
an ICMP Report providing the next Link MTU. The source
sends the next packet at this MTU and the operation may eventually be repeated.
MINIMUM MTU FOR IPv6 IS 1280 BYTES

The data are aligned on 64 bits for better memory access
36

1500 bytes

1

PATH MTU Discovery

MTU1400 bytes
1400 bytes

1500 bytes

2

1300 bytes

1500 bytes

1400 bytes

MTU1300 bytes

3

1300 bytes

3.Extension Headers
The biggest improvement which really gives IPv6 more Flexibility and Versatility is the use of daisy chained Extension Headers. Now, it becomes possible to push many headers in an IPv6
packet and as these Headers are TLV (Type, Length, Value)
you can add a new Header Extension to support a new Network
Layer Application.
The ﬁrst great example of what we can do will be introduced in
a later Module. This is for Mobile IPv6 and the derived applications.

The Extension Headers are the following and SHOULD follow
this order:
Hop-by-hop. This Option MUST be checked by each router
in the path. In IPv4 we had the Router Alert to do the same and
this Router Alert is transported in this Option when needed. It is
used by Multicast (IGMP or PIM), RSVP and other applications.

Router Alert Option
The Router Alert Option (RFC2711) tells the router that it
must takes a look at the pacquet. It is carried in an
hop-by-hop option.

37

Example :
Frame 3836 (90 bytes on wire, 90 bytes captured)
Ethernet II, Src: ca:00:06:a9:00:1c (ca:00:06:a9:00:1c), Dst:
IPv6mcast_00:00:00:01 (33:33:00:00:00:01)
Destination: IPv6mcast_00:00:00:01 (33:33:00:00:00:01)
Source: ca:00:06:a9:00:1c (ca:00:06:a9:00:1c)
Type: IPv6 (0x86dd)
Internet Protocol Version 6
0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 36
Next header: IPv6 hop-by-hop option (0x00)
Hop limit: 1
Source: fe80::c800:6ff:fea9:1c (fe80::c800:6ff:fea9:1c)
Destination: ff02::1 (ff02::1)

Hop-by-Hop Option
Next header: ICMPv6 (0x3a)
Length: 0 (8 bytes)
Router alert: MLD (4 bytes)
PadN: 2 bytes

Internet Control Message Protocol v6
Type: 130 (Multicast listener query)
Code: 0
Checksum: 0x88d1 [correct]
Maximum response delay[ms]: 10000
Multicast Address: ::
S Flag: OFF
Robustness: 2
QQI: 125

Destination options. This Option is only checked by the Destination of the packet. Mobile IPv6 uses this Option.
If a routing header is present it tells what to do to each intermediary router. If there is no routing header, it is only for the ﬁnal
destination.

Example:
ca:01:06:a9:00:1c (ca:01:06:a9:00:1c)
0110 .... = Version: 6
.... 1010 0000 .... .... .... .... .... = Traffic class:
0x000000a0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 60
Hop limit: 64
Source: 2001:db8:c0a8:b:c800:6ff:fea9:1c
(2001:db8:c0a8:b:c800:6ff:fea9:1c)
Destination: 2001:db8:c0a8:b:c801:6ff:fea9:1c
(2001:db8:c0a8:b:c801:6ff:fea9:1c)
Hop-by-Hop Option
Next header: IPv6 destination option (0x3c)
Length: 0 (8 bytes)
PadN: 6 bytes

Destination Option
Next header: UDP (0x11)
Length: 0 (8 bytes)
PadN: 6 bytes

User Datagram Protocol, Src Port: 57768 (57768), Dst Port: echo (7)  
Echo 

Routing Header. 3 Types. Type 0 and 1 are now deprecated
and should not be used anymore, too dangerous. Type 2 is still
used by Mobile IPv6.
Type 0. There is a list of addresses in the header and the
packet must go through each of the routers listed. There is a
pointer for the router to know where in the list we are. The destination IP address of the IP paquet is the next hop of the source
routing header. This was not the case in IPv4 where the IP
source and destination IP addresses were not modiﬁed by
source routing. It is now deprecated since RFC5095.
38

Type 1 is deprecated for a long time.
Type 2 are used by Mobile IPv6. It is used to specify the home
address of the mobile node. Only one hop!
Example of a capture. Note that the addresses used are the
deprecated site-local addresses :
Frame:
+ Ethernet: Etype = IPv6
- Ipv6: Next Protocol = ICMPv6, Payload Length = 64
+ Versions: IPv6, Internet Protocol, DSCP 0
PayloadLength: 64 (0x40)

The Jumbo payload option allow for larger datagram than the
65,536 permitted by plain IPv6. With Jumbo payload option, it
can be up to 4,294,967,295 octets (RFC2675).
Upper layer

4.MAC Encapsulation of IPv6 Packets
4.1. Ethernet Protocol Encapsulation

NextProtocol: IPv6 Routing header, 43(0x2b)
HopLimit: 127 (0x7F)
SourceAddress: FEC0:0:0:2:2B0:D0FF:FEE9:4133
DestinationAddress: FEC0:0:0:2:260:97FF:FE02:578F
- RoutingHeader:

NextHeader: ICMPv6
ExtHdrLen: 2(24 bytes)
RoutingType: 0 (0x0)
SegmentsLeft: 1 (0x1)
Reserved: 0 (0x0)
RouteAddress: FEC0:0:0:1:260:8FF:FE32:F9D8

Protocol: 0x86dd 
In IPv4 it was 0x800 and 0x806 for ARP

4.2. Multicast MAC Address Mapping

+ Icmpv6: Echo request, ID = 0x0, Seq = 0x3d1a

Fragment. If the Source must fragment the packet.
IPSec Authentication (AH)
IPSec Authentication and Encryption (ESP)
Mobility. Used for the signaling of Mobile IPv6.
Destination option (if routing absent)
Jumbo Payload option
39

IPv6 ICMP

5

IPV6 ICMP is pretty much
the same as IPv4. The only
difference is a Parameter
Problem to report an error
in the IPv6 Header. Also
ICMpv6 carries more
protocols than IPv4.

Module 5

IPv6 ICMP

TOPIC
1. Introduction
2. Error Messages
3. Echo Request/Reply
4. Other Protocols supported by ICMPv6

1.Introduction

ICMPv6 can be used to report problems and to ping a destination.
The Type identiﬁes which kind of packet, which problem we
want to report like a "Destination Unreachable" or "Echo Request".
The Code gives more details about the problem. Why the destination is unreachable? Problem with destination address? port?
ﬁltered by an ACL? When ICMP is used to transport other protocols like "Neighbor Discovery" (next chapter), the code is null.
ICMPv6 manage much more in IPv6 than its IPv4 counterpart.
For instance Neighbor Discovery and Multicast Listener Discovery are now part of ICMPv6.
Many ICMP Information are provided in some standard ICMP
Options which are Mandatory with some requests.

2. ICMP Error Messages
Error Messages:
41

1. Destination Unreachable (Type 1)
2. Packet Too Big (Type 2)
3. Time Exceeded (Type 3)
4. Parameter Problem (Type 4)

2.1. ICMPv6 Destination Unreachable (Type 1)
Code
 
0 - No route to destination 
1 - Communication with destination administratively prohibited 
2 - Beyond scope of source address 
3 - Address unreachable 
4 - Port unreachable 
5 - Source address failed ingress/egress policy 
6 - Reject route to destination
Example : Port Unreachable
Ethernet II, Src: ca:01:01:90:00:08 (ca:01:01:90:00:08), Dst:
ca:00:01:90:00:08 (ca:00:01:90:00:08)
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class:
0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 1240
Hop limit: 64
Source: 2001:db8::2 (2001:db8::2)
Destination: 2001:db8::1 (2001:db8::1)

Type: 1 (Unreachable)
Code: 4 (Port unreachable)
Checksum: 0x9160 [correct]

0110 .... = Version: 6
.... 1100 0000 .... .... .... .... .... = Traffic class:
0x000000c0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel:
0x00000000
Payload length: 1960
Hop limit: 64
Source: 2001:db8::1 (2001:db8::1)
Destination: 2001:db8::2 (2001:db8::2)
Hop-by-Hop Option
Next header: IPv6 destination option (0x3c)
Length: 0 (8 bytes)
PadN: 6 bytes
Destination Option
Next header: UDP (0x11)
Length: 0 (8 bytes)
PadN: 6 bytes
User Datagram Protocol, Src Port: 56486 (56486), Dst Port: echo
(7)
Source port: 56486 (56486)
Destination port: echo (7)
Length: 1944
Checksum: 0xa5bd [unchecked, not all data available]
Echo

2.2. Packet Too Big (Type 2)
When a datagram is too big to be switched on an interface, an
ICMP mesage packet Too Big must be sent back to the sender.
MTU of the outgoing link is provided
Frame:
+ Ethernet: Etype = IPv6
- Ipv6: Next Protocol = ICMPv6, Payload Length = 1240
PayloadLength: 1240 (0x4D8)
NextProtocol: ICMPv6, 58(0x3a)
HopLimit: 64 (0x40)
SourceAddress: FEC0:0:0:F282:201:2FF:FE44:87D1
DestinationAddress: FEC0:0:0:F282:2B0:D0FF:FEE9:4143
-

Icmpv6: Packet too big
42

MessageType: Packet too big, 2(0x2)
- PacketTooBig:
Code: 0 (0x0)
Checksum: 44349 (0xAD3D)
MTU: 1280 (0x500)

- InvokingPacket: Next Protocol = ICMPv6, Payload Length = 1460
PayloadLength: 1460 (0x5B4)
NextProtocol: ICMPv6, 58(0x3a)
HopLimit: 63 (0x3F)
SourceAddress: FEC0:0:0:F282:2B:D0FF:FEE9:4143
DestinationAddress: FEC0:0:0:0:fredoc0:0:0:1

2.3. Time Exceed (type 3)
If Code = 0. Hop Limit Exceeded in Tansit. 
If Code = 1. Fragment Reassembly Time Exceeded. The receiving station could not reassemble the original datagram
within 60 seconds.

ca:01:06:a9:00:1c (ca:01:06:a9:00:1c)
Destination: ca:01:06:a9:00:1c (ca:01:06:a9:00:1c)
Source: ca:00:06:a9:00:1c (ca:00:06:a9:00:1c)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class:
0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 60
Hop limit: 64
(2001:db8:c0a8:b:c800:6ff:fea9:1c)
(2001:db8:c0a8:b:c801:6ff:fea9:1c)

Type: 128 (Echo request)
Code: 0
Checksum: 0x401b [correct]
ID: 0x062b
Sequence: 0x0002
Data (52 bytes)

2.4. Parameter Problem (type 4)
4.Echo Reply (Type 129)
Code
0 - Erroneous header ﬁeld encountered 
1 - Unrecognized Next Header type encountered 
2 - Unrecognized IPv6 option encountered

3.ICMPv6 Informational Messages
3.1. ICMPv6 Echo Request. (Type 128)

ca:00:06:a9:00:1c (ca:00:06:a9:00:1c)
Source: ca:01:06:a9:00:1c (ca:01:06:a9:00:1c)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class:
0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 60
Hop limit: 64

43

(2001:db8:c0a8:b:c801:6ff:fea9:1c)
(2001:db8:c0a8:b:c800:6ff:fea9:1c)

Type: 129 (Echo reply)
Code: 0
Checksum: 0x3f1b [correct]
ID: 0x062b
Sequence: 0x0002
Data (52 bytes)

R0>ping 2001:DB8:C0A8:B:C801:6FF:FEA9:1C
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to
2001:DB8:C0A8:B:C801:6FF:FEA9:1C, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max
= 8/19/32 ms
Please note that in IPv6 the paquet which triggers the MAC Address resolution is
not dropped but buffered, waiting for the resolution. This could be a potential target
for DoS attack but you can see ping reached 100% even the first time you ping a
destination.

5.Other Protocols supported by ICMP
ICMPv6 also supports Neighbor Discovery, SEcured Neighbor
Discovery, MLDv1 and MLDv2 for Multicast.
We are going to study ND in the next chapter and Multicast
later in this book. This will be an Intro to Multicast for IPv6 only
as I will develop Multicast for IPv6 in another book.
44

IPv6 Neighbor
Discovery

6

IPv6 Nodes on the same link
use NDP (rfc4861) to discover
each other’s presence and
link-layer addresses, to ﬁnd
routers, and to maintain
reachability information about
the paths to active neighbors.
Both hosts and routers use
NDP. Its functions include
Neighbor Discovery (ND),
Router Discovery (RD),
Address Autoconﬁguration,
Address Resolution, Neighbor
Unreachability Detection
(NUD), Duplicate Address
Detection (DAD), and
Redirection.

Module 6

IPv6 Neighbor
Discovery
TOPICS
1. Introduction
2. ND Packets and Options
3. Neighbor Discovery
1. MAC Address Resoolution
2. Neighbor Unreachability Detection (NUD)
3. Duplicate Address Discovery (DAD)
4. Router Discovery

1.Introduction
IPv6 Nodes on the same link use NDP (rfc4861, rfc4862) to discover each other’s presence and link-layer addresses, to find
routers, and to maintain reachability information about the paths
to active neighbors. Both hosts and routers use NDP.
Its functions include Neighbor Discovery (ND) and MAC or
Layer 2 Address Resolution, Router Discovery (RD), Address
Autoconfiguration, Address Resolution, Neighbor Unreachability
Detection (NUD), Duplicate Address Detection (DAD), and
Redirection.It is much more sophisticated than ARP was and
use a Finite State Machine (FSM) to manage its Neighbor
Cache. NDP use the 5 messages (PDU) and 5 Options.
The 5 bases PDUs are:
Neighbor Solicitation (NS)/Advertisements (NA)
Router Solicitation (RS)/Advertisements (RA)
Redirection
And 5 Options:
Source Link-Layer Address (SLLA). Option 1
Target Link-Layer Address (TLLA). Option 2

5. Autoconfiguration (SLAAC)

Prefix Information. Option 3

6. Renumbering

Redirected Header. Option 4
MTU. Option 5

46

2. ND Packets and Options
2.1. ND Packets
2.1.1.Router Solicitation

F IGURE 6.1 Router Advertizement
Code

Type

Curr Hop Limit M O H Resvd

IPv6 Layer
Link local or unspeciﬁed IPv6 address.
Link local all routers IPv6 address
ICMPv6 Layer
Type 133
Code 0
ICMPv6 Checksum
Source Link-Layer Address option
ICMPv6 Option (Source link-layer address)
Type: Source link-layer address (1)
Length: 8
Link-layer address: ca:02:06:a9:00:54
2.1.2.Router Advertisement
Sent on a regular basis or as an answer to a router solicitation.

Router Lifetime

Reachable Time

Sent by a host to get information from local routers.
MAC Layer
Source MAC Address is NIC address
Destination is all routers MAC address 33-33-00-00-00-02

Checksum

Retrans Time
Options...

Ethernet Layer
Source MAC of the sending NIC
Destination will be 33-33-00-00-00-01 or unicast
IPv6 Layer
Link local source
Destination will be all-nodes : FF02::1 or unicast address of
station which has sent the Router Solicitation
Hop Limit 255
ICMPv6 Layer
Router Advertisement
Type 134
Code 0
Checksum ICMPv6
Current Hop Limit
47

Managed Address Configuration Flag for Statefull DHCPv6.
Other Stateful Configuration Flag for Stateless DHCPv6
Router Lifetime
Retransmission timer
Source Link-Layer Address Option
MTU Option
Prefix Information Options
Advertisement Interval Option
Home Agent Information Option for Mobile IPv6

IPv6mcast_00:00:00:01 (33:33:00:00:00:01)
Source: ca:02:06:a9:00:1c (ca:02:06:a9:00:1c)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 64
Hop limit: 255
Type: 134 (Router advertisement)
Code: 0
Checksum: 0x90a8 [correct]
Cur hop limit: 64
Flags: 0x00
Router lifetime: 1800
Reachable time: 0
Retrans timer: 0

Length: 8
Link-layer address: ca:02:06:a9:00:1c
ICMPv6 Option (MTU)
Type: MTU (5)
Length: 8
MTU: 1500
ICMPv6 Option (Prefix information)
Type: Prefix information (3)
Length: 32
Prefix length: 64
Flags: 0xc0
Valid lifetime: 2592000
Preferred lifetime: 604800
Prefix: 2001:db8:c0a8:b::

2.1.3.Neighbor Solicitation

F IGURE 6.2 Neighbor Solicitation
Type

Code
Checksum
Reserved

Target Address
SLLA Option

IPv6 Layer
Source Address. Either an address assigned to the interface
from which this message is sent or (if Duplicate Address
Detection is in progress) the unspecified address.
48

Destination Address. Either the solicited-node multicast
address corresponding to the target address, or the target
address.
Hop Limit is 255
ICMPv6 Layer
Type 135
Code 0
Target Address
Possible Option:
Source Link-Layer Address Option
Used to ask the link layer address of a neighbour
ca:00:06:a9:00:1c (ca:00:06:a9:00:1c)
Source: ca:01:06:a9:00:1c (ca:01:06:a9:00:1c)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 32
Hop limit: 255
(2001:db8:c0a8:b:c800:6ff:fea9:1c)
Type: 135 (Neighbor solicitation)
Code: 0
Target: 2001:db8:c0a8:b:c800:6ff:fea9:1c
(2001:db8:c0a8:b:c800:6ff:fea9:1c)

Length: 8

2.1.4.Neighbor Advertisement

F IGURE 6.3 Neighbor Advertisement
Type
RSO

Code

Reserved

Checksum

Target Address
TLLA Option

They can be solicited or unsolicited.
ICMPv6 Layer
Type 136
Code 0
Router Flag if this is a Router
Solicited ﬂag if this is an answer to a Solicitation
Override Flag if it must override an entry in the cache
Target Address. For solicited advertisements, the Target
Address ﬁeld in the Neighbor Solicitation message that
prompted this advertisement. For an unsolicite advertisement,

49

the address whose link-layer address has changed. The Target
Address MUST NOT be a multicast address.
Possible Option: 
Target Link-Layer Address Option

2.1.5.Redirect
Inform a neighbor of a better next hop to reach a particular
destination. Redirect messages can be dangerous and can be
ignored by conﬁguration on most platforms (Winods, MAC,
Linux).
Type: 137 (Redirect)
Code: 0
Checksum: 0xd231 [correct]
rfc (2001:db8:c0a8:a:c800:6ff:fea9:1c)
Destination: 2001:db8:c0a8:a:c800:6ff:fea9:1c
(2001:db8:c0a8:a:c800:6ff:fea9:1c)
ICMPv6 Option (Target link-layer address)
Type: Target link-layer address (2)
Length: 8
ICMPv6 Option (Redirected header)
Type: Redirected header (4)
Length: 112
Reserved: 0 (correct)
Redirected packet

0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... =
Traffic class: 0x00000000
.... .... .... 0000 0000 0000 0000 0000 =
Flowlabel: 0x00000000
Payload length: 60
Hop limit: 63
Source: 2001:db8:c0a8:b::1
(2001:db8:c0a8:b::1)
Destination:
2001:db8:c0a8:a:c800:6ff:fea9:1c
(2001:db8:c0a8:a:c800:6ff:fea9:1c)
Code: 0
Checksum: 0xbce7 [correct]
ID: 0x22ef
Sequence: 0x0004
Data (52 bytes)

2.2. Neighbor Discovery Options
2.2.1. Source Link-Layer address Option
It is used by Neighbor Solicitation and Router Advertisement.
Ethernet II, Src: ca:02:06:a9:00:54 (ca:02:06:a9:00:54), Dst:
IPv6mcast_00:00:00:01 (33:33:00:00:00:01)

50

Source: ca:02:06:a9:00:54 (ca:02:06:a9:00:54)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel:
0x00000000
Payload length: 64
Hop limit: 255
Source: fe80::c802:6ff:fea9:54 (fe80::c802:6ff:fea9:54)
Code: 0
Cur hop limit: 64
Flags: 0x00
Reachable time: 0
Retrans timer: 0
Length: 8
ICMPv6 Option (MTU)
Type: MTU (5)
Length: 8
MTU: 1500
Length: 32
Prefix length: 64
Flags: 0xc0
Prefix: 2001:db8:c0a8:3::

2.2.2.Target Link-Layer address Option

It is used by Neighbor Advertisement and Redirect packets.
ca:02:06:a9:00:54 (ca:02:06:a9:00:54)
Destination: ca:02:06:a9:00:54 (ca:02:06:a9:00:54)
Source: ca:01:06:a9:00:54 (ca:01:06:a9:00:54)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 32
Hop limit: 255
Destination: fe80::c802:6ff:fea9:54 (fe80::c802:6ff:fea9:54)
Type: 136 (Neighbor advertisement)
Code: 0
Checksum: 0x5f24 [correct]
Flags: 0xe0000000
Target: fe80::c801:6ff:fea9:54 (fe80::c801:6ff:fea9:54)
Length: 8

2.2.3. Prefix Information Option
Can be sent with a Router Advertisement to advertise
Prefixes. More than one prefixes can be included.
Type. 3  
Length. 4. 
Prefix Length. 8 bits. Generally 64. 
On-Link Flag. 1 bit. If the prefix must be used to derive an
address during SLAAC. 
Autonomous Flag. 1 bit. If the prefix must be used to derive an
51

address during SLAAC. 
Router Address flag. Defined in RFC 3775 for Mobile IPv6 
Site Prefix Flag.  
Valid Lifetime. How long the address derived from this prefix is
Valid without any refreshment before the address is removed
from the interface. A value of ALL ONEs bits represents infinity
(for Static Addresses). 
Prefered Lifetime. If not refreshed and the Preferred Timer
expires, the address becomes deprecated and cannot be used
to establish a new connection but the address is still valid for
existing. A value of ALL ONEs bits represents infinity (for Static
Addresses). 
IPv6mcast_00:00:00:01 (33:33:00:00:00:01)
Source: ca:02:06:a9:00:54 (ca:02:06:a9:00:54)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 64
Hop limit: 255
Code: 0
Cur hop limit: 64
Flags: 0x00
Reachable time: 0
Retrans timer: 0

Length: 8
ICMPv6 Option (MTU)
Type: MTU (5)
Length: 8
MTU: 1500
Length: 32
Prefix length: 64
Flags: 0xc0

2.2.4.Redirected Header Option
It is only used in the ND Redirect packet
ca:02:06:a9:00:1c (ca:02:06:a9:00:1c)
Source: ca:01:06:a9:00:1c (ca:01:06:a9:00:1c)
Type: IPv6 (0x86dd)
0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 160
Hop limit: 255
Destination: 2001:db8:c0a8:b::1 (2001:db8:c0a8:b::1)
Type: 137 (Redirect)
Code: 0
Checksum: 0xd231 [correct]
Target: 2001:db8:c0a8:a:c800:6ff:fea9:1c
(2001:db8:c0a8:a:c800:6ff:fea9:1c)

52

(2001:db8:c0a8:a:c800:6ff:fea9:1c)
Length: 8
ICMPv6 Option (Redirected header)
Type: Redirected header (4)
Length: 112
Reserved: 0 (correct)
Redirected packet
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class:
0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel:
0x00000000
Payload length: 60
Hop limit: 63
Source: 2001:db8:c0a8:b::1 (2001:db8:c0a8:b::1)
(2001:db8:c0a8:a:c800:6ff:fea9:1c)
Code: 0
Checksum: 0xbce7 [correct]
ID: 0x22ef
Sequence: 0x0004
Data (52 bytes)

2.2.5.MTU Option

0110 .... = Version: 6
.... 1110 0000 .... .... .... .... .... = Traffic class:
0x000000e0
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 64
Hop limit: 255
Code: 0
Cur hop limit: 64
Flags: 0x00
Reachable time: 0
Retrans timer: 0
Length: 8
ICMPv6 Option (MTU)
Type: MTU (5)
Length: 8
MTU: 1500
Length: 32
Prefix length: 64
Flags: 0xc0

The MTU option is used in the ICMPv6 Packet too big and in
the ND Router Advertisement.
IPv6mcast_00:00:00:01 (33:33:00:00:00:01)
Source: ca:02:06:a9:00:54 (ca:02:06:a9:00:54)
Type: IPv6 (0x86dd)

53

F IGURE 6.4 Router Advertisements

F IGURE 6.5 Basic Route Information (RFC4191)

Code

Type

Curr Hop Limit M O H Prf Resvd

Checksum
Router Lifetime

Type

Length

Prefx Length Resvd Prf Resvd

Route Lifetime

Reachable Time
Retrans Time

Prefx (variable Length)

Options...
M- Managed bits for Statefull DHCPv6  
O- Other bits for Stateless DHCPv6 
H- Home Agent (Mobile IPv6) 
Prf- Preference.

2.2.6.Route Information Option
Sent in Router Advertisement (see RFC4191.).
It is used to give a preference to a router and to advertise
routes (SHOULD not send more than 17 routes). It SHOULD
not a be default behaviour.
The Preference use the same code for both default router
and route preferences.
01
High
00
Medium (default)
11
Low
10
Reserved - MUST NOT be sent
Possible Option: Route InformationYou can also advertize a
more speciﬁc Route informationRecursive DNS Server Option
54

DNS Server address can also be advertised in RA (RFC
5006):
This is a very simple option with Length, Lifetime and the
addrresses of all the DNS Servers.
Type 25#
Length
Lifetime#
DNS#Server Addresses

55

3.Neighbor Discovery

3.1. MAC Address Resolution

IPv6 use ND to manage its Neighbor Cache. This includes resolving the MAC Address of the Neighbor and check its Reachability (NUD).

When a host needs to send a packet to a destination, it verifies
if it is a Neighbor. In this case it sends the packet directly to the
Neighbor. There is an algorithm to check if the destination is a
Neighbor as there can be many prefixes on the same cable.

Neighbor Discovery uses Neighbor Solicitation (NS) and Neighbor Advertisements (NA).
NS are used to discover the Neighbor MAC Address, to check if
our new address is a DUPlicate or to check if a Neighbor is still
Reachable (NUD).

Once this is verified, the host creates an entry with state INCOMPLETE and the IPv6 Address of the destination in the
Neighbor cache and sends a Neighbor Solicitation to its Solicited Node Multicast Address. The NS contains the MAC Address of the Requester in the SLLA Option to save the reverse
operation (below in Red).

F IGURE 6.6 ND Finite State Machine
F IGURE 6.7 NS Sent for MAC Address
Resolution

Type

Code
Checksum
Reserved

Target Address
SLLA Option

56

Example of NS/NA between two UBUNTU Hosts
• Neighbor Solicitation
Frame 18674: 88 bytes on wire (704 bits), 88 bytes captured (704 bits)
Linux cooked capture
Internet Protocol Version 6,

Src: fe80::f6ca:e5ff:fe44:10ef

(fe80::f6ca:e5ff:fe44:10ef), Dst: ff02::1:ff8c:e4ac (ff02::1:ff8c:e4ac)
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 32
Hop limit: 255
Source: fe80::f6ca:e5ff:fe44:10ef (fe80::f6ca:e5ff:fe44:10ef)
[Source SA MAC: FreeboxS_44:10:ef (f4:ca:e5:44:10:ef)]
Destination: ff02::1:ff8c:e4ac (ff02::1:ff8c:e4ac)
Type: Neighbor Solicitation (135)
Code: 0
Checksum: 0xc88d [correct]
Reserved: 00000000
Target Address: 2a01:e35:2f26:d340:e:6a75:6c8c:e4ac
(2a01:e35:2f26:d340:e:6a75:6c8c:e4ac)
ICMPv6 Option (Source link-layer address : f4:ca:e5:44:10:ef)
Length: 1 (8 bytes)
Link-layer address: FreeboxS_44:10:ef (f4:ca:e5:44:10:ef)

• Neighbor Advertisement
Frame 18675: 88 bytes on wire (704 bits), 88 bytes captured (704 bits)
Linux cooked capture
Internet Protocol Version 6, Src: 2a01:e35:2f26:d340:e:6a75:6c8c:e4ac
(2a01:e35:2f26:d340:e:6a75:6c8c:e4ac), Dst: fe80::f6ca:e5ff:fe44:10ef
(fe80::f6ca:e5ff:fe44:10ef)
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 32
Hop limit: 255
Source: 2a01:e35:2f26:d340:e:6a75:6c8c:e4ac
(2a01:e35:2f26:d340:e:6a75:6c8c:e4ac)
Destination: fe80::f6ca:e5ff:fe44:10ef (fe80::f6ca:e5ff:fe44:10ef)
[Destination SA MAC: FreeboxS_44:10:ef (f4:ca:e5:44:10:ef)]
Type: Neighbor Advertisement (136)
Code: 0
Checksum: 0xe1ad [correct]
Flags: 0x60000000
0... .... .... .... .... .... .... .... = Router: Not set
.1.. .... .... .... .... .... .... .... = Solicited: Set
..1. .... .... .... .... .... .... .... = Override: Set
...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0
Target Address: 2a01:e35:2f26:d340:e:6a75:6c8c:e4ac
(2a01:e35:2f26:d340:e:6a75:6c8c:e4ac)
ICMPv6 Option (Target link-layer address : 00:0c:29:30:33:86)
Length: 1 (8 bytes)
Link-layer address: Vmware_30:33:86 (00:0c:29:30:33:86)

F IGURE 6.8 NA Sent for MAC Address Resolution
Type
RSO

Code

Reserved

Target Address

Checksum

The requester provides its MAC address in tbe SLLA Option. 
The Replier provides its MAC address in the TLLA Option.
Once it has received an answer, it updates the Neighbor MAC
Address from the reply and set the neighbor state as REACH-

TLLA Option
57

F IGURE 6.10 Full DAD Process and UBUNTU Interface
Startup

able.
If the Neighbor does not reply, it retries a MAX_UNICAST_SOLICIT (default: 3) time with a conﬁgured interval of RETRANS_TIMER (default: 1 second) between to request and if
no reply is received, it clears the entry in the Cache.
Example of a ping on a CISCO Router:
sa13-72c#ping 2000:1::100

F IGURE 6.9 NS Send during DAD Process (UBUNTU)

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2000:1::100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms
sa13-72c#
Apr 18 08:36:03: ICMPv6-ND: DELETE -> INCMP: 2000:1::100
Apr 18 08:36:03: ICMPv6-ND: Sending NS for 2000:1::100 on
GigabitEthernet0/2
Apr 18 08:36:03: ICMPv6-ND: Resolving next hop 2000:1::100 on interface GigabitEthernet0/2
Apr 18 08:36:03: ICMPv6-ND: Received NA for 2000:1::100 on
GigabitEthernet0/2 from 2000:1::100
Apr 18 08:36:03: ICMPv6-ND: Neighbour 2000:1::100 on
GigabitEthernet0/2 : LLA 0008.201a.7c38
Apr 18 08:36:03: ICMPv6-ND: INCMP -> REACH: 2000:1::100

F IGURE 6.11 NA Sent during DAD Process (UBUNTU)

3.2. Duplicate Address Detection (DAD)
This process is used when an interface is coming up or every
time a new address is added on an IPv6 Interface.

58

It consists to check that the new address is not a Duplicate
Address. It is a local process so the checking is only done on
the link where the address is added.
This is a very simple process that is just to send a NS to our
own Solicited Node Multicast Address to request the MAC
Address of our newly conﬁgured address.
We expect NO ANSWER.
If somebody does, it means that there is another myself on the
Network and my Address is a DUP.
If I don't receive any NA! We send a NA to claim the Address for
ourself.
DAD Example on a CISCO Router:
ICMPv6-ND: L3 came up on GigabitEthernet0/2
IPv6-Addrmgr-ND: DAD request for 2000:1::1 on
GigabitEthernet0/2
ICMPv6-ND: Sending NS for 2000:1::1 on GigabitEthernet0/2
IPv6-Addrmgr-ND: DAD: 2000:1::1 is unique.
ICMPv6-ND: Sending NA for 2000:1::1 on GigabitEthernet0/2
IPv6-Address: Address 2000:1::1/64 is up on GigabitEthernet0/2

59

4.Neighbor Unreachability Detection

5.Router Discovery

As long as the host communicates with this Neighbor, the Upper Layer reset the Reachable Timer so it is never reached
and the Neighbor remains in the state REACHable.

By default the hosts do not have to conﬁgure a default router.
This is done automatically thanks to NDP.

If the Upper Layer stop communication with the Neighbor for a
time of Reachable Timer (default: 30 seconds), the entry is moving to STALE state.
Then the host does nothing until a packet is sent to the Neighbor. When a packet is sent to this Neighbor the entry is moved
to the DELAY DELAY state (default: 5 seconds) to give some
time to the Upper Layer protocol to check the availability of the
Neighbor.

The Routers sends Unsolicited Router Advertisements on a
regular basis (min interval is 3 seconds).
The hosts listen to the RA to refresh preﬁxes or update some
parameters.
When a host is booting and needs RA Information immediately,
it sends a Router Solicitation message to the All Routers Multicast Address FF02::2.

If no positive packet is received, the entry is moved to PROBE
and the host start sending Unicast NS to the neighbor (Probe)
every Retransmit Interval (default: 1 second). After MAX_UNICAST_SOLICIT (default: 3) attempts the Neighbor is considered as Unreachable and its entry is cleared in the Cache.
Click Here for a step by step animation.

60

The RA contains the following information:

F IGURE 6.12 RA From FREE ISP Explaines

Default Link Parameters (Default Hop Limit, MTU)
Neighbor Unreachability Detection Parameters. These are
Reachable Timer and Retransmit Interval, The value zero
means unspecified which actually means that the configured information on the hosts must not be hanged by the RA.
Prefix availables on the Link with Timers and Flags for each
Prefix about Autoconfiguration (SLAAC, Stateless Address Autoconfiguration
If the Router is a Candidate as Default Gateway (Lifetime,
Preference). The Lifetime parameter is only there to say how
long this advertisement is valid without being refreshed to use
this router as a default Router Candidate. A RA with Lifetime=0
means: "stop using me as your default router immediately"!
Router IPv6 and MAC Addresses
DNS Server Addresses (RFC6106)
If DHCPv6 is available in the Network and if it must be used
to configure Address and Everything or Everything but Addresses. If the Router is a Home Agent (Mobile IPv6)?

6.Autoconfiguration (SLAAC)
6.1. Introduction
An IPv6 node must be able to configure its Network Access unattended with or without the presence of Routers on the Link(s).
Autoconfiguration was one of the main requirements for IPv6
since day 1.
61

In any case if not disable on Linux, the Workstation performs
Stateless Address Autoconfiguration (SLAAC) when the Interfaces are coming Up.
But an IPv6 DHCPv6 can be added to configure address and
additional information, this is stateful DHCPv6 or just the additional information without addresses, this is stateless DHCPv6.
A DHCPv6 Server only needs to keep states when it allocates
some addresses in order to poll a Workstation which did not renew its reservation and get the reserved address back in the
pool if the client fails to answer. DHCPv6 will be studied in details later in this book. Right now we are going to focus on Stateless Address Autoconfiguration (SLAAC) process itself. Just
keep in mind that DHCPv6 cannot replace it but just be a complement to SLAAC. For instance, a default route cannot be configured with DHCPv6.
SLAAC is stateless because no state is kepts on the router
when the default SLAAC is used to configure Address and any
other things on the node.

6.2. SLAAC Process
SLAAC is enabled by default on most platforms. I have seem
some Linux distribution where it must be enabled.
It is possible to configure everything statically and may be interesting for some Datacenter where we have only Servers and

Routers to configure. We may then want to configure the addresses manually and the default route to an HSRP or GLBP
Virtual IPv6 Link-local Address also configured statically. So
you will not loose any time with protocols and don't risk anything with Rogue devices and advertisements.

F IGURE 6.13 Stateless Address Autoconfiguration
Start
Derive the link-local
address
FE80::[Interface ID]

Set Hop Limit,
Reachable Time,
Retrans Timer, MTU

Send NS to the solicited
node multicast address
derived from the linklocal

Yes

??????
Information
present ?

A

No
Yes

NA received ?

Stop

No

B

Managed
Address
?????????????
Flag = 1 ?

Initialize the link-local

No
Other
?????????????
Flag = 1 ?

Send RS

Yes
Use DHCPv6

No

No
RA Received ?

Yes

Use DHCPv6
and exit

Stop

Yes

62

ets, RA included, MUST have the Hop Limit = 255 to be valid or
they are dropped!

F IGURE 6.14 SLAAC Check the Preﬁx List
A

So SLAAC will be performed in most cases and here is the full
process:

T?????????????
??????
???????????

?A
??????????

Y??

Do not initialize
??????????????
???????

??
On-Link
Flag = 0 ?

Y??

????????
??????????

F IGURE 6.15 SLAAC Checking for DHCPv6 Presence

???????????????
??????????
???????

Start

??
Autonomous
Flag = 0 ?

Y??

????????
??????????

?????????????????
???????

Derive the link-local
address
FE80::[Interface ID]

??

B

??
Preferred >
Valid

Y??

????????
??????????

Set Hop Limit,
Reachable Time,
Retrans Timer, MTU

Y??

Send NS to the solicited
node multicast address
derived from the linklocal

??
Y??
Valid = 0

Yes

??????
Information
present ?

A

No
???????
?????????

????????????????

Yes

NA received ?

Stop

No
?????????????????????
????????
?????????????????????
???????????????
???????????????????
???????????????
???????

B

Managed
Address
?????????????
Flag = 1 ?

Initialize the link-local

No
Other
?????????????
Flag = 1 ?

Send RS

For instance a Rogue RA, DNS or DHCP can be forged on the
local link if an employee wants to break the Company Network.
For the RA, it must be on the local link since the most ND Pack-

Yes
Use DHCPv6

No

No
RA Received ?

Yes

Use DHCPv6
and exit

Stop

Yes

63

Here is the full process. Between A and B, this is the Prefix-list
verification process detailed in the next column. Let's explain it
Step-by-Step or Click here for an animation.
6.2.1.

We send a NS to our own Solicited Node Multicast Address for

F IGURE 6.17
The IPv6 ND Router Advertizement (MIPv6)

Validation of the Link-local Address

Type

The Interface is brought up or the host is booting. The interface
enters the TENTATIVE Mode. No user traffic can be exchanged
until we reach the Stop Red State which is the end of the
SLAAC process.

Checksum

Code

Cur Hop Limit

Reserved

MOH Prf

Router Lifetime

Reach Time
Retrans Timer
Options

IPv6 Source Address: link-local address 

From the Start, we can see that the very first step is to figure
out the Link-local address with an EUI-64 or Static Interface ID
and to verify it using the DAD Process.

IPv6 Dest Address: Unicast, Multicast to all node ff02::1
Lifetime: The time that this router will be considered active. A Lifetime of zero is used by a router
which cannot be used as a default router.
Hops: Default Hop-Limit to use on this link.
MTU: Default MTU to use on this link

F IGURE 6.16 Address Autoconfiguration States
VALID

Reachable time: Used by NUD. A length of time that a node considers a neighbor reachable until
another reachability confirmation is received from that neighbor.
Retransmit time: Used by Address Resolution and NUD. It specifies the minimum time, in
milliseconds, between retransmitted Neighbor Solicitation messages.

Tent

Preferred

Deprecated

Preferred Lifetime
Valid Lifetime

Invalid

AddrFlag: This is the Managed Address flag used to signal the use of DHCPv6 for Address and
Other configuration.When set the OtherFlag is redundant.
OtherFlag: Used to signal the use of DHCPv6 for other parameter configuration.
There is also a 1-bit autonomous address-configuration flag in the Prefix Option. When set indicates
that this prefix can be used for stateless address configuration

64

our

F IGURE 6.18 Dynamic Addresses Refresh

2100
1900

Unsolicited Periodic RA

1600

RA Interval default: 200 seconds
RA Lifetime default: 1800 seconds

1400
200s

Preferred and Valid Timers
at the Workstations

IPv6

????????????????????????
On-Link, Autonomous
Preferred:1800, Valid:2100

RA are sent every 200 seconds +/-jitter
Preferred: 1600-200 = 1400 seconds
Valid = 2100 - 200 = 1900 seconds
SLAAC Timers just Before receiving the RA:
Preferred: 1600-200 = 1400 seconds
Valid = 2100 - 200 = 1900 seconds
After receiving the RA:
Preferred is reset to 1600 seconds
Valid was 1900 seconds, RemainingLifetime= 1900
Received Valid = 2100 is greater than RemainingLifetime=1900
So Valid Lifetime is reset to Received Valid Lifetime = 2100

2001:db8:4:1::1/64
initial timers:
Preferred:1800, Valid: 2100

2001:db8:4:1::2/64
Preferred:1400, Valid:1900
Same Principle than other Workstation

Just before receiving RA
Preference:1400, Valid: 1900
After Receiving the RA
Preference: 1800, Valid: 2100

65

own IPv6 address and expect no answer.
If somebody replies, our link-local is not unique nor valid and
the Interface is disabled for IPv6.
Only if we use SeND, we are doing two more attempts before
we quit and log an error! We are very most probably under a
DoS Attack!
6.2.2.

Send a Router Solicitation

Then, the next Step is to send a RS to the All Router Link-Local
Scope Multicast Address: FF02::1
If we don't receive any RA, we try DHCPv6 and we exit SLAAC
process.
Otherwise, we configure the IPv6 interface from the parameter
received in the RA: MTU, Hop Limit, Reachable Timer and Retransmit Interval, Router Lifetime, and so on...
6.2.3.

Check the Prefix-List

The next step is to examine the Prefix-List if there is any in the
Router Advertisement.

With each dynamic address there are two timers: the Preferred
and the Valid.
When the Preferred Timer has expired, the Address is deprecated but remains Valid until the Valid Timer has not expired.
When the Address is deprecated, it is still there and can be
used for existing connection. On the other hand, a deprecated
address cannot be used for a new connection. When the Valid
Timer has expired, the address is removed from the Interface.
Then we must also check the Timers: 
#
The Valid Timer MUST be NON NULL, >0 
#
The Valid Timer MUST be > The preferred timers
If the bits and timers are OK, we derive an address using any of
the configured mode for the Interface ID: Static, EUI-64, Random porary, CGA... And we check that this address is unique
using DAD.
If DAD passed, we initialize the Address otherwise the address
is not used. We go to the next Prefix until there is no more and
we get back from the Prefix-list inspection Loop.

If there is a list we examine each prefix and check that the OnLink and Autonomous bit (Flag in the Capture) are set.

66

The last Steps of this procedure is to check if we need to request a DHCPv6 Server.
If the Managed bit (M bit) is set, we need to do a full DHCPv6 Request including Addresses and Other Information. This is Stateful DHCPv6.
If the Other bit (O bit) is set, we need to request a DHCPv6 Server for everything but Addresses. This is Stateless DHCPv6.
Once the Dynamic addresses have been learned they must be refreshed to remain in the Preferred State. This is true for the addresses learned with
SLAAC from the RA and from address learned from DHCPv6. Both IPv6 Dynamic Addresses follow the same Cycle:
The interface is in the TENTATIVE mode during all the process that we just have explained. No user traffic can be exchanged in this mode. Interface is
coming up.
When the SLAAC Process is over, the dynamic addresses have been learned from the RA Prefix-list or DHCPv6, they are in the PREFERRED state and
remain in this state as long as they are refreshed by a periodic unsolicited RA or when DHCPv6 timer expires and the renew process is successful.
If they cannot be refreshed before the Preferred Lifetime expires, they will enter the DEPRECATED mode (Optional) and can only be used by the existing
connections. If they cannot be refreshed when the Valid Lifetime expires, they are removed from the interface and cannot be used anymore. They become
INVALID.
When DEPRECATED if they can be refreshed, they are PREFERRED again.

Please see aat the end of this Chapter how to configure the CISCO routers for this,

67

Fred explainsi pv6-v2-alpha

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (12)

Semelhante a Fred explainsi pv6-v2-alpha

Semelhante a Fred explainsi pv6-v2-alpha (20)

Mais de Fred Bovy

Mais de Fred Bovy (20)

Último

Último (20)

Fred explainsi pv6-v2-alpha