doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc6606.txt b/doc/rfc/rfc6606.txt
new file mode 100644
index 0000000..add4330
--- /dev/null
+++ b/doc/rfc/rfc6606.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            E. Kim
+Request for Comments: 6606                                          ETRI
+Category: Informational                                        D. Kaspar
+ISSN: 2070-1721                               Simula Research Laboratory
+                                                                C. Gomez
+                     Universitat Politecnica de Catalunya/Fundacio i2CAT
+                                                              C. Bormann
+                                                 Universitaet Bremen TZI
+                                                                May 2012
+
+
+                 Problem Statement and Requirements for
+  IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing
+
+Abstract
+
+   IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are
+   formed by devices that are compatible with the IEEE 802.15.4
+   standard.  However, neither the IEEE 802.15.4 standard nor the
+   6LoWPAN format specification defines how mesh topologies could be
+   obtained and maintained.  Thus, it should be considered how 6LoWPAN
+   formation and multi-hop routing could be supported.
+
+   This document provides the problem statement and design space for
+   6LoWPAN routing.  It defines the routing requirements for 6LoWPANs,
+   considering the low-power and other particular characteristics of the
+   devices and links.  The purpose of this document is not to recommend
+   specific solutions but to provide general, layer-agnostic guidelines
+   about the design of 6LoWPAN routing that can lead to further analysis
+   and protocol design.  This document is intended as input to groups
+   working on routing protocols relevant to 6LoWPANs, such as the IETF
+   ROLL WG.
+
+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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6606.
+
+
+
+Kim, et al.                   Informational                     [Page 1]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Problem Statement ...............................................2
+   2. Terminology .....................................................5
+   3. Design Space ....................................................5
+      3.1. Reference Network Model ....................................6
+   4. Scenario Considerations and Parameters for 6LoWPAN Routing ......8
+   5. 6LoWPAN Routing Requirements ...................................13
+      5.1. Support of 6LoWPAN Device Properties ......................13
+      5.2. Support of 6LoWPAN Link Properties ........................15
+      5.3. Support of 6LoWPAN Characteristics ........................18
+      5.4. Support of Security .......................................22
+      5.5. Support of Mesh-Under Forwarding ..........................25
+      5.6. Support of Management .....................................26
+   6. Security Considerations ........................................27
+   7. Acknowledgments ................................................27
+   8. References .....................................................28
+      8.1. Normative References ......................................28
+      8.2. Informative References ....................................29
+
+1.  Problem Statement
+
+   6LoWPANs are formed by devices that are compatible with the
+   IEEE 802.15.4 standard [IEEE802.15.4].  Most of the LoWPAN devices
+   are distinguished by their low bandwidth, short range, scarce memory
+   capacity, limited processing capability, and other attributes of
+   inexpensive hardware.  The characteristics of nodes participating in
+   LoWPANs are assumed to be those described in the 6LoWPAN problem
+   statement [RFC4919], and in the IPv6 over IEEE 802.15.4 document
+   [RFC4944], which has specified how to carry IPv6 packets over
+   IEEE 802.15.4 and similar networks.  Whereas IEEE 802.15.4
+   distinguishes two types of devices called full-function devices
+   (FFDs) and reduced-function devices (RFDs), this distinction is based
+
+
+
+Kim, et al.                   Informational                     [Page 2]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   on some features of the Medium Access Control (MAC) layer that are
+   not always in use.  Hence, the distinction is not made in this
+   document.  Nevertheless, some 6LoWPAN nodes may limit themselves to
+   the role of hosts only, whereas other 6LoWPAN nodes may take part in
+   routing.  This host/ router distinction can correlate with the
+   processing and storage capabilities of the device and power available
+   in a similar way to the idea of RFDs and FFDs.
+
+   IEEE 802.15.4 networks support star and mesh topologies.  However,
+   neither the IEEE 802.15.4 standard nor the 6LoWPAN format
+   specification ([RFC4944]) define how mesh topologies could be
+   obtained and maintained.  Thus, 6LoWPAN formation and multi-hop
+   routing can be supported either below the IP layer (the adaptation
+   layer or Logical Link Control (LLC)) or the IP layer.  (Note that in
+   the IETF, the term "routing" usually, but not always [RFC5556],
+   refers exclusively to the formation of paths and the forwarding at
+   the IP layer.  In this document, we distinguish the layer at which
+   these services are performed by the terms "route-over" and
+   "mesh-under".  See Sections 2 and 3.)  A number of IP routing
+   protocols have been developed in various IETF working groups.
+   However, these existing routing protocols may not satisfy the
+   requirements of multi-hop routing in 6LoWPANs, for the following
+   reasons:
+
+   o  6LoWPAN nodes have special types and roles, such as nodes drawing
+      their power from primary batteries, power-affluent nodes,
+      mains-powered and high-performance gateways, data aggregators,
+      etc.  6LoWPAN routing protocols should support multiple device
+      types and roles.
+
+   o  More stringent requirements apply to LoWPANs, as opposed to
+      higher-performance or non-battery-operated networks.  6LoWPAN
+      nodes are characterized by small memory sizes and low processing
+      power, and they run on very limited power supplied by primary
+      non-rechargeable batteries (a few KB of RAM, a few dozen KB of
+      ROM/ flash memory, and a few MHz of CPU is typical).  A node's
+      lifetime is usually defined by the lifetime of its battery.
+
+   o  Handling sleeping nodes is very critical in LoWPANs, more so than
+      in traditional ad hoc networks.  LoWPAN nodes might stay in sleep
+      mode most of the time.  Taking advantage of appropriate times for
+      transmissions is important for efficient packet forwarding.
+
+   o  Routing in 6LoWPANs might possibly translate to a simpler problem
+      than routing in higher-performance networks.  LoWPANs might be
+      either transit networks or stub networks.  Under the assumption
+      that LoWPANs are never transit networks (as implied by [RFC4944]),
+
+
+
+
+Kim, et al.                   Informational                     [Page 3]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      routing protocols may be drastically simplified.  This document
+      will focus on the requirements for stub networks.  Additional
+      requirements may apply to transit networks.
+
+   o  Routing in LoWPANs might possibly translate to a harder problem
+      than routing in higher-performance networks.  Routing in LoWPANs
+      requires power optimization, stable operation in lossy
+      environments, etc.  These requirements are not easily satisfiable
+      all at once [ROLL-PROTOCOLS].
+
+   These properties create new challenges for the design of routing
+   within LoWPANs.
+
+   The 6LoWPAN problem statement [RFC4919] briefly mentions four
+   requirements for routing protocols:
+
+      (a) low overhead on data packets
+
+      (b) low routing overhead
+
+      (c) minimal memory and computation requirements
+
+      (d) support for sleeping nodes (consideration of battery savings)
+
+   These four high-level requirements describe the basic requirements
+   for 6LoWPAN routing.  Based on the fundamental features of 6LoWPANs,
+   more detailed routing requirements, which can lead to further
+   analysis and protocol design, are presented in this document.
+
+   Considering the problems above, detailed 6LoWPAN routing requirements
+   must be defined.  Application-specific features affect the design of
+   6LoWPAN routing requirements and corresponding solutions.  However,
+   various applications can be profiled by similar technical
+   characteristics, although the related detailed requirements might
+   differ (e.g., a few dozen nodes in a home lighting system need
+   appropriate scalability for the system's applications, while millions
+   of nodes for a highway infrastructure system also need appropriate
+   scalability).
+
+   This routing requirements document states the routing requirements of
+   6LoWPAN applications in general, providing examples for different
+   cases of routing.  It does not imply that a single routing solution
+   will be favorable for all 6LoWPAN applications, and there is no
+   requirement for different routing protocols to run simultaneously.
+
+
+
+
+
+
+
+Kim, et al.                   Informational                     [Page 4]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   Readers are expected to be familiar with all the terms and concepts
+   that are discussed in "IPv6 over Low-Power Wireless Personal Area
+   Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
+   Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4
+   Networks" [RFC4944].
+
+   This specification makes use of the terminology defined in
+   [6LoWPAN-ND].
+
+3.  Design Space
+
+   Apart from a wide variety of conceivable routing algorithms for
+   6LoWPANs, it is possible to perform routing in the IP layer (using a
+   route-over approach) or below IP, as defined by the 6LoWPAN format
+   document [RFC4944] (using the mesh-under approach).  See Figure 1.
+
+   The route-over approach relies on IP routing and therefore supports
+   routing over possibly various types of interconnected links.
+   Note: The ROLL WG is now working on route-over approaches for
+   Low-power and Lossy Networks (LLNs), not specifically for 6LoWPANs.
+   This document focuses on 6LoWPAN-specific requirements; it may be
+   used in conjunction with the more application-oriented requirements
+   defined by the ROLL WG.
+
+   The mesh-under approach performs the multi-hop communication below
+   the IP link.  The most significant consequence of the mesh-under
+   mechanism is that the characteristics of IEEE 802.15.4 directly
+   affect the 6LoWPAN routing mechanisms, including the use of 64-bit
+   (or 16-bit short) link-layer addresses instead of IP addresses.  A
+   6LoWPAN would therefore be seen as a single IP link.
+
+   Most statements in this document consider both the route-over and
+   mesh-under cases.
+
+
+
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                     [Page 5]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   Figure 1 shows the place of 6LoWPAN routing in the entire network
+   stack.
+
+    +---------------------------+  +-----------------------------+
+    |      Application Layer    |  |      Application Layer      |
+    +---------------------------+  +-----------------------------+
+    | Transport Layer (TCP/UDP) |  |  Transport Layer (TCP/UDP)  |
+    +---------------------------+  +-----------------------------+
+    |     Network Layer (IPv6)  |  |  Network       +---------+  |
+    +---------------------------+  |  Layer         | Routing |  |
+    |  6LoWPAN                  |  |  (IPv6)        +---------+  |
+    |  Adaptation               |  +-----------------------------+
+    |  Layer       +----------+ |  |  6LoWPAN Adaptation Layer   |
+    +--------------| Routing* |-+  +-----------------------------+
+    | 802.15.4 MAC +----------+ |  |        802.15.4 MAC         |
+    +---------------------------+  +-----------------------------+
+    |         802.15.4 PHY      |  |        802.15.4 PHY         |
+    +---------------------------+  +-----------------------------+
+     * Here, "Routing" is not equivalent to IP routing,
+       but includes the functionalities of path computation and
+       forwarding under the IP layer.
+       The term "Routing" is used in the figure in order to
+       illustrate which layer handles path computation and
+       packet forwarding in mesh-under as compared to route-over.
+
+    Figure 1: Mesh-Under Routing (Left) and Route-Over Routing (Right)
+
+   In order to avoid packet fragmentation and the overhead for
+   reassembly, routing packets should fit into a single IEEE 802.15.4
+   physical frame, and application data should not be expanded to an
+   extent that they no longer fit.
+
+3.1.  Reference Network Model
+
+   For multi-hop communication in 6LoWPANs, when a route-over mechanism
+   is in use, all routers (i.e., 6LoWPAN Border Routers (6LBRs) and
+   6LoWPAN Routers (6LRs)) perform IP routing within the stub network
+   (see Figure 2).  In this case, the link-local scope covers the set of
+   nodes within symmetric radio range of a node.
+
+   When a LoWPAN follows the mesh-under configuration, the 6LBR is the
+   only IPv6 router in the LoWPAN (see Figure 3).  This means that the
+   IPv6 link-local scope includes all nodes in the LoWPAN.  For this, a
+   mesh-under mechanism MUST be provided to support multi-hop
+   transmission.
+
+
+
+
+
+
+Kim, et al.                   Informational                     [Page 6]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+        h   h
+       /    |                     6LBR: 6LoWPAN Border Router
+   6LBR -- 6LR --- 6LR --- h       6LR: 6LoWPAN Router
+           / \                       h: Host
+          h  6LR --- h
+              |
+             / \
+          6LR - 6LR -- h
+
+                Figure 2: An Example of a Route-Over LoWPAN
+
+
+        h   h
+       /    |                    6LBR: 6LoWPAN Border Router
+   6LBR --- m --- m --- h           m: mesh-under forwarder
+           / \                      h: Host
+          h   m --- h
+              |
+             / \
+            m - m -- h
+
+                Figure 3: An Example of a Mesh-Under LoWPAN
+
+   Note than in both mesh-under and route-over networks, there is no
+   expectation of topologically based address assignment in the 6LoWPAN.
+   Instead, addresses are typically assigned based on the EUI-64
+   addresses assigned at manufacturing time to nodes, or based on a
+   (from a topological point of view) more or less random process
+   assigning 16-bit MAC addresses to individual nodes.  Within a
+   6LoWPAN, there is therefore no opportunity for aggregation or
+   summarization of IPv6 addresses beyond the sharing of (one or more)
+   common prefixes.
+
+   Not all devices that are within radio range of each other need to be
+   part of the same LoWPAN.  When multiple LoWPANs are formed with
+   globally unique IPv6 addresses in the 6LoWPANs, and device (a) of
+   LoWPAN [A] wants to communicate with device (b) of LoWPAN [B], the
+   normal IPv6 mechanisms will be employed.  For route-over, the IPv6
+   address of (b) is set as the destination of the packets, and the
+   devices perform IP routing to the 6LBR for these outgoing packets.
+   For mesh-under, there is one IP hop from device (a) to the 6LBR of
+   [A], no matter how many radio hops they are apart from each other.
+   This, of course, assumes the existence of a mesh-under routing
+   protocol in order to reach the 6LBR.  Note that a default route to
+   the 6LBR could be inserted into the 6LoWPAN routing system for both
+   route-over and mesh-under.
+
+
+
+
+
+Kim, et al.                   Informational                     [Page 7]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+4.  Scenario Considerations and Parameters for 6LoWPAN Routing
+
+   IP-based LoWPAN technology is still in its early stage of
+   development, but the range of conceivable usage scenarios is
+   tremendous.  The numerous possible applications of sensor networks
+   make it obvious that mesh topologies will be prevalent in LoWPAN
+   environments and robust routing will be a necessity for expedient
+   communication.  Research efforts in the area of sensor networking
+   have put forth a large variety of multi-hop routing algorithms
+   [Bulusu].  Most related work focuses on optimizing routing for
+   specific application scenarios, which can be realized using several
+   modes of communication, including the following [Watteyne]:
+
+   o  Flooding (in very small networks)
+
+   o  Hierarchical routing
+
+   o  Geographic routing
+
+   o  Self-organizing coordinate routing
+
+   Depending on the topology of a LoWPAN and the application(s) running
+   over it, different types of routing may be used.  However, this
+   document abstracts from application-specific communication and
+   describes general routing requirements valid for overall routing in
+   LoWPANs.
+
+   The following parameters can be used to describe specific scenarios
+   in which the candidate routing protocols could be evaluated.
+
+   a.  Network Properties:
+
+       *  Number of Devices, Density, and Network Diameter:
+          These parameters usually affect the routing state directly
+          (e.g., the number of entries in a routing table or neighbor
+          list).  Especially in large and dense networks, policies must
+          be applied for discarding "low-quality" and stale routing
+          entries in order to prevent memory overflow.
+
+       *  Connectivity:
+          Due to external factors or programmed disconnections, a LoWPAN
+          can be in several states of connectivity -- anything in the
+          range from "always connected" to "rarely connected".  This
+          poses great challenges to the dynamic discovery of routes
+          across a LoWPAN.
+
+
+
+
+
+
+Kim, et al.                   Informational                     [Page 8]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+       *  Dynamicity (including mobility):
+          Location changes can be induced by unpredictable external
+          factors or by controlled motion, which may in turn cause route
+          changes.  Also, nodes may dynamically be introduced into a
+          LoWPAN and removed from it later.  The routing state and the
+          volume of control messages may heavily depend on the number of
+          moving nodes in a LoWPAN and their speed, as well as how
+          quickly and frequently environmental characteristics
+          influencing radio propagation change.
+
+       *  Deployment:
+          In a LoWPAN, it is possible for nodes to be scattered randomly
+          or to be deployed in an organized manner.  The deployment can
+          occur at once, or as an iterative process, which may also
+          affect the routing state.
+
+       *  Spatial Distribution of Nodes and Gateways:
+          Network connectivity depends on the spatial distribution of
+          the nodes and on other factors, such as device number,
+          density, and transmission range.  For instance, nodes can be
+          placed on a grid, or randomly located in an area (as can be
+          modeled by a two-dimensional Poisson distribution), etc.
+          Assuming a random spatial distribution, an average of 7
+          neighbors per node are required for approximately 95% network
+          connectivity (10 neighbors per node are needed for 99%
+          connectivity) [Kuhn].  In addition, if the LoWPAN is connected
+          to other networks through infrastructure nodes called
+          gateways, the number and spatial distribution of these
+          gateways affect network congestion and available data rate,
+          among other things.
+
+       *  Traffic Patterns, Topology, and Applications:
+          The design of a LoWPAN and the requirements for its
+          application have a big impact on the network topology and the
+          most efficient routing type to be used.  For different traffic
+          patterns (point-to-point, multipoint-to-point, point-to-
+          multipoint) and network architectures, various routing
+          mechanisms have been developed, such as data-centric, event-
+          driven, address-centric, and geographic routing.
+
+       *  Classes of Service:
+          For mixing applications of different criticality on one
+          LoWPAN, support of multiple classes of service may be required
+          in resource-constrained LoWPANs and may require a new routing
+          protocol functionality.
+
+
+
+
+
+
+Kim, et al.                   Informational                     [Page 9]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+       *  Security:
+          LoWPANs may carry sensitive information and require a high
+          level of security support where the availability, integrity,
+          and confidentiality of data are of prime relevance.  Secured
+          messages cause overhead and affect the power consumption of
+          LoWPAN routing protocols.
+
+   b.  Node Parameters:
+
+       *  Processing Speed and Memory Size:
+          These basic parameters define the maximum size of the routing
+          state and the maximum complexity of its processing.  LoWPAN
+          nodes may have different performance characteristics, queuing
+          strategies, and queue buffer sizes.
+
+       *  Power Consumption and Power Source:
+          The number of battery- and mains-powered nodes and their
+          positions in the topology created by them in a LoWPAN affect
+          routing protocols in their selection of paths that optimize
+          network lifetime.
+
+       *  Transmission Range:
+          This parameter affects routing.  For example, a high
+          transmission range may cause a dense network, which in turn
+          results in more direct neighbors of a node, higher
+          connectivity, and a larger routing state.
+
+       *  Traffic Pattern:
+          This parameter affects routing, since highly loaded nodes
+          (either because they are the source of packets to be
+          transmitted or due to forwarding) may contribute to higher
+          delivery delays and may consume more energy than lightly
+          loaded nodes.  This applies to both data packets and routing
+          control messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 10]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   c.  Link Parameters:
+       This section discusses link parameters that apply to
+       IEEE 802.15.4 legacy mode (i.e., not making use of improved
+       modulation schemes).
+
+       *  Throughput:
+          The maximum user data throughput of a bulk data transmission
+          between a single sender and a single receiver through an
+          unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is
+          as follows [Latre]:
+
+          +  16-bit MAC addresses, unreliable mode: 151.6 kbit/s
+
+          +  16-bit MAC addresses, reliable mode: 139.0 kbit/s
+
+          +  64-bit MAC addresses, unreliable mode: 135.6 kbit/s
+
+          +  64-bit MAC addresses, reliable mode: 124.4 kbit/s
+
+          Throughput for the 915 MHz band is as follows:
+
+          +  16-bit MAC addresses, unreliable mode: 31.1 kbit/s
+
+          +  16-bit MAC addresses, reliable mode: 28.6 kbit/s
+
+          +  64-bit MAC addresses, unreliable mode: 27.8 kbit/s
+
+          +  64-bit MAC addresses, reliable mode: 25.6 kbit/s
+
+          Throughput for the 868 MHz band is as follows:
+
+          +  16-bit MAC addresses, unreliable mode: 15.5 kbit/s
+
+          +  16-bit MAC addresses, reliable mode: 14.3 kbit/s
+
+          +  64-bit MAC addresses, unreliable mode: 13.9 kbit/s
+
+          +  64-bit MAC addresses, reliable mode: 12.8 kbit/s
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 11]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+       *  Latency:
+          Latency ranges -- depending on payload size -- of a frame
+          transmission between a single sender and a single receiver
+          through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal
+          conditions are as shown below [Latre].  For unreliable mode,
+          the actual latency is provided.  For reliable mode, the round-
+          trip time, including transmission of a Layer-2 acknowledgment,
+          is provided:
+
+          +  16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms]
+
+          +  16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms]
+
+          +  64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms]
+
+          +  64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms]
+
+          Latency ranges for the 915 MHz band are as follows:
+
+          +  16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms]
+
+          +  16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms]
+
+          +  64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms]
+
+          +  64-bit MAC addresses, reliable mode: [11.45 ms, 31.82 ms]
+
+          Latency ranges for the 868 MHz band are as follows:
+
+          +  16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms]
+
+          +  16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms]
+
+          +  64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms]
+
+          +  64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms]
+
+   Note that some of the parameters presented in this section may be
+   used as link or node evaluation metrics.  However, multi-criteria
+   routing may be too expensive for 6LoWPAN nodes.  Rather, various
+   single-criteria metrics are available and can be selected to suit the
+   environment or application.
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 12]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+5.  6LoWPAN Routing Requirements
+
+   This section defines a list of requirements for 6LoWPAN routing.  An
+   important design property specific to low-power networks is that
+   LoWPANs have to support multiple device types and roles, such as
+
+   o  host nodes drawing their power from primary batteries or using
+      energy harvesting (sometimes called "power-constrained nodes")
+
+   o  mains-powered host nodes (an example of what we call "power-
+      affluent nodes")
+
+   o  power-affluent (but not necessarily mains-powered) high-
+      performance gateway(s)
+
+   o  nodes with various functionality (data aggregators, relays, local
+      manager/coordinators, etc.)
+
+   Due to these different device types and roles, LoWPANs need to
+   consider the following two primary attributes:
+
+   o  Power conservation: some devices are mains-powered, but many are
+      battery-operated and need to last several months to a few years
+      with a single AA battery.  Many devices are mains-powered most of
+      the time but still need to function on batteries for possibly
+      extended periods (e.g., on a construction site before building
+      power is switched on for the first time).
+
+   o  Low performance: tiny devices, small memory sizes, low-performance
+      processors, low bandwidth, high loss rates, etc.
+
+   These fundamental attributes of LoWPANs affect the design of routing
+   solutions.  Whether existing routing specifications are simplified
+   and modified, or new solutions are introduced in order to fit the
+   low-power requirements of LoWPANs, they need to meet the requirements
+   described below.
+
+5.1.  Support of 6LoWPAN Device Properties
+
+   The general objectives listed in this section should be met by
+   6LoWPAN routing protocols.  The importance of each requirement is
+   dependent on what node type the protocol is running on and what the
+   role of the node is.  The following requirements consider the
+   presence of battery-powered nodes in LoWPANs.
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 13]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   [R01] 6LoWPAN routing protocols SHOULD allow implementation with
+   small code size and require low routing state to fit the typical
+   6LoWPAN node capacity.  Generally speaking, the code size is bounded
+   by available flash memory size, and the routing table is bounded by
+   RAM size, possibly limiting it to less than 32 entries.
+
+      The RAM size of LoWPAN nodes often ranges between 4 KB and 10 KB
+      (2 KB minimum), and program flash memory normally consists of 48
+      KB to 128 KB.  (For example, in the current market, MICAz has 128
+      KB program flash, 4 KB EEPROM, and 512 KB external flash ROM;
+      TIP700CM has 48 KB program flash, 10 KB RAM, and 1 MB external
+      flash ROM.)
+
+      Due to these hardware restrictions, code SHOULD fit within a small
+      memory size -- no more than 48 KB to 128 KB of flash memory,
+      including at least a few tens of KB of application code size.  (As
+      a general observation, a routing protocol of low complexity may
+      help achieve the goal of reducing power consumption, improves
+      robustness, requires lower routing state, is easier to analyze,
+      and may be less prone to security attacks.)
+
+      In addition, operation with limited amounts of routing state (such
+      as routing tables and neighbor lists) SHOULD be maintained, since
+      some typical memory sizes preclude storing state of a large number
+      of nodes.  For instance, industrial monitoring applications may
+      need to support a maximum of 20 hops [RFC5673].  Small networks
+      can be designed to support a smaller number of hops.  While the
+      need for this is highly dependent on the network architecture,
+      there should be at least one mode of operation that can function
+      with 32 forwarding entries or less.
+
+   [R02] 6LoWPAN routing protocols SHOULD cause minimal power
+   consumption by efficiently using control packets (e.g., minimizing
+   expensive IP multicast, which causes link broadcast to the entire
+   LoWPAN) and by efficiently routing data packets.
+
+      One way of optimizing battery lifetime is by achieving a minimal
+      control message overhead.  Compared to such functions as
+      computational operations or taking sensor samples, radio
+      communication is by far the dominant factor of power consumption
+      [Doherty].  Power consumption of transmission and/or reception
+      depends linearly on the length of data units and on the frequency
+      of transmission and reception of the data units [Shih].
+
+      The energy consumption of two example radio frequency (RF)
+      controllers for low-power nodes is shown in [Hill].  The TR1000
+      radio consumes 21 mW when transmitting at 0.75 mW, and 15 mW
+      during reception (with a receiver sensitivity of -85 dBm).  The
+
+
+
+Kim, et al.                   Informational                    [Page 14]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      CC1000 consumes 31.6 mW when transmitting at 0.75 mW, and 20 mW
+      during reception (with a receiver sensitivity of -105 dBm).  Power
+      endurance under the concept of an idealized power source is
+      explained in [Hill].  Based on the energy of an idealized AA
+      battery, the CC1000 can transmit for approximately 4 days straight
+      or receive for 9 consecutive days.  Note that availability for
+      reception consumes power as well.
+
+      As multicast may cause flooding in the LoWPAN, a 6LoWPAN routing
+      protocol SHOULD minimize the control cost by multicasting routing
+      packets.
+
+      Control cost of routing protocols in low-power and lossy networks
+      is discussed in more detail in [ROLL-PROTOCOLS].
+
+5.2.  Support of 6LoWPAN Link Properties
+
+   6LoWPAN links have the characteristics of low data rate and possibly
+   high loss rates.  The routing requirements described in this section
+   are derived from the link properties.
+
+   [R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a
+   single IEEE 802.15.4 frame size, in order to avoid packet
+   fragmentation and the overhead for reassembly.
+
+      In order to save energy, routing overhead should be minimized to
+      prevent fragmentation of frames.  Therefore, 6LoWPAN routing
+      should not cause packets to exceed the IEEE 802.15.4 frame size.
+      This reduces the energy required for transmission, avoids
+      unnecessary waste of bandwidth, and prevents the need for packet
+      reassembly.  The [IEEE802.15.4] standard specifies an MTU of
+      127 bytes, yielding about 80 octets of actual MAC payload with
+      security enabled, some of which is taken for the (typically
+      compressed) IP header [RFC6282].  Avoiding fragmentation at the
+      adaptation layer may imply the use of semantic fragmentation
+      and/or algorithms that can work on small increments of routing
+      information.
+
+   [R04] The design of routing protocols for LoWPANs must consider the
+   fact that packets are to be delivered with sufficient probability
+   according to application requirements.
+
+      Requirements for a successful end-to-end packet delivery ratio
+      (where delivery may be bounded within certain latency levels)
+      vary, depending on the application.  In industrial applications,
+      some non-critical monitoring applications may tolerate a
+      successful delivery ratio of less than 90% with hours of latency;
+
+
+
+
+Kim, et al.                   Informational                    [Page 15]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      in some other cases, a delivery ratio of 99.9% is required
+      [RFC5673].  In building automation applications, application-layer
+      errors must be below 0.01% [RFC5867].
+
+      Successful end-to-end delivery of packets in an IEEE 802.15.4 mesh
+      depends on the quality of the path selected by the routing
+      protocol and on the ability of the routing protocol to cope with
+      short-term and long-term quality variation.  The metric of the
+      routing protocol strongly influences performance of the routing
+      protocol in terms of delivery ratio.
+
+      The quality of a given path depends on the individual qualities of
+      the links (including the devices) that compose that path.
+      IEEE 802.15.4 settings affect the quality perceived at upper
+      layers.  In particular, in IEEE 802.15.4 reliable mode, if an
+      acknowledgment frame is not received after a given period, the
+      originator retries frame transmission up to a maximum number of
+      times.  If an acknowledgment frame is still not received by the
+      sender after performing the maximum number of transmission
+      attempts, the MAC layer assumes that the transmission has failed
+      and notifies the next higher layer of the failure.  Note that
+      excessive retransmissions may be detrimental; see RFC 3819
+      [RFC3819].
+
+   [R05] The design of routing protocols for LoWPANs must consider the
+   latency requirements of applications and IEEE 802.15.4 link latency
+   characteristics.
+
+      Latency requirements may differ -- e.g., from a few hundred
+      milliseconds to minutes -- depending on the type of application.
+      Real-time building automation applications usually need response
+      times below 500 ms between egress and ingress, while forced-entry
+      security alerts must be routed to one or more fixed or mobile user
+      devices within 5 seconds [RFC5867].  Non-critical closed-loop
+      applications for industrial automation have latency requirements
+      that can be as low as 100 ms, but many control loops are tolerant
+      of latencies above 1 s [RFC5673].  In contrast, urban monitoring
+      applications allow latencies smaller than the typical intervals
+      used for reporting sensed information -- for instance, on the
+      order of seconds to minutes [RFC5548].
+
+      The range of latencies of a frame transmission between a single
+      sender and a single receiver through an ideal unslotted
+      IEEE 802.15.4 2.4 GHz channel is between 2.46 ms and 6.02 ms with
+      64-bit MAC addresses in unreliable mode, and between 2.20 ms and
+      6.56 ms with 64-bit MAC addresses in reliable mode.  The range of
+      latencies of the 868 MHz band is from 11.7 ms to 63.7 ms,
+      depending on the address type and mode used (reliable or
+
+
+
+Kim, et al.                   Informational                    [Page 16]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      unreliable).  Note that the latencies may be larger than that,
+      depending on channel load, the MAC-layer settings, and the choice
+      of reliable or unreliable mode.  Note that MAC approaches other
+      than legacy 802.15.4 may be used (e.g., TDMA).  Duty cycling may
+      further affect latency (see [R08]).  Depending on the routing path
+      chosen and the network diameter, multiple hops may contribute to
+      the end-to-end latency that an application may experience.
+
+      Note that a tradeoff exists between [R05] and [R04].
+
+   [R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss
+   caused by link failure or device unavailability either in the short
+   term (approx. 30 ms) -- due to Received Signal Strength Indication
+   (RSSI) variation, interference variation, noise, and asynchrony -- or
+   in the long term, due to a depleted power source, hardware breakdown,
+   operating system misbehavior, etc.
+
+      An important trait of 6LoWPAN devices is their unreliability,
+      which can be due to limited system capabilities and possibly being
+      closely coupled to the physical world with all its unpredictable
+      variations.  In harsh environments, LoWPANs easily suffer from
+      link failure.  Collisions or link failures easily increase send
+      and receive queues and can lead to queue overflow and packet
+      losses.
+
+      For home applications, where users expect feedback after carrying
+      out certain actions (such as handling a remote control while
+      moving around), routing protocols must converge within 2 seconds
+      if the destination node of the packet has moved and must converge
+      within 0.5 seconds if only the sender has moved [RFC5826].  The
+      tolerance of the recovery time can vary, depending on the
+      application; however, the routing protocol must provide the
+      detection of short-term unavailability and long-term
+      disappearance.  The routing protocol has to exploit network
+      resources (e.g., path redundancy) to offer good network behavior
+      despite node failure.
+
+      Different routing protocols may exhibit different scaling
+      characteristics with respect to the recovery/convergence time and
+      the computational resources to achieve recovery after a
+      convergence; see also [R01] and [R10].
+
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 17]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   [R07] 6LoWPAN routing protocols SHOULD be designed to correctly
+   operate in the presence of link asymmetry.
+
+      Link asymmetry occurs when the probability of successful
+      transmission between two nodes is significantly higher in one
+      direction than in the other.  This phenomenon has been reported in
+      a large number of experimental studies, and it is expected that
+      6LoWPANs will exhibit link asymmetry.
+
+5.3.  Support of 6LoWPAN Characteristics
+
+   6LoWPANs can be deployed in different sizes and topologies, adhere to
+   various models of mobility, be exposed to various levels of
+   interference, etc.  In any case, LoWPANs must maintain low energy
+   consumption.  The requirements described in this subsection are
+   derived from the network attributes of 6LoWPANs.
+
+   [R08] The design of 6LoWPAN routing protocols SHOULD take into
+   account that some nodes may be unresponsive during certain time
+   intervals, due to periodic hibernation.
+
+      Many nodes in LoWPAN environments might periodically hibernate
+      (i.e., disable their transceiver activity) in order to save
+      energy.  Therefore, routing protocols must ensure robust packet
+      delivery despite nodes frequently shutting off their radio
+      transmission interface.  Feedback from the lower IEEE 802.15.4
+      layer may be considered to enhance the power awareness of 6LoWPAN
+      routing protocols.
+
+      CC1000-based nodes must operate at a duty cycle of approximately
+      2% to survive for one year from an idealized AA battery power
+      source [Hill].  For home automation purposes, it is suggested that
+      the devices have to maximize the sleep phase with a duty cycle
+      lower than 1% [RFC5826], while in building automation
+      applications, batteries must be operational for at least 5 years
+      when the sensing devices are transmitting data (e.g., 64 bytes)
+      once per minute [RFC5867].
+
+      Depending on the application in use, packet rates may range from
+      one per second to one per day, or beyond.  Routing protocols may
+      take advantage of knowledge about the packet transmission rate and
+      utilize this information in calculating routing paths.  In many
+      IEEE 802.15.4 deployments, and in other wireless low-power
+      technologies, forwarders are mains-powered devices (and hence do
+      not need to sleep).  However, it cannot be assumed that all
+      forwarders are mains-powered.  A routing protocol that addresses
+      this case SHOULD provide a mode in which power consumption is a
+      metric.  In addition, using nodes in power-saving modes for
+
+
+
+Kim, et al.                   Informational                    [Page 18]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      forwarding may increase delay and reduce the probability of packet
+      delivery, which in this case also should be available as an input
+      into the path computation.
+
+   [R09] The metric used by 6LoWPAN routing protocols SHOULD provide
+   some flexibility with respect to the inputs provided by the lower
+   layers and other measures to optimize path selection, considering
+   energy balance and link qualities.
+
+      In homes, buildings, or infrastructure, some nodes will be
+      installed with mains power.  Such power-installed nodes MUST be
+      considered as relay points for a prominent role in packet
+      delivery.  6LoWPAN routing protocols MUST know the power
+      constraints of the nodes.
+
+      Simple hop-count-only mechanisms may be inefficient in 6LoWPANs.
+      There is a Link Quality Indication (LQI) and/or RSSI from
+      IEEE 802.15.4 that may be taken into account for better metrics.
+      The metric to be used (and its goal) may depend on applications
+      and requirements.
+
+      The numbers in Figure 4 represent the Link Delivery Ratio (LDR) of
+      each pair of nodes.  There are studies that show a piecewise
+      linear dependence between the LQI and the LDR [Chen].
+
+                                     0.6
+                                  A-------C
+                                   \     /
+                                0.9 \   / 0.9
+                                     \ /
+                                      B
+
+                         Figure 4: An Example Network
+
+      In this simple example, there are two options in routing from
+      node A to node C, with the following features:
+
+      A.  Path AC:
+
+          +  (1/0.6) = 1.67 avg. transmissions needed for each packet
+             (confirmed link-layer delivery with retransmissions and
+             negligible ACK loss have been assumed)
+
+          +  one-hop path
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 19]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+          +  good energy consumption and end-to-end latency of data
+             packets, poor delivery ratio (0.6)
+
+          +  poor probability of route reconfigurations
+
+      B.  Path ABC:
+
+          +  (1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each
+             packet (under the same assumptions as above)
+
+          +  two-hop path
+
+          +  poor energy consumption and end-to-end latency of data
+             packets, good delivery ratio (0.81)
+
+      If energy consumption of the network must be minimized, path AC is
+      the best (this path would be chosen based on a hop-count metric).
+      However, if the delivery ratio in that case is not sufficient, the
+      best path is ABC (it would be chosen by an LQI-based metric).
+      Combinations of both metrics can be used.
+
+      The metric also affects the probability of route reconfiguration.
+      Route reconfiguration, which may be triggered by packet losses,
+      may require transmission of routing protocol messages.  It is
+      possible to use a metric aimed at selecting the path with a low
+      route reconfiguration rate by using the LQI as an input to the
+      metric.  Such a path has good properties, including stability and
+      low control message overhead.
+
+   Note that a tradeoff exists between [R09] and [R01].
+
+   [R10] 6LoWPAN routing protocols SHOULD be designed to achieve both
+   scalability -- from a few nodes to maybe millions of nodes -- and
+   minimal use of system resources.
+
+      A LoWPAN may consist of just a couple of nodes (for instance, in a
+      body-area network), but may also contain much higher numbers of
+      devices (e.g., monitoring of a city infrastructure or a highway).
+      For home automation applications, it is envisioned that the
+      routing protocol must support 250 devices in the network
+      [RFC5826], while routing protocols for metropolitan-scale sensor
+      networks must be capable of clustering a large number of sensing
+      nodes into regions containing on the order of 10^2 to 10^4 sensing
+      nodes each [RFC5548].  It is therefore necessary that routing
+      mechanisms are designed to be scalable for operation in networks
+      of various sizes.  However, due to a lack of memory size and
+      computational power, 6LoWPAN routing might limit forwarding
+      entries to a small number, such as a maximum of 32 routing table
+
+
+
+Kim, et al.                   Informational                    [Page 20]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      entries.  Particularly in large networks, the routing mechanism
+      MUST be designed in such a way that the number of routers is
+      smaller than the number of hosts.
+
+   [R11] The procedure of route repair and related control messages
+   SHOULD NOT harm overall energy consumption from the routing
+   protocols.
+
+      Local repair improves throughput and end-to-end latency,
+      especially in large networks.  Since routes are repaired quickly,
+      fewer data packets are dropped, and a smaller number of routing
+      protocol packet transmissions are needed, since routes can be
+      repaired without source-initiated route discovery [Lee].  One
+      important consideration here may be to avoid premature energy
+      depletion, even if that impairs other requirements.
+
+   [R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive
+   topologies and mobile nodes.  When supporting dynamic topologies and
+   mobile nodes, route maintenance should keep in mind the goal of a
+   minimal routing state and routing protocol message overhead.
+
+      Topological node mobility may be the result of physical movement
+      and/or a changing radio environment, making it very likely that
+      mobility needs to be handled even in a network with physically
+      static nodes.  6LoWPANs do not make use of a separate protocol to
+      maintain connectivity to moving nodes but expects the routing
+      protocol to handle it.
+
+      In addition, some nodes may move from one 6LoWPAN to another and
+      are expected to become functional members of the latter 6LoWPAN in
+      a limited amount of time.
+
+      Building monitoring applications, for instance, have a number of
+      requirements with respect to recovery and settling time for
+      mobility that range between 5 and 20 seconds (Section 5.3.1 of
+      [RFC5867]).  For more interactive applications such as those used
+      in home automation systems, where users provide input and expect
+      instant feedback, mobility requirements are also stricter and, for
+      moves within a network, a convergence time below 0.5 seconds is
+      commonly required (Section 3.2 of [RFC5826]).  In industrial
+      environments, where mobile equipment (e.g., cranes) moves around,
+      the routing protocol needs to support vehicular speeds of up to
+      35 km/h [RFC5673].  Currently, 6LoWPANs are not normally being
+      used for such fast mobility, but dynamic association and
+      disassociation MUST be supported in 6LoWPANs.
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 21]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      There are several challenges that should be addressed by a 6LoWPAN
+      routing protocol in order to create robust routing in dynamic
+      environments:
+
+      *  Mobile Nodes Changing Their Location inside a LoWPAN:
+         If the nodes' movement pattern is unknown, mobility cannot
+         easily be detected or distinguished by the routing protocols.
+         Mobile nodes can be treated as nodes that disappear and
+         reappear in another place.  The tracking of movement patterns
+         increases complexity and can be avoided by handling moving
+         nodes using reactive route updates.
+
+      *  Movement of a LoWPAN with Respect to Other (Inter)Connected
+         LoWPANs:
+         Within each stub network, (one or more) relatively powerful
+         gateway nodes (6LBRs) need to be configured to handle moving
+         LoWPANs.
+
+      *  Nodes Permanently Joining or Leaving the LoWPAN:
+         In order to ease routing table updates, reduce the size of
+         these updates, and minimize error control messages, nodes
+         leaving the network may announce their disassociation to the
+         closest edge router or to a specific node (if any) that takes
+         charge of local association and disassociation.
+
+   [R13] A 6LoWPAN routing protocol SHOULD support various traffic
+   patterns -- point-to-point, point-to-multipoint, and multipoint-to-
+   point -- while avoiding excessive multicast traffic in a LoWPAN.
+
+      6LoWPANs often have point-to-multipoint or multipoint-to-point
+      traffic patterns.  Many emerging applications include point-to-
+      point communication as well.  6LoWPAN routing protocols should be
+      designed with the consideration of forwarding packets from/to
+      multiple sources/destinations.  Current documents of the ROLL WG
+      explain that the workload or traffic pattern of use cases for
+      LoWPANs tends to be highly structured, unlike the any-to-any data
+      transfers that dominate typical client and server workloads.  In
+      many cases, exploiting such structure may simplify difficult
+      problems arising from resource constraints or variation in
+      connectivity.
+
+5.4.  Support of Security
+
+   The routing requirement described in this subsection allows secure
+   transmission of routing messages.  As in traditional networks,
+   routing mechanisms in 6LoWPANs present another window from which an
+   attacker might disrupt and significantly degrade the overall
+   performance of the 6LoWPAN.  Attacks against non-secure routing aim
+
+
+
+Kim, et al.                   Informational                    [Page 22]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   mainly to contaminate WPANs with false routing information, resulting
+   in routing inconsistencies.  A malicious node can also snoop packets
+   and then launch replay attacks on the 6LoWPAN nodes.  These attacks
+   can cause harm, especially when the attacker is a high-power device,
+   such as a laptop.  It can also easily drain the batteries of 6LoWPAN
+   devices by sending broadcast messages, redirecting routes, etc.
+
+   [R14] 6LoWPAN routing protocols MUST support confidentiality,
+   authentication, and integrity services as required for secure
+   delivery of control messages.
+
+      A general set of requirements that may apply to these services can
+      be found in [KARP-THREATS].
+
+      Security is very important for designing robust routing protocols,
+      but it should not cause significant transmission overhead.  The
+      security aspect, however, seems to be a bit of a tradeoff in a
+      6LoWPAN, since security is always a costly function.  A 6LoWPAN
+      poses unique challenges to which traditional security techniques
+      cannot be applied directly.  For example, public key cryptography
+      primitives are typically avoided (as being too expensive), as are
+      relatively heavyweight conventional encryption methods.
+
+      Consequently, it becomes questionable whether the 6LoWPAN devices
+      can support IPsec as it is.  While [RFC6434] makes support of the
+      IPsec architecture a SHOULD for all IPv6 nodes, considering the
+      power constraints and limited processing capabilities of
+      IEEE 802.15.4-capable devices, IPsec is computationally expensive.
+      Internet Key Exchange (IKEv2) messaging as described in RFC 5996
+      [RFC5996] will not work well in 6LoWPANs, as we want to minimize
+      the amount of signaling in these networks.  IPsec supports the
+      Authentication Header (AH) for authenticating the IP header and
+      the Encapsulating Security Payload (ESP) for authenticating and
+      encrypting the payload.  The main issues of using IPsec are
+      two-fold: (1) processing power and (2) key management.  Since
+      these tiny 6LoWPAN devices do not process huge amounts of data or
+      communicate with many different nodes, whether complete
+      implementation of a Security Association Database (SAD), policy
+      database, and dynamic key-management protocol are appropriate for
+      these small battery-powered devices or not is not well understood.
+
+      Bandwidth is a very scarce resource in 6LoWPAN environments.  The
+      fact that IPsec additionally requires another header (AH or ESP)
+      in every packet makes its use problematic in 6LoWPAN environments.
+      IPsec requires two communicating peers to share a secret key that
+      is typically established dynamically with IKEv2.  Thus, it has an
+      additional packet overhead incurred by the exchange of IKEv2
+      packets.
+
+
+
+Kim, et al.                   Informational                    [Page 23]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      Given existing constraints in 6LoWPAN environments, IPsec may not
+      be suitable for use in such environments, especially since a
+      6LoWPAN node may not be capable of operating all IPsec algorithms
+      on its own.  Thus, a 6LoWPAN may need to define its own keying
+      management method(s) that require minimum overhead in packet size
+      and in the number of signaling messages that are exchanged.  IPsec
+      will provide authentication and confidentiality between end-nodes
+      and across multiple LoWPAN links, and may be useful only when two
+      nodes want to apply security to all exchanged messages.  However,
+      in most cases, the security may be requested at the application
+      layer as needed, while other messages can flow in the network
+      without security overhead.
+
+      Security threats within LoWPANs may be different from existing
+      threat models in ad hoc network environments.  If IEEE 802.15.4
+      security is not used, Neighbor Discovery (ND) in IEEE 802.15.4
+      links is susceptible to threats.  These include Neighbor
+      Solicitation/Neighbor Advertisement (NS/NA) spoofing, a malicious
+      router, a default router that is "killed", a good router that goes
+      bad, a spoofed redirect, replay attacks, and remote ND DoS
+      [RFC3756].  However, if IEEE 802.15.4 security is used, no other
+      protection is needed for ND, as long as none of the nodes become
+      compromised, because the Corporate Intranet Model of RFC 3756 can
+      be assumed [6LoWPAN-ND].
+
+      Bootstrapping may also impose additional threats.  For example, a
+      malicious node can obtain initial configuration information in
+      order to appear as a legitimate node and then carry out various
+      types of attacks.  Such a node can also keep legitimate nodes busy
+      by broadcasting authentication/join requests.  One option for
+      mitigating such threats is the use of mutual authentication
+      schemes based on the use of pre-shared keys [Ikram].
+
+      The IEEE 802.15.4 MAC provides an AES-based security mechanism.
+      Routing protocols may define how this mechanism (in conjunction
+      with IPsec whenever available) can be used to obtain the intended
+      security, either for the routing protocol alone or in conjunction
+      with the security used for the data.  Byte overhead of the
+      mechanism, which depends on the security services selected, must
+      be considered.  In the worst case in terms of overhead, the
+      mechanism consumes 21 bytes of MAC payload.
+
+      The IEEE 802.15.4 MAC security is typically supported by crypto
+      hardware, even in very simple chips that will be used in a
+      6LoWPAN.  Even if the IEEE 802.15.4 MAC security mechanisms are
+      not used, this crypto hardware is usually available for use by
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 24]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+      application code running on these chips.  A security protocol
+      outside IEEE 802.15.4 MAC security SHOULD therefore provide a mode
+      of operation that is covered by this crypto hardware.
+
+      IEEE 802.15.4 does not specify protection for acknowledgment
+      frames.  Since the sequence numbers of data frames are sent in the
+      clear, an adversary can forge an acknowledgment for each data
+      frame.  Exploitation of this weakness can be combined with
+      targeted jamming to prevent delivery of selected packets.
+      Consequently, IEEE 802.15.4 acknowledgments cannot be relied upon.
+      In applications that require high security, the routing protocol
+      must not exploit feedback from acknowledgments (e.g., to keep
+      track of neighbor connectivity, see [R16]).
+
+5.5.  Support of Mesh-Under Forwarding
+
+   One LoWPAN may be built as one IPv6 link.  In this case, mesh-under
+   forwarding mechanisms must be supported.  While this document
+   provides general, layer-agnostic guidelines about the design of
+   6LoWPAN routing, the requirements in this section are specifically
+   related to Layer 2.  These requirements are directed to bodies that
+   might consider working on mesh-under routing, such as the IEEE.  The
+   requirements described in this subsection allow optimization and
+   correct operation of routing solutions, taking into account the
+   specific features of the mesh-under configuration.
+
+   [R15] Mesh-under requires the development of a routing protocol
+   operating below IP.  This protocol MUST support 16-bit short and
+   64-bit extended MAC addresses.
+
+   [R16] In order to perform discovery and maintenance of neighbors
+   (i.e., neighborhood discovery as opposed to ND-style neighbor
+   discovery), LoWPAN nodes SHOULD avoid sending separate "Hello"
+   messages.  Instead, link-layer mechanisms (such as acknowledgments)
+   MAY be utilized to keep track of active neighbors.
+
+      Reception of an acknowledgment after a frame transmission may
+      render unnecessary the transmission of explicit Hello messages,
+      for example.  In a more general view, any frame received by a node
+      may be used as an input to evaluate the connectivity between the
+      sender and receiver of that frame.
+
+   [R17] If the routing protocol functionality includes enabling IP
+   multicast, then it MAY employ structure in the network for efficient
+   distribution in order to minimize link-layer broadcast.
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 25]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+5.6.  Support of Management
+
+   When a new protocol is designed, the operational environment and
+   manageability of the protocol should be considered from the start
+   [RFC5706].  This subsection provides a requirement for the
+   manageability of 6LoWPAN routing protocols.
+
+   [R18] A 6LoWPAN routing protocol SHOULD be designed according to the
+   guidelines for operations and management stated in [RFC5706].
+
+      The management operations that a 6LoWPAN routing protocol
+      implementation can support depend on the memory and processing
+      capabilities of the 6LoWPAN devices used, which are typically
+      constrained.  However, 6LoWPANs may benefit significantly from
+      supporting such 6LoWPAN routing protocol management operations as
+      configuration and performance monitoring.
+
+      The design of 6LoWPAN routing protocols should take into account
+      that, according to "Architectural Principles of the Internet"
+      [RFC1958], "options and parameters should be configured or
+      negotiated dynamically rather than manually".  This is especially
+      important for 6LoWPANs, which can be composed of a large number of
+      devices (and, in addition, these devices may not have an
+      appropriate user interface).  Therefore, parameter
+      autoconfiguration is a desirable property for a 6LoWPAN routing
+      protocol, although some subset of routing protocol parameters may
+      allow other forms of configuration as well.
+
+      In order to verify the correct operation of the 6LoWPAN routing
+      protocol and the network itself, a 6LoWPAN routing protocol should
+      allow monitoring of the status and/or value of 6LoWPAN routing
+      protocol parameters and data structures such as routing table
+      entries.  In order to enable fault management, further monitoring
+      of the 6LoWPAN routing protocol operation is needed.  For this,
+      faults can be reported via error log messages.  These messages may
+      contain information such as the number of times a packet could not
+      be sent to a valid next hop, the duration of each period without
+      connectivity, memory overflow and its causes, etc.
+
+      [RFC5706] -- in particular its Section 3 -- provides a
+      comprehensive guide to properly designing the management solution
+      for a 6LoWPAN routing protocol.
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 26]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+6.  Security Considerations
+
+   Security issues are described in Section 5.4.  The security
+   considerations in RFC 4919 [RFC4919], RFC 4944 [RFC4944], and
+   RFC 4593 [RFC4593] apply as well.
+
+   The use of wireless links renders a 6LoWPAN susceptible to attacks
+   like any other wireless network.  In outdoor 6LoWPANs, the physical
+   exposure of the nodes allows an adversary to capture, clone, or
+   tamper with these devices.  In ad hoc 6LoWPANs that are dynamic in
+   both their topology and node memberships, a static security
+   configuration does not suffice.  Spoofed, altered, or replayed
+   routing information might occur, while multihopping could delay the
+   detection and treatment of attacks.
+
+   This specification expects that the link layer is sufficiently
+   protected, either by means of physical or IP security for the
+   backbone link, or with MAC-sublayer cryptography.  However, link-
+   layer encryption and authentication may not be sufficient to provide
+   confidentiality, authentication, integrity, and freshness to both
+   data and routing protocol packets.  Time synchronization, self-
+   organization, and secure localization for multi-hop routing are also
+   critical to support.
+
+   For secure routing protocol operation, it may be necessary to
+   consider authenticated broadcast (and multicast) and bidirectional
+   link verification.  On the other hand, secure end-to-end data
+   delivery can be assisted by the routing protocol.  For example,
+   multi-path routing could be considered for increasing security to
+   prevent selective forwarding.  However, the challenge is that
+   6LoWPANs already have high resource constraints, so that 6LBR and
+   LoWPAN nodes may require different security solutions.
+
+7.  Acknowledgments
+
+   The authors of this document highly appreciate the authors of "IPv6
+   over Low Power WPAN Security Analysis" [6LoWPAN-SEC].  Although their
+   security analysis work is not ongoing at the time of this writing,
+   the valuable information and text in that document are used in
+   Section 5.4 of this document, per advice received during IESG review
+   procedures.  Thanks to their work, Section 5.4 is much improved.  The
+   authors also thank S. Chakrabarti, who gave valuable comments
+   regarding mesh-under requirements, and A. Petrescu for significant
+   review.
+
+   Carles Gomez has been supported in part by FEDER and by the Spanish
+   Government through projects TIC2006-04504 and TEC2009-11453.
+
+
+
+
+Kim, et al.                   Informational                    [Page 27]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+8.  References
+
+8.1.  Normative References
+
+   [IEEE802.15.4]
+              IEEE Computer Society, "IEEE Standard for Local and
+              Metropolitan Area Networks -- Part 15.4: Low-Rate
+              Wireless Personal Area Networks (LR-WPANs)", IEEE
+              Std. 802.15.4-2011, September 2011.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+              Neighbor Discovery (ND) Trust Models and Threats",
+              RFC 3756, May 2004.
+
+   [RFC3819]  Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
+              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
+              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
+              RFC 3819, July 2004.
+
+   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
+              Routing Protocols", RFC 4593, October 2006.
+
+   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
+              over Low-Power Wireless Personal Area Networks (6LoWPANs):
+              Overview, Assumptions, Problem Statement, and Goals",
+              RFC 4919, August 2007.
+
+   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
+              "Transmission of IPv6 Packets over IEEE 802.15.4
+              Networks", RFC 4944, September 2007.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 28]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+8.2.  Informative References
+
+   [6LoWPAN-ND]
+              Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark,
+              "Neighbor Discovery Optimization for Low Power and Lossy
+              Networks (6LoWPAN)", Work in Progress, October 2011.
+
+   [6LoWPAN-SEC]
+              Park, S., Kim, K., Haddad, W., Ed., Chakrabarti, S., and
+              J. Laganier, "IPv6 over Low Power WPAN Security Analysis",
+              Work in Progress, March 2011.
+
+   [Bulusu]   Bulusu, N., Ed., and S. Jha, Ed., "Wireless Sensor
+              Networks: A Systems Perspective", Artech House,
+              ISBN 9781580538671, July 2005.
+
+   [Chen]     Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc
+              Multicast Routing on Resource-Limited Sensor Nodes", Proc.
+              2nd International Workshop on Multi-hop Ad Hoc Networks,
+              May 2006.
+
+   [Doherty]  Doherty, L., Warneke, B., Boser, B., and K. Pister,
+              "Energy and Performance Considerations for Smart Dust",
+              International Journal of Parallel and Distributed Systems
+              and Networks, Vol. 4, No. 3, 2001.
+
+   [Hill]     Hill, J., "System Architecture for Wireless Sensor
+              Networks", Ph.D. Thesis, UC Berkeley, 2003.
+
+   [Ikram]    Ikram, M., Chowdhury, A., Zafar, B., Cha, H., Kim, K.,
+              Yoo, S., and D. Kim, "A Simple Lightweight Authentic
+              Bootstrapping Protocol for IPv6-based Low Rate Wireless
+              Personal Area Networks (6LoWPANs)", Proc. International
+              Conference on Wireless Communications and
+              Mobile Computing, June 2009.
+
+   [KARP-THREATS]
+              Lebovitz, G. and M. Bhatia, "Keying and Authentication for
+              Routing Protocols (KARP) Overview, Threats, and
+              Requirements", Work in Progress, May 2012.
+
+   [Kuhn]     Kuhn, F., Wattenhofer, R., and A. Zollinger, "Worst-Case
+              Optimal and Average-Case Efficient Ad-Hoc Geometric
+              Routing", MobiHoc '03: Proceedings of the 4th ACM
+              International Symposium on Mobile Ad Hoc Networking and
+              Computing, June 2003.
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 29]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   [Latre]    Latre, B., De Mil, P., Moerman, I., Dhoedt, B., and P.
+              Demeester, "Throughput and Delay Analysis of Unslotted
+              IEEE 802.15.4", Journal of Networks, Vol. 1, No. 1,
+              May 2006.
+
+   [Lee]      Lee, S., Belding-Royer, E., and C. Perkins, "Scalability
+              Study of the Ad Hoc On-Demand Distance-Vector Routing
+              Protocol", International Journal of Network Management,
+              Vol. 13, pp. 97-114, March 2003.
+
+   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
+              Internet", RFC 1958, June 1996.
+
+   [RFC5556]  Touch, J. and R. Perlman, "Transparent Interconnection of
+              Lots of Links (TRILL): Problem and Applicability
+              Statement", RFC 5556, May 2009.
+
+   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
+              Management of New Protocols and Protocol Extensions",
+              RFC 5706, November 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., Ed., De Mil, P., Riou, N., and W. Vermeylen,
+              "Building Automation Routing Requirements in Low-Power and
+              Lossy Networks", RFC 5867, June 2010.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)",
+              RFC 5996, September 2010.
+
+   [RFC6282]  Hui, J., Ed., and P. Thubert, "Compression Format for IPv6
+              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
+              September 2011.
+
+   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
+              Requirements", RFC 6434, December 2011.
+
+   [ROLL-PROTOCOLS]
+              Levis, P., Tavakoli, A., and S. Dawson-Haggerty, "Overview
+              of Existing Routing Protocols for Low Power and Lossy
+              Networks", Work in Progress, April 2009.
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 30]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+   [Shih]     Shih, E., Cho, S., Ickes, N., Min, R., Sinha, A., Wang,
+              A., and A. Chandrakasan, "Physical Layer Driven Protocols
+              and Algorithm Design for Energy-Efficient Wireless Sensor
+              Networks", MobiCom '01: Proceedings of the 7th ACM Annual
+              International Conference on Mobile Computing and
+              Networking, July 2001.
+
+   [Watteyne] Watteyne, T., Molinaro, A., Richichi, M., and M. Dohler,
+              "From MANET To IETF ROLL Standardization: A Paradigm Shift
+              in WSN Routing Protocols", IEEE Communications Surveys and
+              Tutorials, Vol. 13, Issue 4, pp. 688-707, 2011,
+              <http://ieeexplore.ieee.org/xpl/
+              articleDetails.jsp?arnumber=5581105>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 31]
+
+RFC 6606              6LoWPAN Routing Requirements              May 2012
+
+
+Authors' Addresses
+
+   Eunsook Eunah Kim
+   ETRI
+   161 Gajeong-dong
+   Yuseong-gu
+   Daejeon  305-700
+   Korea
+
+   Phone: +82-42-860-6124
+   EMail: eunah.ietf@gmail.com
+
+
+   Dominik Kaspar
+   Simula Research Laboratory
+   Martin Linges v 17
+   Fornebu  1364
+   Norway
+
+   Phone: +47-6782-8223
+   EMail: dokaspar.ietf@gmail.com
+
+
+   Carles Gomez
+   Universitat Politecnica de Catalunya/Fundacio i2CAT
+   Escola d'Enginyeria de Telecomunicacio i Aeroespacial
+      de Castelldefels
+   C/Esteve Terradas, 7
+   Castelldefels  08860
+   Spain
+
+   Phone: +34-93-413-7206
+   EMail: carlesgo@entel.upc.edu
+
+
+   Carsten Bormann
+   Universitaet Bremen TZI
+   Postfach 330440
+   Bremen  D-28359
+   Germany
+
+   Phone: +49-421-218-63921
+   EMail: cabo@tzi.org
+
+
+
+
+
+
+
+
+Kim, et al.                   Informational                    [Page 32]
+