idnits 2.17.1 draft-rizzo-6lo-6legacy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 28, 2015) is 3315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4942' is mentioned on line 470, but not defined == Unused Reference: 'SENSORS' is defined on line 490, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SENSORS' Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo G. Rizzo, Ed. 3 Internet-Draft AJ. Jara, Ed. 4 Intended status: Standards Track A. Olivieri 5 Expires: September 29, 2015 Y. Bocchi 6 HES-SO 7 MR. Palattella 8 SnT/Univ. of Luxembourg 9 L. Ladid 10 SnT/Univ. of Luxembourg/IPv6 Forum 11 S. Ziegler 12 C. Crettaz 13 Mandat International 14 March 28, 2015 16 IPv6 mapping to non-IP protocols 17 draft-rizzo-6lo-6legacy-03 19 Abstract 21 IPv6 is an important enabler of the Internet of Things, since it 22 provides an addressing space large enough to encompass a vast and 23 ubiquitous set of sensors and devices, allowing them to interconnect 24 and interact seamlessly. To date, an important fraction of those 25 devices is based on networking technologies other than IP. An 26 important problem to solve in order to include them into an 27 IPv6-based Internet of Things, is to define a mechanism for assigning 28 an IPv6 address to each of them, in a way which avoids conflicts and 29 protocol aliasing. 31 The only existing proposal for such a mapping leaves many problems 32 unsolved and it is nowadays inadequate to cope with the new scenarios 33 which the Internet of Things presents. This document defines a 34 mechanism, 6TONon-IP, for assigning automatically an IPv6 address to 35 devices which do not support IPv6 or IPv4, in a way which minimizes 36 the chances of address conflicts, and of frequent configuration 37 changes due to instability of connection among devices. Such a 38 mapping mechanism enables stateless autoconfiguration for legacy 39 technology devices, allowing them to interconnect through the 40 Internet and to fully integrate into a world wide scale, IPv6-based 41 IoT. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 29, 2015. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2.1.1. Example 1 - Building automation systems and IoT . . . 4 81 2.1.2. Example 2 - KNX and demand-side management . . . . . 5 82 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 6 83 4. Issues addressed through the 6TONon-IP mapping mechanism . . 6 84 5. 6TONon-IP Mapping Method . . . . . . . . . . . . . . . . . . 8 85 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 6.1. Example 1 - EIB/KNX . . . . . . . . . . . . . . . . . . . 9 87 6.2. Example 2 - RFID . . . . . . . . . . . . . . . . . . . . 10 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 91 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 94 1. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Introduction 102 The Future Internet and the IPv6 protocol enable a new generation of 103 techniques for accessing the network, which extend the Internet 104 seamlessly to personal devices, sensors, home appliances, enabling 105 the so called ''Internet of Things'' (IoT). One of the key issues 106 which presently hampers the development of IoT and limits its 107 potential is the lack of an efficient common framework for the 108 integration among the vast and diverse set of protocols and 109 technologies which compose it. Current sensors and their application 110 environments employ a large set of technologies which lack efficient 111 interoperability. Some associations of manufacturers have been 112 formed to build a common technological framework in specific 113 application domains, e.g. KNX for building automation 114 (http://www.knx.org/), ZigBee (ZigBee Alliance) 115 (http://www.zigbee.org/), and protocols such as X10 and CAN. Such 116 frameworks are based on very different architectures, and the 117 protocols which compose them are generally not interoperable. 118 Finally, most of these technologies were designed in a context of 119 small and local networks, with limited capabilities, and they were 120 not conceived for integration within the Internet. One of the ideas 121 at the basis of the IoT is the constitution of a common set of 122 protocols which enables the interaction between devices through the 123 Internet. By enabling interaction through the Internet, new services 124 could be conceived and implemented, increasing the value produced by 125 the IoT infrastructure. The adoption of a common framework may make 126 more economically convenient its deployment, and foster the 127 development of new smart environments (buildings, cities, etc), 128 ultimately making possible the full realization of the potential of 129 the IoT. As deployment of new sensors is typically expensive, it is 130 unthinkable of putting to disuse an installed set of sensors, once a 131 new set of devices (typically, IPv6 enabled) is deployed. This is 132 not an uncommon case, as the set of deployed legacy devices (sensors, 133 actuators) is to date very large. Rather, mechanisms are needed to 134 integrate legacy devices into a common IoT platform, in order to 135 include them in all the present and future services (e.g. devices and 136 services directory, localization services, etc) which will be 137 implemented on the IoT. For these reasons, many designers of the 138 Internet of Things are focusing on building such common access and 139 communications framework. All the proposals (e.g. CoAP, RESTful Web 140 services) presently under discussion are based on IPv6. This has 141 important implications on the addressing of the devices. Indeed a 142 common addressing at the device level is mandatory, in order to 143 implement true Machine to Machine (M2M) communications without Portal 144 Servers, which would make the whole system difficult to integrate and 145 scale. The present document focuses on the network layer aspects of 146 such IPv6 based integration. At the network layer, a mechanism which 147 assigns an IPv6 address to each device is needed, to solve the 148 addressing problem. In this document, we propose a new mechanism for 149 the users and devices to map the different addressing spaces to a 150 common IPv6 one. Our proposed mechanism solves several issues posed 151 by some of the mappings adopted so far. Such mapping makes it 152 possible for every device from each technology to operate through a 153 common framework based on IPv6 and protocols over IPv6 such as 154 RESTFul WebServices and Constrained Application Protocol (CoAP). For 155 each technology, the proposed mechanism maps technology-specific 156 features to a set of fields defined within the IPv6 address. This 157 allows the location and identification of the devices in a multi- 158 protocol card, or in any gateway or Portal Server. 160 2.1. Examples 162 In this subsection, we present two examples which help understanding 163 the importance of adopting a common IPv6 based framework for 164 interaction between things, and the need for legacy devices to be 165 individually addressable through IPv6. 167 2.1.1. Example 1 - Building automation systems and IoT 169 The IoT is composed by a very large set of devices, which is poised 170 to grow exponentially in the near future. For this reason, a 171 directory service is needed, which offers the possibility to 172 individuate a specific device or set of devices, with given 173 capabilities or within a given geographical region. Let us assume 174 such directory lists devices with their IPv6 addresses, and their 175 function (say a temperature sensor, or a mobile phone, etc). For 176 instance, let us consider the case of someone willing to build a map 177 of temperatures in a given geographical region. Such directory 178 service would allow retrieving the list of available devices within 179 that region, each with its own IPv6 address. Assume some of those 180 devices are legacy, non IP based temperature sensors and part of a 181 given building automation system. Assume also that such system 182 manages several of those temperature sensors. Even if such system 183 would be reachable via IP, without having those sensors individually 184 listed in the directory and appearing as ''autonomous'' things, which 185 can be polled directly, one should resort to techniques for 186 retrieving the temperature reading of those sensors which are 187 specific of that building automation technology. This would make 188 more complex the implementation of such a temperature map. 190 Instead, by having the building automation system expose each sensor 191 as an IPv6 enabled device, the whole set of temperature sensors would 192 be accessible in a homogeneous way, greatly simplifying the task. 194 2.1.2. Example 2 - KNX and demand-side management 196 KNX is a standardized (EN 50090, ISO/IEC 14543), OSI-based network 197 communications protocol for intelligent buildings. Among the devices 198 typically managed through KNX, we find: 200 o Lighting control systems; 202 o Heating/ventilation and air conditioning devices; 204 o Shutter/blind and shading control systems; and 206 o Energy management and electricity/gas/water metering devices. 208 KNX devices do not support IP. Therefore, in order to connect a KNX 209 home network to the Internet, a gateway (KNXnet/IP router) is 210 necessary. Other technologies for home automation are available 211 nowadays, in which each smart device (air conditioners, washing 212 machines, etc) supports IPv6. Let us consider a scenario in which an 213 utility company offers an agreement to a fraction of its clients. In 214 exchange for a cut on the energy bill, the utility company gains 215 direct control over some appliances at the premises of the client. 216 In this way, by powering off some of those devices in periods when 217 the production cost of power are very high, the utility company 218 realizes potentially high savings. 220 In order to implement this, the utility company sends commands to a 221 set of devices under its direct control. For recently installed 222 devices, the utility can assume that they support IPv6, and some 223 application layer protocols such as CoAP. Therefore a command to 224 switch off a device would use the IPv6 address to identify the 225 device, and the application layer protocol to send the actual 226 command. But for KNX devices, the command should have another 227 format: the IPv6 address should be the one of the router bridging the 228 IPv6 and the KNX networks, and upper layers protocols should take 229 care of identifying the specific device inside the KNX home network 230 to whom the command should be sent. Having to format a specific 231 query for each specific home automation protocol adds a level of 232 complexity which translates into higher costs of implementation and 233 maintenance of such a service. 235 3. Reference System 237 In this section we describe a reference system where the IPv6 mapping 238 is used. Such a system includes: 240 1. A set of networks running non-IPv6-compatible technologies, each 241 with one or more hosts connected. Such networks generally use 242 different OSI layer 3 protocols, or they may adopt a technology 243 which does not have any layer 3 protocol. 245 2. A proxy, which hosts the IPv6 mapping functionality. Such device 246 is typically connected to each of the legacy protocols networks, 247 and it accesses the Internet via the IPv6 protocol. Such IPv6 248 addressing proxy performs all the necessary conversions and 249 adaptations between IPv6 and the (local) networking protocol of 250 the legacy technologies, in a way which depends on the specific 251 legacy technology considered. This proxy makes use of the IPv6 252 mapping mechanism in order to transforms the native addressing to 253 IPv6 Host ID and vice versa in a way that depends on the legacy 254 technology. 256 Though in what follows we will describe the proposed mapping with 257 reference to such a system, the main ideas behind it are more 258 general, and they apply to settings others than the one of reference 259 presented here. 261 4. Issues addressed through the 6TONon-IP mapping mechanism 263 In this section we highlight the main open issues regarding 264 assignment of IPv6 addresses to devices which do not support IPv6 or 265 IPv4, and we describe a set of desirable properties for a mechanism 266 for automatic assignment of IPv6 addresses to such devices, which we 267 name henceforth 6TONon-IP. In Appendix A of RFC 4291, a method is 268 described for creating modified EUI-64 format Interface Identifiers 269 out of links or nodes with IEEE EUI-64 Identifiers, or with IEEE 802 270 48-bit MACs. Moreover, for technologies having other link layer 271 interface identifier, some possible mapping methods are sketched, 272 leaving for each legacy protocol the possibility to define its own 273 mapping method. 275 In the present document, we propose a mapping mechanism which enables 276 stateless address autoconfiguration for legacy technologies, and 277 which exploits some protocol specific identifier such as link layer 278 interface identifiers, and the like. The proposed mapping mechanism 279 addresses the following issues: 281 1. Protocol identification: For the legacy protocols to which the 282 mapping described in RFC 4291 does not apply, a mechanism is 283 needed to map an IPv6 address to the right legacy protocol. This 284 feature is necessary in case of devices which operate as proxy 285 for more than one legacy technology at the same time. 287 2. Inter protocol aliasing: Without a mechanism for identifying the 288 legacy protocol from the host part of the IPv6 address, address 289 conflicts are possible among devices belonging to different 290 legacy protocols. For instance, this may happen when the link 291 layer interface identifier is the same for two devices belonging 292 to different technologies. As several legacy technologies are 293 characterized by a small addressing space, address conflicts are 294 not so unlikely. 296 3. Conflicts between IPv6 mapped legacy technology addresses and 297 addresses derived from (modified or not) EUI-64 format interface 298 identifiers. 300 4. Intra-protocol aliasing: As several legacy technologies are 301 characterized by a small addressing space, it is not unlikely to 302 have two legacy devices, mapped to IPv6 addresses with the same 303 network ID (for instance, in the case in which they belong to two 304 separate networks of the same technology, both connected to a 305 same proxy), and with a same interface identifier, and mapping 306 therefore to a same IPv6 address. 308 Moreover, the following is a list of desirable properties for a 309 6TONon-IP mapping: 311 1. Consistency: A host should get the same IPv6 address every time 312 it connects to a same legacy network, assuming that the 313 configuration of all the other devices in that network remains 314 unchanged. This allows avoiding to advertise a new address every 315 time the host reconnects. This feature might be particularly 316 important for devices which are not always "on", or which are not 317 permanently connected. 319 2. Local Uniqueness: For devices which have an IPv6 address with a 320 same network part, the host part should be unique for each host. 321 This property allows avoiding address conflicts. 323 3. Uniqueness within the whole Internet: Coherently with the IoT 324 vision, the host part of an IPv6 address associated to a host 325 should be unique within the whole Internet. 327 Depending on the specific legacy protocol, there might be protocol 328 specific limitations to the satisfaction of these properties. In 329 particular, for those protocols which do not have an interface 330 identifier which is unique, properties 1) and 2) cannot be fully 331 satisfied. Indeed, no mapping can solve address conflicts which take 332 place inside a legacy protocol network. When legacy protocols have a 333 interface identifier which is unique, this can be used to produce a 334 unique host part of an IPv6 address, and its uniqueness would 335 guarantee the satisfaction of properties 1), 2) and 3). 337 5. 6TONon-IP Mapping Method 339 In this section we describe the proposed strategy for forming IPv6 340 addresses from legacy protocol information, and the address format 341 that derives from it. We assume that (one or more) 64 bits Network 342 ID prefixes are given to the mapping function, which therefore 343 computes the 64 bits of the Host ID part of the address (IPv6 344 interface identifier), in order to form a full IPv6 address. 346 The input of the proposed mapping function consists in the interface 347 identifier of the legacy protocol. 349 In the proposed mapping method, the resulting Host ID part (IPv6 350 interface identifier) is composed by six fields, as shown in 351 Figure 1: 353 o A Technology ID field (11 bits), containing a code which 354 identifies the specific legacy protocol. This field is split into 355 two parts, one of 6 bits, and another of 5 bits. 357 o U/L bit (1 bit), in order to keep compatibility with the mapping 358 EUI-64 [RFC4291]. The U/L bit is the seventh bit of the first 359 byte and is used to determine whether the address is universally 360 or locally administered. This bit is set to "0", in order to 361 indicate local scope, analogously to what proposed in [RFC4291]. 362 This choice prevents address conflicts with IPv6 interface 363 identifier generated from IEEE EUI-64 identifiers or IEEE 48-bit 364 MAC identifiers. 366 o A Reserved field (4 bits). This field can be used in the future 367 for the identification of different interfaces for a same 368 technology (in the same subnetwork). 370 o Technology Mapping field (32 bits), which maps the interface 371 identifier of the legacy protocol. For those protocols for which 372 the IID is not larger than 32 bits, this field contains the 32 373 bits of the IID. For IID which are larger than 32 bits, a hashing 374 function is used instead of direct mapping. In particular, some 375 hashing algorithms such as CRC-32 are suggested. Hashing 376 satisfies the requirements of consistency and uniqueness within a 377 subnet with a very high probability, which depends on the hashing 378 algorithm used. This field is split into two parts, one of 8 379 bits, and another of 24 bits. 381 o The fourth and fifth bytes are both set to to "0x00", in order not 382 to conflict with EUI-64 interface identifiers. 384 The resulting format of the Host ID part of the IPv6 address obtained 385 from the mapping is indicated in Figure 1. 387 +--------+-------+-------+---------+--------+----------+---------+ 388 | Tech. | U/L | Tech. | Reserved| Tech. | EUI-64 | Tech. | 389 | ID | "0" | ID | | Mapping| "0x0000" | Mapping | 390 | MSB | | LSB | | MSB | | LSBs | 391 |(6 bits)|(1 bit)|(5 bit)| (4 bits)|(8 bits)| (16 bits)|(24 bits)| 392 +--------+-------+-------+---------+--------+----------+---------+ 394 Figure 1: general format of the host ID part for legacy protocols 396 6. Examples 398 In this section we illustrate the proposed mapping method by applying 399 it on some examples. 401 6.1. Example 1 - EIB/KNX 403 We assume the legacy protocol is EIB/KNX. This device has two kind 404 of addresses: On the one hand, a logical address for management of 405 group operations, and on the other hand, an individual address for 406 identification of the device in the topology. 408 The mapping will be focused for the individual address. This 409 includes an Area ID (4 bits), Line ID (8 bits), and Device ID (8 410 Bits). An example, is the value 0x1/0x01/0x01 for a sensor connected 411 in the Area ID 0x1, Line ID 0x01, and Device ID 0x01. 413 We apply a hash (CRC-32) to the sequence 0x10101. The result is 414 0xDEA258A5. 416 Let us assume that EIB/Konnex Technology ID is "0". Thereby, the 417 IPv6 interface identifier is "0000:DE00:00A2:58A5", considering the 418 documentation network 2001:db8::/32. The final IPv6 address for the 419 legacy device is "2001:db8::DE00:A2:58A5". 421 The address is presented in the Figure 2. 423 +--------+-------+-------+---------+--------+----------+---------+ 424 | Tech. | U/L | Tech. | Reserved| Mapping| EUI-64 | Mapping | 425 | ID MSB | "0" | ID LSB| | MSB | "0x0000" | LSBs | 426 |(6 bits)|(1 bit)|(5 bit)| (4 bits)|(8 bits)| (16 bits)|(24 bits)| 427 | 0x00 | 0 | 0x00 | 0x00 | 0xDE | 0x0000 | 0xA258A5| 428 +--------+-------+-------+---------+--------+----------+---------+ 430 Figure 2: EIB/KNX example: the IPv6 interface identifier. 432 6.2. Example 2 - RFID 434 We assume the legacy protocol is RFID. Each RFID device is 435 identified by its Electronic Product Code (EPC), whose length may 436 vary from 96 to 256 bits. Let us assume to have an RFID device whose 437 EPC is given by 01.23F3D00.8666A3.000000A05 (12 bytes). Let us 438 assume that the RFID technology ID is "1". 440 We apply a hash (CRC-32) to the sequence 0x0123F3D008666A3000000A05. 441 The result is 0xA93AFFA0. 443 Thereby, the IPv6 interface identifier is "0004:A900:003A:FFA0", 444 considering the documentation network 2001:db8::/32. The final IPv6 445 address for the RFID tag is "2001:db8::400:A900:3A:FFA0". 447 The address is presented in the Figure 2. 449 +--------+-------+-------+---------+--------+----------+---------+ 450 | Tech. | U/L | Tech. | Reserved| Mapping| EUI-64 | Mapping | 451 |ID MSB | "0" | ID | | MSB | "0x0000" | LSBs | 452 |(6 bits)|(1 bit)|(5 bit)| (4 bits)|(8 bits)| (16 bits)|(24 bits)| 453 | 0x00 | 0 | 0x04 | 0x00 | 0xA9 | 0x0000 | 0x3AFFA0| 454 +--------+-------+-------+---------+--------+----------+---------+ 456 Figure 3: RFID example: the IPv6 interface identifier. 458 7. IANA Considerations 460 Not yet defined. 462 8. Security considerations 464 The proposed mapping mechanism, being based on mapping proprietary 465 protocol ID, results in such ID being incorporated in the final IPv6 466 address, exposing this piece of information to the Internet. The 467 concern has been that a user might not want to expose the details of 468 the system to outsiders. For such concern, which holds also for MAC 469 address mapping into EUI64 addresses, please refer to appendix B in 470 [RFC4942]. 472 9. Acknowledgements 474 The authors wish to acknowledge the following for their review and 475 constructive criticism of this proposal: Robert Cragie. Thanks to 476 the IoT6 European Project (STREP) of the 7th Framework Program (Grant 477 288445), and the colleagues who have collaborated in this work. In 478 particular, Antonio Skarmeta from the University of Murcia, Peter 479 Kirstein and Socrates Varakliotis from the University Colleague 480 London, and Sebastien Ziegler from Mandat International. 482 10. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, March 1997. 487 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 488 Architecture", RFC 4291, February 2006. 490 [SENSORS] Jara, A., Moreno-Sanchez, P., Skarmeta, A., Varakliotis, 491 S., and P. Kirstein,, "IPv6 Addressing Proxy: Mapping 492 Native Addressing from Legacy Technologies and Devices to 493 the Internet of Things (IPv6)", Sensors 13, no. 5, 494 6687-6712, 2013, 2013. 496 Authors' Addresses 498 Gianluca Rizzo, Ed. 499 HES-SO Valais 500 Technopole 3 501 Sierre, Valais 3960 502 Switzerland 504 Phone: +41-76-6151758 505 Email: gianluca.rizzo@hevs.ch 507 Antonio J. Jara, Ed. 508 HES-SO Valais 509 Technopole 3 510 Sierre, Valais 3960 511 Switzerland 513 Email: jara@ieee.org 514 Alex C. Olivieri 515 HES-SO Valais 516 Technopole 3 517 Sierre, Valais 3960 518 Switzerland 520 Email: Alex.Olivieri@hevs.ch 522 Yann Bocchi 523 HES-SO Valais 524 Technopole 3 525 Sierre, Valais 3960 526 Switzerland 528 Email: yann.bocchi@hevs.ch 530 Maria Rita Palattella 531 University of Luxembourg 532 4, rue Alphonse Weicker 533 Interdisciplinary Centre for Security, Reliability and Trust 534 Luxembourg 536 Phone: (+352) 46 66 44 5841 537 Email: maria-rita.palattella@uni.lu 539 Latif Ladid 540 University of Luxembourg / IPv6 Forum 541 4, rue Alphonse Weicker 542 Interdisciplinary Centre for Security, Reliability and Trust 543 Luxembourg 545 Phone: (+352) 46 66 44 5720 546 Email: latif@ladid.lu 548 Sebastien Ziegler 549 Mandat International 550 3 rue Champ Baron 551 1209 Geneva 552 Switzerland 554 Email: sziegler@mandint.org 555 Cedric Crettaz 556 Mandat International 557 3 rue Champ Baron 558 1209 Geneva 559 Switzerland 561 Email: iot6@mandint.org