Grant agreement for: Collaborative project Grant agreement

Universal Integration of the Internet of Things through an IPv6-based

Service Oriented Architecture enabling heterogeneous components

interoperability

Grant agreement for: Collaborative project

Grant agreement no.: 288445

Start date of project: October 1st, 2011 (36 months duration)

Deliverable D8.3.3

Standardisation Activities & Efforts

Contract Due Date 30/09/2013

Submission Date 30/09/2013

Version v1.0

Responsible Partner University of Luxembourg (UL)

Author List L. Ladid (UL), S. Ziegler (MI), S. Krčo (Ericsson), A.

Skarmeta (UMU) M.R. Palattella (UL)

Dissemination level PU

Keywords Internet of Things, IPv6, Roadmap, Standardisation

Project Coordinator: Mandat International (MI)

Sébastien Ziegler <[email protected]>

D8.3.3 Standardization Activities and Efforts

2

Abstract

This Deliverable describes the new initiatives undertaken in Y3 by the IoT6 project partners for the

standardisation and awareness creation during and beyond the lifetime of the project following the

reviewers Y2 review recommendations, in order to take a strong step in getting the findings and

results out to industry and major stakeholders,

The IoT6 project partners did not spare any effort to form coalitions and partnerships and undertook

convincing stances and positive energy and attitude to win influencers of Standards and key

industry advocates to endorse the mature results of the project and spread them for adoption.


3

Table of Contents

1. Introduction .................................................................................. 4

2. Year 3 Standardisation Activities ......................................................... 5

2.1. New Standardization Efforts with ETSI and IETF ............................................... 5

2.1.1. Direct Cooperation with ETSI ................................................................ 5

2.1.2. IETF work performed ......................................................................... 7

2.1.3. Interaction with the ITU ..................................................................... 9

2.1.4. Cooperation with fora and international Organisations (IEEE ComSoc) ............... 9

2.2. Ongoing standardization effort at OASIS ....................................................... 15

2.3. New standardization effort: Web Service specification for home and building automation .................................................................................................. 15

3. Conclusion ................................................................................... 17

4. Annexes ...................................................................................... 18

4.1. Annex I – ETSI ISG IP6 (first 6 pages from 15) .................................................. 18

4.2. Annex II – IoT Standardisation Chapter, IERC Book 2014 (first 2 pages from 56) ......... 23

4.3. Annex III – Handle System ......................................................................... 25

4.3.1. Some Features of the Handle System ..................................................... 25

4.3.2. Handles as Persistent Identifiers........................................................... 25

4.3.3. Handle Syntax ................................................................................. 25

4.3.4. Handle Resolution and relevance to IoT applications ................................... 26

4.3.5. Administering Handles – Security Provisions and Implications ........................ 26

4.3.6. Handle System Scalability ................................................................... 27

4.3.7. Storage scalability ........................................................................... 27

4.3.8. Security aspects .............................................................................. 28

4.3.9. Authentication ................................................................................ 28

4.3.10. Security Services in Handle ................................................................. 28

4.3.11. Handle Value Types .......................................................................... 29

4.3.12. Template Handles ............................................................................ 29

4.4. Annex IV – IETF Standardisation Efforts ......................................................... 30


4

1. Introduction

The IoT6 project aimed at exploiting the potential of IPv6 and related standards (6LoWPAN,

COAP, etc.) to overcome current shortcomings and fragmentation of the Internet of Things, in

line with the IERC (Internet of Things European Research Cluster) and EC recommendations.

Its main challenges and objectives were 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 has been 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 - STIS Information Service (Smart Things Information Services) innovative

interactions.

The main outcomes of IoT6 are recommendations on IPv6 feature exploitation for the Internet of

Things and an open and well-defined IPv6-based Service Oriented Architecture (SOA) enabling

interoperability, mobility, cloud computing and intelligence distribution among heterogeneous

smart things components, applications and services, including business process management

tools.

To achieve these ambitious goals, the consortium consists of seven international academic or

research partners and two industrial partners that bring in expertise from complementary

research areas such as IPv6, multi-protocol interoperability, routing protocols, security, SOAs,

sensor networks, building automation, mobile phone networks, cloud computing, business

processes and STIS/RFID. IoT6 was supported by a large industry support group with renowned

members, who acted as general advisors and supported the dissemination, exploitation and

standardisation activities.


5

2. Year 3 Standardisation Activities

The main standardisation bodies targeted by the IoT6 partners are ETSI and the IETF. The close

cooperation with the IERC has proved to be of very strategic value. In particular, the core IoT6

partners are championing some IERC WG activities and conference tracks through their leading

roles in the IoT Forum and IoT Week organisation, facilitating smooth and credible interactions

and peering with the other influencers on the strategy of IoT research and standardisation. The

standardisation activities can be summarised as follows:

2.1. New Standardization Efforts with ETSI and IETF

Following the recommendation of the reviewers to take a strong step in getting the findings and

results out to industry and major stakeholders, a closer working relationship has been established

with ETSI in Y3, due mainly to the realisation and acceptance by the IERC standardisation task

run by Patrick Guillemin at ETSI. This has resulted in the realisation that IPv6 is a key

communication protocol for IoT, thereby transforming earlier perceptions of IPv6 as a

controversial technology within the IoT research community which worked for 5 to 6 years on

RFID-only based IoT.

A follow-up workshop was organized by IoT6 on IPv6-and-IoT, within the framework of the IoT

Week 2014 in London. It brought together ETSI, IoT6 partners, the IERC Cluster project as well

as various European research projects to explore the potential of IPv6 and IoT.

2.1.1. Direct Cooperation with ETSI

In a new consultation with our ETSI representative, we have further pursued our standardisation

activities with the following decisive actions:

2.1.1.1 Creation of the ETSI Industry Specification Group IP6 (IPv6 ISG)

Following an evaluation of the IoT6 standardisation efforts from the first and second years of the

project, we have decided to create a new Industry Specification Group (ISG) at ETSI called

“IP6”.

Latif Ladid, a 3GPP board member since 1999, has been asked by ETSI to convene a first

meeting of this ISG. Latif had already established back in 2009 the very first ETSI ISG for

Autonomics called the “Autonomic Future Internet” (AFI), which was formed from the FP7

project EFIPSANS and concluded its work with industry-oriented recommendations.

The first meeting with the ETSI management for the discussion and application of the ETSI ISG

“IP6” was held on February 18, 2014. The application was submitted four weeks later and - after

many re-iterations – it was submitted to the ETSI Board at the end of June. The Board asked for

some detailed definition of the precise objectives and tasks which were resubmitted at the end of

July for review at the next ETSI meeting at the end of September 2014. The Board’s acceptance

at that meeting will enable the start of the work in October 2014 and we have the assurance that

this ISG will be accepted by our ETSI representative on the IoT6 Advisory Board which has a

keen interest in seeing this happen. The complete application can be viewed in Annex 1.


6

Logo of the ETSI “IP6” ISG

The IP6 ISG has the ambition to define Best Practices and garner support and create awareness

of the IPv6 impact on critical infrastructure in the first round, and then on hot topics such as IoT,

Cloud Computing, SDN-NFV and 5G which are similarly built on IPv6.

The “IPv6 integration” Industry Specification Group (“IP6 ISG”) is a Best Practice Working

Group focusing on the investigation of requirements and Use Cases identifying what and where

pre-standardization consensus and harmonization can be reached.

In the case of future wireless networks, the IP6 ISG will decouple its work from radio and focus

on v4-v6 impact in early technical discussions, integrating new technologies with a holistic

approach such as IPv6-based Software Defined Networks (SDN), Machine-to-Machine, Mobile

Internet of Things, Mobile Cloud Computing and Fringe Internet, focusing on commonly agreed

requirements toward the emergence of an “IPv6 integration”.

The tasks of the IP6 ISG will be implemented in three phases:

Phase 1:

The core team will select and define 3 focused Use Cases, where IPv6 can have real

impact, such as:

o Mobile networks and services

o Critical infrastructure in the safety and emergency networks,

o Security and privacy

At the start of Phase 1, new members (to reach some 50 experts and over 200 members

organisations) will be attracted to support not only the groundwork, but also prepare for

Phase 2.

Phase 2:

Attract IPv6 experts with focused and practical knowledge, to define the impact of IPv6

on:

o Mobile Cloud Computing and the impact of Mobile IPv6.

o Internet of Things and the impact of addressing billions of devices.

o SDN and Network Functions Virtualization (NFV) and the role IPv6 will play in

the Internet Data Centres (IDCs) and the Operators networks.

o Fringe Internet and the impact of scalability of the edge network.

Phase 3:

Coordinate with the 5G PPP researchers and attract IPv6 experts with focused and

practical knowledge in 5G networking to:


7

o Define the interaction impact of IPv6 with the 5G radio research (5G PPP)

especially in areas of spectrum efficiency and latency when using IPv6 packets.

2.1.1.2 Contribution to the Global Standardisation Book

The IoT6 has contributed to the Global Standardisation chapter of the IERC Book 2014. The

main focus was to make sure that IPv6 is specified as the preferred IP communication protocol.

The IERC standardisation community that contributed and edited this 56 pages long chapter have

not touched or edited the IPv6 and all related IPv6 sections. This is because for years IPv6 has

been perceived as a controversial topic especially since all past IoT research and standardisation

efforts have concluded that RFID is the Internet of Things.

The complete text can be read on the IERC web site: http://www.internet-of-things-

research.eu/pdf/IoT-

From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_Cluster_e

Book_978-87-93102-95-8_P.pdf

2.1.1.3 Contribution of UCL to ETSI with the Handle System

UCL has participated in the ETSI/EC work on standardisation by participating in the July 3rd

- 4th

meeting on “Standards in IoT” in Nice, France. Peter Kirstein made a presentation entitled:

“Standards for a Digital Object Approach to IoT”. This presentation discussed the Handle

approach to identifier resolution, and how this class of system could be used in the management

of properties of the Handles associated with the identifiers. In particular, he discussed how their

approach to an authorization requirement for any access to the Handles resulted in a system that

revealed much less information about the nature of physical systems to unauthorised agents. The

link to IPv6 addresses was effected by making these attributes to a Handle. The nature of IPv6

multiple addresses for the same object, allows independent agents to access the same IoT

interfaces through independent network paths – which reflects their organisation’s network

routing in their application domain. It also permits the storage of security tokens securely in a

data repository of security tokens associated with specific Handles.

In a related dissemination activity, the same authors contributed to the recent IERC activity on

Governance and Security in IoT.

The features of the Handle System are outlined in Annex III.

2.1.2. IETF work performed

2.1.2.1 Draft Standard submission to the IETF

HESSO and UL have resubmitted the Internet draft “IPv6 mapping to non-IP” draft-rizzo-6lo-

6legacy-01 under the new IETF WG 6lo replacing the 6LowPAN WG.

Abstract:

IPv6 is an important enabler of the Internet of Things, since it provides an addressing space large

enough to encompass a vast and ubiquitous set of sensors and devices, allowing them to

interconnect and interact seamlessly. To date, an important fraction of those devices is based on

networking technologies other than IP. An important problem to solve in order to include them

into an IPv6-based Internet of Things, is to define a mechanism for assigning an IPv6 address to

each of them, in a way which avoids conflicts and protocol aliasing.

http://www.internet-of-things-research.eu/pdf/IoT-From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_Cluster_eBook_978-87-93102-95-8_P.pdf





8

The only existing proposal for such a mapping leaves many problems unsolved and it is

nowadays inadequate to cope with the new scenarios which the Internet of Things presents. This

document defines a mechanism, 6TONon-IP, for assigning automatically an IPv6 address to

devices which do not support IPv6 or IPv4, in a way which minimizes the chances of address

conflicts, and of frequent configuration changes due to connection instability among devices.

Such a mapping mechanism enables stateless autoconfiguration for legacy technology devices,

allowing them to interconnect through the Internet and to fully integrate into a world wide scale,

IPv6-based IoT.

The Internet draft is listed under Annex IV: http://www.ietf.org/mail-archive/web/i-d-

announce/current/msg56550.html

2.1.2.2 UMU Standardisation activity at the IETF

Within Y3, UMU has been active following the newly created WG Authentication and

Authorization for Constrained Environments (ACE). Specifically the UMU team has presented a

draft related to IoT6 work on the use of EAP and CoAP for authentication and authorization

http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-00:

Abstract

This document describes an authentication service that uses EAP transported by means of CoAP

messages with two purposes:

o Authenticate two CoAP endpoints.

o Bootstrap key material to protect CoAP messages exchanged between them.

2.1.2.3 6TiSCH Standardization activities

UL have contributed to the Internet draft 6TiSCH On-the-Fly Scheduling draft-dujovne-6tisch-

on-the-fly-03 under the IETF WG 6TiSCH.

Abstract

This document describes the environment, problem statement, and goals of On-The-Fly (OTF)

scheduling, a Layer-3 mechanism for 6TiSCH networks. The purpose of OTF is to dynamically

adapt the aggregate bandwidth, i.e., the number of reserved soft cells between neighbor nodes,

based on the specific application constraints to be satisfied. When using OTF, softcell and

bundle reservation is distributed: through the 6top interface, neighbor nodes negotiate the cell(s)

to be (re)allocated/deleted, with no intervention needed of a centralized entity. This document

aims at defining a module which uses the functionalities provided by the 6top sublayer to (i)

extract statistics and (ii) determine when to reserve/delete soft cells in the schedule. The exact

reservation and deletion algorithm, and the number and type of statistics to be used in the

algorithm are out of scope. OTF deals only with the number of softcells to be reserved/deleted; it

is up to 6top to select the specific soft cells within the TSCH schedule.

The Internet draft can be viewed under: https://datatracker.ietf.org/doc/draft-dujovne-6tisch-on-the-fly/

http://www.ietf.org/mail-archive/web/i-d-announce/current/msg56550.html

http://www.ietf.org/mail-archive/web/i-d-announce/current/msg56550.html

http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-00

https://datatracker.ietf.org/doc/draft-dujovne-6tisch-on-the-fly/

https://datatracker.ietf.org/doc/draft-dujovne-6tisch-on-the-fly/


9

University of Murcia (UMU) is also involved in the 6TiSCH activities related to the security

aspect of the 6TiSCH architecture. In detail, UMU has co-authors the draft [15]. This document

introduces a more secure and scalable key management framework for 6TiSCH networks using

PANA (Protocol for carrying Authentication for Network Access) as the bootstrapping

mechanism and identifies requirements for key management protocols to be used in the

framework.

2.1.3. Interaction with the ITU

MI has maintained an active link with the International Telecommunication Union (ITU). The

effort was focused on three ITU fora:

• The ITU World Telecom Conference in Bangkok, where UL and MI have organized an

IoT6 workshop on IPv6 for IoT. The workshop has been well attended and managed to

explore links of cooperation with the Asian research community.

• The JCA-IoT, which coordinates the standardization effort on the IoT. MI attended

several meetings and made two presentations of its research effort on IoT and IPv6.

• Green ICT Week, which focuses on green ICT and climate changes. MI attended two

Green ICT Weeks and made each time a presentation of its research efforts and

outcomes.

At the last Green ICT Week organized by the ITU in Beijing, MI has formally submitted

a proposal to organize a session and a demonstration on IoT technologies, in the

framework of an ITU IoT-JCA and/or Green ICT meetings. The idea is to present not

only IoT6 results, but to involve other European research projects too, including IoT Lab.

The targeted time would be in 2015 and will be further discussed with the ITU. Finally,

the ITU Regional Office for Asia and the Pacific has requested MI to provide support on

IPv6 and security strategy.

2.1.4. Cooperation with fora and international Organisations (IEEE

ComSoc)

The IoT6 partners have contributed in the foundation of the IoT Forum under the leadership of

MI based now in Switzerland: http://iotforum.org/contact/.

The IEEE ComSoc IoT initiative proved to be a strategic channel to get the results of the IoT6

out to the world. The chair of the IEEE ComSoc Emerging Technologies Committee, Prof

Andrea Schmidt from Stanford, a highly recognized expert in the IEEE world has been very

laudable with the IoT subC work and was very supportive of the new initiatives in 5G and SDN-

NFV.

The work done by Antonio Jara with the IPSO alliance is very important to note.

2.1.4.1 IoT Forum

IoT6 took part in the Technology WG session of the International IoT Forum (London, June

2014) and presented the vision of IPv6’s role in IoT. Moreover, MI organized with the other

IoT6 members a special session on IoT and IPv6 which gave the opportunity to strengthen the

links and align the visions on IPv6 potential for IoT related projects.

http://iotforum.org/contact/


10

2.1.4.2 IPSO Alliance

Antonio Jara has contributed to the IPSO alliance IoT Starter Pack 1.0 working with the inventor

of 6LoWPAN Geoff Mulligan with a quote in this press release listed below.

“Thanks to contributions such as GLoWBAL IPv6 developed in the context of IoT6, IPv6

support is being offered for Bluetooth Smart devices. This means that millions of Smart Phones

and SOHO devices can be benefited of IPv6 capabilities, presenting a disruptive innovation for

the Internet of Things market powered by IPv6. This IPv6 capabilities in conjunction with the

other protocols addressed such as CoAP are enabling this personal area network devices,

invisible until now for Internet, be able to interact with Cloud Computing services, and cross

borders between capillary and cellular networks. In fact, the solution based on Bluetooth Smart

is considered the reference implementation from OMA LWM2M (http://oma.post.camp/source-

code/lab-kit/) and being considered the most innovative solution during the IPSO Challenge

2014 (Best people's choice award) and Sensors Expo (Attendees Award) during its last edition in

Chicago (USA). The innovation value was to offer the first Bluetooth Smart and IPv6-ready

solution in the market (http://www.ipso-alliance.org/challenge/ipso-challenge-2014-

interviews/hop-into-the-iot-through-ipv6-ready-bluetooth-smart-devices).”

Nowadays, these capabilities are making echo in other EU projects such as BUTLER and

OpenIoT (in the context of the Smart Action initiative), which is integrating this IPv6-ready

devices into their platforms.

Finally, the HOP Ubiquitous team continues contributing to OMA LWM2M for the mapping of

Bluetooth Smart functions and emerging devices, which will be released in the coming releases

of OMA Web objects definitions from the IPSO Alliance.

IPSO Alliance Publishes Smart Objects Guideline – Starter Pack 1.0

Smart Objects promote web scale interoperability between IP-connected devices and

Internet of Things (IoT) applications

Colorado Springs, CO – September 30, 2014—The Internet Protocol for Smart Objects

(IPSO) Alliance has published its Smart Objects Guideline – Starter Pack 1.0. The Smart

Objects Starter Pack (SOSP) 1.0 provides a basis for interoperability across devices

connected to the IoT through an open common object model. This open standards based

data design is crucial for the wide scale deployment and success of IoT and Machine to

Machine (M2M) applications.

In its role as the leader in the use of Internet Protocol (IP) across the IoT, IPSO has been

working to promote the use of open standards and explain the benefits of an IP based

end-to-end IoT. With this publication, IPSO is moving from “Why use IP” to “How to

use IP”. Geoff Mulligan, IPSO Chairman, explains, “This document is the first in a series

that will serve as a guide to developers, product designers and anyone choosing between

closed proprietary systems and open standards based solutions. These guidelines will help

innovators more easily use IP in Smart Objects for new application domains and help

facilitate growth in the IoT.”

The Alliance is now working on IoT architecture guidelines that will bring together the

knowledge of IPSO members from across industries including Smart Energy, Smart

Cities, Healthcare, Home Automation, Process Control and Building Automation. These

documents will provide a guide to understanding how various open standards can be

http://oma.post.camp/source-code/lab-kit/

http://oma.post.camp/source-code/lab-kit/

http://www.ipso-alliance.org/challenge/ipso-challenge-2014-interviews/hop-into-the-iot-through-ipv6-ready-bluetooth-smart-devices

http://www.ipso-alliance.org/challenge/ipso-challenge-2014-interviews/hop-into-the-iot-through-ipv6-ready-bluetooth-smart-devices

http://www.ipso-alliance.org/ipso-alliance-publishes-smart-objects-guideline-starter-pack-1-0

http://www.ipso-alliance.org/

http://www.ipso-alliance.org/

http://www.ipso-alliance.org/smart-object-guidelines


11

combined to build a secure, interoperable, extensible and maintainable IoT and M2M

communications stack.

“Much like the LAMP (Linux, Apache, MySQL and PHP) stack brought growth to the

Internet, a standards based IoT Architecture and Stack design will bring growth,

understanding and stability to the IoT”, Antonio J. Jara, IEEE ComSoc IoT ETC and

HOP Ubiquitous CEO, stated.

To contribute to the development of future technical guidelines, join IPSO Alliance

today. Members receive exclusive access to the IPSO think tank and are instrumental in

driving the direction for the IoT. For more information, visit www.ipso-

alliance.org/membership.

About The IPSO Alliance

The IPSO Alliance was formed in 2008 to promote the use of IP in Smart Objects.

The IPSO Smart Object Committee formed in 2011 to provide guidance on how to use IP

and other standards to enable interoperability between IP-connected devices and IoT

applications.

For more information, contact Jessica Barnes at [email protected].

https://www.linkedin.com/company/ipso-alliance

https://www.facebook.com/IPSOAlliance

https://www.twitter.com/IPSOAlliance

2.1.4.3 IEEE ComSoc IoT subCommittee

http://committees.comsoc.org/IoT

In the context of the project, an IEEE ComSoc technical working group on Internet of Things

(IoT) has been created in November 2012. The group is chaired by Latif Ladid (UL), and vice-

chaired by: Antonio Jara (UMU), Antonio Skarmeta (UMU) and Sebastien Ziegler (MI).

The objective of this subcommittee is to facilitate a global definition of IoT architecture and

governance; investigate the sensitive security and privacy issues; and explore the different

technology scenarios and impacts when enabling Internet protocols over the emerging

generations of IoT devices and networks in order to reach harmonization and end to end

transparency through IPv6. For this reason it is supported by IPv6 Forum (www.ipv6forum.org).

Moreover, this subcommittee has pursued a global collaboration with IEEE ComSoc and non-

IEEE organizations from academia and industry. For this purpose, current members from the

TPCs in the GLOBECOM 2013 IoT Symposium track have been invited as well as members

from industrial alliances such as IPSO Alliance, Open Mobile Alliance (OMA) and

standardization groups such as ETSI M2M, oneM2M and IETF. The worldwide research

community such as the European IERC community has been invited too (http://www.internet-of-

http://www.ipso-alliance.org/membership

http://www.ipso-alliance.org/membership

http://www.ipso-alliance.org/smart-object-committee-charter

mailto:[email protected]

https://www.linkedin.com/company/ipso-alliance

https://www.facebook.com/IPSOAlliance

https://www.twitter.com/IPSOAlliance

http://committees.comsoc.org/IoT

http://www.ipv6forum.org/

http://www.internet-of-things-research.eu/


12

things-research.eu/ ). This multi-discipline of the members from this TC will promote a common

understanding to enable harmonization and convergence on governance, integration and security

of the Internet of Things.

IEEE ComSoc IoT is supporting different conferences such as Globecom 2014 with an Industry

Forum session with participation of the Project Officer Dr. Jorge Pereira to influence the IEEE

ComSoc community to adopt the IoT6 results for a global good. It is also supporting the IEEE

World Forum on Internet of Things, WF-IoT, (http://sites.ieee.org/wf-iot/).

IEEE ComSoc IoT has edited some special issues in journals such as the Journal of Networks

and Computer Applications (http://www.journals.elsevier.com/journal-of-network-and-

computer-applications/).

2.1.4.4 IEEE ComSoc 5G subCommittee

Following the highly successful IEEE ComSoc IoT subcommittee in 2013 start by the IoT6

partners, two new IEEE ComSoc initiatives have been started: 5G and SDN-NFV

IEEE ComSoc 5G subC:

http://committees.comsoc.org/5gmwi

The IoT6 project has taken again a strategic step in applying at the end of 2013 for the IEEE

COMSOC 5G subcommittee and won it to build a set of Best Practices for the industry

deployment in enabling IPv6 as well as IoT on 5G. This 5G subC has started in January 2014.

A certain number of experts from academia and “industry-oriented” has been invited to support

this work, such as but not limited to:

Chair of 5G subC: 3GPP PCG Board member, Founder & President of the IPv6 Forum,

Latif Ladid

Member of the ETSI standardization Group and the Industrial Forum about M2M/IoT:

Patrick Guillemin

Work for leading vendors: Fredrik Garneij, 3-4-5G and IPv6 Specialist at Ericsson;

Pascal Thubert, IoT and IPv6 Expert at the IETF, designer of 6LoWPAN/6TiSH, Cisco

5G Mobile Wirless Internet web site: http://committees.comsoc.org/5gmwi

5G in EU

On the EU side, a very important programme is the 5G –PPP (Public Private Partnership)

programme.

http://www.internet-of-things-research.eu/

http://sites.ieee.org/wf-iot/

http://www.journals.elsevier.com/journal-of-network-and-computer-applications/

http://www.journals.elsevier.com/journal-of-network-and-computer-applications/




13

The 5G Infrastructure Public-Private Partnership, in short 5G PPP, has been initiated by the EU

Commission and industry manufacturers, telecommunications operators, service providers,

SMEs and researchers. The 5G PPP will deliver solutions, architectures, technologies and

standards for the ubiquitous next generation communication infrastructures of the coming

decade. See www.5g-ppp.eu

The challenge for the 5G Public-Private Partnership (5G PPP) is to secure Europe’s leadership in

the particular areas where Europe is strong or where there is potential for creating new markets

such as smart cities, e-health, intelligent transport, education or entertainment and media. The 5G

PPP initiative will reinforce the European industry to successfully compete on global markets

and open new innovation opportunities. It will “open a platform that helps us reach our common

goal to maintain and strengthen the global technological lead”. Our key challenges for the 5G

Infrastructure PPP are:

1. Providing 1000 times higher wireless area capacity and more varied service

capabilities compared to 2010.

2. Saving up to 90% of energy per service provided. The main focus will be in mobile

communication networks where the dominating energy consumption comes from the

radio access network.

3. Reducing the average service creation time cycle from 90 hours to 90 minutes.

4. Creating a secure, reliable and dependable Internet with a “zero perceived” downtime

for services provision.

5. Facilitating very dense deployments of wireless communication links to connect over

7 trillion wireless devices serving over 7 billion people.

6. Ensuring for everyone and everywhere the access to a wider panel of services and

applications at lower cost.

There are currently some very strategic 5G academic research community from around the world

namely with the newly European Commission funded 5G projects such as METIS and 5GNOW

and the newly founded 5G Fora in South Korea (5 Forum Korea), China and Japan:

METIS (Nov. 2012) The first stage of the 5G EU “missile”.

China - “IMT-2020 (5G) Promotion group” (Feb. 2013) Program 863.

Korea - 5G Forum (June 2013) Ambitious plan.

Japan - 2020 and Beyond AdHoc (Oct. 2013) ARIB established new AdHoc working

group called “2020 and Beyond AdHoc”.

http://www.5g-ppp.eu/


14

There is an H2020 Open Call for 5G PPP projects, closing 25th

November 2014 for a total budget

of 125 Million Euros ( http://5g-ppp.eu/call/).

2.1.4.5 IEEE ComSoc SDN-NFV subcommittee

http://www.comsoc.org/about/committees/emerging#sdnnfv

The Software Defined Networking (SDN) and Network Functions Virtualization (NFV) ComSoc

Emerging Technology sub-committee focuses on exploring next generation networking

technologies and their interaction with the other major IT inflexion points: IPv6, Cloud and

Mobility.

The Software Defined Networking (SDN) and Network Functions Virtualization (NFV) IEEE

ComSoc Technical Sub-committee focuses on exploring next generation networking

technologies enabling software defined service delivery, network virtualization, network

function virtualization, and the enablement of mobility. The subcommittee will analyze and drive

integration around the touch points with all the other major IT inflexion points such as next

generation IP, compute and storage virtualization, cloud, mobility and the next generation

applications. The key challenge to be addressed is to support multivendor networks in a software

defined infrastructure that meets the demands of the next generation IT environments.

Topics addressed by the subcommittee will include network architecture, protocols and

implementations that fully leverage the SDN/NFV concepts, strengths and weakness of current

standards such as OpenFlow, alignment with cloud standards and IPv6 concepts, security

considerations of SDN/NFV, innovative architectures, operations and service assurance in

SDN/NFV-enabled environments; and education to develop the engineering talent needed to

design, deploy and operate SDN/NFV environments. This committee will harmonize its work

with the Open Networking Foundation (ONF), IEEE and non-IEEE organizations from academia

and industry including the academic research community, SDN/NFV and next-generation

infrastructure projects, and standardization bodies.

Committee Members:

Chairperson: Ciprian Ciprianou, Founder & CEO of Nephos6

Vice-chairs: Adam Johnson, General Manager Midokura

Dan Torbet, Technology Lead Arris

Latif Ladid, Founder & President, IPv6 Forum, Senior Researcher, UL

http://5g-ppp.eu/call/

http://www.comsoc.org/about/committees/emerging#sdnnfv


15

2.2. Ongoing standardization effort at OASIS

VUT worked on the standardization of efficient IoT protocol bindings for OBIX. The latest draft

has been enhanced with REST bindings to CoAP and with message encoding bindings to JSON

and EXI.

Achievements:

15th

January 2014

30-day public reviews for five specifications begins. The original announcement with

instructions for commenting are at https://www.oasis-

open.org/news/announcements/30-day-public-review-for-5-open-building-

information-exchange-obix-committee-spec.

OBIX v1.1 provides the core information model and interactions for interactions with

building control systems. It also describes the default XML encoding for OBIX.

Encodings for OBIX: Common Encodings v1.0 specifies different encodings for

OBIX objects adhering to the OBIX object model. Elaborates the XML encodings

used in the core specification as well as common alternate encodings, including

CoAP, EXI, and JSON.

Bindings for OBIX: REST Bindings v1.0 specifies REST bindings for OBIX. REST

can be used in conjunction with XML, EXI, CoAP, and JSON encodings, as well as

other encodings that may be specified elsewhere.

Bindings for OBIX: SOAP Bindings v1.0 specifies SOAP protocol bindings for

OBIX. The specification includes a WSDL artefact.

Bindings for oBIX: WebSocket Bindings v1.0 specifies WebSocket protocol bindings

for OBIX.

17th January 2014:

The TC began the discussion of broadcast and peer-to-peer interactions for OBIX 2.0.

This joins service interactions and potential WS-Calendar interactions on the work

plan. The Committee invites other suggestions for inclusion in OBIX 2.0.

2.3. New standardization effort: Web Service specification for home and

building automation

VUT is assisting a well-known home and building automation association as editor for a

standardized Web service interface specification. Findings of the IoT6 research project are

incorporated into the proposed interface specification. The underlying association is the

organization responsible for maintaining a worldwide standard for home and building control

with the highest market share in Europe. A first draft of a Web service specification based on

OBIX together with IoT protocol bindings has been presented at a technical board meeting to

members of the association.


16

Timetable of events in the context of standardisation

Dates Location Role Title Partner

18/2/2014 Sophia Antipolis, France Presentation of

ISG

ETSI ISG IPv6 UL, Mandat

International

26/6/2014 London Workshops IoT6 and IPv6 UL, UMU, UCL,

Mandat

International,

HESSO

17/7/2014 Frankfurt Moderator Home and Building

Web Service

Interface

Specification

VUT

Table 1 – Participation in Standardisation Organisation Meetings


17

3. Conclusion

The IoT6 project has participated directly and led some initiatives in the strategic standardisation

bodies such ETSI, the IETF, ITU and IEEE ComSoc and standards influencing projects such as

the IoT Forum and the IERC Cluster.

The creation of the ETSI IP6 ISG and the IEEE ComSoc IoT/5G/SDN-NFV as well as the IoT

Forum and IERC will contribute to the dissemination of Best Practices beyond the project

lifetime with a strategic sustainability vision and also beyond IoT including pre-standardisation

efforts of IoT or MTC for 5G networks.

Some lasting impacts in this area are:

Leading the adoption of IPv6 as key communication protocol

Winning ETSI’s support to lead the ETSI IP6 ISG.

Leading the IoT Forum.

Leading the IEEE ComSoc IoT subcommittee.

Contributing to the IoT Book for the 4th

time.

Leading the IoT Week program.

Chairing many conferences and invited as speakers in standardisation.


18

4. Annexes

4.1. Annex I – ETSI ISG IP6 (first 6 pages from 15)


19


20


21


22


23

4.2. Annex II – IoT Standardisation Chapter, IERC Book 2014

(first 2 pages from 56)


24


25

4.3. Annex III – Handle System

4.3.1. Some Features of the Handle System

The following description of HS features is not an exhaustive list. We discuss features that we

believe are pertinent to IoT applications and where the HS architecture can provide the necessary

infrastructure and network operations to make these applications a reality with the least effort. In

addition, the infrastructure satisfies many of the requirements of the IoT architectures and in

particular, many of the desired functions of the IoT6 architecture.

4.3.2. Handles as Persistent Identifiers

Handles are persistent identifiers for Internet resources. A handle does not have to be derived in

any way from the entity that it names – the connection is maintained within the Handle System.

This allows the name to persist over changes of location, ownership, and other ‘current state’

conditions. When a named resource moves from one location to another, e.g., from an old server

to a new server, the handle is kept current by updating its value in the Handle System to reflect

the new location.

The Handle system is designed to meet the following requirements for persistence.

Handles are:

Not based on any changeable attributes of the entity they identify (location, ownership, or

any other attribute that may change over time);

Opaque, preferably ‘dumb numbers’ from which no potentially confusing meaning can be

drawn, and from which no assumptions about ownership or use can be made;

Unique within the Handle System, avoiding collisions and referential uncertainty;

Easy to make user friendly, human-readable, cut-and-paste-able, and can be embedded, if

needed;

Easily fit into common systems, e.g., URI specification.

Handle resolution is:

Reliable, using redundancy, with no single points of failure and resolution time fast

enough never to appear broken;

Scalable, so that higher loads are easily managed with more computers;

Flexible and easily adapted to changing computing environments and new applications;

Trusted, with both resolution and administration built on proven trust methods;

Built on an open architecture that encourages the community of users to build

applications on top of the infrastructure;

Transparent to users who don't need to know the infrastructure details.

The above requirements for persistence fit most, if not all, the requirements of IoT architectures,

including IoT6. In particular, where IETF-compliant standards have been defined for IoT

operations, such as the CoRE group’s specifications of link formats and CoAP operations based

on URIs, the above features cover all these aspects.

4.3.3. Handle Syntax

Within the Handle namespace, every identifier consists of two parts: its Handle prefix, and a

suffix or unique “local name” under the prefix. The prefix and suffix are separated by the ASCII

character “/”. An identifier may thus be defined as

<handle> ::= <handle prefix> “/” <handle suffix>


26

4.3.4. Handle Resolution and relevance to IoT applications

The Handle System allows identifiers (Handles) to be resolved in a distributed fashion, using

dedicated clients, common clients such as web browsers using special extensions or plug-ins, or

un-extended clients going through various proxies. In all cases, communication with the Handle

System is carried out using Handle System protocols, and in all cases, those protocols have both

a formal specification and some specific implementations.

4.3.5. Administering Handles – Security Provisions and Implications

Conducting handle administration (i.e., creating, modifying, and deleting individual Handles)

requires that you authenticate yourself to the Handle System. To authenticate yourself, you need

to have an ID that uniquely identifies you, and since the Handle System is global in nature, your

ID must also be globally unique. Since globally unique identifiers are the Handle System’s

specialty, it is natural that administrators should be identified by Handles.

An administrator handle contains either a public key or a secret key (password) that authenticates

the individual identified by that handle. If an administrator handle is specified with permission to

perform some operation in the Handle System, then that administrator can perform that operation

as long as he can authenticate himself against the public or secret key in the administrator

handle.

The above descriptions clearly define the access control mechanisms embedded into Handle

systems, which can be suitable to the IoT. The mechanisms provide a strong framework for

authentication and authorisation that can be extended to operate in a M2M environment,

involving gateways or end-nodes of an IoT subsystem and the Handle infrastructure (see details

in Figure 1).

Where the nodes of an IoT subsystem are involved, further DTLS-based provisions can be

applied to create secure end-to-end transactions (noted as green curved arrows). In particular, the

CoAP DeviceNet-side access to the Handle infrastructure is not mandated to be secure, therefore

we foresee use of DTLS when CoAP-enabled Handle proxies are used for interaction towards a

Handle Service (i.e., from DeviceNets to the ServiceNet and from DeviceNets to the Internet).

Figure 1: Secure end-to-end handle administration from DeviceNets to the Internet.


27

4.3.6. Handle System Scalability

Scalability has been a fundamental requirement and design criterion for Handle. It reflects on

storage and performance issues. We examine each separately below.

The basic questions to address are whether some limits exist in the number of identifiers that can

be added and whether performance decreases with the number of Handles served.

Scalability can be a relatively subjective issue. It may be addressed differently at design stage or

at implementation phase. A design that is fundamentally scalable, may exhibit problems with a

specific implementation instance.

Furthermore, the use of intermediary services, such as http proxies, may introduce other

scalability issues, which the basic Handle System design does not and cannot address.

4.3.7. Storage scalability

The Handle System has been designed at a very basic level as a distributed system; that is, it will

run across as many computers and domains as are required to provide the desired functionality.

There are three architectural concepts that have been implemented in Handle to satisfy storage

scalability: Handle Servers, Handle Sites and Handle Services.

Figure 2: Logical separation of Handle Service to Servers and Sites

As shown in Figure 2, Handles are held in, and resolved by, Handle servers and the servers are

grouped into one or more Handle sites within each Handle service. There are no design limits on

the total number of Handle services which constitute the Handle System, there are no design

limits on the number of sites which make up each service, and there are no limits on the number

of servers which make up each site. Replication by site, within a Handle service, does not require


28

that each site contain the same number of servers; that is, while each site will have the same

replicated set of Handles, each site may allocate that set of Handles across a different number of

servers. Thus, increased numbers of Handles within a site can be accommodated by adding

additional servers, either on the same or additional computers, additional sites can be added to a

Handle service at any time, and additional Handle services can be created. Every service must be

registered with the Global Handle Registry, but that Handle service can also have as many sites

with as many servers as needed.

The result is that the number of identifiers that can be accommodated in the current Handle

System is limited only by the number of computers available.

4.3.8. Security aspects

In the previous section, we discussed how the architecture ensures the administration, storage

and access of Handles can be secured (Section 0). To implement the secure functions, the Handle

server uses cryptographic libraries that come with Java v.5 distribution (called Sun Java™

Cryptography Extension and Provider). We revisit and analyse below the key security aspects of

the system implementation.

4.3.9. Authentication

The Handle System provides two forms of authentication: public key and secret key. The system

can authenticate all administrators of the Handles stored in its database, main and delegated

administrators in the hierarchical chain of prefixes and identifiers, allowing for fine-grained

control of each structure.

Handle clients can request that a handle server cryptographically certify its messages with its

public key. This certification can be used to verify the authenticity of handle server

transmissions. The current implementation of the Handle System uses DSA for this purpose. The

DSA public key for a handle server is stored in its site information record.

4.3.10. Security Services in Handle

There are two important differences, and one similarity, between the security services provided

in Handle from those in the DNS (with its DNSSEC extension). Both have the same constraints

on entry creation, deletion and replication. Both require strong authorisation with specific

administration credentials. Both provide proof of source and integrity. However, Handle has two

additional features: session services and access control.

Handle allows a client to establish secure sessions with a server for encrypted communication.

This functionality is permitted for example when operating in batch execution mode. This is

equivalent to using SSL or TLS (as used by HTTPS), as it affords protection from eavesdropping

and man-in-the middle attacks (currently encrypting sessions using 56 bit DES).

Handle also can require credentials to permit access to the contents of the Handle. This feature is

very important for IoT, for two reasons. First the attributes of the Handle may reveal properties

of the DO that should be protected information. Second, by requiring fine-grained authorisation

to access of the Handle contents, one can greatly simplify the authorisation needs in the IoT

processes. Provided the relevant access is vouched for by the Handle-provided credentials, no

further authorisation is required.


29

4.3.11. Handle Value Types

A handle has a set of values assigned to it and may be thought of as a record that consists of a

group of fields. Each handle value must have a data type specified in its <type> field that defines

the syntax and semantics of its data, and a unique <index> value that distinguishes it from the

other values of the set.

Types are identified by handles and can be any UTF8-string. Handle System users must take care

of potential conflicts introduced by custom handle clients if users assign types that are not

registered and recognised across the global handle infrastructure.

In IoT applications, one would probably specify a set of data types that are common in the

application domain or technology registered in the Handle System serving the IoT domain. For

example, a particular building management infrastructure may employ a standardised legacy

DeviceNet, such as a KNX or LonWorks set of A/C units. These may come pre-arranged in a

networked configuration with proprietary communications (signalling) protocols.

4.3.12. Template Handles

A single template Handle can be created as a base that will allow any number of extensions to

that base to be resolved as full Handles, according to a pattern, without each such Handle being

individually registered. This would allow, for example, the use of Handles to reference an

unlimited number of resources or service endpoints in a building (lights, switches, sockets, etc.,

as exhibited by sensor measurements, actuation and other operations) without each potential

resource or service having to be registered with a separate handle. If the pattern needs to be

changed, e.g., a light bulb moves location or a different kind of server is used to deliver the

building’s resources, only the single base handle needs to be changed to allow an unlimited

number of previously constructed extensions to continue to resolve properly.


30

4.4. Annex IV – IETF Standardisation Efforts

6lo G. Rizzo, Ed.

Internet-Draft AJ. Jara, Ed.

Intended status: Standards Track A. Olivieri

Expires: February 15, 2015 Y. Bocchi

HES-SO

MR. Palattella

SnT/Univ. of Luxembourg

L. Ladid

SnT/Univ. of Luxembourg/IPv6 Forum

August 14, 2014

IPv6 mapping to non-IP protocols

draft-rizzo-6lo-6legacy-01

Abstract

IPv6 is an important enabler of the Internet of Things, since it

provides an addressing space large enough to encompass a vast and

ubiquitous set of sensors and devices, allowing them to interconnect

and interact seamlessly. To date, an important fraction of those

devices is based on networking technologies other than IP. An

important problem to solve in order to include them into an

IPv6-based Internet of Things, is to define a mechanism for assigning

an IPv6 address to each of them, in a way which avoids conflicts and

protocol aliasing.

The only existing proposal for such a mapping leaves many problems

unsolved and it is nowadays inadequate to cope with the new scenarios

which the Internet of Things presents. This document defines a

mechanism, 6TONon-IP, for assigning automatically an IPv6 address to

devices which do not support IPv6 or IPv4, in a way which minimizes

the chances of address conflicts, and of frequent configuration

changes due to instability of connection among devices. Such a

mapping mechanism enables stateless autoconfiguration for legacy

technology devices, allowing them to interconnect through the

Internet and to fully integrate into a world wide scale, IPv6-based

IoT.

Status of This Memo

This Internet-Draft is submitted in full conformance with the

provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering


31

Task Force (IETF). Note that other groups may also distribute

working documents as Internet-Drafts. The list of current Internet-

Drafts is at http://datatracker.ietf.org/drafts/current/.

Rizzo, Ed., et al. Expires February 15, 2015 [Page 1]

Internet-Draft 6TONon-IP August 2014

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 15, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the

document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal

Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect

to this document. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

Table of Contents

1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1. Example 1 - Building automation systems and IoT . . . 4

2.1.2. Example 2 - KNX and demand-side management . . . . . 5

3. Reference System . . . . . . . . . . . . . . . . . . . . . . 5

4. Issues addressed through the 6TONon-IP mapping mechanism . . 6

5. 6TONon-IP Mapping Method . . . . . . . . . . . . . . . . . . 8

6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.1. Example 1 - EIB/KNX . . . . . . . . . . . . . . . . . . . 9

6.2. Example 2 - RFID . . . . . . . . . . . . . . . . . . . . 10

7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10

8. Security considerations . . . . . . . . . . . . . . . . . . . 10

9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10

10. Normative References . . . . . . . . . . . . . . . . . . . . 11

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11


32

1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in [RFC2119].



2. Introduction

The Future Internet and the IPv6 protocol enable a new generation of

techniques for accessing the network, which extend the Internet

seamlessly to personal devices, sensors, home appliances, enabling

the so called ''Internet of Things'' (IoT). One of the key issues

which presently hampers the development of IoT and limits its

potential is the lack of an efficient common framework for the

integration among the vast and diverse set of protocols and

technologies which compose it. Current sensors and their application

environments employ a large set of technologies which lack efficient

interoperability. Some associations of manufacturers have been

formed to build a common technological framework in specific

application domains, e.g. KNX for building automation

(http://www.knx.org/), ZigBee (ZigBee Alliance)

(http://www.zigbee.org/), and protocols such as X10 and CAN. Such

frameworks are based on very different architectures, and the

protocols which compose them are generally not interoperable.

Finally, most of these technologies were designed in a context of

small and local networks, with limited capabilities, and they were

not conceived for integration within the Internet. One of the ideas

at the basis of the IoT is the constitution of a common set of

protocols which enables the interaction between devices through the

Internet. By enabling interaction through the Internet, new services

could be conceived and implemented, increasing the value produced by

the IoT infrastructure. The adoption of a common framework may make

more economically convenient its deployment, and foster the

development of new smart environments (buildings, cities, etc),

ultimately making possible the full realization of the potential of

the IoT. As deployment of new sensors is typically expensive, it is

unthinkable of putting to disuse an installed set of sensors, once a

new set of devices (typically, IPv6 enabled) is deployed. This is

not an uncommon case, as the set of deployed legacy devices (sensors,

actuators) is to date very large. Rather, mechanisms are needed to

integrate legacy devices into a common IoT platform, in order to

include them in all the present and future services (e.g. devices and

services directory, localization services, etc) which will be

implemented on the IoT. For these reasons, many designers of the

Internet of Things are focusing on building such common access and


33

communications framework. All the proposals (e.g. CoAP, RESTful Web

services) presently under discussion are based on IPv6. This has

important implications on the addressing of the devices. Indeed a

common addressing at the device level is mandatory, in order to

implement true Machine to Machine (M2M) communications without Portal

Servers, which would make the whole system difficult to integrate and

scale. The present document focuses on the network layer aspects of

such IPv6 based integration. At the network layer, a mechanism which

assigns an IPv6 address to each device is needed, to solve the



addressing problem. In this document, we propose a new mechanism for

the users and devices to map the different addressing spaces to a

common IPv6 one. Our proposed mechanism solves several issues posed

by some of the mappings adopted so far. Such mapping makes it

possible for every device from each technology to operate through a

common framework based on IPv6 and protocols over IPv6 such as

RESTFul WebServices and Constrained Application Protocol (CoAP). For

each technology, the proposed mechanism maps technology-specific

features to a set of fields defined within the IPv6 address. This

allows the location and identification of the devices in a multi-

protocol card, or in any gateway or Portal Server.

2.1. Examples

In this subsection, we present two examples which help understanding

the importance of adopting a common IPv6 based framework for

interaction between things, and the need for legacy devices to be

individually addressable through IPv6.

2.1.1. Example 1 - Building automation systems and IoT

The IoT is composed by a very large set of devices, which is poised

to grow exponentially in the near future. For this reason, a

directory service is needed, which offers the possibility to

individuate a specific device or set of devices, with given

capabilities or within a given geographical region. Let us assume

such directory lists devices with their IPv6 addresses, and their

function (say a temperature sensor, or a mobile phone, etc). For

instance, let us consider the case of someone willing to build a map

of temperatures in a given geographical region. Such directory

service would allow retrieving the list of available devices within

that region, each with its own IPv6 address. Assume some of those

devices are legacy, non IP based temperature sensors and part of a

given building automation system. Assume also that such system

manages several of those temperature sensors. Even if such system


34

would be reachable via IP, without having those sensors individually

listed in the directory and appearing as ''autonomous'' things, which

can be polled directly, one should resort to techniques for

retrieving the temperature reading of those sensors which are

specific of that building automation technology. This would make

more complex the implementation of such a temperature map.

Instead, by having the building automation system expose each sensor

as an IPv6 enabled device, the whole set of temperature sensors would

be accessible in a homogeneous way, greatly simplifying the task.



2.1.2. Example 2 - KNX and demand-side management

KNX is a standardized (EN 50090, ISO/IEC 14543), OSI-based network

communications protocol for intelligent buildings. Among the devices

typically managed through KNX, we find:

o Lighting control systems;

o Heating/ventilation and air conditioning devices;

o Shutter/blind and shading control systems; and

o Energy management and electricity/gas/water metering devices.

KNX devices do not support IP. Therefore, in order to connect a KNX

home network to the Internet, a gateway (KNXnet/IP router) is

necessary. Other technologies for home automation are available

nowadays, in which each smart device (air conditioners, washing

machines, etc) supports IPv6. Let us consider a scenario in which an

utility company offers an agreement to a fraction of its clients. In

exchange for a cut on the energy bill, the utility company gains

direct control over some appliances at the premises of the client.

In this way, by powering off some of those devices in periods when

the production cost of power are very high, the utility company

realizes potentially high savings.

In order to implement this, the utility company sends commands to a

set of devices under its direct control. For recently installed

devices, the utility can assume that they support IPv6, and some

application layer protocols such as CoAP. Therefore a command to

switch off a device would use the IPv6 address to identify the

device, and the application layer protocol to send the actual

command. But for KNX devices, the command should have another

format: the IPv6 address should be the one of the router bridging the


35

IPv6 and the KNX networks, and upper layers protocols should take

care of identifying the specific device inside the KNX home network

to whom the command should be sent. Having to format a specific

query for each specific home automation protocol adds a level of

complexity which translates into higher costs of implementation and

maintenance of such a service.

3. Reference System

In this section we describe a reference system where the IPv6 mapping

is used. Such a system includes:

1. A set of networks running non-IPv6-compatible technologies, each

with one or more hosts connected. Such networks generally use



different OSI layer 3 protocols, or they may adopt a technology

which does not have any layer 3 protocol.

2. A proxy, which hosts the IPv6 mapping functionality. Such device

is typically connected to each of the legacy protocols networks,

and it accesses the Internet via the IPv6 protocol. Such IPv6

addressing proxy performs all the necessary conversions and

adaptations between IPv6 and the (local) networking protocol of

the legacy technologies, in a way which depends on the specific

legacy technology considered. This proxy makes use of the IPv6

mapping mechanism in order to transforms the native addressing to

IPv6 Host ID and vice versa in a way that depends on the legacy

technology.

Though in what follows we will describe the proposed mapping with

reference to such a system, the main ideas behind it are more

general, and they apply to settings others than the one of reference

presented here.

4. Issues addressed through the 6TONon-IP mapping mechanism

In this section we highlight the main open issues regarding

assignment of IPv6 addresses to devices which do not support IPv6 or

IPv4, and we describe a set of desirable properties for a mechanism

for automatic assignment of IPv6 addresses to such devices, which we

name henceforth 6TONon-IP. In Appendix A of RFC 4291, a method is

described for creating modified EUI-64 format Interface Identifiers

out of links or nodes with IEEE EUI-64 Identifiers, or with IEEE 802

48-bit MACs. Moreover, for technologies having other link layer

interface identifier, some possible mapping methods are sketched,


36

leaving for each legacy protocol the possibility to define its own

mapping method.

In the present document, we propose a mapping mechanism which enables

stateless address autoconfiguration for legacy technologies, and

which exploits some protocol specific identifier such as link layer

interface identifiers, and the like. The proposed mapping mechanism

addresses the following issues:

1. Protocol identification: For the legacy protocols to which the

mapping described in RFC 4291 does not apply, a mechanism is

needed to map an IPv6 address to the right legacy protocol. This

feature is necessary in case of devices which operate as proxy

for more than one legacy technology at the same time.

2. Inter protocol aliasing: Without a mechanism for identifying the

legacy protocol from the host part of the IPv6 address, address

conflicts are possible among devices belonging to different



legacy protocols. For instance, this may happen when the link

layer interface identifier is the same for two devices belonging

to different technologies. As several legacy technologies are

characterized by a small addressing space, address conflicts are

not so unlikely.

3. Conflicts between IPv6 mapped legacy technology addresses and

addresses derived from (modified or not) EUI-64 format interface

identifiers.

4. Intra-protocol aliasing: As several legacy technologies are

characterized by a small addressing space, it is not unlikely to

have two legacy devices, mapped to IPv6 addresses with the same

network ID (for instance, in the case in which they belong to two

separate networks of the same technology, both connected to a

same proxy), and with a same interface identifier, and mapping

therefore to a same IPv6 address.

Moreover, the following is a list of desirable properties for a

6TONon-IP mapping:

1. Consistency: A host should get the same IPv6 address every time

it connects to a same legacy network, assuming that the

configuration of all the other devices in that network remains

unchanged. This allows avoiding to advertise a new address every

time the host reconnects. This feature might be particularly


37

important for devices which are not always "on", or which are not

permanently connected.

2. Local Uniqueness: For devices which have an IPv6 address with a

same network part, the host part should be unique for each host.

This property allows avoiding address conflicts.

3. Uniqueness within the whole Internet: Coherently with the IoT

vision, the host part of an IPv6 address associated to a host

should be unique within the whole Internet.

Depending on the specific legacy protocol, there might be protocol

specific limitations to the satisfaction of these properties. In

particular, for those protocols which do not have an interface

identifier which is unique, properties 1) and 2) cannot be fully

satisfied. Indeed, no mapping can solve address conflicts which take

place inside a legacy protocol network. When legacy protocols have a

interface identifier which is unique, this can be used to produce a

unique host part of an IPv6 address, and its uniqueness would

guarantee the satisfaction of properties 1), 2) and 3).



5. 6TONon-IP Mapping Method

In this section we describe the proposed strategy for forming IPv6

addresses from legacy protocol information, and the address format

that derives from it. We assume that (one or more) 64 bits Network

ID prefixes are given to the mapping function, which therefore

computes the 64 bits of the Host ID part of the address (IPv6

interface identifier), in order to form a full IPv6 address.

The input of the proposed mapping function consists in the interface

identifier of the legacy protocol.

In the proposed mapping method, the resulting Host ID part (IPv6

interface identifier) is composed by six fields, as shown in

Figure 1:

o A Technology ID field (11 bits), containing a code which

identifies the specific legacy protocol. This field is split into

two parts, one of 6 bits, and another of 5 bits.

o U/L bit (1 bit), in order to keep compatibility with the mapping

EUI-64 [RFC4291]. The U/L bit is the seventh bit of the first

byte and is used to determine whether the address is universally

or locally administered. This bit is set to "0", in order to


38

indicate local scope, analogously to what proposed in [RFC4291].

This choice prevents address conflicts with IPv6 interface

identifier generated from IEEE EUI-64 identifiers or IEEE 48-bit

MAC identifiers.

o A Reserved field (4 bits). This field can be used in the future

for the identification of different interfaces for a same

technology (in the same subnetwork).

o Technology Mapping field (32 bits), which maps the interface

identifier of the legacy protocol. For those protocols for which

the IID is not larger than 32 bits, this field contains the 32

bits of the IID. For IID which are larger than 32 bits, a hashing

function is used instead of direct mapping. In particular, some

hashing algorithms such as CRC-32 are suggested. Hashing

satisfies the requirements of consistency and uniqueness within a

subnet with a very high probability, which depends on the hashing

algorithm used. This field is split into two parts, one of 8

bits, and another of 24 bits.

o The fourth and fifth bytes are both set to to "0x00", in order not

to conflict with EUI-64 interface identifiers.



The resulting format of the Host ID part of the IPv6 address obtained

from the mapping is indicated in Figure 1.

+--------+-------+-------+---------+--------+----------+---------+

| Tech. | U/L | Tech. | Reserved| Tech. | EUI-64 | Tech. |

| ID | "0" | ID | | Mapping| "0x0000" | Mapping |

| MSB | | LSB | | MSB | | LSBs |

|(6 bits)|(1 bit)|(5 bit)| (4 bits)|(8 bits)| (16 bits)|(24 bits)|

+--------+-------+-------+---------+--------+----------+---------+

Figure 1: general format of the host ID part for legacy protocols

6. Examples

In this section we illustrate the proposed mapping method by applying

it on some examples.

6.1. Example 1 - EIB/KNX

We assume the legacy protocol is EIB/KNX. This device has two kind

of addresses: On the one hand, a logical address for management of

group operations, and on the other hand, an individual address for


39

identification of the device in the topology.

The mapping will be focused for the individual address. This

includes an Area ID (4 bits), Line ID (8 bits), and Device ID (8

Bits). An example, is the value 0x1/0x01/0x01 for a sensor connected

in the Area ID 0x1, Line ID 0x01, and Device ID 0x01.

We apply a hash (CRC-32) to the sequence 0x10101. The result is

0xDEA258A5.

Let us assume that EIB/Konnex Technology ID is "0". Thereby, the

IPv6 interface identifier is "0000:DE00:00A2:58A5", considering the

documentation network 2001:db8::/32. The final IPv6 address for the

legacy device is "2001:db8::DE00:A2:58A5".

The address is presented in the Figure 2.

+--------+-------+-------+---------+--------+----------+---------+

| Tech. | U/L | Tech. | Reserved| Mapping| EUI-64 | Mapping |

| ID MSB | "0" | ID LSB| | MSB | "0x0000" | LSBs |


| 0x00 | 0 | 0x00 | 0x00 | 0xDE | 0x0000 | 0xA258A5|

+--------+-------+-------+---------+--------+----------+---------+

Figure 2: EIB/KNX example: the IPv6 interface identifier.



6.2. Example 2 - RFID

We assume the legacy protocol is RFID. Each RFID device is

identified by its Electronic Product Code (EPC), whose length may

vary from 96 to 256 bits. Let us assume to have an RFID device whose

EPC is given by 01.23F3D00.8666A3.000000A05 (12 bytes). Let us

assume that the RFID technology ID is "1".

We apply a hash (CRC-32) to the sequence 0x0123F3D008666A3000000A05.

The result is 0xA93AFFA0.

Thereby, the IPv6 interface identifier is "0004:A900:003A:FFA0",

considering the documentation network 2001:db8::/32. The final IPv6

address for the RFID tag is "2001:db8::400:A900:3A:FFA0".

The address is presented in the Figure 2.

+--------+-------+-------+---------+--------+----------+---------+

| Tech. | U/L | Tech. | Reserved| Mapping| EUI-64 | Mapping |


40

|ID MSB | "0" | ID | | MSB | "0x0000" | LSBs |


| 0x00 | 0 | 0x04 | 0x00 | 0xA9 | 0x0000 | 0x3AFFA0|

+--------+-------+-------+---------+--------+----------+---------+

Figure 3: RFID example: the IPv6 interface identifier.

7. IANA Considerations

Not yet defined.

8. Security considerations

The proposed mapping mechanism, being based on mapping proprietary

protocol ID, results in such ID being incorporated in the final IPv6

address, exposing this piece of information to the Internet. The

concern has been that a user might not want to expose the details of

the system to outsiders. For such concern, which holds also for MAC

address mapping into EUI64 addresses, please refer to appendix B in

[RFC4942].

9. Acknowledgements

The authors wish to acknowledge the following for their review and

constructive criticism of this proposal: Robert Cragie. Thanks to

the IoT6 European Project (STREP) of the 7th Framework Program (Grant

288445), and the colleagues who have collaborated in this work. In

particular, Antonio Skarmeta from the University of Murcia, Peter



Kirstein and Socrates Varakliotis from the University Colleague

London, and Sebastien Ziegler from Mandat International.

10. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing

Architecture", RFC 4291, February 2006.

[SENSORS] Jara, A., Moreno-Sanchez, P., Skarmeta, A., Varakliotis,

S., and P. Kirstein,, "IPv6 Addressing Proxy: Mapping

Native Addressing from Legacy Technologies and Devices to

the Internet of Things (IPv6)", Sensors 13, no. 5,

6687-6712, 2013, 2013.


41

Authors' Addresses

Gianluca Rizzo, Ed.

HES-SO Valais

Technopole 3

Sierre, Valais 3960

Switzerland

Phone: +41-76-6151758

Email: [email protected]

Antonio J. Jara, Ed.

HES-SO Valais

Technopole 3

Sierre, Valais 3960

Switzerland


Alex C. Olivieri

HES-SO Valais

Technopole 3

Sierre, Valais 3960

Switzerland




Yann Bocchi

HES-SO Valais

Technopole 3

Sierre, Valais 3960

Switzerland


Maria Rita Palattella

University of Luxembourg

4, rue Alphonse Weicker

Interdisciplinary Centre for Security, Reliability and Trust

Luxembourg

Phone: (+352) 46 66 44 5841



42

Latif Ladid

University of Luxembourg / IPv6 Forum

4, rue Alphonse Weicker

Interdisciplinary Centre for Security, Reliability and Trust

Luxembourg

Phone: (+352) 46 66 44 5720

