RFC 5826
Home Automation Routing Requirements in Low-Power and Lossy Networks
RFC 5826: Home Automation Routing Requirements in Low-Power and Lossy Networks 🏡✨
Okay bestie, this is RFC 5826, published by the IETF in April 2010 🎀. The authors are A. Brandt and J. Buron (both at Sigma Designs, Inc.) and G. Porcu (Telecom Italia) 💅. It's Informational, so it's not a standards track spec, and its ISSN is 2070-1721 🌸. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🙌.
Abstract 🦋
Okay so this doc lays out the routing requirements for home control and automation stuff running over ROLL (Routing Over Low power and Lossy) networks 🏠. Soon, homes are gonna be FULL of wireless devices for all kinds of jobs 😭. Think actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control) 💖. Since these little guys only have a limited radio range, they usually need routing to get anywhere 📡. The whole point of this doc is to spell out what routing has to do for these constrained devices in a home-control and automation setup ✨.
Status of This Memo 📜
This document is not an Internet Standards Track specification; it is published for informational purposes 🧚.
This document is a product of the Internet Engineering Task Force (IETF) 🎀. It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🫶. Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 💅.
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc5286 🌈.
Copyright Notice ©️
Copyright (c) 2010 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) as in effect on the date of publication of this document. Please read these carefully, because they spell out your rights and restrictions for this document 🧾. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🔥.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without getting an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 🙈.
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................6
2. Home Automation Applications ....................................6
2.1. Lighting Application in Action .............................6
2.2. Energy Conservation and Optimizing Energy Consumption ......6
2.3. Moving a Remote Control Around .............................7
2.4. Adding a New Module to the System ..........................7
2.5. Controlling Battery-Operated Window Shades .................8
2.6. Remote Video Surveillance ..................................8
2.7. Healthcare .................................................9
2.7.1. At-Home Health Reporting ...........................10
2.7.2. At-Home Health Monitoring ..........................10
2.8. Alarm Systems .............................................10
3. Unique Routing Requirements of Home Automation Applications ....11
3.1. Constraint-Based Routing ..................................12
3.2. Support of Mobility .......................................12
3.3. Scalability ...............................................13
3.4. Convergence Time ..........................................13
3.5. Manageability .............................................14
3.6. Stability .................................................14
4. Traffic Pattern ................................................14
5. Security Considerations ........................................15
6. Acknowledgments ................................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................171. Introduction ✨
Okay so this doc is all about home control and automation requirements for ROLL (Routing Over Low power and Lossy) networks 🏡. Soon, a bunch of homes are gonna have TONS of wireless devices doing all sorts of things 😭. Examples are actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers 💖. Basic home-control modules like wall switches and plug-in modules can level up into a full home automation solution when there's an IP-enabled app responding to events from wall switches, motion sensors, light sensors, rain sensors, and so on 🪄.
Network nodes can be sensors and actuators at the same time 🔥. Like, a wall switch meant to replace an existing one in a home 💅. Its push buttons can generate events for a controller node or to activate other actuator nodes, and at the same time, a built-in relay can act as an actuator for a controller or for other remote sensors 🧚.
Since ROLL nodes only cover a limited radio range, routing is often required 📡. These devices are usually super constrained when it comes to resources like battery and memory, and they operate in unstable environments 😩. People walking around the house, a door opening or closing, or someone starting a microwave oven can all mess with the reception of weak radio signals 🍓. Reflection and absorption can make a reliable radio link turn unreliable for a while, and then become usable again. That's where the term "lossy" comes from 🙈. All traffic in a ROLL network is carried as IPv6 packets 💜.
The connected home area is very consumer oriented, so devices are super cost sensitive 💸. That leads to resource-constrained environments with slow CPUs and small memory footprints 🥺. Nodes also have to be physically small, which limits how big the battery can be, and so the battery capacity is limited too 🔋. So it's common for battery-operated, sensor-style nodes to shut down their radio and CPU resources most of the time 😴. The radio tends to use the same power for listening as it does for transmitting 📻.
This doc focuses on radio-based wireless networks, but home-automation networks can also run over a bunch of other links, like IEEE 802.15.4, Bluetooth, Low-Power WiFi, and wired or other low-power PLC (Power-Line Communication) links 🦋. A lot of these low-power link technologies have similar characteristics to low-power wireless, so this doc should be treated as applying equally to all of them ✨.
Section 2 describes a few typical use cases for home automation applications 🎀. Section 3 covers the routing requirements for networks made of these constrained devices in a home network environment 💖. These requirements may overlap with requirements derived from other application-specific routing requirements presented in [BUILDING-REQS], [RFC5673], and [RFC5548] 📚.
A full list of requirements documents can be found in Section 7 🫶.
1.1. Terminology 🧠
Here's the glossary, copied exactly as written so nothing gets lost in translation 💅:
ROLL: Routing Over Low-power and Lossy networks. A ROLL
node may be classified as a sensor, actuator, or
controller.
Actuator: Network node that performs some physical action.
Dimmers and relays are examples of actuators. If
sufficiently powered, actuator nodes may participate
in routing network messages.
Border router: Infrastructure device that connects a ROLL network to
the Internet or some backbone network.
Channel: Radio frequency band used to carry network packets.
Controller: Network node that controls actuators. Control
decisions may be based on sensor readings, sensor
events, scheduled actions, or incoming commands from
the Internet or other backbone networks. If
sufficiently powered, controller nodes may participate
in routing network messages.
Downstream: Data direction traveling from a Local Area Network
(LAN) to a Personal Area Network (PAN) device.
DR: Demand-Response. The mechanism of users adjusting
their power consumption in response to the actual
pricing of power.
DSM: Demand-Side Management. Process allowing power
utilities to enable and disable loads in consumer
premises. Where DR relies on voluntary action from
users, DSM may be based on enrollment in a formal
program.
LLNs: Low-Power and Lossy Networks.
LAN: Local Area Network.
PAN: Personal Area Network. A geographically limited
wireless network based on, e.g., 802.15.4 or Z-Wave
radio.
PDA Personal Digital Assistant. A small, handheld
computer.
PLC Power-Line Communication.
RAM Random Access Memory.
Sensor: Network node that measures some physical parameter
and/or detects an event. The sensor may generate a
trap message to notify a controller or directly
activate an actuator. If sufficiently powered, sensor
nodes may participate in routing network messages.
Upstream: Data direction traveling from a PAN to a LAN device.For the full list of ROLL terms, check out the ROLL terminology reference document [ROLL-TERM], since that's what the IETF ROLL WG uses 🤓.
1.2. Requirements Language 🫶
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 RFC 2119 [RFC2119] 💖.
2. Home Automation Applications ✨
okay so home automation is its own special little world 🏡 with a unique set of requirements 💅. Back in the day these apps ran on wired networks or power-line communication (PLC), but wireless options have shown up, so upgrading existing homes is way easier now 🫶.
To set up the requirements talk in Section 3, here are a few typical use cases 🎀. New apps are popping up super fast, so this list is not trying to be exhaustive 💀. Most home automation apps run some kind of command/response protocol 🤖, and the command can come from several places 🌸.
2.1. Lighting Application in Action 💡
A lamp can be switched on by a wall switch, but also by a movement sensor 🏃. The wall-switch module might itself be a push-button sensor and an actuator at the same time 🔘. This is often the case when upgrading existing homes, since the existing wiring isn't set up for automation 🧵.
One event can make a bunch of actuators activate at once 💥.
Think of it like an electronic car key 🔑: a house owner can trigger the "leaving home" function from an electronic house key, a mobile phone, etc. For the visual vibe ✨, all lights should turn off at the same time, or at least it should appear to happen at the same time 😌.
2.2. Energy Conservation and Optimizing Energy Consumption ⚡
To save energy 🌍, air conditioning, central heating, window shades, etc. can be controlled by timers, motion sensors, or remotely over the Internet or cell 📱. Central heating may also drop to a reduced temperature at night 🌙.
The power grid sometimes has more wind-generated power than it needs 🌬️, typically during night hours.
When electricity demand is higher than what's available, appliances like air conditioning, climate-control systems, washing machines, etc. can be turned off so they don't overload the power grid 🙅♀️.
This is known as Demand-Side Management (DSM) 📊. Remote control of household appliances is a perfect fit for this 🎯.
The start/stop decisions for appliances can also be guided by dynamic power pricing info from electricity utility companies 💸. This method, called Demand-Response (DR), works by motivating users with pricing, bonus points, etc. 🏆 For example, the washing machine and dishwasher might just as well run while power is cheap 🧼. The electric car should also charge its batteries on cheap power 🚗⚡.
To get real electricity savings 💰, the energy monitoring app must guarantee that the power consumption of the ROLL devices is much lower than that of the appliance itself.
Most of these appliances are mains powered, so they're ideal for providing reliable, always-on routing resources 🔌. Battery-powered nodes, by comparison, are constrained routing resources and may only provide reliable routing under some circumstances 🔋.
2.3. Moving a Remote Control Around 🎮
A remote control is a classic example of a mobile device in a home automation network 📺. A fancy one might dim the dining room light while you eat, then turn up the music while you do the dishes in the kitchen 🍽️. Reaction must appear to be instant (within a few hundred milliseconds) even when the remote has moved to a new location ⚡. The remote may talk to either a central home automation controller or directly to the lamps and the media center 🎬.
2.4. Adding a New Module to the System 🧩
Small, low-cost modules may have no user interface except a single button 🔘. So an automated inclusion process is needed for controllers to find new modules 🔍. Inclusion covers detecting neighbors and assigning a unique node ID 🪪. Inclusion should be completed within a few seconds ⏱️.
For ease of use in a consumer space like home control 🏠, nodes may be included without typing in special codes first. One way to balance security and convenience is to block inclusion during normal operation, explicitly enable inclusion support just before adding a new module, and disable it again right after adding it 🔐.
For security considerations, see Section 5 🛡️.
If assignment of unique addresses is done by a central controller, it must be possible to route the inclusion request from the joining node to the central controller before the joining node has been included in the network 🗺️.
2.5. Controlling Battery-Operated Window Shades 🪟
In homes, window shades are often battery-powered since there's no mains power over the windows 🔋. To conserve battery, the actuator node sleeps most of the time 😴. A controller sending commands to a sleeping actuator node via ROLL devices will have no trouble getting the packet to the nearest powered router, but that router may experience a delay until the next wake-up time before the command can be delivered ⏰.
2.6. Remote Video Surveillance 📹
Remote video surveillance is a pretty classic home networking app 🎥. The end-user can get a video stream from a web cam reached via the Internet. The stream may be triggered by the end-user after an alarm from a sensor (movement or smoke detector), or the user just wants to check the home status via video 👀.
In the former case, there's more than likely going to be some inter-device communication 🤝: when movement is detected, the movement sensor may send a request to the light controller to turn on the lights, and to the Web Cam to start a video stream that then goes to the end-user's cell phone or Personal Digital Assistant (PDA) via the Internet 📲.
Unlike other apps, e.g., industrial sensors, where data mostly flows from a sensor to a sink and back, this scenario involves direct inter-device communication between ROLL devices 🔁.
2.7. Healthcare 🩺
By adding communication to devices, patients and elderly citizens may be able to do simple measurements at home 💗.
Thanks to online devices, a doctor can keep an eye on a patient's health and receive warnings if a new trend is spotted by automated filters 👩⚕️.
Fine-grained, daily measurements presented in proper ways may let the doctor establish a more precise diagnosis 🔬.
These apps may be wearable products that frequently do a measurement and automatically deliver the result to a data sink, either locally or over the Internet ⌚.
Apps in this category are referred to as at-home health reporting 📝. Whether measurements are done at a fixed interval or manually activated, all processing is left to the receiving data sink 🧠.
A more active category may send an alarm if some alarm condition is triggered 🚨. This category is referred to as at-home health monitoring. Measurements are interpreted in the device and may cause reporting of an event if an alarm is triggered.
Many implementations may overlap both categories 💞.
Since wireless and battery-operated systems may never reach 100% guaranteed operational time, healthcare and security systems will need a management layer implementing alarm mechanisms for low battery, report activity, etc. 🔋⚠️
For instance, if a blood pressure sensor did not report a new measurement, say five minutes after the scheduled time, some responsible person must be notified 📞.
The structure and performance of such a management layer is outside the scope of the routing requirements listed in this document 📄.
2.7.1. At-Home Health Reporting 📝
Applications might include:
- Temperature
- Weight
- Blood pressure
- Insulin level
Measurements may be stored for long-term statistics 📈. At the same time, a critically high blood pressure may cause the generation of an alarm report. Refer to Section 2.7.2 👀.
To avoid a high number of request messages 🙅, nodes may be configured to autonomously do a measurement and send a report in intervals ⏲️.
2.7.2. At-Home Health Monitoring 🚑
An alarm event may become active, e.g., if the measured blood pressure exceeds a threshold or if a person falls to the ground 😱. Alarm conditions must be reported with the highest priority and timeliness 🏆.
Applications might include:
- Temperature
- Weight
- Blood pressure
- Insulin level
- Electrocardiogram (ECG)
- Position tracker
2.8. Alarm Systems 🚨
A home security alarm system is made up of various sensors (vibration, fire, carbon monoxide, door/window, glass-break, presence, panic button, etc.) 🕵️.
Some smoke alarms are battery powered and mounted in a high place 🪜. Battery-powered safety devices should only be used for routing if no other alternatives exist, to avoid draining the battery 🔋. A smoke alarm with a drained battery doesn't provide a lot of safety 💀. Also, it may be inconvenient to change the batteries in a smoke alarm 🙄.
Alarm system applications may have both a synchronous and an asynchronous behavior 🔄; i.e., they may be periodically queried by a central control application (e.g., for a periodical refreshment of the network state) or send a message to the control application on their own initiative 📣.
When a node (or a group of nodes) identifies a risk situation (e.g., intrusion, smoke, fire), it sends an alarm message to a central controller 🚨. That controller could autonomously forward it via the Internet or interact with other network nodes (e.g., try to obtain more detailed information or ask other nodes close to the alarm event) 🕸️.
Finally, routing via battery-powered nodes may be very slow if the nodes are sleeping most of the time (they could appear unresponsive to the alarm detection) 😴. To ensure fast message delivery and avoid battery drain, routing should be avoided via sleeping devices 🛑.
3. Unique Routing Requirements of Home Automation Applications ✨
okay so home automation apps have a bunch of specific routing needs, because of the whole home networking vibe and how the system has to feel to the person using it 🏠💖
here's the tea on which use cases connect to which requirements (it's in a table because we love a good grid 🎀):
+------------------------------+-----------------------------+
| Use case | Requirement |
+------------------------------+-----------------------------+
|2.1. Lighting Application in |3.2. Support of Mobility |
|Action |3.3. Scalability |
+------------------------------+-----------------------------+
|2.2. Energy Conservation and |3.1. Constraint-Based Routing|
|Optimizing Energy Consumption | |
+------------------------------+-----------------------------+
|2.3. Moving a Remote Control |3.2. Support of Mobility |
|Around |3.4. Convergence Time |
+------------------------------+-----------------------------+
|2.4. Adding a New Module to |3.4. Convergence Time |
|the System |3.5. Manageability |
+------------------------------+-----------------------------+
|2.7. Healthcare |3.1. Constraint-Based Routing|
| |3.2. Support of Mobility |
| |3.4. Convergence Time |
+------------------------------+-----------------------------+
|2.8. Alarm Systems |3.3. Scalability |
| |3.4. Convergence Time |
+------------------------------+-----------------------------+3.1. Constraint-Based Routing 🔋
okay this one is giving battery life drama 😭 for convenience and low running costs, consumer products have to keep their power use super low so the battery lasts forever. one result is that RAM is limited, and it may even get powered down, so only a few 100 bytes of RAM are still alive while the device is sleeping 💤
battery-powered devices are amazing because they cut installation costs, and they let you install stuff even where there are no main power lines 🦋 but, to be cost effective and efficient, these devices have to maximize their sleep phase with a duty cycle lower than 1%. iconic restraint, honestly 👑
some devices only wake up when something happens, like a push button 🔘
simple battery-powered nodes, like movement sensors on garage doors and rain sensors, may not be able to help with routing at all 🙈 depending on the node type, the node never listens, listens rarely, or only makes contact on demand with a pre-configured target node. trying to talk to these nodes may take a long time before you get a response 😩
other battery-powered nodes can participate in routing though 🫶 the routing protocol SHOULD route via mains-powered nodes if possible, and it MUST support constraint-based routing that takes into account node properties (CPU, memory, level of energy, sleep intervals, safety/convenience of changing battery). the main character energy here is picking the right node for the job 💅
3.2. Support of Mobility 🏃♀️
in a home, most devices are fixed, but there's still a whole variety of mobile devices. like, a remote control is extremely likely to move around 📱 wearable healthcare devices are another example of mobile devices 💜
healthcare devices that deliver measurement results can handle route discovery times measured in seconds 🩺 but a remote control looks totally unresponsive if it takes more than 0.5 seconds to, e.g., pause the music. not it, pausing a song and having to wait 🙃
on rarer occasions, receiving nodes may also move around 🧚 examples include a safety-off switch in a clothes iron, a vacuum cleaner robot, or the wireless chime of a doorbell set 🔔
refer to Section 3.4 for routing protocol convergence times 📌
a non-responsive node can happen for three reasons: 1) a failure in the node, 2) a failed link on the path to the node, or 3) a moved node. in the first two cases, the node can be expected to show up at roughly the same spot in the network, but in the last case it can return anywhere in the network 🌍
3.3. Scalability 📈
if you look at how many wall switches, power outlets, sensors of all kinds, video equipment, and so on are in a modern house, it's actually pretty realistic that hundreds of devices could form a home-automation network in a fully loaded "smart" home 🏡✨ and a big chunk of those could be low-power devices 🔋 moving toward professional-building automation, the number of devices could be in the order of several thousands. the scale is unreal 😳
the routing protocol needs to support a basic home deployment, so it MUST be able to support at least 250 devices in the network 🎀 furthermore, the protocol SHOULD be extensible to support more sophisticated and future deployments with a larger number of devices. future-proofing is everything 🔮
3.4. Convergence Time ⏱️
a wireless home automation network is subject to all kinds of instabilities, like signal strength variation, moving people, and that sort of thing 🌀
the following convergence time requirements apply, measured from the transmission of a packet 📦
the routing protocol MUST converge within 0.5 seconds if no nodes have moved (see Section 3.2 for the motivation) ⚡
the routing protocol MUST converge within four seconds if nodes have moved, so connectivity is re-established within a time that a human operator would find tolerable, like when you're moving a remote control unit 🕐
in both cases, "converge" means "the originator node has received a response from the destination node" 💌 these convergence time requirements apply to a home control network environment of up to 250 nodes with up to four repeating nodes between source and destination 🧩
3.5. Manageability 🛠️
auto-configuration is of the utmost importance here 😤 most end-users won't have the expertise or skills to do advanced configuration and troubleshooting, so the routing protocol designed for home-automation networks MUST provide a set of features, including zero-configuration of the routing protocol for a new node added to the network. from a routing perspective, zero-configuration means a node can obtain an address and join the network on its own, almost without human intervention 🤖💕
3.6. Stability 🧘♀️
if a node fails often compared to the rest of the network, that node SHOULD NOT be the first choice for routing traffic 🚫 we don't pick the flaky friend for the group project 💀
4. Traffic Pattern 🚦
depending on the design philosophy of the home network, wall switches might be configured to directly control individual lamps. or, alternatively, all the wall switches send control commands to a central lighting control computer, which then sends out control commands to the relevant devices 💡
in a distributed system, the traffic tends to be multipoint-to-multipoint 🕸️ in a centralized system, it's a mix of multipoint-to-point and point-to-multipoint. two vibes, both valid 💜
wall switches only generate traffic when they're activated, which typically happens from one to ten times per hour 💡
remote controls have a similar transmit pattern to wall switches, but they may get activated more frequently in some deployments 📱
temperature/air and pressure/rain sensors send frames when queried by the user, or they can be preconfigured to send measurements at fixed intervals (typically minutes) 🌡️ motion sensors typically send a frame when motion is first detected, and another frame when an idle period with no movement has elapsed 🏃♀️ the highest transmission frequency depends on the idle period used in the sensor. and sometimes a timer triggers a frame transmission when an extended period without status change has elapsed ⏰
all frames sent in the examples above are quite short, typically less than five bytes of payload 🤏 lost frames and interference from other transmitters may lead to retransmissions 📡 in all cases, acknowledgment frames with a size of a few bytes are used ✅
5. Security Considerations 🔐
okay bestie, security is where things get SERIOUS but also where I get obsessed 😭🫶. So as is the case with every network, LLNs are exposed to routing security threats that need to be addressed 💀. The wireless and distributed nature of these networks increases the spectrum of potential routing security threats 🦋. And it gets worse, because the resource constraints of the nodes basically stop resource-intensive routing security approaches from being deployed 🙈. So a viable routing security approach SHOULD be sufficiently lightweight that it may be implemented across all nodes in a LLN ✨. These issues need special attention during the design process so that a commercially attractive deployment is actually possible 💅.
An attacker can snoop, replay, or originate arbitrary messages to a node in an attempt to manipulate or disable the routing function 👀. Not me… 😤
To mitigate this, the LLN MUST be able to authenticate a new node before it's allowed to participate in the routing decision process 🔥. The routing protocol MUST support message integrity 🫶.
Another example of routing security issues is the abnormal behavior of nodes that act egoistic, like not obeying network rules or forwarding no packets or false packets 💀. Literally the worst roommate energy 🙃.
Other important issues can show up with denial-of-service (DoS) attacks, malicious address space allocations, advertisement of variable addresses, a wrong neighborhood, and so on 😭. The routing protocol(s) SHOULD support defense against DoS attacks and other attempts to maliciously or inadvertently make the routing mechanisms over-consume the limited resources of LLN nodes 🚨. Like, for example, by constructing forwarding loops or causing excessive routing protocol overhead traffic 🌀.
The self-configuration and self-organization that make LLNs so desirable also bring in extra routing security considerations 🎀. Mechanisms MUST be in place to deny any node that tries to take malicious advantage of self-configuration and self-organization procedures 🚫. These attacks might try to cause DoS, drain the energy of power-constrained devices, or hijack the routing mechanism 🔋💀. A node MUST authenticate itself to a trusted node that is already associated with the LLN before the former can take part in self-configuration or self-organization 🔑. A node that has already authenticated and associated with the LLN MUST deny, to the maximum extent possible, the allocation of resources to any unauthenticated peer 🛡️. The routing protocol(s) MUST deny service to any node that has not clearly established trust with the HC-LLN 🙅♀️.
In a home-control environment, it's considered unlikely that a network is constantly being snooped, and at the same time ease of use is important 🏠. So the network key MAY be exposed for short periods during inclusion of new nodes 🔓. Lowkey a fair trade ✨.
Electronic door locks and other critical applications SHOULD apply end-to-end application security on top of the network transport security 🚪🔐. Door locks are NOT the place to cut corners, periodt 💅.
If connected to a backbone network, the LLN SHOULD be capable of limiting the resources utilized by nodes in said backbone network so as not to be vulnerable to DoS 🌐. This should typically be handled by border routers providing access from a backbone network to resources in the LLN 🧚.
With low-computation power and scarce energy resources, LLN nodes may not be able to resist any attack from high-power malicious nodes (e.g., laptops and strong radios) 💻😩. However, the amount of damage done to the whole network SHOULD be commensurate with the number of nodes physically compromised 📉. For example, an intruder taking control over a single node SHOULD NOT be able to completely deny service to the whole network 🙅♀️💜.
In general, the routing protocol(s) SHOULD support the implementation of routing security best practices across the LLN 🌈. That implementation ought to include defense against, for example, eavesdropping, replay, message insertion, modification, and man-in-the-middle attacks 👑.
The choice of routing security solutions will have an impact on the routing protocol(s) 🧠. So routing protocol(s) proposed in the context of LLNs MUST support authentication and integrity measures and SHOULD support confidentiality (routing security) measures 🔒✨.
6. Acknowledgments 🌸
J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler, and Massimo Maggiorotti are gratefully acknowledged for their contributions to this document 🫶💖.
7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.7.2. Informative References
[BUILDING-REQS] Martocci, J., Ed., De Mil, P., Vermeylen, W., and N.
Riou, "Building Automation Routing Requirements in
Low Power and Lossy Networks", Work in Progress,
January 2010.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed.,
and D. Barthel, Ed., "Routing Requirements for Urban
Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-
Power and Lossy Networks", RFC 5673, October 2009.
[ROLL-TERM] Vasseur, JP. "Terminology in Low power And Lossy
Networks", Work in Progress, October 2009.Authors' Addresses
Anders Brandt
Sigma Designs, Inc.
Emdrupvej 26
Copenhagen, DK-2100
Denmark
EMail: abr@sdesigns.dk
Jakob Buron
Sigma Designs, Inc.
Emdrupvej 26
Copenhagen, DK-2100
Denmark
EMail: jbu@sdesigns.dk
Giorgio Porcu
Telecom Italia
Piazza degli Affari, 2
20123 Milan
Italy
EMail: gporcu@gmail.com📦 where this page comes from
- ietf: rfc5826 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms