InterComms :: International Communications Project
  Intercomms Issue 20
Issue 20 Articles

IPv6 Forum logoThe Big Shift to IPv6-Based IoT
is on the Roll!

Based on the IoT6 Project preliminary results: IoT6 – Moving to an IPv6-based Future IoT report

PDF icon Download article as PDF
Latif Ladid, IPv6 Forum President
Latif Ladid, IPv6 Forum President

IoT6 in brief

The Internet protocol version 6 (IPv6) is emerging as the de facto solution to scale up the current Internet to an almost unlimited number of globally reachable unique addresses. IoT6 is a 3 years FP7 European research project on the future Internet of Things. It aims at exploiting the potential of IPv6 and related standards (6LoWPAN, CORE, COAP, etc.) to overcome current shortcomings and fragmentation of the Internet of Things. Its main challenges and objectives are to research, design and develop a highly scalable IPv6-based Service-Oriented Architecture to achieve interoperability, mobility, cloud computing integration and intelligence distribution among heterogeneous smart things components, applications and services. Its potential will be researched by exploring innovative forms of interactions such as:

  • Information and intelligence distribution.
  • Multi-protocol interoperability with and among heterogeneous devices.
  • Device mobility and mobile phone networks integration, to provide ubiquitous access and seamless communication.
  • Cloud computing integration with Software as a Service (SaaS).
  • IPv6 - Smart Things Information Services (STIS) innovative interactions.

The main outcomes of IoT6 are recommendations on IPv6 features exploitation for the Internet of Things and an open and well-defined IPv6-based Service Oriented Architecture enabling interoperability, mobility, cloud computing and intelligence distribution among heterogeneous smart things components, applications and services, including with business processes management tools.

IPv6 capabilities for the Internet of Things

Global Internet human users are currently estimated at 2.4 Billion and are further projected to climb to 3.0 Billion by 2015. More significantly, the number of Internet connected objects has overpassed the number of connected human beings, and is expected to expend far beyond the human population, with 20 to 50 Billion interconnected smart things. Over the last decades, the Internet Protocol version 4 (IPv4) has emerged as the mainstream protocol for networking layer. However, this protocol was not designed for the Internet of Things (IoT) and is inherently limited to about 4 Billion addresses. At the global level, IANA has entirely exhausted its IPv4 addresses allocation on 3rd Feb 2011; and two out of five RIRs (Regional Internet Registries) have achieved their address allocation limit in April 2011 by APNIC and in August 2012 by RIPE. The Internet Protocol version 6 (IPv6) has been adopted by IANA and the RIRs to overpass the IPv4 limitations and to address the growing demand. IPv6 provides an almost unlimited (2128) number of unique Internet addresses. It also provides new features enabling an easier configuration of devices, improved security, and enable real peer-to-peer connections, without passing through NAT barriers. All those elements contribute to turn IPv6 into a natural candidate for IoT addressing and networking.

Many devices are already interconnected through the Internet Protocol, including printers, sensors, lightings, healthcare systems, energy meters, video cameras, TVs and heating control systems. The emergence of IPv6-related standards specifically designed for the IoT, such as 6LoWPAN, CoAP, and CoRE, has enabled highly con-strained devices to become natively IP compliant. IPv6 is being referred to in a growing number of IoT and M2M related standards, such as oneM2M or the IEEE 802.15.4g protocol, which will support Advanced Metering Infrastructure (AMI) for smart cities deployments.

IPv6 Worldwide Deployment

In order to assess the potential of IPv6 to integrate the future IoT, it is important to evaluate its effective and potential adoption by the industry. 2012, has indicated a clear shift towards IPv6 global deployment both by the public and private sectors. IPv6 is increasingly deployed across the World. Google has reached 1% of users connecting over IPv6 and over 22% of the top 500 web sites are already IPv6 compliant.1 In Europe, IPv6 adoption is gaining significant momentum with RIPE NCC having announced its final /8 allocation policy for IPv4 address pool in August 2012. It is reinforced by the European Commission action plan for the deployment of IPv6.2 On a percentage basis, Romania is leading the deployment with 8.43% per cent adoption rate followed by France at 4.69%.

In North America, IPv6 adoption rate is at 1.97%. It translates into an estimated IPv6 user base of 3.5 million users, the largest base of IPv6 users in the world. In September 2010, the US Federal CIO released a new IPv6 directive that established a step-wise approach for agencies transitioning to IPv6. This approach focused Federal agencies on meeting a short-term goal of making their external and public-facing services IPv6 operational by the end of 2012

In Asia and Pacific, with India and China evolving into large internet economies, the impact of IPv4 exhaustion is more acute since APNIC has exhausted its IPv4 address pool and has initiated the final /8 allocation policy.

Africa being a late entrant into the technology landscape also has the advantage of direct IPv6 implementation. According to AfriNIC, IPv4 allocations have been on the decline and countries have started taking up IPv6. Kenya and South Africa are leading in IPv6 allocations. In Latin America, countries such as Brazil, Argentina, Venezuela, Columbia, Chile and Peru are beginning their IPv6 transition.

Figure 1: High-level IoT6 architecture indicating network domains
Figure 1: High-level IoT6 architecture indicating network domains

IoT6 Architectural Perspective

Over the years, a number of projects have specified various versions of IoT architectures, basing them on the specific requirements the projects were addressing (SENSEI,3 HOBNET,4 etc.) Due to a large heterogeneity of application domains and consequently the requirements, the approaches to the architecture specification differed between the projects resulting in more or less different architectures comprised of a number of components and protocols. The diversity of the architectures was soon recognized by the community as one of the factors limiting the progress in the domain which resulted in more coordinated efforts driven by the IERC aiming to specify a common, harmonized reference IoT architecture. A significant role in this effort has the IoT-A project.5 This project has extensively analysed IoT application domains and devised a reference architecture model that can be used for specification of reference architectures and architecture instantiations suitable for specific systems.

Other important coordinated effort that should be noted is the FI-PPP program and the FI-WARE architecture.6 There, a detailed architecture of a Future Internet platform has been designed taking into account inputs from numerous European organizations, also covering in the process the IoT functionality as an important aspect of the Future Internet. Further to this, a large and significant has been done in the framework of the ETSI M2M Technical Committee, and more recently oneM2M alliance.7

The aim of the IoT6 architecture is to enable a highly scalable IPv6-based Service-Oriented Architecture to achieve interoperability between different communication technologies and efficient interaction with the cloud based services providing intelligent information processing, application specific visualization and integration with business processes and workflows. The approach selected towards definition of the IoT6 architecture is to leverage the on-going related activities by extending, enhancing and modifying different architectural components with a particular focus on the communication layer. This focus on the communication layer comes from the project focus on IPv6 as the as the main integrating point for various IoT devices, underlying technologies as well as higher layer services and applications. The goal was not only to use IPv6 as a pure transport protocol, but to leverage the embedded IPv6 features to enable functions currently implemented using higher layer protocols. This approach complements well other IoT architecture efforts as these mainly focus on higher layers and do not address the details of the communication layer, but usually assume IP or any other communication paradigm.

Having this in mind, based on the requirements analysis of several application do-mains and similar efforts done in other projects as well as the IoT reference architecture model proposed by the IoT-A project and FI-WARE’s and ETSI M2M proposed IoT architectures, the initial IoT6 architecture was designed. To a large extent, the IoT6 architecture adopts the existing solutions and provides novel proposals on the communication layer. These proposals facilitate utilization of IPv6 addressing schemes across IoT devices, including those that do not natively support IPv6 and leverage DNS functionality to provide resource and service registration and discovery. To that end, discovery of services is conducted through the IPv6 network-based information systems that are already deployed, such as the domain name system with service discovery (DNS-SD). In the same manner, a resource directory serving a local domain can be replaced with a multicast DNS (mDNS), thus providing the required functionality exploiting and extending the IPv6 functions only.8

Figure 1 shows the IoT6 architecture model indicating different network domains. IoT devices (sensors and actuators) can be found at the bottom of the architecture stack outlined in Figure 1. There are two distinct types of devices: IoT6 compliant and IoT6 non-compliant or legacy devices. The IoT6 compliant devices can be IPv6-enabled IoT devices or IoT devices based on protocols such as 6LoWPAN and the proposed GLoWBAL IPv6,9 CoAP10 and CoRE11 [9] protocols. The IoT6 non-compliant devices are based on other, non-IP communication protocols, as well as IPv4-based devices. The IoT6 non-compliant devices, require gateways or proxies to be connected to the rest of the IoT6 system in order to adapt the native protocols, functionality and addressing to IPv6 through a transparent mechanism. IoT6 Local Area Network (LAN) provides connectivity mechanisms to IoT devices taking into account their specific protocols and technology and making them available to the rest of the IPv6 powered environment in terms of discovery, access and management. The IoT6 wide area network (WAN) enables the interconnection of multiple IoT6 LANs and IoT6 backend servers and creates the overall IoT6 core infrastructure. This infrastructure offers access to the IoT devices from the application-level layer consisting of different services such as Software as a Service (SaaS), Smart Things Information Service (STIS), Web and mobile applications to mention a few examples.

Figure 2: Digcovery ecosystem
Figure 2: Digcovery ecosystem

Resources repository and service discovery

A key requirement for any IoT architecture is to provide adequate service discovery and registries. This becomes even more challenging, when it is supposed to en-compass the actual heterogeneity of the IoT. IoT6 has designed a concept of “Digcovery”, which is illustrated in Figure 2. This presents how the different technologies involved in the Internet of Things ecosystem such as Smart Objects, RFID tags, and legacy devices, are integrated into different directories named “digrectories”. These digrectories are managed through DNS-queries extended with an elastic search engine in order to make it scalable at the same time it offers a centralized point, called “digcovery core”, to manage and discover them.

All the resources and services are mapped to a common ontology and description, based on existing ontologies and profiles from the IP-enabled Smart Objects Alliance (IPSO),12 13 and oBIX from the Building Automation area. It will also consider emerging profiles developed by standardization bodies such as the Open Mobile Alliance (OMA)14. These semantic layer interfaces have been integrated into the DNS-SD types, in order to reach a common semantic description accessible through DNS and powered with the universal IPv6 capabilities to carry out the discovery resolution.

This also presents how to interoperate with the discovery architecture through other interfaces different to DNS such as RESTful architecture with data structured in JSON format. JSON has been chosen for the interoperability with all the resources, since it is considered by the Working Groups from the IETF such as the Constrained Resources (CoRE) Working Group, and the Constrained Management (COMA) Working Group as the most suitable protocol to structure the data for constrained resources, leaving other formats such as XML optional.

Specific solutions have been developed to enable look-up and queries over digcovery, exploiting ElasticSearch and enabling queries on various Digrectories with context awareness, based on location or resource types. The proposed architecture enables organized and context-based queries over heterogeneous and distributed registries of resources and services.

The IoT6 architecture uses a RESTFul interface based on CoAP15 developed by the IETF CoRE Working Group. This enables the integration of constrained devices with an overhead of only 4 bytes and a functionality optimized for the observation of resources,16 application-layer fragmentation,17 and mapping with the HTTP-based RESTFul architecture.

The platform can use Domain Name Servers (DNS) in order to exploit existing IP-based technologies, protocols and mechanisms. It can also use a Web-based platform to access and register resources through a RESTFul architecture. However, the IoT6 architecture can integrate other repositories such as HANDLE,18 for the mirroring of the objects with Digital Object Identifiers (DOI), or EPCIS for RFID tags.

This is an extract from a report compiled by: Sébastien Ziegler and Cedric Crettaz (Mandat International, Geneva, Switzerland {iot6, sziegler}, Latif Ladid (University of Luxembourg, Luxembourg, Luxembourg, Srdjan Krco (Ericsson, Belgrade, Serbia, Boris Pokric ( Antonio Skarmeta and Antonio Jara (University of Murcia, Murcia, Spain {skarmeta, jara} and Wolfgang Kastner (Technical University of Vienna, Vienna, Austria

IPv6 Forum logo
For more information visit:

1 According to a study launched by Lars Eggert , IRTF Chair– IPv6 Deployment Trends
2 “ADVANCING THE INTERNET Action Plan for the deployment of Internet Protocol version 6 (IPv6) in Europe” - click here
3 SENSEI (Integrating the Physical with the Digital World of the Network of the Future), Per-vasive and Trusted Network and Service Infrastructures: ICT-2007.1.1: The Network of the Future, Contract no. 215923,
4 Hobnet project,
5 Internet of Things Architecture, IoT-A,
6 FI-WARE Internet of Things (IoT) Services Enablement, click here
7 ETSI M2M Communications,
8 Jara, A.J.; Martinez-Julia, P.; Skarmeta A.F.: “Light-weight multicast DNS and DNS-SD (lmDNS-SD): IPv6-based resource and service discovery for the Web of Things”, Interna-tional Workshop on Extending Seamlessly to the Internet of Things, 2012.
9 Jara, A. J.; Zamora, M.A.; Skarmeta, A.F.; “GLoWBAL IP: an adaptive and transparent IPv6 integration in the Internet of Things”, Mobile Information Systems, “accepted and in press”, 2012.
10 Constrained Application Protocol (CoAP), draft-ietf-core-coap-11,, 2012-07-16.
11 Constrained RESTful Environments,
12 Dunkels, A., Vasseur, J.: IP for Smart Objects, Internet Protocol for Smart Objects (IPSO) Alliance, White Paper, N. 1, IPSO Alliance (2008)
13 Shelby, Z., Chauvenet, C.: The IPSO Application Framework, draft-ipso-app-framework-04, IPSO Alliance, Interop Committee (2012)
14 Linyi Tian: Lightweight M2M (OMA LWM2M), OMA Device Management Working Group (OMA DM WG), Open Mobile Alliance - OMA (2012)
15 Shelby, Z., Hartke, K., Bormann, C., Frank, B.: Constrained Application Protocol (CoAP), Constrained Resources (CoRE) Working Group, Internet Engineering Task Force (IETF), work in progress, draft-ietf-core-coap-13 (2012)
16 Li, Shi Tao, Hoebeke, J., Jara, A.J.: Conditional observe in CoAP, Constrained Resources (CoRE) Working Group, Internet Engineering Task Force (IETF), work in progress, draft-li-core-conditional-observe-03 (2012)
17 Shelby, Z.: Embedded web services, Wireless Communications, IEEE, Vol.17, No.6, pp. 52-57, doi: 10.1109/MWC.2010.5675778 (2010)
18 Sun, S., Lannom, L., Boesch, B.: RFC3650 - Handle System Overview, , IETF Standards (2003)

Upcoming Events
Intercomms on ereader
Intercomms ebook: click here
Valid XHTML 1.0 Strict
Other publications by Intercomms: