Archive | IPv6 RSS feed for this section

Thread Network

21 May

Thread is not a new standard, but rather a combination of existing, open source standards such as IEEE and IETF that define a uniform, interoperable wireless network stack enabling communication between devices of different manufacturers. Thread uses IPv6 protocol as well the energy efficient wireless IEEE 802.15.4 PHY/MAC standard.

Use of the IPv6 standard allows components in a Thread network to be easily connected to existing IT infrastructure. The Thread network layer combines physical as well as transport layers. UDP serves as the transport layer, on which various application layers such as COAP or MQTT-SN can be used. UPD also supports proprietary layers such as Nest Weave. Layers that are used for most applications, and that service network infrastructure, are defined uniformly via Thread. Application layers are implemented depending on end user requirements.

Two security mechanisms are used within Thread network layers: MAC layer encryption and Datagram Transport Layer Security (DTLS). MAC Layer encryption encodes call content above the PHY/MAC layers. DTLS is implemented in conjunction with the UDP protocol and encrypts application data, but not packet data from the lower layers (IPv6). Thread also enables mesh network topologies. Routing algorithms ensure that messages within a network reach the target node using the IPv6 addressing. When a single nodes fail, Thread changes the network topology in order to preserve network integrity. Thread also supports in parallel multiple Ethernet or wireless networks established via Border Routers. This ensures reliability through network redundancy. Thread is ideal for home automation due to its mesh network topology and support of inexpensive nodes.

The following image shows a possible setup of such topology. Rectangular boxes represent Border Routers such as phyGATE-AM335 (alternately phyGATE-i.MX7, phyGATE-K64) or the phySTICK. The two Border Routers in the image establish the connection to the IT infrastructure via Ethernet or WiFi. The pentagon icons represent nodes, such as phyWAVEs and phyNODEs, that are addressable and can relay messages within the Thread mesh network. Nodes depicted by circles, which can be phyWAVEs and phyNODEs, are nodes that can be configured for low power and to operate for an extensive time using a single battery.



IPv6: IPv6 / IPv4 Comparative Statistics

5 Sep
  IPv6   IPv4   IPv6 / IPv4
Prefix Count 32409 628153 32409 / 628153 = 0.0516
  IPv6   IPv4   IPv6 / IPv4
Announced Address Span 155.235 0.60377371 15.5235 / 0.60377371 = 25.7108
Announced % of Total Address span 0.002123 65.803.047 0.002123 / 65.803047 = 0.0000
Average Address Span per Announcement 305.076 198.646 30.5076 / 19.8646 = 1.5358
Average Announcement Length 411.111 225.802 41.1111 / 22.5802 = 1.8207
AS Numbers
  IPv6   IPv4   IPv6 / IPv4
AS Count 12161 55014 12161 / 55014 = 0.2211
Origin-only ASes 9956 47333 9956 / 47333 = 0.2103
Origin and Transit ASes 2032 7470 2032 / 7470 = 0.2720
Transit ASes 173 211 173 / 211 = 0.8199
ASs Announcing a single prefix 8557 21224 8557 / 21224 = 0.4032
Average Announcements per AS 27.035 114.620 2.7035 / 11.4620 = 0.2359
Average Address Range per AS (prefix) 290.728 29.0728 / 11.4620 = 2.5365
Max Announcments for an AS 597 3582 597 / 3582 = 0.1667
Max Announced span for an AS 18.95 18.95 / 3582 = 0.0053
Use of More Specific Announcements
  IPv6   IPv4   IPv6 / IPv4
Root Prefix Count 21624 297134 21624 / 297134 = 0.0728
Number of More Specifics 10785 331019 10785 / 331019 = 0.0326
Specifics: % of Announcements 332.778 526.972 33.2778 / 52.6972 = 0.6315
Specifics: % of Address Space 24.004 348.608 2.4004 / 34.8608 = 0.0689
Additional Data
More Specifics
  IPv6   IPv4   IPv6 / IPv4
Specifics where AS prepended Path matches aggregate 4991 144476 4991 / 144476 = 0.0345
Specifics where AS prepended Path matches aggregate % 46.28 43.65 46.28 / 43.65 = 1.0603
Specifics where AS Path matches aggregate 5301 151388 5301 / 151388 = 0.0350
Specifics where AS Path matches aggregate % 491.516 457.339 49.1516 / 45.7339 = 1.0747
Specifics where AS Origin matches aggregate 8232 246644 8232 / 246644 = 0.0334
Specifics where AS Origin matches aggregate % 763.282 745.105 76.3282 / 74.5105 = 1.0244
AS Numbers
  IPv6   IPv4   IPv6 / IPv4
ASes visible in only one AS path 9133 35341 9133 / 35341 = 0.2584
Origin ASs announced via a single AS path 8965 35011 8965 / 35011 = 0.2561
Multi-Origin Prefixes 95 1585 95 / 1585 = 0.0599
AS Paths
  IPv6   IPv4   IPv6 / IPv4
Unique AS Paths 27835 159629 27835 / 159629 = 0.1744
Selected AS Paths 11081 83091 11081 / 83091 = 0.1334
AS paths associated with a single FIB entry 10677 38819 10677 / 38819 = 0.2750
Unique AS prepended Paths 28156 169180 28156 / 169180 = 0.1664
AS Paths using prepending 2104 36619 2104 / 36619 = 0.0575
AS Paths using private ASs 5 151 5 / 151 = 0.0331
Average AS path length 55.162 57.137 5.5162 / 5.7137 = 0.9654
Average address weighted AS path length 51.802 69.349 5.1802 / 6.9349 = 0.7470
Maximum AS Path length 12 13 12 / 13 = 0.9231
Maximum prepended AS Path length 22 56 22 / 56 = 0.3929
Average entries per AS Path 11.643 39.351 1.1643 / 3.9351 = 0.2959
Average entries per Selected AS Path 22.660 75.598 2.2660 / 7.5598 = 0.2997
AS Paths per origin AS 23.219 29.128 2.3219 / 2.9128 = 0.7971
Selected AS Paths per origin AS 11.930 15.162 1.1930 / 1.5162 = 0.7868

IPv6 Series part 6: ICMPv6

22 Aug

So far in this series, we have looked at the features of IPv6, IPv6 addressing, and the structures of IPv6 headers and packets. In this article, we will be looking at a protocol that is important to the working of IPv6—ICMPv6.

Introduction to ICMPv6

ICMPv6 is similar to ICMP for IPv4, except that ICMPv6 has added functionality and implements some changes that are necessary for the operation of IPv6. Like ICMP for IPv4, ICMPv6 provides error reporting (e.g., destination unreachable) and network diagnostic functions (e.g., ping). Also, ICMPv6 provides a foundation for other IPv6 operations, such as neighbor discovery (ND), which we will look at in future articles.

ICMPv6 Message Structure

The general format of ICMPv6 messages is similar to that of ICMP for IPv4. As we saw in the previous article, an ICMP message will be preceded by an IPv6 header and IPv6 extension headers if available and the Next Header value for an ICMP message will be 58. The figure below shows the Wireshark capture we used in the previous article:



As described in RFC 4443, the general structure for ICMPv6 messages is shown below:

The Type field defines the type of message, e.g., Destination Unreachable or Echo Reply. TheCode field may be used to add granularity to a particular message type; for example, the reason why a destination is unreachable. The Checksum field is used to check that the integrity of the ICMPv6 message and parts of the IPv6 header is preserved. Finally, the Message Body will vary depending on the ICMPv6 message type.

ICMPv6 Message Types

Let’s consider the Type field in the ICMPv6 general message structure above. Notice that it is made up of 8 bits, therefore you have a range of 00000000 (0 in decimal) to 11111111 (255 in decimal). Unlike ICMP for IPv4, which had “scattered” message types, ICMPv6 message types are divided into two groups:

  1. Error messages—These messages have “0″ in the high-order bit of Type field; therefore, error messages are in the range of 00000000 (0) to 01111111 (127).
  2. Informational messages—These message types have “1″ in the high-order bit of the Type field; therefore informational messages are in the range of 10000000 (128) to 11111111 (255).

ICMPv6 Error Messages

Currently, there are four ICMPv6 error messages that have been assigned, i.e., type 1 to type 4. Also, type 0 is reserved; type 100 and type 101 have been assigned for private experimentation; and type 127 has been reserved for possible future expansion of ICMPv6 error messages. We will now consider the type 1 to 4 error messages.

Type 1—Destination Unreachable

A Destination Unreachable message is generated when a packet cannot be delivered to the destination address. The ICMPv6 destination unreachable message has the following structure:

The Type field will have a value of 1. Also, because there are several reasons why a packet may not be deliverable, there are various values for the Code field in this message as shown in the table below:

Let’s take a look at a Destination Unreachable message in Wireshark. I have applied an access list to filter ping packets to fe80::2; therefore, from our table, the code should be 1 as shown below.

Type 2—Packet Too Big

The Packet Too Big message is generated in response to a packet that cannot be sent because the packet size exceeds the MTU of the outgoing link. This message is especially useful for the path MTU discovery process.

The Type field is set to 2 and the Code field is set to 0. The MTU field contains the maximum transmission unit of the outgoing link.

Type 3—Time Exceeded

A time exceeded message is sent when either the hop limit of a packet is 0 (upon receipt or after decrementing) or there is a timeout during fragment reassembly.

The Type field is set to 3, while the Code field can be either 0 (hop limit exceeded) or 1 (fragment reassembly timeout exceeded).

Type 4—Parameter Problem

The ICMPv6 message is sent when there is a problem with the IPv6 header or IPv6 extension header and further processing of the IPv6 packet cannot take place. For example, if “144″ is found in the Next Header field, this message will be generated because “144″ is not currently assigned to any protocol.

The Type field is set to 4, while the Code field can have a value between 0 and 3, as shown in the table below. The Pointer field gives information about the part of the IPv6 packet that had issues.

ICMPv6 Informational Messages

There are about 19 ICMPv6 informational messages that have been assigned, but we will be focusing on two common informational messages—Echo Reply and Echo Request.

Type 128- Echo Request and Type 129- Echo Reply

I have grouped these two messages together because they have a similar structure. The major difference is in the Type field: Echo Request has a type value of 128 and Echo Reply has a type value of 129.

Side talk: These type values for Echo Request and Echo Reply are finally logical. I used to wonder in ICMP for IPv4 why Echo Request, which comes first, would have a type value (8) greater than Echo Reply, which comes later (0).

The Identifier and Sequence Number fields help in matching corresponding echo replies to echo requests. For example, look at the Wireshark capture below, which shows the ping (echo request and reply) between fe80::1 and fe80::2; notice that the Identifier is the same (0x13a0) while theSequence Number increases (from 0 to 4). It shows that it is the same ping session but with 5 packets, i.e., the default repeat of ping on Cisco is 5.


This brings us to the end of this article on ICMPv6, in which we have looked at the general structure of ICMPv6 messages and also discussed the four error messages and two informational messages of ICMPv6. We will see still more of this protocol in other articles, but this is good enough for an introduction.

In the next article, we will begin discussing the neighbor discovery (ND) process of IPv6. I hope you have found this article insightful.

References and Further Reading


IPv6 Series part 5: Packet Header and Structure

22 Aug

Welcome to the fifth article in the IPv6 series. In past articles, we have looked at IPv6 address types, the IPv6 scoped address architecture and, most recently, interface identifiers for unicast addresses. In this article, we will consider the structure of an IPv6 packet and also look at the IPv6 header and how it compares to the IPv4 header.

IPv4 and IPv6 Packet Structures

From our IPv4 knowledge, we are familiar with the concept of encapsulation, in which each lower-level OSI layer takes the data passed down from higher layers of the OSI model and encapsulates it in its own format, including a header (and sometimes a footer). At the IP (network) layer, we call this message an IP packet or IP datagram. The general format of an IPv4 packet is as shown below:

The IP header is added at the IP layer and contains information such as the source and destination IP address, while the payload contains the upper-layer protocol data unit (i.e., the upper-layer header + upper-layer payload). Stemming from this format, the IPv6 packet is also similar except that the Payload portion is made up of upper-layer protocol data and IPv6 extension headers if available.

We will talk about IPv6 extension headers in a later section of this article, but keep in mind that an IPv6 packet may not contain an IPv6 extension header, effectively making the structure of that IPv6 packet similar to that of an IPv4 packet.

IPv4 and IPv6 Headers

As usual, let us begin with what we are familiar with. According to the RFC on IPv4, the IPv4 header is shown below:

Let’s briefly highlight what each field is about, because it will help in our understanding of the IPv6 header:

  1. Version—Identifies the format of the header. For IPv4, this value will be 4. As we will see, the value will be 6 for IPv6.
  2. IHL—This stands for Internet header length. Remember that, because of IP options, the IPv4 header does not have a fixed length. The minimum length is 20 bytes and the maximum length is 60 bytes.
  3. Type of Service—This has been renamed the differentiated services field and it finds its use in quality of service (QoS).
  4. Total Length—Entire length of the IPv4 packet, i.e., the header plus payload.
  5. Identification—Helps in reassembly of fragmented packets.
  6. Flags—Conveys information about fragmentation.
  7. Fragment Offset—Indicates the position of a fragment in the payload.
  8. Time to Live (TTL)—Specifies the maximum lifetime of a packet as it traverses links.
  9. Protocol—Indicates the upper-layer protocol, e.g., TCP (6), ICMP (1).
  10. Header Checksum—Ensures integrity of the IPv4 header. The payload is not included in the checksum calculation.
  11. Source Address—Address of sending host.
  12. Destination Address—Address of recipient.
  13. Options—Variable length field that carries IPv4 options information, such as loose source routing.
  14. Padding—Used to ensure that the header is a multiple of 32 bits.

Let’s look at an example packet (telnet session) captured through Wireshark.

The first thing you will notice is the concept of encapsulation that I mentioned above, i.e., the TCP segment is encapsulated in the IP packet, which is encapsulated in an Ethernet frame, and so on. Then, if we look at the IPv4 portion, we will see all the fields we discussed above, although there are no options (or padding) specified in this packet.

We can now move on to the IPv6 header. As I mentioned in the introductory article, the IPv6 header is much simpler than the IPv4 header even though it is twice the (minimum) size of an IPv4 header. According to RFC 2460, the main IPv6 header format is as shown below:

Let’s also highlight the fields in the IPv6 header as we did for IPv4:

  1. Version—The same as in IPv4 except that it has a value of 6.
  2. Traffic Class—Similar functionality as the differentiated services (ToS) field.
  3. Flow Label—New to IPv6, this allows the source to identify that a packet belongs to a sequence of packets (i.e., flow) that require special handling by the router
  4. Payload Length—This is similar to the Total Length field in the IPv4 header except that it specifies only the length of the payload, i.e., the IPv6 extension headers (if any) + upper-layer PDU.
  5. Next Header—Uses the same values as the Protocol field in the IPv4 header. It identifies the type of header after the IPv6 header, i.e., an IPv6 extension header or an upper-layer protocol (e.g., TCP, UDP).
  6. Hop Limit—Similar to the TTL field in the IPv4 header. The TTL field initially related to time in theory but, as we know, practical implementations used TTL as hop counts. This is why the field was renamed in IPv6.
  7. Source Address—128-bit IPv6 address of the sender.
  8. Destination Address—128-bit IPv6 address (unicast, anycast, or multicast) of the destination.

Let’s now try to compare the IPv4 and IPv6 headers.

  1. Looking at the IPv6 header, the first thing you notice is that there are only 8 fields compared to the 14 fields in the IPv4 header; thus it is simpler.
  2. There is no header length field in the IPv6 header because it has a fixed value of 40 bytes.
  3. All fragmentation fields in the IPv4 header have been removed completely from the IPv6 header. They have been moved to an IPv6 extension header.
  4. The header checksum field has also been removed from the IPv6 header.
  5. As highlighted above, there is a new field in IPv6: Flow Label.
  6. Finally, all options have been moved away from the main IPv6 header to IPv6 extension headers.

IPv6 Extension Headers

All through this article, I have mentioned the IPv6 Extension headers, so let’s talk about them now. In IPv4, if options are present in the IP header, all intermediate routers must also process them, thereby slowing down packet forwarding. In IPv6, all options have been moved to the IPv6 extension headers and intermediate routers do not need to process these headers (with the exception of the hop-by-hop options header). This speeds up the IPv6 header processing and also the packet forwarding.

There are six IPv6 extension headers that must be supported by all implementations as defined by RFC 2460:

  1. Hop-by-hop options header
  2. Routing (Type 0) header
  3. Fragment header
  4. Destination options header
  5. Authentication header
  6. Encapsulating security payload header

Hint: We are already familiar with the authentication header (AH) and encapsulating security payload Header (ESP) from IPsec.

An IPv6 packet may or may not include any of these IPv6 Extension headers the same way an IPv4 packet may or may not have options specified in the IPv4 header.

We can also look at a Wireshark capture of a ping (ICMPv6) between two IPv6 hosts and see the fields in the IPv6 header.

Notice that the Next Header field in the IPv6 packet shown above contains the value “58,” which is the protocol number of ICMPv6. The table below shows common values (in decimal) that can be found in the Next Header field of an IPv6 header.

You can find a list of all the protocol numbers here. Also, you can find a list of the values for the IPv6 extension header types here.

Let us end this article with an example of the Next Header field values.

Be the first to hear of new free tutorials, training videos, product demos, and more. We’ll deliver the best of our free resources to you each month, sign up here:

Using the Next header value table above, we can fill in the values for what the next header field will be in this diagram:

Below is a real capture of a fragmented ping between two hosts. Notice the IPv6 Fragment Headerand also Next Header values as discussed above.


In this article, we have looked at the packet and header structures for IPv6. We saw that IPv6 headers have a fixed length of 40 bytes and options from IPv4 have been moved to extension headers in IPv6.

In the next article, we will discuss ICMPv6, which plays a very important role in IPv6. I hope you have found this article insightful.

References and Further Reading


IPv4 and IPv6 dual-stack PPPoE

13 Mar

The lab covers a scenario of adding basic IPv6 access to an existing PPPoE (PPP for IPv4).

PPPoE is established between CPE (Client Premise Equipment) the PPPoE client and the PPPoE server also known as BNG (Broadband Network Gateway).

ipv4 and IPv6 dual-stack PPPoe

Figure1: ipv4 and IPv6 dual-stack PPPoe

PPPoE server plays the role of the authenticator (local AAA) as well as the authentication and address pool server (figure1). Obviously, a higher centralized prefix assignment and authentication architecture (using AAA RADIUS) is more scalable for broadband access scenarios (figure2).

For more information about RADIUS attributes for IPv6 access networks, start from rfc6911 (

Figure2: PPPoE with RADIUS

Figure2: PPPoE with RADIUS

PPPoE for IPv6 is based on the same PPP model as for PPPoE over IPv4. The main difference in deployment is related to the nature of the routed protocol assignment to CPEs (PPPoE clients).

  • IPv4 in routed mode, each CPE gets its WAN interface IP centrally from the PPPoE server and it’s up to the customer to deploy an rfc1918 prefix to the local LAN through DHCP.
  • PPPoE client gets its WAN interface IPv6 address through SLAAC and a delegated prefix to be used for the LAN segment though DHCPv6.

Animation: PPP encapsulation model

Let’s begin with a quick reminder of a basic configuration of PPPoE for IPv4.

PPPoE for IPv4

pppoe-client WAN address assignment

The main steps of a basic PPPoE configuration are:

  • Create a BBAG (BroadBand Access Group).
  • Tie the BBAG to virtual template interface
  • Assign a loopback interface IP (always UP/UP) to the virtual template.
  • Create and assign the address pool (from which client will get their IPs) to the virtual template interface.
  • Create local user credentials.
  • Set the authentication type (chap)
  • Bind the virtual template interface to a physical interface (incoming interface for dial-in).
  • The virtual template interface will be used as a model to generate instances (virtual access interfaces) for each dial-in session.

Figure3: PPPoE server

Figure3: PPPoE server model


ip local pool PPPOE_POOL
bba-group pppoe BBAG
virtual-template 1
interface Virtual-Template1
ip unnumbered Loopback0
ip mtu 1492
peer default ip address pool PPPOE_POOL
ppp authentication chap callin


interface FastEthernet0/0

pppoe enable group BBAG


interface FastEthernet0/1
pppoe enable group global
pppoe-client dial-pool-number 1
interface FastEthernet1/0
ip address
interface Dialer1
mtu 1492
ip address negotiated

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication chap callin

ppp chap hostname pppoe-client

ppp chap password 0 cisco

Figure4: PPPoE client model

Figure4: PPPoE client model


As mentioned in the beginning, DHCPv4 is deployed at the CPE device to assign rfc1819 addresses to LAN clients and then translated, generally using PAT (Port Address Translation) with the assigned IPv4 to the WAN interface.

You should have the possibility to configure static NAT or static port-mapping to give public access to internal services.

Address translation

interface Dialer1
ip address negotiated
ip nat outside
interface FastEthernet0/0
ip address
ip nat inside
ip nat inside source list NAT_ACL interface Dialer1 overload

ip access-list standard NAT_ACL

permit any

pppoe-client LAN IPv4 address assignment


ip dhcp excluded-address
ip dhcp pool LAN_POOL
interface FastEthernet0/0
ip address

PPPoE for IPv6

pppoe-client WAN address assignment

All IPv6 prefixes are planned from the 2001:db8::


ipv6 local pool PPPOE_POOL6 2001:DB8:5AB:10::/60 64
bba-group pppoe BBAG
virtual-template 1
interface Virtual-Template1
ipv6 address FE80::22 link-local
ipv6 enable
ipv6 nd ra lifetime 21600
ipv6 nd ra interval 4 3
peer default ipv6 pool PPPOE_POOL6

ppp authentication chap callin


interface FastEthernet0/0

pppoe enable group BBAG

IPCP (IPv4) negotiates the IPv4 address to be assigned to the client, where IPC6CP negotiates only the interface identifier, the prefix information is performed through SLAAC.


interface FastEthernet0/1
pppoe enable group global
pppoe-client dial-pool-number 1
interface Dialer1
mtu 1492
dialer pool 1
dialer-group 1
ipv6 address FE80::10 link-local

ipv6 address autoconfig default

ipv6 enable

ppp authentication chap callin

ppp chap hostname pppoe-client

ppp chap password 0 cisco

The CPE (PPPoE client) is assigned an IPv6 address through SLAAC along with a static default route: ipv6 address autoconfig default

pppoe-client#sh ipv6 interface dialer 1
Dialer1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::10
No Virtual link-local address(es):

Stateless address autoconfig enabled
Global unicast address(es):

2001:DB8:5AB:10::10, subnet is 2001:DB8:5AB:10::/64 [EUI/CAL/PRE]
valid lifetime 2587443 preferred lifetime 600243

Note from the below traffic capture (figure5) that both IPv6 and IPv4 use the same PPP session (layer2 model)(same session ID=0×0006) because the Link Control Protocol is independent of the network layer.

Figure5: Wireshark capture of common PPP layer2 model

Figure5: Wireshark capture of common PPP layer2 model


pppoe-client LAN IPv6 assignment

The advantage of using DHCPv6 PD (Prefix Delegation is that the PPPoE will automatically add a static route to the assigned prefix, very handy!


ipv6 dhcp pool CPE_LAN_DP
prefix-delegation 2001:DB8:5AB:2000::/56
00030001CA00075C0008 lifetime infinite infinite
interface Virtual-Template1

ipv6 dhcp server CPE_LAN_DP

Now the PPPoE client can use the delegated prefix to assign an IPv6 address (::1) to its own interface (fa0/0) and the remaining for SLAAC advertisement.

No NAT needed for the delegated prefixes to be used publically, so no translation states on the PPPoE server. The prefix is directly accessible from outside.

For more information about the client ID used for DHCPv6 assignment, please refer to the prior post about DHCPv6.


pppoe-client#sh ipv6 dhcp
This device’s DHCPv6 unique identifier(DUID): 00030001CA00075C0008
interface Dialer1

ipv6 dhcp client pd PREFIX_FROM_ISP
interface FastEthernet0/0
ipv6 address FE80::2000:1 link-local

ipv6 address PREFIX_FROM_ISP ::1/64
ipv6 enable

pppoe-client#sh ipv6 dhcp interface
Dialer1 is in client mode
Prefix State is OPEN
Renew will be sent in 3d11h
Address State is IDLE
List of known servers:
Reachable via address: FE80::22
DUID: 00030001CA011F780008
Preference: 0
Configuration parameters:

IA PD: IA ID 0×00090001, T1 302400, T2 483840

Prefix: 2001:DB8:5AB:2000::/56

preferred lifetime INFINITY, valid lifetime INFINITY

Information refresh time: 0

Prefix name: PREFIX_FROM_ISP

Prefix Rapid-Commit: disabled

Address Rapid-Commit: disabled


Now the customer LAN is assigned globally available IPv6 from the CPE (PPPoE client).

client-LAN#sh ipv6 interface fa0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::2000:F
No Virtual link-local address(es):

Stateless address autoconfig enabled
Global unicast address(es):

2001:DB8:5AB:2000::2000:F, subnet is 2001:DB8:5AB:2000::/64 [EUI/CAL/PRE]

client-LAN#sh ipv6 route


S ::/0 [2/0]

via FE80::2000:1, FastEthernet0/0

C 2001:DB8:5AB:2000::/64 [0/0]

via FastEthernet0/0, directly connected

L 2001:DB8:5AB:2000::2000:F/128 [0/0]

via FastEthernet0/0, receive

L FF00::/8 [0/0]

via Null0, receive


End-to-end dual-stack connectivity check

client-LAN#ping 2001:DB8:5AB:3::100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:5AB:3::100, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/45/88 ms
client-LAN#trace 2001:DB8:5AB:3::100
Type escape sequence to abort.
Tracing the route to 2001:DB8:5AB:3::100

1 2001:DB8:5AB:2000::1 28 msec 20 msec 12 msec

2 2001:DB8:5AB:2::FF 44 msec 20 msec 32 msec

3 2001:DB8:5AB:3::100 48 msec 20 msec 24 msec


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/63/96 ms
Type escape sequence to abort.
Tracing the route to

1 32 msec 44 msec 20 msec

2 56 msec 68 msec 80 msec

3 72 msec 56 msec 116 msec


I assigned PREFIX_FROM_ISP as locally significant name for the delegated prefix, no need to match the name on the DHCPv6 server side.

Finally, the offline lab with all the commands needed for more detailed inspection:


References (french)



Embedded Packet Capture, let’s go fishing for some packets!

27 Feb

EPC (Embedded Packet Capture) is another useful troubleshooting tool to occasionally capture traffic to be analyzed locally or exported to remote device. Occasionally, in contrast with RITE (Router IP Traffic Export) or SPAN on switches which are meant to have permanent flow of copied traffic directed to a traffic analyzer or IDS (Intrusion Detection System).

The configuration workflow is straightforward, but I would like to make a conceptual graphical analogy to illustrate it.

Let’s imagine traffic flowing through a router interface like the following:

Embedded Packet Capture

1- Capture point:

Specify the protocol to capture, the interface and the direction, this is the Here you indicate which IP protocol you need to capture.

monitor capture point ip cef CAPTURE_POINT fastEthernet 0/0 both
monitor capture point ipv6 cef CAPTURE_POINT fastEthernet 0/0 both

2- Packet buffer:

Memory area where the frames are stored once captured. 

monitor capture buffer CAPTURE_BUFFER


Embedded Packet Capture

3- ACL:

If needed you can filter a specific type of traffic, available only for IPv4. 

(config)#access-list 100 permit icmp host host capture buffer CAPTURE_BUFFER filter access-list 100 



Except the optional IPv4 ACL, configured at the global configuration mode, everything else is configured at the privileged EXEC mode.

Embedded Packet Capture

4- Associate capture point with capture buffer

monitor capture point associate CAPTURE_POINT CAPTURE_BUFFER

You can associate multiple capture points (on the same or multiple interfaces) to the same buffer.

Embedded Packet Capture

5- Start and stop capture process

monitor capture point start CAPTURE_POINTmonitor capture point stop CAPTURE_POINT


If you are familiar with wireshark, it will be easier to remember the steps needed to capture traffic.

Wireshark analogy

wireshark and Embedded Packet Capture

Deployment 1

Two capture points are created to capture IPv4 and IPv6 traffic into separate capture buffers.

monitor capture point ipv6 cef CAPTURE_POINT6 fa0/0 bothmonitor capture buffer CAPTURE_BUFFER6 

monitor capture point associate CAPTURE_POINT6 CAPTURE_BUFFER6


monitor capture point ip cef CAPTURE_POINT4 fa0/0 both

monitor capture buffer CAPTURE_BUFFER4

monitor capture point associate CAPTURE_POINT4 CAPTURE_BUFFER4

Following is the result on the router

Deployment 2

Two capture points are created to capture IPv4 and IPv6 traffic into single capture buffer.

monitor capture point ipv6 cef CAPTURE_POINT6 fa0/0 bothmonitor capture point ip cef CAPTURE_POINT4 fa0/0 both! 

monitor capture buffer CAPTURE_BUFFER46


monitor capture point associate CAPTURE_POINT6 CAPTURE_BUFFER46

monitor capture point associate CAPTURE_POINT4 CAPTURE_BUFFER46


Following is the result on the router


!Example of export to tftpR1#monitor capture buffer CAPTURE_BUFFER46 export ftp://login:password@ 

Writing Volume_1/ecp.pcap


!Example of export to tftp

R1# monitor capture buffer CAPTURE_BUFFER46 export tftp://



And the file opened in wireshark:

EPC traffic opened with wireshark


8 Key Changing Factors That Will Grow IoT

17 Feb
Growth of IoT

The Internet of Things (IOT) is driven by change in the following nine Key Areas:

  1. The explosion of Apps for anything and everything
  2. Increased growth of Big Data and Analytics
  3. Standarization of IPv6; Huge increase in available IP addresses
  4. Mainstream of Cloud and Smart Devices  (who store data in cloud, think smart meter)
  5. Trend of App Developers to push artificial intelligence from the App Lay to the network layer (or Cloud)
  6. Consumerization of enriched experiences with devices or things (think i-watch)
  7. Ever increasing network speeds at reducing rates.
  8. Nanotechnology

Add the human colaboration on top if, empowered by much if not all of the above, and a strong platform or movement is visibile!

source: /

IP addressing – a numbers game

10 Feb

The depletion of the IPv4 allocation pool has been a concern since the late 1980’s, when the internet really started to see enormous growth. Since then there have been many techniques developed to address the IPv4 scalability issues (limited to 4.3 billion addresses) such as CIDR, NAT and finally the introduction of IPv6 in 1998.

IPv6 is the only workable solution to IPv4 depletion as it can provide 340 undecillion (3.4×1038) addresses. This therefore eliminates the need for NAT in the future internet. To put the numbers in perspective, if the current pool of IPv4’s 4.3 billion addresses were the size of a golf ball, the new IPv6’s 340 undecillion address space would be about the size of the sun.

IPv4 to IPv6 – The network problem 
IPv4 and IPv6 are completely separate Network layer protocols that cannot interact directly. As the internet community rolls out IPv6, what is actually happening is the build out of a second, logical IPv6 internet, which runs in parallel and over the same physical Layer1 &2 infrastructure as the current IPv4 internet, with the eventual goal of phasing out the IPv4 Internet.

Since there is no set time limit when everything must be IPv6 network providers need to design and implement mechanisms that allow networks to work on IPv4 and IPv6 at the same time, and also, in preparation for the eventual date when IPv4 address space is completely exhausted, have a solution where they can deploy IPv6 only sites that can still communicate with the IPv4 Internet.

IPv4 to IPv6 – the solutions
Dual stack means that all devices are able to run both IPv4 and IPv6 in parallel. This is the solution that should be implemented now as it offers flexibility and coexistence, allowing users to reach both IPv4 and IPv6 simultaneously.

Dual stack does not require any tunnelling over networks as IPv4 and IPv6 work independently of each other. This allows for a granular migration of services from IPv4 to IPv6 over time.

Dual-Stack Lite

Dual Stack Lite is a solution which is primarily adopted for broadband solutions. Its design does not require any registered IPv4 address space to be assigned to a Customer site. In this design only IPv4 private addresses for the LAN clients are used and IPv4 in encapsulated in IPv6 over the WAN.

The network provider implements a Carrier Grade NAT (CGN) device within its network infrastructure and the Dual Stack Lite CPE uses its unique IPv6 connection to deliver packets to the CGN which has a pool of IPv4 addresses.


IPv6 – Scopes and Zones

20 Jan

IPv6 is well designed. The model of scopes and zones along with the zone isolation principle is based on solid mathematical standards and can provide straight answers to tricky questions regarding packets with mixed source and destination address scopes. Can a packet with a link-local or ULA address reach the global destination? There is no doubt about that, at least not in IPv6 theory.

Ivan Pepelnjak was discussing the usage of ULA (Unique Local Addresses) recently in one of his blog post at ipSpace. He says: “If the destination IPv6 address is a global IPv6 address and the source host has an ULA address but no global IPv6 address, it tries to use the ULA source IPv6 address (and might reach the destination or not).”. To understand why this can actually work, it is necessary to have some insight about scopes and zone in IPv6, and the basic rules that dictate the packet forwarding within the scope zone.

Here is a simple question for you. You have two IPv6 systems, node N1 and node N2, connected to each other with a link L12 as depicted below:


N1 has interface i1 with link-local address only, fe80::1 in our example – on the other hand, N2 has two IPv6 addresses on its interface i2, link-local (fe80::<something>) and a unicast-global address 2001:db8::2. N1 has a default route to reach the IPv6 internet pointing via i1 to i2, N2 has no routing enabled. N1 and N2 have no other interfaces in our example.

The question is:

Will “ping” from a link-local source i1 at N1 to a global destination i2 at N2 work?

I admit I was not sure about the answer at first because I was “taught” that a link-local source can not reach the global address ever. But this is a very oversimplified statement, wrong even. Actually, what is required and sufficient for a successful communication in our case is that the interface which is sending the packet (source interface) is part of this packet’s destination address zone and the interface that receives the packet (destination interface) is in the packet’s source address zone. Therefore, a packet will never leave a zone.

By the way, I’ve found some very nice explanations about IPv6 Address Scope and Zone in the IPv6 for IPv4 Experts book, written by Yar Tikhiy. This book is very special in a way it explains the IPv6 principles. It is not written as a technical manual but as a true story about IPv6 :-). Of course, reading RFCs, like RFC 4007 – IPv6 Scoped Address Architecture also helps.

So, let us define the scopes and the zones first.

  • IPv6 address defines a scope. Scope is a topological span within which the address is meaningful as a unique identifier of a network interface (or of a set of interfaces, in case of a multicast address).
  • A scope zone, or simply a zone, is a connected region of topology of a given scope (RFC 4007).
    • Zone boundaries cut through nodes, not through links.
    • There is no partial overlap between zones.
    • A zone of a larger scope can fully contain zones of smaller scope.

(Programmers, you can think of a scope as an abstract class and of a zone as a specific object derived from that class.)

This is the important rule: Zone isolation principle demands that the entire path of a packet whose source or destination address is from a particular zone must stay within that zone boundaries.

IPv6 interface belongs to a certain zone of each possible scope, that is – each IPv6 interface is attached to no more than one zone of each scope. As show on the following picture, the interface with its link-local address is in the link zone and at the same time this interface with its global address is part of the global zone called Internet:


So, what happens with N1> ping 2001:db8::2 source fe80::1? Packet can be sent from node N1 because the sending interface i1 is part of the global internet zone, same as the destination address 2001:db8::2. This is true because interface i1 is the default gateway for N1. The egress interface i1 is part of both zones, link L12 and internet.
When packet is received by N2, its source address is link-local scope, same as the zone (link L12) of the receiving interface i2. Similar arguments hold for the reply. Source i2 is in the same zone as the destination address fe80::1 (zone link L12) and receiving interface i1 is in the same zone as source address 2001:db8::2 (internet). Therefore, ping should work fine. Go ahead and try it in your little lab ;-). Then try to answer and explain this one:


Will N1> ping 2001:db8:ffff::f source fe80::1work?



IPv6 nd State Machine

9 Jan

Have you ever questioned yourself what happens when an IPv6 host wants to send a packet to a certain destination with a link-layer address unknown. In IPv4, finding a proper link-layer address for a certain IPv4 address is done by ARP. However, in IPv6, ARP is replaced by IPv6 Neighbour Discovery, ND for short. Instead of an ARP cache an IPv6 host maintains a Neighbour Cache (NC) with IP-to-link-layer address mappings. Each NC entry has a well-defined state, namely INCOMPLETE, REACHABLE, STALE, DELAY and PROBE. A host is capable of sending packets to a destination in all states except INCOMPLETE or when there is no corresponding NC entry. In INCOMPLETE state the data packets are queued pending completion of address resolution. Please, refer to RFC 4861 for more details.

An algorithm that controls transitions between the states of a NC cache entry is in my focus here. What actually impressed me was the art of the ND Reachability State Machine. Here is how it might look like:


Yes, the background of the IPv6 alternative for ARP is complex but well-defined. A piece of tech-art, I’d say. You might never come close to it in practice, but it is there and it makes IPv6 work for you :-).


%d bloggers like this: