[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 RFC 6971

Internet Engineering Task Force                          U. Herberg, Ed.
Internet-Draft                                               A. Cardenas
Intended status: Experimental                                    T. Iwao
Expires: December 28, 2012                                       Fujitsu
                                                                  M. Dow
                                                               Freescale
                                                             S. Cespedes
                                                 U. Icesi/U. of Waterloo
                                                           June 26, 2012


          Depth-First Forwarding in Unreliable Networks (DFF)
                         draft-cardenas-dff-06

Abstract

   This document specifies the "Depth-First Forwarding" (DFF) protocol
   for IPv6 networks, a data forwarding mechanism that can increase
   reliability of data delivery.  The protocol operates entirely on the
   forwarding plane, but may interact with the routing plane.  DFF
   forwards data packets using a mechanism similar to a "depth-first
   search" for the destination of a packet.  This document specifies the
   DFF mechanism both for IPv6 networks (as specified in RFC2460) and in
   addition also for LoWPAN "mesh-under" networks (as specified in
   RFC4944).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 28, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Herberg, et al.         Expires December 28, 2012               [Page 1]

Internet-Draft                     DFF                         June 2012


   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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Protocol Dependencies  . . . . . . . . . . . . . . . . . .  5
   2.  Notation and Terminology . . . . . . . . . . . . . . . . . . .  5
     2.1.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  7
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  8
     4.1.  Information Base Overview  . . . . . . . . . . . . . . . .  8
     4.2.  Signaling Overview . . . . . . . . . . . . . . . . . . . .  8
   5.  Information Sets . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Candidate Neighbor List  . . . . . . . . . . . . . . . . .  9
     5.2.  Processed Set  . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 10
   7.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Data Packet Generation and Processing  . . . . . . . . . . . . 11
     8.1.  Data Packet Generation . . . . . . . . . . . . . . . . . . 11
     8.2.  Data Packet Processing . . . . . . . . . . . . . . . . . . 12
   9.  Unsuccessful Packet Transmission . . . . . . . . . . . . . . . 14
   10. Determining the Next Hop for a Packet  . . . . . . . . . . . . 15
   11. Informing the Routing Protocol . . . . . . . . . . . . . . . . 16
   12. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 16
   13. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 17
     13.1. Route-Over . . . . . . . . . . . . . . . . . . . . . . . . 17
       13.1.1.  Mapping of IPv6 Terminology to DFF  . . . . . . . . . 17
       13.1.2.  Packet Format . . . . . . . . . . . . . . . . . . . . 17
     13.2. Mesh-Under . . . . . . . . . . . . . . . . . . . . . . . . 19
       13.2.1.  Mapping of LoWPAN Terminology to DFF  . . . . . . . . 19
       13.2.2.  Packet Format . . . . . . . . . . . . . . . . . . . . 20
   14. Scope Limitation of DFF  . . . . . . . . . . . . . . . . . . . 21
     14.1. Route-Over MoP . . . . . . . . . . . . . . . . . . . . . . 23
     14.2. Mesh-Under MoP . . . . . . . . . . . . . . . . . . . . . . 24
   15. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
     15.1. Attacks Out of Scope . . . . . . . . . . . . . . . . . . . 25
     15.2. Protection Mechanisms of DFF . . . . . . . . . . . . . . . 25



Herberg, et al.         Expires December 28, 2012               [Page 2]

Internet-Draft                     DFF                         June 2012


     15.3. Attacks In Scope . . . . . . . . . . . . . . . . . . . . . 25
       15.3.1.  Denial of Service . . . . . . . . . . . . . . . . . . 26
       15.3.2.  Packet Header Modification  . . . . . . . . . . . . . 26
         15.3.2.1.  Return Flag Tampering . . . . . . . . . . . . . . 26
         15.3.2.2.  Duplicate Flag Tampering  . . . . . . . . . . . . 27
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     18.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     18.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 29
     A.1.  Example 1: Normal Delivery . . . . . . . . . . . . . . . . 29
     A.2.  Example 2: Forwarding with Link Failure  . . . . . . . . . 30
     A.3.  Example 3: Forwarding with Missed Link Layer
           Acknowledgment . . . . . . . . . . . . . . . . . . . . . . 31
     A.4.  Example 4: Forwarding with a Loop  . . . . . . . . . . . . 31
   Appendix B.  Deployment Experience . . . . . . . . . . . . . . . . 32
     B.1.  Deployments in Japan . . . . . . . . . . . . . . . . . . . 32
     B.2.  Kit Carson Electric Cooperative  . . . . . . . . . . . . . 32
     B.3.  Simulations  . . . . . . . . . . . . . . . . . . . . . . . 33
     B.4.  Open Source Implementation . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33





























Herberg, et al.         Expires December 28, 2012               [Page 3]

Internet-Draft                     DFF                         June 2012


1.  Introduction

   This document specifies the Depth-First Forwarding (DFF) protocol for
   IPv6 networks, both for IPv6 forwarding ([RFC2460], henceforth
   denoted "route-over"), and also for "mesh-under" forwarding using the
   LoWPAN adaptation layer ([RFC4944]).  The protocol operates entirely
   on the forwarding plane, but may interact with the routing plane.
   The purpose of DFF is to increase reliability of data delivery in
   networks with dynamic topologies and/or lossy links.

   DFF forwards data packets using a "depth-first search" for the
   destination of the packets.  DFF relies on an external neighborhood
   discovery mechanism which lists neighbors of a router that may be
   attempted as next hops for a data packet.  In addition, DFF may use
   information from the Routing Information Base (RIB) for deciding in
   which order to try to send the packet to the neighboring routers.

   If the packet makes no forward progress using the first selected next
   hop, DFF will successively try all neighbors of the router.  If none
   of the next hops successfully receives or forwards the packet, DFF
   returns the packet to the previous hop, which in turn tries to send
   it to alternate neighbors.

   As network topologies do not necessarily form a tree, loops can
   occur.  Therefore, DFF contains a loop detection and avoidance
   mechanism.

   DFF may provide information, which may - by a mechanism outside of
   this specification - be used for updating cost of routes in the RIB
   based on failed or successful delivery of packets through alternative
   next hops.  Such information may also be used by a routing protocol.

1.1.  Motivation

   In networks with dynamic topologies and/or lossy links, even frequent
   exchanges of control messages between routers for updating the
   routing tables cannot guarantee that the routes correspond to the
   effective topology of the network at all times.  Packets may not be
   delivered to their destination because the topology has changed since
   the last routing protocol update.

   More frequent routing protocol updates can mitigate that problem to a
   certain extent, however this requires additional signaling, consuming
   channel and router resources (e.g., when flooding control messages
   through the network).  This is problematic in networks with lossy
   links, where further control traffic exchange can worsen the network
   stability because of collisions.  Moreover, additional control
   traffic exchange may drain energy from battery-driven routers.



Herberg, et al.         Expires December 28, 2012               [Page 4]

Internet-Draft                     DFF                         June 2012


   The data-forwarding mechanism specified in this document allows for
   forwarding data packets along alternate paths for increasing
   reliability of data delivery, using a depth-first search.  The
   objective is to decrease the necessary control traffic overhead in
   the network, and at the same time to increase delivery success rates.

   As this specification is intended for experimentation, the mechanism
   is also specified for forwarding on the LoWPAN adaption layer
   (according to Section 11 of [RFC4944]), denoted "mesh-under", in
   addition to IPv6 forwarding as specified in [RFC2460] (denoted
   "route-over").  Other than different header formats, the DFF
   mechanism for route-over and mesh-under is similar, and is therefore
   first defined in general, and then more specifically for both IPv6
   route-over forwarding (as specified in Section 13.1), and for LoWPAN
   adaptation layer mesh-under (as specified in Section 13.2).

1.2.  Protocol Dependencies

   DFF MAY use information from the Routing Information Base (RIB),
   notably for determining an order of preference for to which next hops
   a packet should be forwarded (e.g., the packet may be forwarded first
   to neighbors that are listed in the RIB as next hops to the
   destination, preferring those with the lowest route cost).

   DFF MUST have access to a list of bidirectional neighbors for each
   router, provided by a mechanism such as, e.g., NHDP [RFC6130].  That
   neighborhood discovery protocol is not specified in this document.


2.  Notation and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Additionally, this document uses the notation in Section 2.1 and the
   terminology in Section 2.2.

2.1.  Notation

   The following notations are used in this document:

   List  - A list of elements is defined as [] for an empty list,
      [element] for a list with one element, and [element1, element2,
      ...] for a list with multiple elements.





Herberg, et al.         Expires December 28, 2012               [Page 5]

Internet-Draft                     DFF                         June 2012


   Concatenation of lists:  If L1 and L2 are lists, then L1@L2 is a new
      list with first all elements of L1, followed by all elements of L2
      in that order.

2.2.  Terminology

   The following terms are used in this document.  As the DFF mechanism
   is specified both for route-over IPv6 and for mesh-under LoWPAN
   adaptation layer, the terms are generally defined in this section,
   and then specifically mapped for each of the different modes of
   operation in Section 13.

   Mode of Operation (MoP)  - The DFF mechanism specified in this
      document can either be used as "route-over" IPv6 forwarding
      mechanism (Mode of Operation: "route-over"), or as "mesh-under"
      LoWPAN adaptation layer (Mode of Operation: "mesh-under").

   Packet  - An IPv6 Packet (for "route-over" MoP) or a "LoWPAN
      encapsulated packet" (for "mesh-under" MoP) containing an IPv6
      Packet as payload.

   Packet Header  - An IPv6 extension header (for "route-over" MoP) or a
      LoWPAN header (for "mesh-under" MoP).

   Address  - An IPv6 address (for "route-over" MoP), or a 16-bit short
      or EUI-64 link layer address (for "mesh-under" MoP).

   Originator  - The router which added the DFF header (specified in
      Section 6) to a Packet.

   Originator Address  - An Address of the Originator.  This Address
      SHOULD be an Address configured on the interface which transmits
      the Packet, selected according to [RFC3484].

   Destination Address  - An Address to which the Packet is sent.

   Next Hop  - An Address of the next hop router to which the Packet is
      sent along the path to the Destination.

   Previous Hop  - The Address of the previous hop router from which a
      Packet has been received.

   Hop Limit  - An upper bound how many times the Packet may be
      forwarded.







Herberg, et al.         Expires December 28, 2012               [Page 6]

Internet-Draft                     DFF                         June 2012


3.  Applicability Statement

   This protocol:

   o  Is applicable for use in IPv6 networks, either as "route-over"
      forwarding mechanism using IPv6 ([RFC2460]), or as "mesh-under"
      forwarding mechanism using the frame format for transmission of
      IPv6 packets defined in [RFC4944].

   o  Assumes addresses used in the network are either IPv6 addresses
      (if the protocol is used as "route-over"), or 16-bit short or
      EUI-64 link layer addresses, as specified in [RFC4944] if the
      protocol is used as "mesh-under".

   o  Assumes that the underlying link layer provides means to detect if
      a Packet has been successfully delivered to the Next Hop or not
      (e.g., by L2 ACK messages).

   o  Is designed to work in networks with lossy links and/or with a
      dynamic topology.

   o  Is designed to work in a completely distributed manner, and does
      not depend on any central entity.

   o  Is designed for networks with little traffic in terms of numbers
      of Packets per second (such as common in Low-Power and Lossy
      Networks (LLNs)), since each recently forwarded Packet increases
      the state on a router.  The routers have to be provisioned with
      enough memory to maintain the state required for this
      specification.

   o  Is designed for dense topologies with multiple paths between each
      source and each destination.  Certain topologies may be less
      suitable for DFF (e.g. a network topology that can be partitioned
      by the removal of a single router or link, or a network topology
      with multiple stub routers that each have a single link to the
      network).  It is out of scope for this document to provide
      guidelines as to in which topologies DFF is or is not beneficial.
      In topologies unsuitable for DFF, the Packet may never reach the
      Destination, and therefore unnecessary transmissions of data
      Packets may occur until the Hop Limit of the Packet reaches zero
      and the Packet is dropped.  This may consume channel and router
      resources.

   o  Is used for unicast transmissions only.






Herberg, et al.         Expires December 28, 2012               [Page 7]

Internet-Draft                     DFF                         June 2012


4.  Protocol Overview and Functioning

   When a Packet is to be forwarded by a router using DFF, the router
   creates a list of candidate Next Hops for that Packet.  This list is
   ordered, containing first Next Hops listed in the RIB, if available,
   ordered in increasing cost, followed by other neighbors provided of
   by an external neighborhood discovery.  DFF proceeds to forward the
   Packet to the Next Hop listed first in the list.  If the transmission
   was not successful (as determined by the underlying link layer) or if
   the Packet was "returned" by a Next Hop to which it had been sent
   before, the router will try to forward the Packet to the next Next
   Hop on the list.  A router "returns" a Packet to the router from
   which it was originally received, once it has unsuccessfully tried to
   forward the Packet to all elements in the candidate Next Hop list.
   If the Packet is eventually returned to the Originator of the Packet,
   it is dropped.

   For each recently forwarded Packet, a router running DFF stores the
   list of Next Hops to which a Packet has been sent.  Packets are
   identified by a sequence number that is included in the Packet
   Header.  This list of recently forwarded Packets also allows for
   avoiding loops when forwarding a Packet.

4.1.  Information Base Overview

   This specification requires a single set on each router, the
   Processed Set. This set stores the sequence number, the Originator
   Address, the Previous Hop and a list of Next Hops, to which the
   Packet has been sent, for each recently seen Packet.  Entries in the
   set are removed after a predefined time-out.  Each time a Packet is
   forwarded to a Next Hop, that Next Hop is added to the list of Next
   Hops of the entry for the Packet.

   Note that an implementation of this protocol may maintain the
   information of the Processed Set in the indicated form, or in any
   other organization which offers access to this information.  In
   particular, it is not necessary to remove Tuples from a Set at the
   exact time indicated, only to behave as if the Tuples were removed at
   that time.

4.2.  Signaling Overview

   DFF requires additional header information in each data Packet by a
   router using this specification.  This information is stored in a
   Packet Header that is specified in this document as LoWPAN header and
   as IPv6 Hop-by-Hop Options extension header respectively, for the
   intended "route-over" and "mesh-under" Modes of Operations.  This DFF
   header contains a sequence number used for uniquely identifying a



Herberg, et al.         Expires December 28, 2012               [Page 8]

Internet-Draft                     DFF                         June 2012


   Packet, and two flags: RET (for "return") and DUP (for "duplicated").

   If none of the transmissions of a data Packet to the neighbors of a
   router have succeeded, the Packet is returned to the Previous Hop,
   indicated by setting the return flag (RET := 1).  The RET flag is
   required to discern between a deliberately returned Packet and a
   looping Packet: if a router receives a Packet with RET = 1 that it
   had already forwarded, the Packet was deliberately returned, and the
   router will continue to successively send the Packet to routers from
   the candidate Next Hop list.  If the received Packet has RET = 0, the
   router assumes that the Packet is looping and returns it to the
   Previous Hop. An external mechanism may use this information for
   increasing the route cost of the route using the Next Hop which
   resulted in the loop the RIB, and/or the routing protocol may be
   informed.

   Whenever a Packet transmission to a neighbor has failed (as
   determined by the underlying link layer, e.g., using L2 ACKs), the
   duplicate (DUP) flag is set in the Packet Header for the following
   transmissions.  The rationale is that the Packet may have been
   successfully received by the neighbor and only the L2 ACK has been
   lost, resulting in possible duplicates of the Packet in the network.
   The DUP flag tags such a possible duplicate.  The DUP flag is
   required to discern between a duplicated Packet and a looping Packet:
   if a router receives a Packet with DUP = 1 that it had already
   forwarded, the Packet is not considered looping, and successively
   forwarded to routers from the candidate Next Hop list.  If the
   received Packet has DUP = 0, the router assumes that the Packet is
   looping and returns it to the Previous Hop (with RET flag set).
   Again, an external mechanism may use this information for increasing
   route costs and/or informing the routing protocol.


5.  Information Sets

   This section specifies the information sets used by DFF.

5.1.  Candidate Neighbor List

   DFF MUST have access to a list of Addresses of bidirectional
   neighbors of the router, provided by an external neighborhood
   discovery mechanism, which is not specified within this document.

5.2.  Processed Set

   Each router maintains a Processed Set in order to support the loop
   detection functionality.  The Processed Set lists sequence numbers of
   previously received Packets, as well as a list of Next Hops to which



Herberg, et al.         Expires December 28, 2012               [Page 9]

Internet-Draft                     DFF                         June 2012


   the Packet has been sent successively as part of the depth-first
   forwarding mechanism.  The set consists of Processed Tuples

      (P_orig_address, P_seq_number, P_prev_hop,
      P_next_hop_neighbor_list, P_time)

   where

      P_orig_address is the Originator Address of the received Packet;

      P_seq_number is the sequence number of the received Packet;

      P_prev_hop is the Address of the Previous Hop of the Packet;

      P_next_hop_neighbor_list is a list of Addresses of Next Hops to
      which the Packet has been sent previously, as part of the depth-
      first forwarding mechanism, as specified in Section 8.2;

      P_time specifies when this Tuple expires and MUST be removed.


6.  Packet Header Fields

   This section specifies the information required by DFF in the Packet
   Header.  Note that, depending on whether DFF is used in the "route-
   over" MoP or in the "mesh-under" MoP, the DFF header is either an
   IPv6 Hop-by-Hop Options extension header (as specified in
   Section 13.1.2) or a LoWPAN header (as specified in Section 13.2.2).
   Those sections specify the precise order, format and encoding of the
   fields that are listed in this section.

   Duplicate Packet Flag (D)  - This 1-bit flag is included in the DFF
      header to indicate that the Packet has been re-sent as a
      duplicate.  The flag MUST be set to 1 by the router that re-sends
      the Packet after detecting link-layer failure to deliver through
      the last attempted Next Hop, as specified in Section 8.2.  Once
      the flag is set to 1, it MUST NOT be modified by routers
      forwarding the Packet.

   Return Packet Flag (R)  - This 1-bit flag is included in the DFF
      header to indicate that the Packet has been returned to the
      Previous Hop after failure to deliver to all the available Next
      Hops.  The flag MUST be set to 1 prior to sending the Packet back
      to the Previous Hop and MUST be set to 0 when a router receives a
      Packet with RET = 1, as specified in Section 8.2.






Herberg, et al.         Expires December 28, 2012              [Page 10]

Internet-Draft                     DFF                         June 2012


   Sequence Number  - A 14-bit field, containing an unsigned integer
      sequence number generated by the Originator, unique to each router
      for each new generated Packet, as specified in Section 12.  The
      Originator Address concatenated with the sequence number
      represents an identifier of previously seen data Packets.  Refer
      to Section 12 for further information about sequence numbers.


7.  Protocol Parameters

   The parameters used in this specification are listed in this section.

   P_HOLD_TIME  - is the time period after which a newly created or
      modified Processed Tuple expires and MUST be deleted.  An
      implementation SHOULD use a value for P_HOLD_TIME that is high
      enough that the Processed Tuples for a Packet is still in memory
      on all forwarding routers while the Packet is transiting the
      routing domain.  The value SHOULD at least be MAX_HOP_LIMIT times
      the expected time to send a Packet to a router on the same link.

   MAX_HOP_LIMIT  - is the initial value of Hop Limit, and therefore the
      maximum number of times that a Packet is forwarded in the routing
      domain.  When choosing the value of MAX_HOP_LIMIT, the size of the
      network, the distance between source and destination in number of
      hops, and the maximum possible "detour" of a Packet SHOULD be
      considered (compared to the shortest path).  Such information MAY
      be used from the RIB, if provided.


8.  Data Packet Generation and Processing

   The following sections specify the process of handling a new Packet,
   generated on a router (Section 8.1), as well as forwarding a data
   Packet from another router (Section 8.2).

8.1.  Data Packet Generation

   This section applies for any data Packets upon their first entry into
   a routing domain, in which DFF is used.  This occurs when a new data
   Packet is generated on this router, or when a data Packet is
   forwarded from outside the routing domain (i.e., from a host attached
   to this router or from a router outside the routing domain in which
   DFF is used).  Before such a data Packet (henceforth denoted "current
   Packet") is transmitted, the following steps MUST be executed:

   1.  If required, encapsulate the Packet as specified in Section 14.





Herberg, et al.         Expires December 28, 2012              [Page 11]

Internet-Draft                     DFF                         June 2012


   2.  Add the DFF header to the current Packet (to the outer header if
       the Packet has been encapsulated), with:

       *  Duplicate Packet Flag (D) := 0;

       *  Return Packet Flag (R) := 0;

       *  Sequence Number := a new sequence number of the Packet (as
          specified in Section 12).

   3.  Select the Next Hop (henceforth denoted "next_hop") for the
       current Packet, as specified in Section 10.

   4.  Add a Processed Tuple to the Processed Set with:

       *  P_orig_address := the Originator Address of the current
          Packet;

       *  P_seq_number := the sequence number of the current Packet;

       *  P_prev_hop := the Originator Address of the current Packet;

       *  P_next_hop_neighbor_list := [next_hop];

       *  P_time := current time + P_HOLD_TIME.

   5.  Pass the current Packet to the underlying link layer for
       transmission to next_hop.  If the transmission fails (as
       determined by the MAC layer), the procedures in Section 9 MUST be
       executed.

8.2.  Data Packet Processing

   When a Packet (henceforth denoted the "current Packet") is received
   by a router, then the following tasks MUST be performed:

   1.  If the Packet Header is malformed (i.e., the header format is not
       as expected by this specification), drop the Packet.

   2.  Otherwise, if the Destination Address of the Packet matches an
       Address of an interface of this router, deliver the Packet to
       upper layers.

   3.  If no Processed Tuple (henceforth denoted the "current tuple")
       exists in the Processed Set, with:






Herberg, et al.         Expires December 28, 2012              [Page 12]

Internet-Draft                     DFF                         June 2012


       +  P_orig_address = the Originator Address of the current Packet,
          AND;

       +  P_seq_number = the sequence number of the current Packet.

       Then:

       1.  Add a Processed Tuple (henceforth denoted the "current
           tuple") with:

           +  P_orig_address := the Originator Address of the current
              Packet;

           +  P_seq_number := the sequence number of the current Packet;

           +  P_prev_hop := the Previous Hop Address of the current
              Packet;

           +  P_next_hop_neighbor_list := [];

           +  P_time := current time + P_HOLD_TIME.

       2.  Decrement the value of the Hop Limit field by one (1).  Drop
           the Packet if Hop Limit is decremented to zero.

       3.  Set RET to 0 in the DFF header.

       4.  Select the Next Hop (henceforth denoted "next_hop") for the
           current Packet, as specified in Section 10.

       5.  P_next_hop_neighbor_list := P_next_hop_neighbor_list@
           [next_hop].

       6.  Pass the current Packet to the underlying link layer for
           transmission to next_hop.  If the transmission fails (as
           determined by the MAC layer), the procedures in Section 9
           MUST be executed.

   4.  Otherwise, if a tuple exists:

       1.  If the return flag of the current Packet is not set (RET = 0)
           (i.e., a loop has been detected):

           1.  Decrement the value of the Hop Limit field by one (1).
               Drop the Packet if Hop Limit is decremented to zero.

           2.  Set RET := 1.




Herberg, et al.         Expires December 28, 2012              [Page 13]

Internet-Draft                     DFF                         June 2012


           3.  Pass the current Packet to the underlying link layer for
               transmission to the Previous Hop.

       2.  Otherwise, if the return flag of the current Packet is set
           (RET = 1):

           1.  If the Previous Hop of the Packet is not contained in
               P_next_hop_neighbor_list of the current tuple, drop the
               Packet.

           2.  Decrement the value of the Hop Limit field by one (1).
               Drop the Packet if Hop Limit is decremented to zero.

           3.  Set RET := 0.

           4.  Select the Next Hop (henceforth denoted "next_hop") for
               the current Packet, as specified in Section 10.

           5.  Modify the current tuple:

               -  P_next_hop_neighbor_list := P_next_hop_neighbor_list@
                  [next_hop];

               -  P_time := current time + P_HOLD_TIME.

           6.  If the selected Next Hop is equal to P_prev_hop of the
               current tuple, as specified in Section 10, (i.e., all
               neighbors have been unsuccessfully tried), set the RET
               flag (RET := 1).  If this router (i.e., the router
               receiving the current packet) has the same Address as the
               Originator Address of the current Packet, drop the
               Packet.

           7.  Pass the current Packet to the underlying link layer for
               transmission to next_hop.  If transmission fails (as
               determined by the MAC layer), the procedures in Section 9
               MUST be executed.


9.  Unsuccessful Packet Transmission

   DFF requires that the underlying link layer provides information as
   to if a Packet is successfully received by the Next Hop. Absence of
   such a signal is interpreted as delivery failure of the Packet
   (henceforth denoted the "current Packet").  Whenever Section 8
   explicitly requests it in case of such a delivery failure, the
   following steps MUST be executed:




Herberg, et al.         Expires December 28, 2012              [Page 14]

Internet-Draft                     DFF                         June 2012


   1.  Set the duplicate flag (DUP) of the DFF header of the current
       Packet to 1.

   2.  Select the Next Hop (henceforth denoted "next_hop") for the
       current Packet, as specified in Section 10.

   3.  Find the Processed Tuple (the "current tuple") in the Processed
       Set, with:

       +  P_orig_address = the Originator Address of the current Packet,
          AND;

       +  P_seq_number = the sequence number of the current Packet,

   4.  If no current tuple is found (e.g., because it has expired), drop
       the Packet.

   5.  Otherwise, modify the current tuple:

       *  P_next_hop_neighbor_list := P_next_hop_neighbor_list@
          [next_hop];

       *  P_time := current time + P_HOLD_TIME.

   6.  If the selected next_hop is equal to P_prev_hop of the current
       tuple, as specified in Section 10 (i.e., all neighbors have been
       unsuccessfully tried):

       *  RET := 1

       *  Decrement the value of the Hop Limit field by one (1).  Drop
          the Packet if Hop Limit is decremented to zero.

   7.  Otherwise

       *  RET := 0

   8.  Transmit the current Packet to next_hop.  If transmission fails
       (determined by the MAC layer), and if the next_hop does not equal
       P_prev_hop from the current tuple, the procedures in Section 9
       MUST be executed.


10.  Determining the Next Hop for a Packet

   When generating or forwarding a Packet, a router determines a valid
   Next Hop for that Packet as specified in Section 8.  This section
   specifies how to select the Next Hop (henceforth denoted "next_hop").



Herberg, et al.         Expires December 28, 2012              [Page 15]

Internet-Draft                     DFF                         June 2012


   As a Processed Tuple was either existing when receiving the Packet
   (henceforth denoted the "current Packet"), or otherwise was created,
   it can be assumed the a Processed Tuple for that Packet (henceforth
   denoted the "current tuple") is available.

   The Next Hop is chosen from a list of candidate Next Hops in order of
   decreasing priority.  This list is only a suggestion, any other way
   of constructing the list MAY be used.  The list SHOULD NOT contain
   Addresses which are listed in P_next_hop_neighbor_list of the current
   tuple, in order to avoid sending the Packet to the same neighbor
   multiple times.  Moreover, an Address SHOULD NOT appear more than
   once in the list, for the same reason.

   1.  If the RIB of the router contains one or more entries
       corresponding to the Destination, add the Next Hop(s) from these
       entries to the list of Next Hops for the Packet, where entries
       with lower cost have a higher preference.

   2.  Add a subset or all other neighbors from an external neighborhood
       discovery process.

   If the candidate Next Hop list so created is empty, the selected Next
   Hop MUST be P_prev_hop of the current tuple; this case applies when
   returning the Packet to the Previous Hop.


11.  Informing the Routing Protocol

   When a Packet is returned (i.e., a Packet with RET = 1 is received by
   a router) or a link layer acknowledgment (ACK) has not been received
   for a forwarded Packet, an external mechanism (not specified in this
   document) MAY use this information to increase the cost for the route
   in the RIB, and/or to inform the routing protocol.  Care has to be
   taken by this external mechanism not to create loops.  The rationale
   for such a mechanism is to update routes based on information from
   DFF, so that future packet transmissions will take better routes.


12.  Sequence Numbers

   Whenever a router generates a Packet or forwards a Packet on behalf
   of a host or a router outside the routing domain where DFF is used, a
   sequence number MUST be created and included in the DFF header.  This
   sequence number MUST be unique locally on each router where it is
   created.  A sequence number MUST start at 0 for the first generated
   Packet, and then increase in steps of 1 for each new Packet.  The
   sequence number MUST not be greater than 16383 and MUST wrap around
   to 0.



Herberg, et al.         Expires December 28, 2012              [Page 16]

Internet-Draft                     DFF                         June 2012


13.  Modes of Operation

   DFF can be used either as "route-over" IPv6 forwarding protocol, or
   alternatively as "mesh-under" data forwarding protocol for the LoWPAN
   adaptation layer ([RFC4944]).  Previous sections have specified the
   DFF mechanism in general; specific differences for each MoP are
   specified in this section.

13.1.  Route-Over

   This section maps the general terminology from Section 2.2 to the
   specific terminology when using the "route-over" MoP.

13.1.1.  Mapping of IPv6 Terminology to DFF

   The following terms are those listed in Section 2.2, and their
   meaning is explicitly defined when DFF is used in the "route-over"
   MoP:

   Packet  - An IPv6 packet, as specified in [RFC2460].

   Packet Header  - An IPv6 extension header, as specified in [RFC2460].

   Address  - An IPv6 address, as specified in [RFC4291].

   Originator Address  - The Originator Address corresponds to the
      Source address field of the IPv6 header as specified in [RFC2460].

   Destination Address  - The Destination Address corresponds to the
      Destination field of the IPv6 header as specified in [RFC2460].

   Next Hop  - The Next Hop is the IPv6 address of the next hop to which
      the Packet is sent; the MAC address from that IP address is
      resolved by a mechanism such as ND [RFC4861].  The MAC address is
      then used by L2 as destination.

   Previous Hop  - The Previous Hop is the IPv6 address from the
      interface of the previous hop from which the Packet has been
      received.

   Hop Limit  - The Hop Limit corresponds to the Hop Limit field in the
      IPv6 header as specified in [RFC2460].

13.1.2.  Packet Format

   In the "router-over" MoP, all IPv6 Packets MUST conform with the
   format specified in [RFC2460].




Herberg, et al.         Expires December 28, 2012              [Page 17]

Internet-Draft                     DFF                         June 2012


   The DFF header, as specified below, is an IPv6 Extension Hop-by-Hop
   Options header, and is depicted in Figure 1.  This document specifies
   a new option to be used inside the Hop-by-Hop Options header, which
   contains the DFF fields (D, and R flags and sequence number, as
   specified in Section 6).

   [RFC6564] specifies:

      New options for the existing Hop-by-Hop Header SHOULD NOT be
      created or specified unless no alternative solution is feasible.
      Any proposal to create a new option for the existing Hop-by-Hop
      Header MUST include a detailed explanation of why the hop-by-hop
      behavior is absolutely essential in the document proposing the new
      option with hop-by-hop behavior.

   [RFC6564] recommends to use Destination Headers instead of Hop-by-Hop
   Option headers.  Destination Headers are only read by the destination
   of an IPv6 packet, not by intermediate routers.  However, the
   mechanism specified in this document relies on intermediate routers
   reading and editing the header.  Specifically, the sequence number
   and the D and R flags are read by each router running the DFF
   protocol.  Modifying the D flag and R flag is essential for this
   protocol to tag duplicate or returned Packets.  Without the D flag, a
   duplicate Packet cannot be discerned from a looping Packet, and
   without the R flag, a returned Packet cannot be discerned from a
   looping Packet.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |  Hdr Ext Len  |  OptTypeDFF   | OptDataLenDFF |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |D|R|      Sequence Number      |0|0|0|0|0|0|0|1|0|0|0|0|0|0|0|0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 1: IPv6 DFF Header

   Field definitions of the DFF header are as follows:

   Next Header  - 8-bit selector.  Identifies the type of header
      immediately following the Hop-by-Hop Options header.  As specified
      in [RFC2460].

   Hdr Ext Len  - 8-bit unsigned integer.  Length of the Hop-by-Hop
      Options header in 8-octet units, not including the first 8 octets.
      As specified in [RFC2460].  This value is set to 0 (zero).




Herberg, et al.         Expires December 28, 2012              [Page 18]

Internet-Draft                     DFF                         June 2012


   OptTypeDFF  - 8-bit identifier of the type of option as specified in
      [RFC2460].  This value is set to IP_DFF.  The two high order bits
      of the option type MUST be set to '00' and the third bit is equal
      to '1'.  With these bits, according to [RFC2460], routers that do
      not understand this option on a received Packet skip over this
      option and continue processing the header.  Also, according to
      [RFC2460], the values within the option are expected to change en
      route.

   OptDataLenDFF  - 8-bit unsigned integer.  Length of the Option Data
      field of this option, in octets as specified in [RFC2460].  This
      value is set to 2 (two).

   DFF fields  - The D and R flags and the sequence number follow, as
      specified in Section 6.

   PadN  - Since the Hop-by-Hop Options header must have a length of
      multiples of 8 octets, a PadN option with length N=2 is used, as
      specified in [RFC2460].

13.2.  Mesh-Under

   This section maps the general terminology from Section 2.2 to the
   specific terminology when using the "mesh-under" MoP.

13.2.1.  Mapping of LoWPAN Terminology to DFF

   The following terms are those listed in Section 2.2 (besides "Mode of
   Operation"), and their meaning is explicitly defined when DFF is used
   in the "mesh-under" MoP:

   Packet  - A "LoWPAN encapsulated packet" (as specified in [RFC4944],
      which contains an IPv6 packet as payload.

   Packet Header  - A LoWPAN header, as specified in [RFC4944].

   Address  - A 16-bit short or EUI-64 link layer address, as specified
      in [RFC4944].

   Originator Address  - The Originator Address corresponds to the
      Originator Address field of the Mesh Addressing header as
      specified in [RFC4944].

   Destination Address  - The Destination Address corresponds to the
      Final Destination field of the Mesh Addressing header as specified
      in [RFC4944].





Herberg, et al.         Expires December 28, 2012              [Page 19]

Internet-Draft                     DFF                         June 2012


   Next Hop  - The Next Hop is the destination address of a frame
      containing a LoWPAN encapsulated packet, as specified in
      [RFC4944].

   Previous Hop  - The Previous Hop is the source address of the frame
      containing a LoWPAN encapsulated packet, as specified in
      [RFC4944].

   Hop Limit  - The Hop Limit corresponds to the Deep Hops Left field in
      the Mesh Addressing header as specified in [RFC4944].

13.2.2.  Packet Format

   In the "mesh-under" MoP, all IPv6 Packets MUST conform with the
   format specified in [RFC4944].  All data Packets exchanged by routers
   using this specification MUST contain the Mesh Addressing header as
   part of the LoWPAN encapsulation, as specified in [RFC4944].

   The DFF header, as specified below, MUST follow the Mesh Addressing
   header.  After these two headers, any other LoWPAN header, e.g.,
   header compression or fragmentation headers, MAY also be added before
   the actual payload.  Figure 2 depicts the Mesh Addressing header
   defined in [RFC4944], and Figure 3 depicts the DFF header.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 0|V|F|HopsLft| DeepHopsLeft  |orig. address, final address...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 2: Mesh Addressing Header


                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 1| Mesh Forw |D|R|      sequence number      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 3: Header for DFF data Packets

   Field definitions of the Mesh Addressing header are as specified in
   [RFC4944].  When adding that header to the LoWPAN encapsulation on
   the Originator, the fields of the Mesh Addressing header MUST be set
   to the following values:




Herberg, et al.         Expires December 28, 2012              [Page 20]

Internet-Draft                     DFF                         June 2012


   o  V := 0 if the Originator Address is an IEEE extended 64-bit
      address (EUI-64); otherwise, V := 1 if it is a short 16-bit
      address.

   o  F := 0 if the Final Destination Address is an IEEE extended 64-bit
      address (EUI-64); otherwise, F := 1 if it is a short 16-bit
      address.

   o  Hops Left := 0xF (i.e., reserved value indicating that the Deep
      Hops Left field is following);

   o  Deep Hops Left := MAX_HOP_LIMIT.

   Field definitions of the DFF header are as follows:

   Mesh Forw  - A 6-bit identifier that allows for the use of different
      mesh forwarding mechanisms.  As specified in [RFC4944], additional
      mesh forwarding mechanisms should use the reserved dispatch byte
      values following LOWPAN_BCO; therefore, 0 1 MUST precede Mesh
      Forw.  The value of Mesh Forw is LOWPAN_DFF.

   DFF fields  - The D and R flags and the sequence number follow after
      Mesh Forw, as specified in Section 6.


14.  Scope Limitation of DFF

   The forwarding mechanism specified in this document MUST be limited
   in scope to the routing domain in which DFF is used.  That also
   implies that any headers specific to DFF do not traverse the
   boundaries of the routing domain.  This section specifies, both for
   the "route-over" MoP and the "mesh-under" MoP, how to limit the scope
   of DFF to the routing domain in which it is used.

   Figure 4 to Figure 7 depict four different cases for source and
   destination of traffic with regards to the scope of the routing
   domain in which DFF is used.  Section 14.2 and Section 14.1 specify
   how routers limit the scope of DFF for the "route-over" MoP and the
   "mesh-under" MoP respectively for these cases.  In these sections,
   all routers "inside the routing domain" use DFF, and all sources or
   destinations "outside the routing domain" are either hosts attached
   to a router running DFF or routers not running DFF.









Herberg, et al.         Expires December 28, 2012              [Page 21]

Internet-Draft                     DFF                         June 2012


                        +-----------------+
                        |                 |
                        |  (S) ----> (D)  |
                        |                 |
                        +-----------------+
                        Routing Domain


         Figure 4: Traffic within the routing domain (from S to D)


                        +-----------------+
                        |                 |
                        |  (S) --------> (R) --------> (D)
                        |                 |
                        +-----------------+
                        Routing Domain


    Figure 5: Traffic from within the routing domain to outside of the
                           domain (from S to D)


                        +-----------------+
                        |                 |
         (S) --------> (R) --------> (D)  |
                        |                 |
                        +-----------------+
                        Routing Domain


      Figure 6: Traffic from outside the routing domain to inside the
                           domain (from S to D)


                        +-----------------+
                        |                 |
         (S) --------> (R1) -----------> (R2) --------> (D)
                        |                 |
                        +-----------------+
                        Routing Domain


     Figure 7: Traffic from outside the routing domain, traversing the
        domain and then to the outside of the domain  (from S to D)






Herberg, et al.         Expires December 28, 2012              [Page 22]

Internet-Draft                     DFF                         June 2012


14.1.  Route-Over MoP

   In Figure 4, both the source and destination of the traffic are
   routers within the routing domain in which DFF is used.  If traffic
   is originated at S, the DFF header is added to the IPv6 header (as
   specified in Section 13.1.2).  The Originator Address is set to S and
   the Destination Address is set to D. The packet is forwarded to D
   using this specification.  When router D receives the packet, it
   decapsulates the inner IPv6 packet if encapsulation was used, and
   then processes the payload of the IPv6 packet in upper layers.

   In Figure 5, the source of the traffic (S) is within the routing
   domain in which DFF is used, and the destination (D) is outside of
   the routing domain.  If traffic is originated at router S, the IPv6
   packet MUST be encapsulated according to [RFC2473], and the DFF
   header added to the outer IPv6 header.  The Originator Address is set
   to S and the Destination Address is set to R (in the outer IPv6
   header).  The packet is forwarded to R using this specification.
   When router R receives the packet, it decapsulates the IPv6 packet
   and forwards the inner IPv6 packet to D, using normal IPv6 forwarding
   as specified in [RFC2460].

   In Figure 6, the source of the traffic (S) is outside of the routing
   domain in which DFF is used, and the destination (D) is inside of the
   routing domain.  For traffic originated at S, the IPv6 packet is
   forwarded to R using normal IPv6 forwarding as specified in
   [RFC2460].  Router R MUST encapsulate the IPv6 packet according to
   [RFC2473], and add the DFF header (as specified in Section 13.1.2) to
   the outer IPv6 header.  The Originator Address is set to R, the
   Destination Address to D (both in the outer IPv6 header), the
   sequence number in the DFF header is generated locally on R. The
   packet is forwarded to D using this specification.  When router D
   receives the packet, it decapsulates the inner IPv6 packet and
   processes the payload of the inner IPv6 packet in upper layers.

   In Figure 7, both the source of the traffic (S) and the destination
   (D) are outside of the routing domain in which DFF is used.  For
   traffic originated at S, the IPv6 packet is forwarded to R1 using
   normal IPv6 forwarding as specified in [RFC2460].  Router R1 MUST
   encapsulate the IPv6 packet according to [RFC2473] and add the DFF
   header (as specified in Section 13.1.2).  The Originator Address is
   set to R1, the Destination Address to R2 (both in the outer IPv6
   header), the sequence number in the DFF header is generated locally
   on R1.  The packet is forwarded to R2 using this specification.  When
   router R2 receives the packet, it decapsulates the inner IPv6 packet
   and forwards the inner IPv6 packet to D, using normal IPv6 forwarding
   as specified in [RFC2460].




Herberg, et al.         Expires December 28, 2012              [Page 23]

Internet-Draft                     DFF                         June 2012


14.2.  Mesh-Under MoP

   In Figure 4, both the source and destination of the traffic are
   routers within the routing domain in which DFF is used.  If traffic
   is originated at router S, the LoWPAN encapsulated packet is created
   from the IPv6 packet as specified in [RFC4944].  Then, the Mesh
   Addressing header and the DFF header (as specified in Section 13.2.2)
   are added to the LoWPAN encapsulation on router S. The Originator
   Address is set to S and the Destination Address is set to D. The
   packet is then forwarded using this specification.  When router D
   receives the packet, it processes the payload of packet in upper
   layers.

   In Figure 5, the source of the traffic (S) is within the routing
   domain in which DFF is used, and the destination (D) is outside of
   the routing domain.  For traffic originated at router S, the LoWPAN
   encapsulated packet is created from the IPv6 packet as specified in
   [RFC4944].  Then, the Mesh Addressing header and the DFF header (as
   specified in Section 13.2.2) are added to the LoWPAN encapsulation on
   router S. The Originator Address is set to S and the Destination
   Address is set to R. The packet is then forwarded using this
   specification.  When router R receives the packet, it restores the
   IPv6 packet from the LoWPAN encapsulated packet and forwards it to D,
   using normal IPv6 forwarding as specified in [RFC2460].

   In Figure 6, the source of the traffic (S) is outside of the routing
   domain in which DFF is used, and the destination (D) is inside of the
   routing domain.  For traffic originated at S, the IPv6 packet is
   forwarded to R using normal IPv6 forwarding as specified in
   [RFC2460].  Router R creates the LoWPAN encapsulated packet from the
   IPv6 packet as specified in [RFC4944].  Then, R adds the Mesh
   Addressing header and the DFF header (as specified in
   Section 13.2.2).  The Originator Address is set to R, the Destination
   Address to D, the sequence number in the DFF header is generated
   locally on R. The packet is forwarded to D using this specification.
   When router D receives the packet, it restores the IPv6 packet from
   the LoWPAN encapsulated packet and processes the payload in upper
   layers.

   In Figure 7, both the source of the traffic (S) and the destination
   (D) are outside of the routing domain in which DFF is used.  For
   traffic originated at S, the IPv6 packet is forwarded to R1 using
   normal IPv6 forwarding as specified in [RFC2460].  Router R1 creates
   the LoWPAN encapsulated packet from the IPv6 packet as specified in
   [RFC4944].  Then, it adds the Mesh Addressing header and the DFF
   header (as specified in Section 13.2.2).  The Originator Address is
   set to R1, the Destination Address to R2, the sequence number in the
   DFF header is generated locally on R1.  The packet is forwarded to R2



Herberg, et al.         Expires December 28, 2012              [Page 24]

Internet-Draft                     DFF                         June 2012


   using this specification.  When router R2 receives the packet, it
   restores the IPv6 packet from the LoWPAN encapsulated packet and
   forwards the IPv6 packet to D, using normal IPv6 forwarding as
   specified in [RFC2460].


15.  Security Considerations

   Based on the recommendations in [RFC3552], this section describes
   security threats to DFF, lists which attacks are out of scope, which
   attacks DFF is susceptible to, and which attacks DFF protects
   against.

15.1.  Attacks Out of Scope

   As DFF is a data forwarding protocol, any security issues concerning
   the payload of the Packets are not considered in this section.

   It is the responsibility of upper layers to use appropriate security
   mechanisms (IPsec, TLS, ...) according to application requirements.
   As DFF does not modify the contents of IP datagrams, other than the
   DFF header (which is a Hop-by-Hop Options extension header in the
   "route-over" MoP, and therefore not protected by IPsec), no special
   considerations for IPsec have to be addressed.

   Any attack that is not specific to DFF, but that applies in general
   to the link layer (e.g., wireless, PLC), is out of scope.  In
   particular, these attacks are: Eavesdropping, Packet insertion,
   Packet replaying, Packet deletion, and man-in-the-middle attacks.
   Appropriate MAC-layer encryption can mitigate part of these attacks
   and is therefore RECOMMENDED.

15.2.  Protection Mechanisms of DFF

   DFF itself does not provide any additional integrity, confidentiality
   or authentication.  Therefore, the level of protection of DFF depends
   on the underlying link layer security as well as protection of the
   payload by upper layer security (e.g., IPsec).

   In the following sections, whenever encrypting or digitally signing
   Packets is suggested for protecting DFF, it is assumed that routers
   are not compromised.

15.3.  Attacks In Scope

   This section discusses security threats to DFF, and for each
   describes whether (and how) DFF is affected by the threat.  DFF is
   designed to be used in lossy and unreliable networks.  Predominant



Herberg, et al.         Expires December 28, 2012              [Page 25]

Internet-Draft                     DFF                         June 2012


   examples of lossy networks are wireless networks, where routers send
   Packets via broadcast.  The attacks listed below are easier to
   exploit in wireless media, but can also be observed in wired
   networks.

15.3.1.  Denial of Service

   Denial of Service attacks are possible when using DFF by either
   exceeding the storage on a router, or by exceeding the available
   bandwidth of the channel.  As DFF does not contain any algorithms
   with high complexity, it is unlikely that the processing power of the
   router could be exhausted by an attack on DFF.

   The storage of a router can be exhausted by increasing the size of
   the Processed Set, i.e., by adding new tuples, or by increasing the
   size of each tuple.  New tuples can be added by injecting new Packets
   in the network, or by forwarding overheard Packets.

   Another possible DoS attack is to send Packets to a non-existing
   Address in the network.  DFF would perform a depth-first search until
   the Hop Limit has reached zero.  Is is therefore RECOMMENDED to set
   the Hop Limit to a value that limits the path length.

   If security provided by the MAC layer is used, this attack can be
   mitigated if the malicious router does not possess valid credentials,
   since other routers would not forward data through the malicious
   router.

15.3.2.  Packet Header Modification

   The following attacks can be exploited by modifying the Packet Header
   information, unless additional security (such as MAC layer security)
   is used:

15.3.2.1.  Return Flag Tampering

   A malicious router may tamper the "return" flag of a DFF Packet, and
   send it back to the previous hop, but only if that router had been
   selected as next hop by the receiving router before (as specified in
   Section 8.2).  If the malicious router had not been selected as next
   hop, then a returned Packet is dropped by the receiving router.  If,
   otherwise, the malicious router had been selected as next hop by the
   receiving router, and the malicious router has set the return flag,
   the receiving router would then try alternative neighbors.  This may
   lead to Packets never reaching their Destination, as well as
   unnecessary depth-first search in the network (bandwidth exhaustion /
   energy drain).




Herberg, et al.         Expires December 28, 2012              [Page 26]

Internet-Draft                     DFF                         June 2012


   This attack can be mitigated by using appropriate security of the
   underlying link layer.

15.3.2.2.  Duplicate Flag Tampering

   A malicious router may modify the Duplicate Flag of a Packet that it
   forwards.

   If it changes the flag from 0 to 1, the Packet would be detected as
   duplicate by other routers in the network and not as looping packet.
   This may have an impact on route repair mechanisms, if an external
   mechanism as described in Section 11 is used.

   If the Duplicate Flag is set from 1 to 0, and a router receives that
   Packet for the second time (i.e., it has already received a Packet
   with the same Originator Address and sequence number before), it will
   wrongly detect a loop.  This may have an impact on route repair
   mechanisms, if an external mechanism as described in Section 11 is
   used.

   This attack can be mitigated by using appropriate security of the
   underlying link layer.


16.  IANA Considerations

   IANA is requested to allocate a value from the Dispatch Type Field
   registry for LOWPAN_DFF.

   IANA is requested to allocate a value from the Destination Options
   and Hop-by-Hop Options registry for IP_DFF.  The first three bits of
   that value MUST be 001.


17.  Acknowledgements

   Jari Arkko (Ericsson), Antonin Bas (Ecole Polytechnique), Thomas
   Clausen (Ecole Polytechnique), Yuichi Igarashi (Hitachi), Kazuya
   Monden (Hitachi), Geoff Mulligan (Proto6), Hiroki Satoh (Hitachi),
   Ganesh Venkatesh (Mobelitix), and Jiazi Yi (Ecole Polytechnique)
   provided useful reviews of the draft and discussions which helped to
   improve this document.


18.  References






Herberg, et al.         Expires December 28, 2012              [Page 27]

Internet-Draft                     DFF                         June 2012


18.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

   [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
              M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
              RFC 6564, April 2012.

18.2.  Informative References

   [DFF_paper1]
              Cespedes, S., Cardenas, A., and T. Iwao, "Comparison of
              Data Forwarding Mechanisms for AMI Networks",  2012 IEEE
              Innovative Smart Grid Technologies Conference (ISGT),
              January 2012.

   [DFF_paper2]
              Iwao, T., Iwao, T., Yura, M., Nakaya, Y., Cardenas, A.,
              Lee, S., and R. Masuoka, "Dynamic Data Forwarding in
              Wireless Mesh Networks",  First IEEE International
              Conference on Smart Grid Communications (SmartGridComm),
              October 2010.

   [KCEC_press_release]
              Kit Carson Electric Cooperative (KCEC), "DFF deployed by
              KCEC (Press Release)",  http://www.kitcarson.com/
              index.php?option=com_content&view=article&id=45&Itemid=1,



Herberg, et al.         Expires December 28, 2012              [Page 28]

Internet-Draft                     DFF                         June 2012


              2011.

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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.


Appendix A.  Examples

   In this section, some example network topologies are depicted, using
   the DFF mechanism for data forwarding.  In these examples, it is
   assumed that a routing protocol is running which adds or inserts
   entries into the RIB.

A.1.  Example 1: Normal Delivery

   Figure 8 depicts a network topology with seven routers A to G, with
   links between them as indicated by lines.  It is assumed that router
   A sends a Packet to G, through B and D, according to the routing
   protocol.

                                        +---+
                                    +---+ D +-----+
                                    |   +---+     |
                            +---+   |             |
                        +---+ B +---+             |
                        |   +---+   |             |
                      +-+-+         |   +---+   +-+-+
                      | A |         +---+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        |   +---+                 |
                        +---+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

                   Figure 8: Example 1: normal delivery

   If no link fails in this topology, and no loop occurs, then DFF
   forward the Packet along the Next Hops listed in each of the routers
   RIB along the path towards the destination.  Each router adds a
   Processed Tuple for the incoming Packet, and selects the Next Hop as
   specified in Section 10, i.e., it will first select the next hop for



Herberg, et al.         Expires December 28, 2012              [Page 29]

Internet-Draft                     DFF                         June 2012


   router G as determined by the routing protocol.

A.2.  Example 2: Forwarding with Link Failure

   Figure 9 depicts the same topology as the Example 1, but both links
   between B and D and between B and E are unavailable (e.g., because of
   wireless link characteristics).

                                        +---+
                                    XXX-+ D +-----+
                                    X   +---+     |
                            +---+   X             |
                        +---+ B +---+             |
                        |   +---+   X             |
                      +-+-+         X   +---+   +-+-+
                      | A |         XXXX+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        |   +---+                 |
                        +---+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

                     Figure 9: Example 2: link failure

   When B receives the Packet from router A, it adds a Processed Tuple,
   and then tries to forward the Packet to D. Once B detects that the
   Packet cannot be successfully delivered to D because it does not
   receive link layer ACKs, it will follow the procedures listed in
   Section 9, by setting the DUP flag to 1, selecting E as new next hop,
   adding E to the list of next hops in the Processed Tuple, and then
   forwarding the Packet to E.

   As the link to E also fails, B will again follow the procedure in
   Section 9.  As all possible next hops (D and E) are listed in the
   Processed Tuple, B will set the RET flag in the Packet and return it
   to A.

   A determines that it already has a Processed Tuple for the returned
   Packet, reset the RET flag of the Packet and select a new next hop
   for the Packet.  As B is already in the list of next hops in the
   Processed Tuple, it will select C as next hop and forward the Packet
   to it.  C will then forward the Packet to F, and F delivers the
   Packet to its Destination G.






Herberg, et al.         Expires December 28, 2012              [Page 30]

Internet-Draft                     DFF                         June 2012


A.3.  Example 3: Forwarding with Missed Link Layer Acknowledgment

   Figure 10 depicts the same topology as the Example 1, but the link
   layer acknowledgments from C to A are lost (e.g., because the link is
   uni-directional).  It is assumed that A prefers a path to G through C
   and F.

                                        +---+
                                    +---+ D +-----+
                                    |   +---+     |
                            +---+   |             |
                        +---+ B +---+             |
                        |   +---+   |             |
                      +-+-+         |   +---+   +-+-+
                      | A |         +---+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        .   +---+                 |
                        +...+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

          Figure 10: Example 3: missed link layer acknowledgment

   While C successfully receives the Packet from A, A does not receive
   the L2 ACK and assumes the Packet has not been delivered to C.
   Therefore, it sets the DUP flag of the Packet to 1, in order to
   indicate that this Packet may be a duplicate.  Then, it forwards the
   Packet to B.

A.4.  Example 4: Forwarding with a Loop

   Figure 11 depicts the same topology as the Example 1, but there is a
   loop from D to A, and A sends the Packet to G through B and D.
















Herberg, et al.         Expires December 28, 2012              [Page 31]

Internet-Draft                     DFF                         June 2012


                        +-----------------+
                        |                 |
                        |               +-+-+
                        |           +---+ D +
                        |           |   +---+
                       \|/  +---+   |
                        +---+ B +---+
                        |   +---+   |
                      +-+-+         |   +---+   +-+-+
                      | A |         +---+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        |   +---+                 |
                        +---+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

                        Figure 11: Example 4: loop

   When A receives the Packet through the loop from D, it will find a
   Processed Tuple for the Packet.  Router A will set the RET flag and
   return the Packet to D, which in turn will return it to B. B will
   then select E as next hop, which will then forward it to G.


Appendix B.  Deployment Experience

   DFF has been deployed and experimented with both in real deployments
   and in network simulations, as described in the following.

B.1.  Deployments in Japan

   The majority of the large Advanced Metering Infrastructure (AMI)
   deployments using DFF are located in Japan, but the data of these
   networks is property of Japanese utilities and cannot be disclosed.

B.2.  Kit Carson Electric Cooperative

   DFF has been deployed at Kit Carson Electric Cooperative (KCEC), a
   non-profit organization distributing electricity to about 30,000
   customers in New Mexico.  As described in a press release
   [KCEC_press_release], DFF is running on currently about 400 electric
   meters, and will be further extended to 2,100 meters in summer 2012.
   All meters are connected through a mesh network using an unreliable,
   wireless medium.  DFF is used together with a distance vector routing
   protocol.  Metering data from each meter is sent towards a gateway
   periodically every 15 minutes.  The data delivery reliability is over



Herberg, et al.         Expires December 28, 2012              [Page 32]

Internet-Draft                     DFF                         June 2012


   99%.

B.3.  Simulations

   DFF has been evaluated in OMNEST simulations, in conjunction with a
   distance vector routing protocol.  The performance of DFF has been
   compared to using only the routing protocol without DFF.  The results
   published in peer-reviewed academic papers ([DFF_paper1][DFF_paper2])
   show significant improvements of the Packet delivery ratio compared
   to using only the distance vector protocol.

B.4.  Open Source Implementation

   Fujitsu Laboratories of America is currently working on an open
   source implementation of DFF, which is to be released in 2012, and
   which allows for interoperability testings of different DFF
   implementations.  The implementation is written in Java, and can be
   used both on real machines and in the Ns2 simulator.


Authors' Addresses

   Ulrich Herberg (editor)
   Fujitsu
   1240 E. Arques Avenue, M/S 345
   Sunnyvale, CA  94085
   US

   Phone: +1 408 530-4528
   Email: ulrich.herberg@us.fujitsu.com


   Alvaro A. Cardenas
   Fujitsu
   1240 E. Arques Avenue, M/S 345
   Sunnyvale, CA  94085
   US

   Phone: +1 408 530-4516
   Email: alvaro.cardenas-mora@us.fujitsu.com











Herberg, et al.         Expires December 28, 2012              [Page 33]

Internet-Draft                     DFF                         June 2012


   Tadashige Iwao
   Fujitsu
   Shiodome City Center, 5-2, Higashi-shimbashi 1-chome, Minato-ku
   Tokyo,
   JP

   Phone: +81-44-754-3343
   Email: smartnetpro-iwao_std@ml.css.fujitsu.com


   Michael L. Dow
   Freescale
   6501 William Cannon Drive West
   Austin, TX  78735
   USA

   Phone: +1 512 895 4944
   Email: m.dow@freescale.com


   Sandra L. Cespedes
   U. Icesi/U. of Waterloo
   Calle 18 No. 122-135 Pance
   Cali, Valle
   Colombia

   Phone:
   Email: slcesped@bbcr.uwaterloo.ca























Herberg, et al.         Expires December 28, 2012              [Page 34]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/