Subject: [6lo] 6TONon-IP mapping

From: "Gianluca Rizzo" <[email-masked]>
Date: Wed, 05 Feb 2014 10:48:11 +0100

Hi 6lo WG,
 
we are following up the integration of IPv6 and Internet of things devices. In particular, we have found additional requirements to the existing works from 6LoWPAN for the assigning an IPv6 address to legacy technologies which do not support natively IPv4 or IPv6. Many of these protocols belong to the domain of Building Automation, such as BACnet. 
In order to solve this problem, we came out with a method for automatic assignment of an IPv6 address to devices running legacy technologies. As we think that the problem and the proposed solution fit well the scope of this group, we would like to submit them to your attention for discussion and feedback.
For this reason, we include here a drafty description of our idea for the mapping method, which we baptized 6TONon-IP.

   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 thew were not thought 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 entrance 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,
   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 that reason, many
   designers of the Internet of Things are considering a move toward a
   common access and communication 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 the use of 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.
 
   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 of more hosts connected.  Such networks generally use
	   each a different OSI layer 3 protocol, 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, on one side, connected to each of the legacy protocols
	   networks.  Moreover, it is connected to 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 technology, 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 is dependent on the legacy technology.
 
   Though in what follows we will describe the proposed mapping with
   reference to such a system, the main ideas behing it are more
   general, and they may apply to settings other than the one of
   reference presented here.
 
   Desirable properties of the 6TONon-IP mapping mechanism
 
   In this section we describe a set of desirable properties for a
   mechanism for automatic assignment of IPv6 addresses to devices which
   do not support IPv6 or IPv4, which we name hencefort 6TONon-IP.
 
   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 in the on state, 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 a unique host
   identifier, 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 havea unique host
   identifier, 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).
 
   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 it derives.  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, in order to form a
   full IPv6 address.
 
   The input to the proposed mapping function consists in the name of
   the legacy protocol, in the protocol specific host ID of the device
   which needs an IPv6 address, and in the number of the transceiver
   through which the proxy communicates with the given device (assuming
   all transceivers at the proxy to be numbered).
 
   In the proposed mapping method, the resulting Host ID part is divided
   into three fields, as shown in Figure 1:
 
   o  A Technology ID field (8 bits), containing a code which identifies
	  the specific protocol being mapped.  For compatibility with the
	  EUI-64 addresses, the code FE is reserved for MAC addresses, and
	  the code FF for IPv4 addresses mapped into IPv6.
 
   o  A Line ID field (8 bits), which is used to group devices accessed
	  through a same transceiver.  For protocols which do not have a
	  unique ID for each device, this field is used to differentiate
	  between two devices with same ID but attached to different
	  transceivers, and avoid in this way possible conflicts.  For
	  homogeneity with EUI-64 addresses, the code FF is used for mapped
	  MAC addresses, and for IPv4 addresses mapped into IPv6.
 
   o  A Reserved Technology Mapping field (48 bits).  This field maps
	  the protocol specific ID.  For those protocols for which a unique
	  ID is available, this field contains the protocol specific ID,
	  possibly with some stuffing bits (set to zero) when the protocol
	  ID is less than 48 bits.  For protocols whose protocol specific ID
	  is larger than 48 bits (e.g. RFID), a hashing function is used to
	  map it into 48 bits.  In this case, the requirements of
	  consistency and uniqueness within a proxy are satisfied with a
	  very high probability, which depends on the hashing algorithm
	  used.
 
   The resulting format of the Host ID part of the IPv6 address obtained
   from mapping is indicated in Figure 1.
	    +-------------------+---------+----------+-------------------+
	    | Res.Tech. Mapping | Line ID | Tech. ID | Res.Tech. Mapping |
	    |    (24 bits)      | (8 bits)| (8 bits) |   (24 bits)       |
	    +-------------------+---------+----------+-------------------+
		   Figure 1: general format of the host ID part for legacy protocols
 
   Note that for compatibility with EUI-64 addresses [RFC4291], and in
   order to eliminate the (already very small) probability of conflict
   of the generated address with a EUI-64 MAC mapped or IPv4 mapped
   address within the same proxy, the reserved technology mapping field
   is split into two equally sized parts (24 bits-long), as shown in
   Figure 1.  In this way it is possible to maintain the structure of
   EUI-64 addresses.  The Technology ID field is used to discriminate
   among MAC addresses, IPv4 mapped addresses, and legacy protocols
   mapped into IPv6.
 
   For protocols whose protocol ID is not larger than 48 bits, the host
   ID part of the IPv6 address may be obtained via direct mapping, on
   the "reserved technology mapping" field, of the protocol ID, possibly
   with the addition of stuffing bits set to zero.  When the protocol ID
   is larger than 48 bits, a hashing function might be employed to
   obtain the 48 bits of the reserved technology mapping part of the
   Host ID.
 
   Examples
 
   In this section we illustrate the proposed mapping method by applying
   it on some examples.
 
   Example 1 - Bluetooth
 
   We assume the legacy protocol is Bluetooth.  As Bluetooth devices
   have a MAC address, the host part of the IPv6 address is obtained
   from the MAC address in the EUI-64 format.  That is, if the MAC
   address is 00902717FC0F, we have a host part of the IPv6 address
   given by
 
		  +-------------------+---------+----------+-------------------+
		  | Res.Tech. Mapping | Line ID | Tech. ID | Res.Tech. Mapping |
		  | 00 90 27   	   | FF      | FE 	  | 17 FC 0F   	   |
		  +-------------------+---------+----------+-------------------+
			 Figure 2: Bluetooth example: the host ID part.
 
   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.23G3D00.8666A3.000000A05.  Let us assume that its
   hash in 48 bits is given by 52A5 13B7 6DA1.  Let us assume that the
   interface to which the proxy is connected to the RFID network is the
   interface number 1, and that the technology ID code for RFID is 07.
   Then the host id part of the IPv6 address is given by
 
		  +-------------------+---------+----------+-------------------+
		  | Res.Tech. Mapping | Line ID | Tech. ID | Res.Tech. Mapping |
		  | 52 A5 13   	   | 01      | 07 	  | B7 6D A1   	   |
		  +-------------------+---------+----------+-------------------+
			 Figure 3: RFID example: the host ID part.

Best regards,
 
Gianluca Rizzo

---

From: Robert Cragie <[email-masked]>
Date: Thu, 6 Feb 2014 13:37:48 +0000

This is already defined in RFC 4291 for Modified EUI-64 addresses.

A few points:

The example you give for Bluetooth below is wrong:

EUI-48: 00-90-27-17-FC-0F
EUI-64: 00-90-27-FF-FE-17-FC-0F (as defined in
http://standards.ieee.org/develop/regauth/tut/eui48.pdf)
IID: 0290:27FF:FE17:FC0F - *need to set the "u" bit*

It doesn't seem possible to specify the use of the middle two octets for
universal IIDs as these can conflict with EUI-64s.

I guess it would be possible to come up with some scheme for all IIDs with
"u" bit set to 0 - is that the intention? Even then, it would seem more
appropriate to use a link layer address than a device identifier, which may
be the same in certain cases but is not in others.

Robert

On 5 February 2014 09:48, Gianluca Rizzo <[email-masked]> wrote:

>  Hi 6lo WG,
>
> we are following up the integration of IPv6 and Internet of things
> devices. In particular, we have found additional requirements to the
> existing works from 6LoWPAN for the assigning an IPv6 address to legacy
> technologies which do not support natively IPv4 or IPv6. Many of these
> protocols belong to the domain of Building Automation, such as BACnet.
> In order to solve this problem, we came out with a method for automatic
> assignment of an IPv6 address to devices running legacy technologies. As we
> think that the problem and the proposed solution fit well the scope of this
> group, we would like to submit them to your attention for discussion and
> feedback.
> For this reason, we include here a drafty description of our idea for the
> mapping method, which we baptized 6TONon-IP.
>
>
>    Introduction
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Feb 2014 01:45:40 +0000

Hello Robert,

Thanks for reviewing the document. I am forwarding the email to the co-authors of the document for their attention.
Can the co-authors of draft-rizzo-6lo-6legacy-00 address the questions from Robert Cragie?

Thanks,
-Samita
From: 6lo [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Thursday, February 06, 2014 5:38 AM
To: [email-masked]
Subject: Re: [6lo] 6TONon-IP mapping

A few points:

EUI-48: 00-90-27-17-FC-0F
EUI-64: 00-90-27-FF-FE-17-FC-0F (as defined in http://standards.ieee.org/develop/regauth/tut/eui48.pdf)
IID: 0290:27FF:FE17:FC0F - *need to set the "u" bit*

It doesn't seem possible to specify the use of the middle two octets for universal IIDs as these can conflict with EUI-64s.

I guess it would be possible to come up with some scheme for all IIDs with "u" bit set to 0 - is that the intention? Even then, it would seem more appropriate to use a link layer address than a device identifier, which may be the same in certain cases but is not in others.

Robert

On 5 February 2014 09:48, Gianluca Rizzo <[email-masked]<mailto:[email-masked]>> wrote:
Hi 6lo WG,

   Introduction

   Reference System

   6TONon-IP Mapping Method

   Examples

   Example 1 - Bluetooth

   Example 2 - RFID

Best regards,

Gianluca Rizzo

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Antonio Jara <[email-masked]>
Date: Thu, 13 Feb 2014 02:49:07 +0100

Dear Samita,

The input of Robert was considered and we adapted the initial proposal from
the email, to what has been submited as the 00 version.

Such as you can see, we have already even ack his great feedback.

It could be nice, if Robert could confirm us that the current version in
the 00 document, is fine, and satisfies his issues, or other way, continues
proving his highly valuable input.

BR,
Antonio J. Jara

On Thu, Feb 13, 2014 at 2:45 AM, Samita Chakrabarti <
[email-masked]> wrote:

>  Hello Robert,
>
>
>
> Thanks for reviewing the document. I am forwarding the email to the
> co-authors of the document for their attention.
>
> *From:* 6lo [mailto:[email-masked]] *On Behalf Of *Robert Cragie
> *Sent:* Thursday, February 06, 2014 5:38 AM
> *To:* [email-masked]
> *Subject:* Re: [6lo] 6TONon-IP mapping
>
>
>