IPv6 mapping to non-IP protocols
draft-rizzo-6lo-6legacy-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Gianluca Rizzo , Antonio J. Jara , Alex C. Olivieri , Yann Bocchi , Maria Rita Palattella , Latif Ladid | ||
| Last updated | 2014-02-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rizzo-6lo-6legacy-00
6lo G. Rizzo, Ed.
Internet-Draft AJ. Jara, Ed.
Intended status: Standards Track A. Olivieri
Expires: August 15, 2014 Y. Bocchi
HES-SO
MR. Palattella
SnT/Univ. of Luxembourg
L. Ladid
SnT/Univ. of Luxembourg/IPv6 Forum
February 11, 2014
IPv6 mapping to non-IP protocols
draft-rizzo-6lo-6legacy-00
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. Many of those devices presently are based
on networking technologies other than IP. In order to include them
into an IPv6 based Internet of Things, a mechanism for assigning an
IPv6 address to each of them is required.
The only existing proposal for a standard way of assigning an IPv6
address to devices which do not support IPv6 or IPv4, is very
generic, it leaves many problems unsolved and it is nowadays
inadequate to cope with the new scenarios opened by the Internet of
Things. 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 to
interconnect through the Internet and to fully integrate into a world
wide scale IPv6 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
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 August 15, 2014 [Page 1]
Internet-Draft 6TONon-IP February 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 August 15, 2014.
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
3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4
4. Issues addressed through the 6TONon-IP mapping mechanism . . 4
5. 6TONon-IP Mapping Method . . . . . . . . . . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Example 1 - EIB/Konnex . . . . . . . . . . . . . . . . . 7
6.2. Example 2 - RFID . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Further considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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].
Rizzo, Ed., et al. Expires August 15, 2014 [Page 2]
Internet-Draft 6TONon-IP February 2014
2. Introduction
The Future Internet and IPv6 protocol present a new generation of
capabilities and access to the network, which will extend the
Internet seamlessly to personal devices, smart phones and sensors,
enabling the Internet of Things (IoT). Current sensors and their
application environments consist of a vast group of technologies
which lack efficient interoperability among them. Some associations
of manufactures have been formed to build a common technological
framework in specific application domains, e.g. Konnex (KNX) for
building automation, ZigBee with an independent Alliance (ZigBee
Alliance), and protocols such as X10 and CAN. These protocols are
not interoperable. Moreover, most of these technologies were
designed in a context of small and local networks, with limited
capabilities, so that they were not conceived for integration within
the Internet. For instance, several years ago when X10 was defined,
only a small number of sensors would be placed in the same building
or a single control area. The same applied for EIB/KNX, which was
one of the first technologies to offer an extended deployment of
sensors in home and building automation. Nowadays, sensors are found
almost everywhere. Indeed their number will increase exponentially
in a short period of time with the definition of the smart grid, of
smart cities, and the demand to connect every device to the Internet
for full connectivity and interoperability via technologies such as
ZigBee-IP, 6LoWPAN, and GLoWBAL IPv6. For those reasons, many
designers of the Internet of Things are considering a move towards a
common access and communications framework based on IPv6. Such a
move would affect the addressing of the devices, since a common
addressing at the device level is mandatory, in order to implement
true Machine to Machine (M2M) communications without Portal Servers,
or gateways. In order to integrate such legacy technologies within
the Internet of Things, it is necessary to define an IPv6 mapping for
the native addressing of the devices. Indeed, as a migration
strategy, it would be desirable to have a mechanism to integrate them
into the IoT. We propose here a mechanism for the users and devices
to map the different addressing spaces to a common IPv6 one. This
would make 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.
Rizzo, Ed., et al. Expires August 15, 2014 [Page 3]
Internet-Draft 6TONon-IP February 2014
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,
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
Rizzo, Ed., et al. Expires August 15, 2014 [Page 4]
Internet-Draft 6TONon-IP February 2014
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
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
Rizzo, Ed., et al. Expires August 15, 2014 [Page 5]
Internet-Draft 6TONon-IP February 2014
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 (6 bits), containing a code which identifies
the specific legacy protocol.
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
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 I/G bit (1 bit). The I/G bit is not used. It will be used with
value "0" by default.
o A Reserved field (8 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
Rizzo, Ed., et al. Expires August 15, 2014 [Page 6]
Internet-Draft 6TONon-IP February 2014
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 | I/G | Reserved| Tech. | EUI-64 | Tech. |
| ID | "0" | "0" | | Mapping| "0x0000" | Mapping |
| | | | | MSB | | LSBs |
|(6 bits)|(1 bit)|(1 bit)| (8 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/Konnex
We assume the legacy protocol is EIB/Konnex. 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
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.
Rizzo, Ed., et al. Expires August 15, 2014 [Page 7]
Internet-Draft 6TONon-IP February 2014
+--------+-------+-------+---------+--------+----------+---------+
| Tech. | U/L | I/G | Reserved| Mapping| EUI-64 | Mapping |
| ID | "0" | "0" | | MSB | "0x0000" | LSBs |
|(6 bits)|(1 bit)|(1 bit)| (8 bits)|(8 bits)| (16 bits)|(24 bits)|
| 0x00 | 0 | 0 | 0x00 | 0xDE | 0x0000 | 0xA258A5|
+--------+-------+-------+---------+--------+----------+---------+
Figure 2: EIB/Konnex 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 EIB/Konnex Technology ID is "1".
We apply a hash (CRC-32) to the sequence 0x0123F3D008666A3000000A05.
The result is 0xA93AFFA0.
Thereby, the IPv6 interface identifier is "0400: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 | I/G | Reserved| Mapping| EUI-64 | Mapping |
| ID | "0" | "0" | | MSB | "0x0000" | LSBs |
|(6 bits)|(1 bit)|(1 bit)| (8 bits)|(8 bits)| (16 bits)|(24 bits)|
| 0x04 | 0 | 0 | 0x00 | 0xA9 | 0x0000 | 0x3AFFA0|
+--------+-------+-------+---------+--------+----------+---------+
Figure 3: RFID example: the IPv6 interface identifier.
7. IANA Considerations
Not yet defined.
8. Further considerations
Not yet defined.
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
Rizzo, Ed., et al. Expires August 15, 2014 [Page 8]
Internet-Draft 6TONon-IP February 2014
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.
Authors' Addresses
Gianluca Rizzo, Ed.
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Phone: +41-76-6151758
Email: gianluca.rizzo@hevs.ch
Antonio J. Jara, Ed.
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Email: jara@ieee.org
Alex C. Olivieri
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Email: Alex.Olivieri@hevs.ch
Rizzo, Ed., et al. Expires August 15, 2014 [Page 9]
Internet-Draft 6TONon-IP February 2014
Yann Bocchi
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Email: yann.bocchi@hevs.ch
Maria Rita Palattella
University of Luxembourg
4, rue Alphonse Weicker
Interdisciplinary Centre for Security, Reliability and Trust
Luxembourg
Phone: (+352) 46 66 44 5841
Email: maria-rita.palattella@uni.lu
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
Email: latif@ladid.lu
Rizzo, Ed., et al. Expires August 15, 2014 [Page 10]