RFC 6574

Report from the Smart Object Workshop

📅 published April 2012, from ietf

Report from the Smart Object Workshop ✨🎀

Part 1 of 8

RFC number: 6574
Series: Internet Architecture Board (IAB) 🏛️
Authors: H. Tschofenig and J. Arkko 🫶
Category: Informational
Date: April 2012
ISSN: 2070-1721
Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈

Abstract

okay so this doc is a recap 💖 of a workshop the Internet Architecture Board (IAB) ran on 'Interconnecting Smart Objects with the Internet' 🧚. It happened in Prague on 25 March 2011. The big goal was to ask the wider community what their experience was deploying IETF protocols in constrained environments 🔥. It sums up the discussions and lists the conclusions and recommendations for the Internet Engineering Task Force (IETF) community 💅.

Quick heads up: this is a report on what happened at the workshop. The views and positions in here belong to the workshop participants, and they don't necessarily match IAB views and positions 🙈✨.

Status of This Memo 🎀

This doc is not an Internet Standards Track specification. It's published for informational purposes, so no vibes of "this is a standard now" 🙅‍♀️.

It's a product of the Internet Architecture Board (IAB) and it's basically information the IAB thought was worth keeping on the permanent record 📚. Anything the IAB approves for publication is not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 if you want the receipts 🧾.

For the current status, any errata, and how to give feedback, check out http://www.rfc-editor.org/info/rfc6574 🌈.

Copyright Notice 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 📜🙈.

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Constrained Nodes and Networks . . . . . . . . . . . . . . . .  5
3.  Workshop Structure . . . . . . . . . . . . . . . . . . . . . .  6
  3.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  6
    3.1.1.  One Internet vs. Islands . . . . . . . . . . . . . . .  6
    3.1.2.  Domain-Specific Stacks and Profiles  . . . . . . . . .  8
    3.1.3.  Which Layer? . . . . . . . . . . . . . . . . . . . . .  9
  3.2.  Sleeping Nodes . . . . . . . . . . . . . . . . . . . . . . 10
  3.3.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
  3.4.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.  Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 16
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A.  Program Committee . . . . . . . . . . . . . . . . . . 25
Appendix B.  Workshop Materials  . . . . . . . . . . . . . . . . . 25
Appendix C.  Accepted Position Papers  . . . . . . . . . . . . . . 25
Appendix D.  Workshop Participants . . . . . . . . . . . . . . . . 30
Appendix E.  IAB Members at the Time of Approval . . . . . . . . . 32

1. Introduction 🧚

so the IAB holds occasional workshops to think about long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture 🔮. This long-term planning is complementary to the ongoing engineering work done by IETF working groups, under the leadership of the Internet Engineering Steering Group (IESG) and area directorates 💼.

Today's Internet is experienced by users as a set of applications, like email, instant messaging, and services on the Web 📱. These apps don't require users to be present when the service runs, but in lots of cases they are 🙈. There are also big performance differences among end devices, but generally, end devices on the Internet are considered to be high performance 💪.

BUT there are a LOT of deployed embedded devices, and there's real value in connecting them to the Internet 🔥. The term "Internet of Things" describes the trend where tons of devices use communication services offered by Internet protocols 🌐. A lot of these devices aren't directly operated by humans. They live as components in buildings or vehicles, or they're spread out in the environment 🏠🚗. Computing power, available memory, (electrical) power, and communications bandwidth vary hugely between device types 📊.

Lots of these devices can offer new possibilities or add value for devices that weren't connected before ✨. Some devices used to run on proprietary communication networks, but they're now moving to the Internet Protocol suite so everything can share the same network and get rich communications services 🦋.

A lot of this can simply run on existing Internet protocols 💅. For example, home entertainment and monitoring systems often offer a Web interface to the end user 📺. In many cases, though, the new, constrained environments can benefit from extra protocols and protocol extensions that help optimize communications and lower computational requirements 🧠. Some examples of standardization work already underway for these environments are the Constrained RESTful Environments (CoRE), IPv6 over Low power WPAN (6LoWPAN), Routing Over Low power and Lossy networks (ROLL), and the Light-Weight Implementation Guidance (LWIG) working groups of the IETF 💜.

This workshop looked at what researchers and developers have learned when they think about the characteristics of constrained devices 🔬. Engineers know that a LOT of design considerations go into protocols and architecture 😭. Balancing code size, economic incentives, power consumption, usability, and security is often really hard, as Clark et al. showed in "Tussle in Cyberspace: Defining Tomorrow's Internet" [Tussle] 🥹.

The participants talked about the experience and approaches they took when designing protocols and architectures for connecting smart objects to the Internet 🌸. The investigation covered constrained nodes as well as constrained networks 🫶.

The call for position papers asked people to look into integrating with the Internet in these categories:

Scalability 📈
Power efficiency 🔋
Interworking between different technologies and network domains 🌉
Usability and manageability 🎀
Security and privacy 🔐

The workshop goals can be summed up like this:

As many deployed smart objects demonstrate, running protocols like the Internet Protocol Version 4 [RFC0791] and Version 6 [RFC2460], the User Datagram Protocol (UDP) [RFC0768], the Transmission Control Protocol (TCP) [RFC0793], the Hypertext Transfer Protocol (HTTP) [RFC2616], etc., on constrained devices is clearly possible. Still, protocol designers, system architects, and developers have to keep various limitations in mind. The organizers were interested to discuss the experience with deploying IETF protocols in different constrained environments. Furthermore, the organizers were seeking to identify issues either where current implementers do not yet have solutions or where researchers predict potential issues. The workshop served as a venue to identify problems and to discover common interests that may turn into new work or into changes in direction of already ongoing work at the IETF and or the Internet Research Task Force (IRTF).

2. Constrained Nodes and Networks ✨

Okay so the whole workshop got started because tiny devices keep showing up on the network 🔌🧚. The obvious next question is how these limits change the way the affected nodes get designed 🤔. Real talk: not every node has the same set of limitations, so don't assume they all match 💅.

Energy constraints:

Wireless communication can eat a huge chunk of a wireless device's power budget 🔋😭, so cutting out unnecessary communication can seriously extend the battery life of a low-end device. The choice of low-power radio can also make a big difference to overall energy consumption, and so can sleeping periodically whenever the device isn't in use 💤. In some cases these nodes only wake up now and then to handle the communications they need 🌙. This is so different from the "always on" paradigm you find on regular Internet hosts, bestie 🙈. And even non-battery-operated devices still have power as a constraint when it comes to energy efficiency goals ⚡.

Bandwidth constraints:

Various low-power radio networks only offer limited bandwidth, and they show high packet loss as well as high link quality variability 📉. Data transmission rates vary from 20 to 900 kilobits per second (for example, with IEEE 802.15.4) 🦋. Nodes may be used in radio environments that are usually super unstable 😵. The physical-layer packet size may be limited (~100 bytes) 🍓.

Memory constraints:

How much volatile and persistent storage a device has really shapes how programs run, and it has big implications for what the protocol stack can do 🧠. The Arduino UNO board, for example, gives a developer 2 KB RAM and 32 KB flash memory (without any extensions, such as microSD cards) 💀.

A system designer also has to think about CPU constraints, which often tie back to energy constraints: a processor with lower performance consumes less energy 🔥. As we'll get into later in this document, the design of the mainboard may let certain components be put to sleep to lower energy consumption even more 😴. In general, embedded systems are often purpose built with only the hardware components needed for the given task 🎀. General-purpose personal computers, on the other hand, are less constrained when it comes to their mainboard layout and typically offer a huge number of optional plug-in peripherals to connect 💻.

The intended usage environment matters too 🌍. For example, a humidity sensor deployed outside a building may need to deal with temperatures from -50 degrees C to +85 degrees C 🥶🔥. Smart objects also often have physical size limitations 📏. Traditional mainboards are pretty big, like the Advanced Technology eXtended (ATX) design with a board size of 305 x 244 mm that you'll find in many PCs, or the mini-ITX design typically found in home theater PCs with 170 x 170 mm 🎬. Mainboard layouts for embedded systems are typically much smaller, like the CoreExpress layout with 58 x 65 mm, or even smaller 🤏. On top of the plain mainboard, you also have to account for additional sensors, peripherals, a power adapter/battery, and a case 🎒. And then there are cost restrictions as well 💸.

The situation gets even more challenging when it's not only the hosts that are constrained but also the network nodes themselves 🚧.

While constant improvements are being made, Moore's law tends to be less effective in the embedded system space than in personal computing devices 📉. Gains from increases in transistor count and density are more likely to get invested in reducing cost and power requirements than in continual increases in computing power 💅✨.

3. Workshop Structure 🎀

With the ongoing work on connecting smart objects to the Internet, there are so many challenges the workshop participants raised across more than 70 accepted position papers 🤯. With a single workshop day, the discussions had to be focused, so priority went to the topics that lots of authors had raised 🎯. A summary of the identified issues is captured in the subsections below 🫶.

3.1. Architecture 🏛️

A number of architectural questions came up at the workshop, and that makes sense, because architectural choices affect the technical solutions that are needed and the need for standards 🧩. The discussions covered questions about the separation of traffic, the need for profiling for application-specific domains, the demand for data-model-specific standardization, and the design choices about the layer at which functionality should be put. They're briefly summarized below 👑.

3.1.1. One Internet vs. Islands 🏝️

Devices that used to live in proprietary or application-specific networks are now migrating to IP networks 🚀. The question is whether these smart objects are now on the same IP network as every other application 🤔. Controlled applications, like the fountains in front of the Bellagio hotel in Las Vegas that run as a distributed control system [Dolin], probably aren't exchanging their control messages over the same network that hotel guests use for their Internet traffic ⛲. The same had been argued for smart grids, which are described as follows in [SmartGrid]:

A smart grid is a digitally enabled electrical grid that gathers, distributes, and acts on information about the behavior of all participants (suppliers and consumers) in order to improve the efficiency, reliability, economics, and sustainability of electricity services.

So the question the workshop raised is, in what sense are we talking about one Internet, or about using IP technology for a separate, "walled garden" network that's independent of the Internet? Main character question alert 🚨💖

Cullen Jennings compared the current state of smart object deployment with the evolution of Voice over IP (VoIP) 📞, and it's giving déjà vu 😭: "Initially, many vendors recommended to run VoIP over a separate VLAN or a separate infrastructure. Nobody could imagine how to make the type of real-time guarantees, how to debug it, and how to get it to work because the Internet is not ideally suited for making any types of guarantees for real-time systems. As time went on, people got better at making voice work across that type of IP network. They suddenly noticed that having voice running on a separate virtual network than their other applications was a disaster. They couldn't decide if a PC was running a softphone and whether it went on a voice or a data network. At that point, people realized that they needed a converged network and all moved to one. I wouldn't be surprised to see the same happen here. Initially, we will see very separated networks. Then, those will be running over the same hardware to take advantage of the cost benefits of not having to deploy multiple sets of wires around buildings. Over time, there will be strong needs to directly communicate with each other. We need to be designing the system for the long run. Assume everything will end up on the same network even if you initially plan to run it in separate networks."

It is clearly possible to let sensors in a building communicate through the wireless access points and through the same infrastructure used for Internet access, if you want to 🛜. Those who want separation at the physical layer can do that too 🧱. What really matters is making sure these different deployment philosophies don't force a loss of interoperability 🫶🔥.

The level of interoperability that IP accomplished fostered innovation at the application layer 💡. Ralph Droms backed this up by saying: "Bright people will take a phone, build an application and connect it, with the appropriate security controls in place, to the things in my house in ways we have never thought about before. Otherwise, we are just building another telephone network." 📱✨

3.1.2. Domain-Specific Stacks and Profiles ✨

okay bestie, picture this 🎀 a building network where you install a brand new light bulb and it just works with the light switch from a totally different vendor in the same room. no config, no drama. for a lot of people, that's the dream for smart object design 💡 but getting there is NOT just a network-layer thing. even if both devices run the same transport and app protocol (like HTTP), it's still not enough, because they also both need to understand the semantics of the payloads for "Turn the light on" 🫶

Standardizing the entire stack for this exact "light switch / light bulb" situation is totally possible 💅 for example, a stack could use IPv6 with a specific address configuration mechanism (such as stateless address autoconfiguration), a network access authentication security mechanism such as Protocol for carrying Authentication for Network Access (PANA) [RFC5191], a service discovery mechanism (e.g., multicast DNS with DNS-Based Service Discovery [DNS-SD]), an application-layer protocol, for example, Constrained Application Protocol (CoAP) [CoAP] (which uses UDP), and the syntax and semantic for the light on/off functionality.

As you can see, even this simple list already has a bunch of protocol stuff that a lot of different stakeholders have to agree on to make this work seamlessly 🙈 and it gets way more complex from there. at the network layer you've got IPv4 and IPv6. at the transport layer there are options like UDP, TCP, the Stream Control Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP) [RFC4340]. and at the application layer there are plenty of choices when it comes to communication protocols, data formats, and data models 🌈 different requirements have led to a variety of communication protocols: client-server protocols in the style of the original HTTP, publish-subscribe protocols (like the Session Initiation Protocol (SIP) [RFC3261] or Extensible Messaging and Presence Protocol (XMPP) [RFC6121]), and store-and-forward messaging (borrowed from the delay tolerant networking community). and on top of all the different application-layer communication protocols come various identity and security mechanisms 😭

With smart object constraints, it feels natural to build these stacks, since each application domain (e.g., healthcare, smart grids, building networking) has its own unique requirements and its own community involved in the design process 💖 but real talk, the questions start piling up. how likely is it that these profiles will be the right match for the future, especially for the new innovations that are coming? how many of these stacks are we going to end up with? will the differences between profiles come purely from the different requirements of each application domain, or will the mismatches reflect the spirit, understanding, and preferences of the community designing them? and how many stacks will multipurpose devices have to implement? 💀

Standardizing profiles separately for each application isn't the only option, btw 👑 another option is to let many different applications use a common foundation, meaning a protocol stack that is implemented and used by every device. the catch is that this requires analyzing the various application domains for their common characteristics and identifying the requirements they all share. how hard it is to agree on what that foundation stack should look like depends on how many layers it covers and how lightweight it has to be ✨

from the discussions at the workshop, it was clear that none of the available options are ideal, and further discussions are needed 🫶

3.1.3. Which Layer? 🦋

okay so the end-to-end principle says functionality should go into the end points instead of into the networks. an additional recommendation, which is just as important, is to put functionality higher up in the protocol stack 💅 making common functionality available as building blocks for higher layers is useful, but the wide range of application requirements led to a model where lower layers provide only very basic functionality and the more sophisticated features are offered by the various applications. still, there's been a desire to put application-layer functionality into the lower layers of the networking stack 👀 a common belief is that performance benefits can be gained if functionality is placed at the lower layers. this new functionality may be offered in the form of a gateway, which bridges different communication technologies, acts on behalf of other nodes, and offers more generic functionality (such as name-based routing and caching) 🧚

two examples of functionality offered at the network layer and discussed during the workshops were location and name-based routing 🌸

Location:

the notion of location gives each network node an understanding of proximity (e.g., 'I am a light bulb and in the same room as the light switch.') 💡 today, a router may tell you whether other nodes belong to the same subnet, or it may provide location information (for example, in the form of GPS-based coordinates). but providing a sense of the specific environment (e.g., a room, building, campus, etc.) isn't possible without manual configuration 🙃 it's been a desirable feature for lots of ubiquitous computing applications to know this type of information and use it for richer application-layer interactions, but widespread deployment hasn't happened yet.

Name-Based Routing:

with the work on recent "clean slate" architecture proposals, such as named data networking, flexible naming concepts are being researched so application developers can express their application-layer concepts in a way that the underlying networking stack can use natively, without translation 🔥 for example, Jeff Burke shared his work in a theater with a distributed control system for technical equipment (such as projectors, dimmers, and light systems). application developers name their equipment with human-readable identifiers, which may change after the end of a rehearsal, and address them using those names. these naming concepts, based on variable-length strings, raise questions about scalability 🤔

the workshop participants weren't able to agree on what functionality should move from the application layer to the network layer 😭🫶

3.2. Sleeping Nodes 💤

okay so the big problem with smart objects is their energy 🔋. To make a watch battery or a single AAA battery last for months, these low-power devices have to sleep 99% to 99.5% of their time 😴. For example, a light sensor may only wake up to check whether it's nighttime so it can turn on the light bulbs 🌙. Most parts of the system, especially communication components (like the WLAN radio interface), get put into a sleeping state, while selected components, such as sensors, periodically check for relevant events and, if necessary, turn on other hardware modules. Every bit is precious, as is every round trip and every millisecond of radio activity 💅.

Many IETF protocols are basically designed to be always on 😳. The protocol implementation waits for and reacts to incoming messages, and may maintain session state (at various layers of the stack) 🧠. These protocols work well when energy consumption isn't a concern and when receiving and sending messages happens at a low cost. It should be understood that energy is consumed both in transmitting messages (and, often more importantly, in keeping the receiver awake) ⚡. Allowing devices to sleep most of the time preserves energy but creates challenges for protocol designs 🫠.

The inherent issue for a stationary node resuming from sleep is that another node may have chosen the same address while it was asleep 🙈. A number of steps have to be taken before sending a packet. A new address may have to be obtained, for example using the Dynamic Host Configuration Protocol (DHCP) or stateless address autoconfiguration. Optionally, Detecting Network Attachment (DNA) procedures (see [RFC4436] and [RFC6059]) can be used to shorten the setup time by noticing that the node is using the same default gateway 🏃‍♀️.

The issue with a mobile node that's sleeping is that it may have been moved to another network (think a sleeping laptop being carried into a new environment) 💻. On resumption, it may discover that its address has become invalid 💀.

The following design considerations should be taken into account when energy efficiency is a concern 📝:

Rethink the Always-On Assumption 🛌

When designing a protocol that assumes nodes are always on, alternatives need to be considered. This could involve eliminating functionality (e.g., not implementing DNA or duplicate address detection) or considering the use of a sleep proxy. While sleep proxies (e.g., proxZzzy(TM) [proxZzzy]) enable periodic messages to be sent on behalf of sleeping nodes, this approach assumes that energy management constraints do not apply to the sleep proxy, which may not always be the case (e.g., if the entire network is deployed in the field without access to power) 🌳. Yet another option is for devices to explicitly communicate sleep cycles so that they can only check for messages periodically (be it measured in milliseconds, seconds, or hours) ⏰.

This is the approach taken in IEEE 802.11, which supports multiple energy conservation mechanisms designed to enable a station to spend a large fraction of the time sleeping 🫶.

Reduce Network Attachment Costs 💸

As noted above, the procedures for obtaining an address and assuring its uniqueness can be costly. In a network where nodes spend a large fraction of the time sleeping, but are not necessarily mobile, are all of these procedures really necessary? 🤔

Can we find ways to reduce the number of protocol interactions without sacrificing correctness? The main focus of past investigations has been on IPv6 and ND, but other protocols do also deserve a deeper investigation, such as DNS and DHCP 🔍.

Avoid Verbose Protocols 📜

Protocols involving multiple roundtrips and/or lengthy messages with verbose encodings (e.g., XML) are not always well-suited for constrained environments 🙅‍♀️. Low-power nodes utilizing verbose protocols have to use more energy in sending messages and have to stay powered on for a longer period of time as they wait for the multi-roundtrip protocol exchanges to complete 😩.

The best way to address these problems is to ensure that the simplest possible protocol exchanges are used when the protocols in question are designed. In some cases, alternative encoding formats and compression may also help ✨.

Think about System-Wide Efficiency 🌍

While energy efficiency is critical for low-power devices running on batteries, it is also beneficial for other devices as well, including notebook computers, desktop computers, and smartphones 💻📱. However, if the goal is energy efficiency as opposed to battery life extension for low-power devices, then it is important to consider the total energy consumption of all the elements of the system 🧮.

For example, consider energy consumption in a home environment. In these scenarios it is important to evaluate the energy usage of the entire system. A light bulb utilizing Internet technology described in this document may use less power, but there is also the device that controls the bulb, which may consume a lot of energy 💡. If the goal is to reduce overall energy usage, then it is important to consider these two devices (and potentially many others) together 🏡.

3.3. Security 🔐

In the development of smart object applications, as with any other protocol application solution, security has to be considered early in the design process 🛡️. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 [RFC3552] and RFC 4101 [RFC4101], apply also to the smart object space.

While there are additional constraints, as described in Section 2, security has to be a mandatory part of the solution. The hope is that this will lead to implementations that provide security features, deployments that utilize them, and finally use of better security mechanisms 🥹. It is important to point out that the lack of direct user interaction will place hard requirements on deployment models, configuration mechanisms, and software upgrade / crypto-agility mechanisms 🚨.

Since many of the security mechanisms allow for customization, particularly with regard to the cryptographic primitives utilized, many believe that IETF security solutions are usable without modifications in a large part of the smart object domain. Others call for new work on cryptographic primitives that make use of a single primitive (such as the Advanced Encryption Standard (AES) [AES]) as a building block for all cryptographic functions. The benefit would be a smaller footprint of the overall solution, specifically with respect to hardware limitations (e.g., the hardware architecture of certain embedded devices prevents pipelining from being used). In the excitement for new work on optimizations of cryptographic primitives, other factors have to be taken into consideration that influence successful deployment, such as widespread support in libraries, as well as intellectual property rights (IPR) 📚. As an example of the latter aspect, the struggle of Elliptic Curve Cryptography (ECC)-based cryptographic algorithms [ECC] to find deployment can partially be attributed to its IPR situation. The reuse of libraries providing cryptographic functions is clearly an important way to use available memory resources in a more efficient way 🧩. To deal with the performance and footprint concerns, investigations into offloading certain resource-hungry functions to parties that possess more cryptographic power have been considered. For example, the ability to delegate certificate validation to servers has been standardized in the IETF before, for the support of the Online Certificate Status Protocol (OCSP) in the Internet Key Exchange protocol version 2 (IKEv2) and in Transport Layer Security (TLS); see [RFC4806] and [RFC5246], respectively 🤝.

Focusing only on the cryptographic primitives would be shortsighted; many would argue that this is the easy part of a smart object security solution 🙄. Key management and credential enrollment, however, are considered a big challenge by many, particularly when usability requirements have to be taken into account. Another group of challenges concern privacy. With smart grids, for example, some have voiced concerns regarding the ability of third parties to keep track of an individual's energy consumption (and draw associated conclusions) 👀. As another example, it is easy to see how a scale that is connected to the Internet for uploading weight information to a social network could lead to privacy concerns ⚖️. While security mechanisms that are used to offer protection of the communication between different parties also provide a certain degree of privacy protection, they are clearly not enough to address all concerns. Even with the best communication security and access control mechanisms in place, one still needs additional safeguards against the concerns mentioned in the examples 🚧.

While better deployment of security protocols on the entire Internet would be very desirable, practical considerations regarding usability and the incentives of the stakeholders involved have often lead to slower adoption 🐢.

3.4. Routing ✨

okay so routing in smart object networks is literally its own whole saga 🧚 these devices are constrained (low power, lossy links, the works), and the routers in the network are often under the same constraints as the end devices. 🫶 right now there are two approaches being looked at for routing in these low-power and lossy networks: mesh-under and route-over. 💅

the mesh-under approach puts the routing functions at the link layer, so every device looks like an immediate neighbor at the network layer. it's giving "everyone is next to everyone" energy 🦋 with route-over, routing happens in the IP layer and not at all in the link layer. each physical hop shows up as a single IP hop (ignoring stuff that just extends the physical range of signaling, like repeaters 📡). and when we say routing here, we mean running a routing protocol. the IPv6 Routing Protocol for Low-power and Lossy Networks (RPL) [RPL] is the main character of the route-over category 👑

now, architecturally there are some questions that pop up depending on where the routing actually lives 🤔 like:

Protocols often assume that link characteristics are predictable when talking to any device on the same link, but latency, throughput, and reliability can vary a LOT between devices that are several link-layer hops away 😭 what timeout should be used? what happens if a device is unreachable? if you're picking a default router and two advertised routers are a different number of hops away, which one do you pick? and should a device be able to see the path to make a decision? if so, which path characteristics would actually be useful to have? 🙈
scoped message delivery to a neighboring IP hop (via link-local addressing) lets certain IP protocols talk only to their immediate neighbors and scope their recipients 🎀 but a link-local multicast message gets received by every node in the same IP link-local realm, unless the link layer does some special optimizations 💀
when path computations happen at the link layer AND at the network layer, what coordination needs to take place between them? 🧩

when multiple different link-layer technologies are involved in a network design, routing at layer 3 has to be provided anyway, no exceptions 🔥 [IoT-ARCH] goes into these route-over vs. mesh-under tradeoffs in a lot of detail, so go check it out if you're curious 🌸 and the people deciding on a deployment also have to figure out how to connect smart objects to the Internet infrastructure. a bunch of wired and wireless technologies might work for a given deployment, and depending on which ones you pick, the mesh-under vs. route-over choice has to be made, plus you still have to decide which specific routing protocol to use 💜

in 2008, the IETF formed the Routing Over Low power and Lossy networks (ROLL) working group to specify a routing solution for smart object environments ✨ during its first year, the group studied the routing requirements in detail (see [RFC5867], [RFC5826], [RFC5673], and [RFC5548]) 📚 it also worked on a protocol survey comparing a bunch of existing routing protocols against the requirements it had identified, including Ad hoc On-Demand Distance Vector (AODV)-style protocols [RFC3561] 🦋 the protocol survey [PROT-SURVEY] was inconclusive, and it got abandoned without ever becoming an RFC 🥲

the ROLL WG concluded that a new routing protocol satisfying the documented requirements had to be developed, so the work on RPL started as the IETF routing protocol for smart object networks 🎀 but ngl, the workshop still had heated debates about which routing protocol is best in a given environment, and those are still going 🍓 Thomas Clausen, for example, argued for using an AODV-like routing protocol in [Clausen] 🌈

4. Conclusions and Next Steps ✨

okay so the workshop was honestly such a vibe 🌸 everyone got to see super interesting applications and their requirements (buildings, fountains, theater, etc.) 🎀 and they had real debates about radically different architectures and their issues (e.g., information centric networking) 🦋. they also looked at existing tech from a totally new angle (sleeping nodes, energy consumption) 💡, zoomed in on some details of the protocol stack (neighbor discovery, security, routing) 🔍, and got to learn from actual implementation experience 🛠️. iconic, honestly 💅

one goal of the workshop was to figure out which areas still need more investigation 🧐. the list below is what the workshop participants were thinking on the day itself 📅. quick heads up: the suggested items are potential work for the IETF and the IRTF, and the order does not imply a particular preference 🙈

Security:

A discussion of security is in Section 3.3 🔐. ngl, security exchanges and the computational resources they need can add a lot to overall processing 😭. so it's a real challenge to improve performance without sacrificing the overall security level, while still keeping the whole system usable 💖

another challenge is balancing the security and performance needs of smart objects with the interoperability needs of hosts on the Internet 🌐. different algorithm suites tend to get picked for these different environments, which means trade-offs between performance on the smart objects and end-to-end security 🧩. solutions that require a "trusted" middlebox whose only job is to terminate security associations tend to get side-eyed from a security perspective 👀, especially since end users of challenged devices (where those exist) are unlikely to understand the security consequences of such middleboxes 💀

the discussion wrapped up with these recommendations:

investigate usability in cryptographic protocol design with regard to credential management 🎀. the Bluetooth pairing mechanism was mentioned as a simple and yet reasonably secure way to introduce devices into a new environment 📱. fun fact: the IETF working group Credential and Provisioning (ENROLL) was set up years ago to deal with residential networks, but got terminated prematurely due to lack of progress 🥀. the email archive still exists and is available [ENROLL], and it may have useful historical info 📚
standardized authentication and key exchange mechanisms should be surveyed for suitability in smart object environments with respect to message size, computational performance, number of messages, code size, and main memory requirements 📊. a starting point for this (in the case of IKEv2) was provided by Tero Kivinen with [MINIMAL-IKEv2] ✨, and a suitable venue for discussion could be the recently established Light-Weight Implementation Guidance (LWIG) working group [LWIG] 🦋
research has to be done on lightweight cryptographic primitives, namely block ciphers, stream ciphers, and cryptographic hash functions 🧪. it's worth mentioning the early work with the National Institute of Standards and Technology (NIST) new cryptographic hash algorithm 'SHA-3' competition [SHA3] 🏆. a suitable forum for discussion is the IRTF Crypto Forum Research Group (CFRG) [CFRG] 🌈

the difficulty and impact of choosing specialized algorithms for smart objects should not be underestimated 😤. issues include the extra specification complexity (e.g., TLS already has hundreds of ciphersuites defined, most of which are unused in practice) 🤯, the long latency in rollout (many hosts are still using deprecated algorithms 5-10 years after those algorithms were deprecated) 🐢, and the barriers that IPR-encumbered schemes present to widespread deployment 🚧. research on this in CFRG and the wider cryptographic research community is a very worthwhile goal 💜, but any such algorithms will likely need to offer very significant benefits before they get broadly adopted. 20% less CPU usage is unlikely to be a winning argument, no matter what an algorithm inventor believes 💅😂

Energy Design Considerations:

one part of the workshop focused on energy implications for IETF protocol design ⚡. proposals were made about how to extend protocols to better support nodes that are mostly sleeping 😴. discussions are encouraged on the RECIPE mailing list [RECIPE] 📬. the workshop position paper [Wasserman] by Margaret Wasserman is a good starting point for further investigation 🌸

Information-/Content-Centric Networking:

Information/Content Centric Networking is about accessing named content, and a bunch of research projects have popped up around this theme 🌍. at this point, the work is not ready for standardization in the IETF 🙅‍♀️. instead, forming an IRTF research group has been proposed, and more details are on the IRTF DISCUSS mailing list [irtf-discuss] 💬

Architectural Guidelines:

participants suggested writing up an architectural explanation of what can be done with the IETF protocols we have today and how these different elements can be combined, for the broader community 📝. this would be a task for the IAB 👑. an example of prior work that serves as input is [RFC6272] ✨

Network Management:

this topic wasn't on the workshop agenda, but it was still considered useful to start a discussion about how to implement network management protocols, such as Network Configuration Protocol (NETCONF) [RFC6241], on smart objects 🎀. the following position papers may be useful starting points: [Ersue] and [Schoenwaelder] 📄. there's also an IETF draft document available: [SNMP-OPT] 🧚

Congestion Control:

when smart objects send sensor readings to a server on the Internet, these exchanges often carry a small amount of data and happen infrequently (but regularly) 📈. with new application protocols like CoAP [CoAP] 🌷, the question comes up of whether congestion control should be used at the underlying transport protocol or by the application protocol itself 🤔. [CoAP-CC] is a starting point for CoAP, but more work is needed 🛠️

Data Models:

standardizing application-layer protocols is important, but it doesn't ensure that, for example, a light switch and a light bulb can actually talk to each other 💡. participants saw a need for more work on data models 📐. prior IETF work on things like location [GEOPRIV] can be reused 🗺️, but the question was raised of where the IETF should focus its standardization efforts, since domain expertise in each area will be needed 🧠. as a potential example, energy pricing was discussed, with an example provided by [ENERGY-PRICING] ⚡

Building Networking:

network architectures in residential and commercial buildings should take the presence of smart objects and dedicated subnetworks focused on smart objects into account 🏠. a new working group, Home Networking (HOMENET) [HOMENET], was created after the workshop to look at this 🏡

Discovery:

extra extensions to discovery protocols like multicast DNS (mDNS) may be needed for the smart object environment 🔎. for instance, the HOMENET working group wants to extend current discovery protocols to work across multiple subnets 🌐. smart object networks are often organized in separate subnets, so these extensions may be useful there too 💜

Routing:

changing radio conditions and link fluctuation may lead to the need for renumbering 📡. workshop participants argued that work should start on multi-link subnetworks to mitigate this problem, i.e., to extend the notion of a subnet so it can span multiple links 🔗. with the publication of RFC 4903 [RFC4903], the Internet Architecture Board had already looked into this topic and laid out pros and cons 📚

the applicability of specific routing protocols designed for smart object networks needs further investigation 🧭. the ROLL working group is chartered to construct an applicability document for RPL, for instance 🦋

5. Security Considerations 🔐

the workshop discussions covered a range of potential engineering activities, and each one has its own security considerations 🛡️. as the IETF community starts to pursue specific avenues from this workshop, addressing the relevant security requirements is going to be crucial 😤🔥

as described in this report, part of the agenda focused on security discussions; see Section 3.3 💖

6. Acknowledgements 🫶

we would like to thank all the participants for their position papers 💌. the authors of the accepted position papers were invited to the workshop 🎟️

big thanks to Elwyn Davies for helping us fix language bugs 🙌. we would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba, and Henning Schulzrinne for their review comments 🥹✨

additionally, we would like to thank Ericsson and Nokia Siemens Networks for their financial support 💕🌟

7. Informative References ✨

Okay bestie, this is the reference list, so it's basically the reading list for the whole doc 📚 Every entry is copied exactly as written so nothing gets lost in translation 🫶

   [AES]             Wikipedia, "Advanced Encryption Standard",
                     December 2011, <http://en.wikipedia.org/w/
                     index.php?title=Advanced_Encryption_Standard&
                     oldid=481153988>.

   [CFRG]            McGrew (Chair), D., "IRTF Crypto Forum Research
                     Group (CFRG)", June 2011, <http://irtf.org/cfrg>.

   [Clausen]         Clausen, T. and U. Herberg, "Some Considerations on
                     Routing in Particular and Lossy Environments", IAB
                     Interconnecting Smart Objects with the Internet
                     Workshop, Prague, Czech Republic, March 2011,
                     <http://www.iab.org/wp-content/IAB-uploads/
                     2011/03/Herberg.pdf>.

   [CoAP]            Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
                     "Constrained Application Protocol (CoAP)", Work
                     in Progress, October 2011.

   [CoAP-CC]         Eggert, L., "Congestion Control for the Constrained
                     Application Protocol (CoAP)", Work in Progress,
                     January 2011.

   [DNS-SD]          Cheshire, S. and M. Krochmal, "DNS-Based Service
                     Discovery", Work in Progress, December 2011.

   [Dolin]           Dolin, B., "Application Communications Requirements
                     for 'The Internet of Things'", IAB Interconnecting
                     Smart Objects with the Internet Workshop, Prague,
                     Czech Republic, March 2011, <http://www.iab.org/
                     wp-content/IAB-uploads/2011/03/Dolin.pdf>.

   [ECC]             Wikipedia, "Elliptic Curve Cryptography",
                     December 2011, <http://en.wikipedia.org/w/
                     index.php?title=Elliptic_curve_cryptography&
                     oldid=480053167>.

   [ENERGY-PRICING]  Jennings, C. and B. Nordman, "Communication of
                     Energy Price Information", Work in Progress,
                     July 2011.

   [ENROLL]          "The ietf-enroll Archives",
                     <http://mailman.mit.edu/pipermail/ietf-enroll/>.

   [Ersue]           Ersue, M. and J. Korhonen, "Position Paper on
                     'Interconnecting Smart Objects with the Internet'",
                     IAB Interconnecting Smart Objects with the Internet
                     Workshop, Prague, Czech Republic, February 2011,
                     <http://www.iab.org/wp-content/IAB-uploads/2011/03/
                     Ersue.pdf>.

   [GEOPRIV]         IETF, "Geographic Location/Privacy (geopriv)
                     Working Group",
                     <http://datatracker.ietf.org/wg/geopriv/>.

   [HOMENET]         "Home Networking (homenet) Working Group",
                     <http://datatracker.ietf.org/wg/homenet>.

   [IoT-ARCH]        Hui, J. and J. Vasseur, "Routing Architecture in
                     Low-Power and Lossy Networks (LLNs)", Work
                     in Progress, March 2011.

   [LWIG]            IETF, "Light-Weight Implementation Guidance (lwig)
                     Working Group", June 2011,
                     <http://datatracker.ietf.org/wg/lwig/charter/>.

   [MINIMAL-IKEv2]   Kivinen, T., "Minimal IKEv2", Work in Progress,
                     February 2011.

   [PROT-SURVEY]     Tavakoli, A., Dawson-Haggerty, S., and P. Levis,
                     "Overview of Existing Routing Protocols for Low
                     Power and Lossy Networks", Work in Progress,
                     April 2009.

   [RECIPE]          "Reducing Energy Consumption with Internet
                     Protocols Exploration (RECIPE) Mailing List",
                     <https://www.ietf.org/mailman/listinfo/recipe>.

   [RFC0768]         Postel, J., "User Datagram Protocol", STD 6,
                     RFC 768, August 1980.

   [RFC0791]         Postel, J., "Internet Protocol", STD 5, RFC 791,
                     September 1981.

   [RFC0793]         Postel, J., "Transmission Control Protocol", STD 7,
                     RFC 793, September 1981.

   [RFC2460]         Deering, S. and R. Hinden, "Internet Protocol,
                     Version 6 (IPv6) Specification", RFC 2460,
                     December 1998.

   [RFC2616]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                     Masinter, L., Leach, P., and T. Berners-Lee,
                     "Hypertext Transfer Protocol -- HTTP/1.1",
                     RFC 2616, June 1999.

   [RFC3261]         Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                     Johnston, A., Peterson, J., Sparks, R., Handley,
                     M., and E. Schooler, "SIP: Session Initiation
                     Protocol", RFC 3261, June 2002.

   [RFC3552]         Rescorla, E. and B. Korver, "Guidelines for Writing
                     RFC Text on Security Considerations", BCP 72,
                     RFC 3552, July 2003.

   [RFC3561]         Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc
                     On-Demand Distance Vector (AODV) Routing",
                     RFC 3561, July 2003.

   [RFC4101]         Rescorla, E. and IAB, "Writing Protocol Models",
                     RFC 4101, June 2005.

   [RFC4340]         Kohler, E., Handley, M., and S. Floyd, "Datagram
                     Congestion Control Protocol (DCCP)", RFC 4340,
                     March 2006.

   [RFC4436]         Aboba, B., Carlson, J., and S. Cheshire, "Detecting
                     Network Attachment in IPv4 (DNAv4)", RFC 4436,
                     March 2006.

   [RFC4806]         Myers, M. and H. Tschofenig, "Online Certificate
                     Status Protocol (OCSP) Extensions to IKEv2",
                     RFC 4806, February 2007.

   [RFC4903]         Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
                     June 2007.

   [RFC4960]         Stewart, R., "Stream Control Transmission
                     Protocol", RFC 4960, September 2007.

   [RFC5191]         Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H.,
                     and A. Yegin, "Protocol for Carrying Authentication
                     for Network Access (PANA)", RFC 5191, May 2008.

   [RFC5246]         Dierks, T. and E. Rescorla, "The Transport Layer
                     Security (TLS) Protocol Version 1.2", RFC 5246,
                     August 2008.

   [RFC5548]         Dohler, M., Watteyne, T., Winter, T., and D.
                     Barthel, "Routing Requirements for Urban Low-Power
                     and Lossy Networks", RFC 5548, May 2009.

   [RFC5673]         Pister, K., Thubert, P., Dwars, S., and T. Phinney,
                     "Industrial Routing Requirements in Low-Power and
                     Lossy Networks", RFC 5673, October 2009.

   [RFC5826]         Brandt, A., Buron, J., and G. Porcu, "Home
                     Automation Routing Requirements in Low-Power and
                     Lossy Networks", RFC 5826, April 2010.

   [RFC5867]         Martocci, J., De Mil, P., Riou, N., and W.
                     Vermeylen, "Building Automation Routing
                     Requirements in Low-Power and Lossy Networks",
                     RFC 5867, June 2010.

   [RFC6059]         Krishnan, S. and G. Daley, "Simple Procedures for
                     Detecting Network Attachment in IPv6", RFC 6059,
                     November 2010.

   [RFC6121]         Saint-Andre, P., "Extensible Messaging and Presence
                     Protocol (XMPP): Instant Messaging and Presence",
                     RFC 6121, March 2011.

   [RFC6241]         Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
                     Bierman, "Network Configuration Protocol
                     (NETCONF)", RFC 6241, June 2011.

   [RFC6272]         Baker, F. and D. Meyer, "Internet Protocols for the
                     Smart Grid", RFC 6272, June 2011.

   [RPL]             Brandt, A., Vasseur, J., Hui, J., Pister, K.,
                     Thubert, P., Levis, P., Struik, R., Kelsey, R.,
                     Clausen, T., and T. Winter, "RPL: IPv6 Routing
                     Protocol for Low-Power and Lossy Networks", Work
                     in Progress, March 2011.

   [SHA3]            NIST, "Cryptographic Hash Algorithm Competition",
                     December 2010, <http://csrc.nist.gov/groups/ST/
                     hash/sha-3/index.html>.

   [SNMP-OPT]        Schoenwaelder, J., Mukhtar, H., Joo, S., and K.
                     Kim, "SNMP Optimizations for Constrained Devices",
                     Work in Progress, October 2010.

   [Schoenwaelder]   Schoenwaelder, J., Tsou, T., and B. Sarikaya,
                     "Protocol Profiles for Constrained Devices", IAB
                     Interconnecting Smart Objects with the Internet
                     Workshop, Prague, Czech Republic, February 2011,
                     <http://www.iab.org/wp-content/IAB-uploads/2011/03/
                     Schoenwaelder.pdf>.

   [SmartGrid]       Wikipedia, "Smart Grid", December 2011,
                     <http://en.wikipedia.org/w/
                     index.php?title=Smart_grid&oldid=479750548>.

   [Tussle]          Clark, D., Wroclawski, J., Sollins, K., and R.
                     Braden, "Tussle in Cyberspace: Defining Tomorrow's
                     Internet", In Proc. ACM SIGCOMM, 2002,
                     <http://conferences.sigcomm.org/sigcomm/2002/
                     papers/tussle.html>.

   [Wasserman]       Wasserman, M., "It's Not Easy Being 'Green'", IAB
                     Interconnecting Smart Objects with the Internet
                     Workshop, Prague, Czech Republic, March 2011,
                     <http://www.iab.org/wp-content/IAB-uploads/2011/03/
                     Wasserman.pdf>.

   [irtf-discuss]    Ohlman, B., "Draft ICN RG Charter", message to IRTF
                     DISCUSS Mailing List, May 2011,
                     <http://www.ietf.org/mail-archive/web/irtf-discuss/
                     current/msg00041.html>.

   [proxZzzy]        ECMA, "proxZzzy(TM) for sleeping hosts",
                     Standard ECMA-393, February 2010,
                     <http://www.ecma-international.org/publications/
                     standards/Ecma-393.htm>.

Appendix A. Program Committee 🎀

These are the lovely people who organised the workshop and also took care of this event 💜 The crew is: Jari Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David Culler, Lars Eggert, JP. Vasseur, Stewart Bryant, Adrian Farrel, Ralph Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen Jennings, Manfred Hauswirth, and Lukas Kencl. Iconic squad, no notes 👑

Appendix B. Workshop Materials 🦋

Here's where you can find all the workshop stuff 🌸

Main page: http://www.iab.org/about/workshops/smartobjects/

Position papers: http://www.iab.org/about/workshops/smartobjects/papers/

Slides: http://www.iab.org/about/workshops/smartobjects/agenda/

Minutes: http://www.iab.org/activities/workshops/smartobjects/smartobjectworkshopmeetingminutes/

Appendix C. Accepted Position Papers ✨

Okay bestie, this is the big list of 71 accepted position papers from the workshop 🌸 Every paper is listed in the same order as the original, with the author names exactly as written.

"Deployment Experience with Low Power Lossy Wireless Sensor Networks" by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. Philipp, and G. Wittenburg
"CoAP improvements to meet embedded device hardware constraints" by Davide Barbieri
"Unified Device Networking Protocols for Smart Objects" by Daniel Barisic and Anton Pfefferseder
"Simplified neighbour cache implementation in RPL/6LoWPAN" by Dominique Barthel
"Home Control in a consumer's perspective" by Anders Brandt
"Authoring Place-based Experiences with an Internet of Things: Tussles of Expressive, Operational, and Participatory Goals" by Jeff Burke
"A Dynamic Distributed Federated Approach for the Internet of Things" by Diego Casado Mansilla, Juan Ramon Velasco Perez, and Mario Lopez-Ramos
"Quickly interoperable Internet of Things using simple transparent gateways" by Angelo P. Castellani, Salvatore Loreto, Nicola Bui, and Michele Zorzi
"Position Paper of the Brno University of Technology Department of Telecommunications" by Vladimir Cervenka, Lubomir Mraz, Milan Simek, and Karel Pavlata
"Secure Access to IOT Network: An Application-based Group Key Approach" by Samita Chakrabarti and Wassim Haddad
"Domain-Insulated Autonomous Network Architecture (DIANA)" by W. Chun
"Yet Another Definition on Name, Address, ID, and Locator (YANAIL)" by W. Chun
"The Challenge of Mobility in Low Power Networks" by E. Davies
"If the routing protocol is so smart, why should neighbour discovery be so dumb?" by Nicolas Dejean
"Making Smart Objects IPv6 Ready: Where are we?" by M. Durvy and M. Valente
"Position Paper on 'Interconnecting Smart Objects with the Internet'" by Mehmet Ersue and Jouni Korhonen
"The Real-time Enterprise: IoT-enabled Business Processes" by Stephan Haller and Carsten Magerkurth
"Making Internet-Connected Objects readily useful" by Manfred Hauswirth, Dennis Pfisterer, and Stefan Decker
"Some Considerations on Routing in Particular and Lossy Environments" by Thomas Clausen and Ulrich Herberg
"A Security Protocol Adaptation Layer for the IP-based Internet of Things" by Rene Hummen, Tobias Heer, and Klaus Wehrle
"Simplified SIP Approach for the Smart Object" by Ryota Ishibashi, Takumi Ohba, Arata Koike, and Akira Kurokawa
"Mobility support for the small and smart Future Internet devices" by Antonio J. Jara and Antonio F. G. Skarmeta
"The Need for Efficient Reliable Multicast in Smart Grid Networks" by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk
"Lightweight Cryptography for the Internet of Things" by Masanobu Katagi and Shiho Moriai
"Thoughts on Reliability in the Internet of Things" by James Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli
"IKEv2 and Smart Objects" by Tero Kivinen
"Position Paper on Thing Name Service (TNS) for the Internet of Things (IoT)" by Ning Kong and Shuo Shen
"Connecting Smart Objects to Wireless WANs" by Suresh Krishnan
"Towards an Information-Centric Internet with more Things" by D. Kutscher and S. Farrell
"Application of 6LoWPAN for the Real-Time Positioning of Manufacturing Assets" by Jaacan Martinez and Jose L. M. Lastra
"Lighting interface to wireless network" by Jaroslav Meduna
"Social-driven Internet of Connected Objects" by Paulo Mendes
"Protocols should go forward that are required by non IP based protocols" by Tsuyoshi Momose
"Web services for Wireless Sensor and Actuator Networks" by Guido Moritz
"Connecting BT-LE sensors to the Internet using Ipv6" by Markus Isomaki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, Basavaraj Patil, Teemu Savolainen, and Zach Shelby
"Building Networks" by Bruce Nordman
"Issues and Challenges in Provisioning Keys to Smart Objects" by Yoshihiro Ohba and Subir Das
"Challenges and Solutions of Secure Smart Environments" by Eila Ovaska and Antti Evesti
"Research Experiences about Internetworking Mechanisms to Integrate Embedded Wireless Networks into Traditional Networks" by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar
"Scalable Video Coding in Networked Environment" by Naeem Ramzan, Tomas Piatrik, and Ebroul Izquierdo
"Challenges in Opportunistic Networking" by Mikko Pitkaenen and Teemu Kaerkkaeinen
"Position Statement" by Neeli R. Prasad and Sateesh Addepalli
"A Gateway Architecture for Interconnecting Smart Objects to the Internet" by Akbar Rahman, Dorothy Gellert, Dale Seed
"Routing Challenges and Directions for Smart Objects in Future Internet of Things" by T. A. Ramrekha, E. Panaousis, and C. Politis
"6LoWPAN Extension for IPsec" by Shahid Raza, Thiemo Voigt, and Utz Roedig
"Connected Vehicle as Smart Object(s)" by Ryuji Wakikawa
"Problem and possible approach of development and operation of Smart Objects" by Shoichi Sakane
"Connecting Passive RFID Tags to the Internet of Things" by Sandra Dominikus and Joern-Marc Schmidt
"Protocol Profiles for Constrained Devices" by Juergen Schoenwaelde, Tina Tsou, and Behcet Sarikaya
"Multihoming for Sensor Networks" by J. Soininen
"Internet Objects for Building Control" by Peter van der Stok and Nicolas Riou
"Optimal information placement for Smart Objects" by Shigeya Suzuki
"Multi-National Initiative for Cloud Computing in Health Care (MUNICH)" by Christoph Thuemmler
"The time of the hourglass has elapsed" by Laurent Toutain, Nicolas Montavont, and Dominique Barthel
"Sensor and Actuator Resource Architecture" by Vlasios Tsiatsis, Jan Hoeller, and Richard Gold
"IT'S NOT EASY BEING 'GREEN'" by Margaret Wasserman
"Trustworthy Wireless Industrial Sensor Networks" by Markus Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis Olivereau, and Oualha Nouha
"Interconnecting smart objects through an overlay networking architecture" by Anastasios Zafeiropoulos, Athanassios Liakopoulos and Panagiotis Gouvas
"Building trust among Virtual Interconnecting Smart Objects in the Future Internet" by Theodore Zahariadic, Helen C. Leligou, Panagiotis Trakadas, and Mischa Dohler
"Experience and Challenges of Integrating Smart Devices with the Mobile Internet" by Zhen Cao and Hui Deng
"The 'mesh-under' versus 'route over' debate in IP Smart Objects Networks" by JP. Vasseur and Jonathan Hui
"Identification and Authentication of IoT Devices" by Alper Yegin
"Security Challenges For the Internet of Things" by Tim Polk and Sean Turner
"Application Communications Requirements for 'The Internet of Things'" by Bob Dolin
"Interoperability Concerns in the Internet of Things" by Jari Arkko
"Privacy in Ubiquitous Computing" by Ivan Gudymenko and Katrin Borcea-Pfitzmann
"The 10 Laws of Smart Object Security Design" by Hannes Tschofenig and Bernard Aboba
"Position Paper on 'In-Network Object Cloud' Architecture and Design Goals" by Alex Galis and Stuart Clayman
"Temptations and Difficulties of Protocols for Smart Objects and the Internet" by Alexandru Petrescu
"The Internet of Things - Challenge for a New Architecture from Problems" by Gyu Myoung Lee and Noel Crespi
"Garrulity and Fluff" by Carsten Bormann and Klaus Hartke

Appendix D. Workshop Participants 💜

We'd like to thank the following workshop participants for attending the workshop 🫶

Adrian Farrel
Akbar Rahman
Alissa Cooper
Alper Yegin
Anastasios Zafeiropoulos
Anders Brandt
Angelo P. Castellani
Antonio F. G. Skarmeta
Antonio Jara
Arvind Ramrekha
Behcet Sarikaya
Bernard Aboba
Bruce Nordman
Carsten Bormann
Cullen Jennings
Daniel Barisic
Dave Thaler
Davide Barbieri
Diego Casado Mansilla
Dirk Kutscher
Dominique Barthel
Dorothy Gellert
Elwyn Davis
Emmanuel Baccelli
Fred Baker
Guido Moritz
Gyu Myoung Lee
Hannes Tschofenig
Hui Deng
Ivan Gudymenko
Jaacan Martinez
Jari Arkko
Jaroslav Meduna
Jeff Burke
Johanna Nieminen
Jonathan Hui
Jonne Soininen
Jouni Korhonen
JP. Vasseur
Karel Pavlata
Klaus Hartke
Lars Eggert
Laura Gheorghe
Laurent Toutain
Lukas Kencl
Marcelo Bagnulo
Marco Valente
Margaret Wasserman
Markus Isomaki
Markus Wehner
Masanobu Katagi
Mathilde Durvy
Mehmet Ersue
Mikko Pitkaenen
Milan Simek
Neeli R. Prasad
Nicolas Dejean
Ning Kong
Pascal Thubert
Paulo Mendes
Pete Resnick
Peter van der Stok
Ralph Droms
Rene Hummen
Ross Callon
Ruediger Martin
Russ Housley
Ryota Ishibashi
Ryuji Wakikawa
Samita Chakrabarti
Sandra Dominikus
Sean Shen
Sean Turner
Shahid Raza
Shoichi Sakane
Spencer Dawkins
Stephan Haller
Stephen Farrell
Stewart Bryant
Subir Das
Suresh Krishnan
Tea Sang Choi
Tero Kivinen
Theodore Zahariadis
Thomas Clausen
Tim Polk
Tina Tsou
Tsuyoshi Momose
Vladimir Cervenka
Wassim Haddad
Woojik Chun
Zach Shelby

Appendix E. IAB Members at the Time of Approval 👑

These were the IAB members when the document was approved 🌈

Bernard Aboba
Ross Callon
Alissa Cooper
Spencer Dawkins
Joel Halpern
Russ Housley
David Kessens
Olaf Kolkman
Danny McPherson
Jon Peterson
Andrei Robachevsky
Dave Thaler
Hannes Tschofenig

Authors' Addresses 🦋

Here are the contact details for the authors, exactly as they appear in the original:

Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo  02600
Finland

Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI:   http://www.tschofenig.priv.at


Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net


Internet Architecture Board

EMail: iab@iab.org

📦 where this page comes from

ietf: rfc6574 2012-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms