doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6554.txt b/doc/rfc/rfc6554.txt
new file mode 100644
index 0000000..67e55e5
--- /dev/null
+++ b/doc/rfc/rfc6554.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            J. Hui
+Request for Comments: 6554                                   JP. Vasseur
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                                D. Culler
+                                                             UC Berkeley
+                                                               V. Manral
+                                                     Hewlett Packard Co.
+                                                              March 2012
+
+
+             An IPv6 Routing Header for Source Routes with
+      the Routing Protocol for Low-Power and Lossy Networks (RPL)
+
+Abstract
+
+   In Low-Power and Lossy Networks (LLNs), memory constraints on routers
+   may limit them to maintaining, at most, a few routes.  In some
+   configurations, it is necessary to use these memory-constrained
+   routers to deliver datagrams to nodes within the LLN.  The Routing
+   Protocol for Low-Power and Lossy Networks (RPL) can be used in some
+   deployments to store most, if not all, routes on one (e.g., the
+   Directed Acyclic Graph (DAG) root) or a few routers and forward the
+   IPv6 datagram using a source routing technique to avoid large routing
+   tables on memory-constrained routers.  This document specifies a new
+   IPv6 Routing header type for delivering datagrams within a RPL
+   routing domain.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc6554.
+
+
+
+
+
+
+
+
+
+
+
+Hui, et al.                  Standards Track                    [Page 1]
+
+RFC 6554                 RPL Source Route Header              March 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. Introduction ....................................................2
+      1.1. Requirements Language ......................................3
+   2. Overview ........................................................3
+   3. Format of the RPL Routing Header ................................6
+   4. RPL Router Behavior .............................................8
+      4.1. Generating Source Routing Headers ..........................8
+      4.2. Processing Source Routing Headers ..........................9
+   5. Security Considerations ........................................11
+      5.1. Source Routing Attacks ....................................11
+      5.2. ICMPv6 Attacks ............................................12
+   6. IANA Considerations ............................................12
+   7. Acknowledgements ...............................................12
+   8. References .....................................................12
+      8.1. Normative References ......................................12
+      8.2. Informative References ....................................13
+
+1.  Introduction
+
+   The Routing Protocol for Low-Power and Lossy Networks (RPL) is a
+   distance vector IPv6 routing protocol designed for Low-Power and
+   Lossy Networks (LLNs) [RFC6550].  Such networks are typically
+   constrained in resources (limited communication data rate, processing
+   power, energy capacity, memory).  In particular, some LLN
+   configurations may utilize LLN routers where memory constraints limit
+   nodes to maintaining only a small number of default routes and no
+   other destinations.  However, it may be necessary to utilize such
+   memory-constrained routers to forward datagrams and maintain
+   reachability to destinations within the LLN.
+
+
+
+
+
+
+Hui, et al.                  Standards Track                    [Page 2]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   To utilize paths that include memory-constrained routers, RPL relies
+   on source routing.  In one deployment model of RPL, more-capable
+   routers collect routing information and form paths to arbitrary
+   destinations within a RPL routing domain.  However, a source routing
+   mechanism supported by IPv6 is needed to deliver datagrams.
+
+   This document specifies the Source Routing Header (SRH) for use
+   strictly between RPL routers in the same RPL routing domain.  A RPL
+   routing domain is a collection of RPL routers under the control of a
+   single administration.  The boundaries of routing domains are defined
+   by network management by setting some links to be exterior, or inter-
+   domain, links.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Overview
+
+   The format of the SRH draws from that of the Type 0 Routing header
+   (RH0) [RFC2460].  However, the SRH introduces mechanisms to compact
+   the source route entries when all entries share the same prefix with
+   the IPv6 Destination Address of a packet carrying an SRH, a typical
+   scenario in LLNs using source routing.  The compaction mechanism
+   reduces consumption of scarce resources such as channel capacity.
+
+   The SRH also differs from RH0 in the processing rules to alleviate
+   security concerns that led to the deprecation of RH0 [RFC5095].
+   First, RPL routers implement a strict source route policy where each
+   and every IPv6 hop between the source and destination of the source
+   route is specified within the SRH.  Note that the source route may be
+   a subset of the path between the actual source and destination and is
+   discussed further below.  Second, an SRH is only used between RPL
+   routers within a RPL routing domain.  RPL Border Routers, responsible
+   for connecting other RPL routing domains and IP domains that use
+   other routing protocols, do not allow datagrams already carrying an
+   SRH header to enter or exit a RPL routing domain.  Third, a RPL
+   router drops datagrams that include multiple addresses assigned to
+   any interfaces on that router to avoid forwarding loops.
+
+   There are two cases that determine how to include an SRH when a RPL
+   router requires the use of an SRH to deliver a datagram to its
+   destination.
+
+
+
+
+
+
+Hui, et al.                  Standards Track                    [Page 3]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   1.  If the SRH specifies the complete path from source to
+       destination, the router places the SRH directly in the datagram
+       itself.
+
+   2.  If the SRH only specifies a subset of the path from source to
+       destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and
+       places the SRH in the outer IPv6 header.  Use of tunneling
+       ensures that the datagram is delivered unmodified and that ICMP
+       errors return to the source of the SRH rather than the source of
+       the original datagram.
+
+   In a RPL network, Case 1 occurs when both source and destination are
+   within a RPL routing domain and a single SRH is used to specify the
+   entire path from source to destination, as shown in the following
+   figure:
+
+                           +--------------------+
+                           |                    |
+                           |  (S) -------> (D)  |
+                           |                    |
+                           +--------------------+
+                             RPL Routing Domain
+
+
+   In the above scenario, datagrams traveling from source, S, to
+   destination, D, have the following packet structure:
+
+                   +--------+---------+-------------//-+
+                   | IPv6   | Source  | IPv6           |
+                   | Header | Routing | Payload        |
+                   |        | Header  |                |
+                   +--------+---------+-------------//-+
+
+   S's address is carried in the IPv6 header's Source Address field.
+
+   D's address is carried in the last entry of the SRH for all but the
+   last hop, when D's address is carried in the IPv6 header's
+   Destination Address field of the packet carrying the SRH.
+
+   In a RPL network, Case 2 occurs for all datagrams that have a source
+   and/or destination outside the RPL routing domain, as shown in the
+   following diagram:
+
+
+
+
+
+
+
+
+
+Hui, et al.                  Standards Track                    [Page 4]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+                            +-----------------+
+                            |                 |
+                            |  (S) --------> (R) --------> (D)
+                            |                 |
+                            +-----------------+
+                            RPL Routing Domain
+
+                            +-----------------+
+                            |                 |
+             (S) --------> (R) --------> (D)  |
+                            |                 |
+                            +-----------------+
+                            RPL Routing Domain
+
+                            +-----------------+
+                            |                 |
+             (S) --------> (R) ------------> (R) --------> (D)
+                            |                 |
+                            +-----------------+
+                            RPL Routing Domain
+
+   In the scenarios above, R may indicate a RPL Border Router (when
+   connecting to other routing domains) or a RPL Router (when connecting
+   to hosts).  The datagrams have the following structure when traveling
+   within the RPL routing domain:
+
+               +--------+---------+--------+-------------//-+
+               | Outer  | Source  | Inner  | IPv6           |
+               | IPv6   | Routing | IPv6   | Payload        |
+               | Header | Header  | Header |                |
+               +--------+---------+--------+-------------//-+
+                                   <--- Original Packet --->
+                <---          Tunneled Packet           --->
+
+
+   Note that the outer header (including the SRH) is added and removed
+   by the RPL router.
+
+   Case 2 also occurs whenever a RPL router needs to insert a source
+   route when forwarding a datagram.  One such use case with RPL is to
+   have all RPL traffic flow through a Border Router and have the Border
+   Router use source routes to deliver datagrams to their final
+   destination.  When including the SRH using tunneled mode, the Border
+   Router would encapsulate the received datagram unmodified using IPv6-
+   in-IPv6 and include an SRH in the outer IPv6 header.
+
+
+
+
+
+
+Hui, et al.                  Standards Track                    [Page 5]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+                           +-----------------+
+                           |                 |
+                           |  (S) -------\   |
+                           |              \  |
+                           |               (LBR)
+                           |              /  |
+                           |  (D) <------/   |
+                           |                 |
+                           +-----------------+
+                           RPL Routing Domain
+
+   In the above scenario, datagrams travel from S to D through the Low-
+   Power and Lossy Network Border Router (LBR).  Between S and the LBR,
+   the datagrams are routed using the DAG built by the RPL and do not
+   contain an SRH.  The LBR encapsulates received datagrams unmodified
+   using IPv6-in-IPv6 and the SRH is included in the outer IPv6 header.
+
+3.  Format of the RPL Routing Header
+
+   The Source Routing Header has the following format:
+
+      0                   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  | Routing Type  | Segments Left |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | CmprI | CmprE |  Pad  |               Reserved                |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     .                                                               .
+     .                        Addresses[1..n]                        .
+     .                                                               .
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Next Header         8-bit selector.  Identifies the type of header
+                       immediately following the Routing header.  Uses
+                       the same values as the IPv6 Next Header field
+                       [RFC2460].
+
+   Hdr Ext Len         8-bit unsigned integer.  Length of the Routing
+                       header in 8-octet units, not including the first
+                       8 octets.  Note that when Addresses[1..n] are
+                       compressed (i.e., value of CmprI or CmprE is not
+                       0), Hdr Ext Len does not equal twice the number
+                       of Addresses.
+
+
+
+
+
+Hui, et al.                  Standards Track                    [Page 6]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   Routing Type        8-bit selector.  Identifies the particular
+                       Routing header variant.  An SRH should set the
+                       Routing Type to 3.
+
+   Segments Left       8-bit unsigned integer.  Number of route segments
+                       remaining, i.e., number of explicitly listed
+                       intermediate nodes still to be visited before
+                       reaching the final destination.  The originator
+                       of an SRH sets this field to n, the number of
+                       addresses contained in Addresses[1..n].
+
+   CmprI               4-bit unsigned integer.  Number of prefix octets
+                       from each segment, except than the last segment,
+                       (i.e., segments 1 through n-1) that are elided.
+                       For example, an SRH carrying full IPv6 addresses
+                       in Addresses[1..n-1] sets CmprI to 0.
+
+   CmprE               4-bit unsigned integer.  Number of prefix octets
+                       from the last segment (i.e., segment n) that are
+                       elided.  For example, an SRH carrying a full IPv6
+                       address in Addresses[n] sets CmprE to 0.
+
+   Pad                 4-bit unsigned integer.  Number of octets that
+                       are used for padding after Address[n] at the end
+                       of the SRH.
+
+   Reserved            This field is unused.  It MUST be initialized to
+                       zero by the sender and MUST be ignored by the
+                       receiver.
+
+   Address[1..n]       Vector of addresses, numbered 1 to n.  Each
+                       vector element in [1..n-1] has size (16 - CmprI)
+                       and element [n] has size (16-CmprE).  The
+                       originator of an SRH places the next (first)
+                       hop's IPv6 address in the IPv6 header's IPv6
+                       Destination Address and the second hop's IPv6
+                       address as the first address in Address[1..n]
+                       (i.e., Address[1]).
+
+   The SRH shares the same basic format as the Type 0 Routing header
+   [RFC2460].  When carrying full IPv6 addresses, the CmprI, CmprE, and
+   Pad fields are set to 0 and the only difference between the SRH and
+   Type 0 encodings is the value of the Routing Type field.
+
+   A common network configuration for a RPL routing domain is that all
+   routers within a RPL routing domain share a common prefix.  The SRH
+   introduces the CmprI, CmprE, and Pad fields to allow compaction of
+   the Address[1..n] vector when all entries share the same prefix as
+
+
+
+Hui, et al.                  Standards Track                    [Page 7]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   the IPv6 Destination Address field of the packet carrying the SRH.
+   The CmprI and CmprE fields indicate the number of prefix octets that
+   are shared with the IPv6 Destination Address of the packet carrying
+   the SRH.  The shared prefix octets are not carried within the Routing
+   header and each entry in Address[1..n-1] has size (16 - CmprI) octets
+   and Address[n] has size (16 - CmprE) octets.  When CmprI or CmprE is
+   non-zero, there may exist unused octets between the last entry,
+   Address[n], and the end of the Routing header.  The Pad field
+   indicates the number of unused octets that are used for padding.
+   Note that when CmprI and CmprE are both 0, Pad MUST carry a value of
+   0.
+
+   The SRH MUST NOT specify a path that visits a node more than once.
+   When generating an SRH, the source may not know the mapping between
+   IPv6 addresses and nodes.  Minimally, the source MUST ensure that
+   IPv6 addresses do not appear more than once and the IPv6 Source and
+   Destination addresses of the encapsulating datagram do not appear in
+   the SRH.
+
+   Multicast addresses MUST NOT appear in an SRH or in the IPv6
+   Destination Address field of a datagram carrying an SRH.
+
+4.  RPL Router Behavior
+
+4.1.  Generating Source Routing Headers
+
+   To deliver an IPv6 datagram to its destination, a router may need to
+   generate a new SRH and specify a strict source route.  When the
+   router is the source of the original packet and the destination is
+   known to be within the same RPL routing domain, the router SHOULD
+   include the SRH directly within the original packet.  Otherwise, the
+   router MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the SRH in
+   the tunnel header.  Using IPv6-in-IPv6 tunneling ensures that the
+   delivered datagram remains unmodified and that ICMPv6 errors
+   generated by an SRH are sent back to the router that generated the
+   SRH.
+
+   When using IPv6-in-IPv6 tunneling, in order to respect the IPv6 Hop
+   Limit value of the original datagram, a RPL router generating an SRH
+   MUST set the Segments Left to less than the original datagram's IPv6
+   Hop Limit value upon forwarding.  In the case that the source route
+   is longer than the original datagram's IPv6 Hop Limit, only the
+   initial hops (determined by the original datagram's IPv6 Hop Limit)
+   should be included in the SRH.  If the RPL router is not the source
+   of the original datagram, the original datagram's IPv6 Hop Limit
+   field is decremented before generating the SRH.  After generating the
+   SRH, the RPL router decrements the original datagram's IPv6 Hop Limit
+   value by the SRH Segments Left value.  Processing the SRH Segments
+
+
+
+Hui, et al.                  Standards Track                    [Page 8]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   Left and original datagram's IPv6 Hop Limit fields in this way
+   ensures that ICMPv6 Time Exceeded errors occur as would be expected
+   on more traditional IPv6 networks that forward datagrams without
+   tunneling.
+
+   To avoid fragmentation, it is desirable to employ MTU sizes that
+   allow for the header expansion (i.e., at least 1280 + 40 (outer IP
+   header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path
+   length for a given RPL network.  To take advantage of this, however,
+   the communicating endpoints need to be aware of the MTU along the
+   path (i.e., through Path MTU Discovery).  Unfortunately, the larger
+   MTU size may not be available on all links (e.g., 1280 octets on IPv6
+   Low-Power Wireless Personal Area Network (6LoWPAN) links).  However,
+   it is expected that much of the traffic on these types of networks
+   consists of much smaller messages than the MTU, so performance
+   degradation through fragmentation would be limited.
+
+4.2.  Processing Source Routing Headers
+
+   As specified in [RFC2460], a routing header is not examined or
+   processed until it reaches the node identified in the Destination
+   Address field of the IPv6 header.  In that node, dispatching on the
+   Next Header field of the immediately preceding header causes the
+   Routing header module to be invoked.
+
+   The function of the SRH is intended to be very similar to the Type 0
+   Routing header defined in [RFC2460].  After the routing header has
+   been processed and the IPv6 datagram resubmitted to the IPv6 module
+   for processing, the IPv6 Destination Address contains the next hop's
+   address.  When forwarding an IPv6 datagram that contains an SRH with
+   a non-zero Segments Left value, if the IPv6 Destination Address is
+   not on-link, a router MUST drop the datagram and SHOULD send an ICMP
+   Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set
+   to 7 to the packet's Source Address.  This ICMPv6 Code indicates that
+   the IPv6 Destination Address is not on-link and the router cannot
+   satisfy the strict source route requirement.  When generating ICMPv6
+   error messages, the rules in Section 2.4 of [RFC4443] MUST be
+   observed.
+
+   To detect loops in the SRH, a router MUST determine if the SRH
+   includes multiple addresses assigned to any interface on that router.
+   If such addresses appear more than once and are separated by at least
+   one address not assigned to that router, the router MUST drop the
+   packet and SHOULD send an ICMP Parameter Problem, Code 0, to the
+   Source Address.  While this loop check does add significant per-
+   packet processing overhead, it is required to mitigate bandwidth
+   exhaustion attacks that led to the deprecation of RH0 [RFC5095].
+
+
+
+
+Hui, et al.                  Standards Track                    [Page 9]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   The following describes the algorithm performed when processing an
+   SRH:
+
+   if Segments Left = 0 {
+      proceed to process the next header in the packet, whose type is
+      identified by the Next Header field in the Routing header
+   }
+   else {
+      compute n, the number of addresses in the Routing header, by
+      n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1
+
+      if Segments Left is greater than n {
+         send an ICMP Parameter Problem, Code 0, message to the Source
+         Address, pointing to the Segments Left field, and discard the
+         packet
+      }
+      else {
+         decrement Segments Left by 1
+
+         compute i, the index of the next address to be visited in
+         the address vector, by subtracting Segments Left from n
+
+         if Address[i] or the IPv6 Destination Address is multicast {
+            discard the packet
+         }
+         else if 2 or more entries in Address[1..n] are assigned to
+                 local interface and are separated by at least one
+                 address not assigned to local interface {
+            send an ICMP Parameter Problem (Code 0) and discard the
+            packet
+         }
+         else {
+            swap the IPv6 Destination Address and Address[i]
+
+            if the IPv6 Hop Limit is less than or equal to 1 {
+               send an ICMP Time Exceeded -- Hop Limit Exceeded in
+               Transit message to the Source Address and discard the
+               packet
+            }
+            else {
+               decrement the Hop Limit by 1
+
+               resubmit the packet to the IPv6 module for transmission
+               to the new destination
+            }
+         }
+      }
+   }
+
+
+
+Hui, et al.                  Standards Track                   [Page 10]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   RPL routers are responsible for ensuring that an SRH is only used
+   between RPL routers:
+
+   1.  For datagrams destined to a RPL router, the router processes the
+       packet in the usual way.  For instance, if the SRH was included
+       using tunneled mode and the RPL router serves as the tunnel
+       endpoint, the router removes the outer IPv6 header, at the same
+       time removing the SRH as well.
+
+   2.  Datagrams destined elsewhere within the same RPL routing domain
+       are forwarded to the correct interface.
+
+   3.  Datagrams destined to nodes outside the RPL routing domain are
+       dropped if the outermost IPv6 header contains an SRH not
+       generated by the RPL router forwarding the datagram.
+
+5.  Security Considerations
+
+5.1.  Source Routing Attacks
+
+   The RPL message security mechanisms defined in [RFC6550] do not apply
+   to the RPL Source Route Header.  This specification does not provide
+   any confidentiality, integrity, or authenticity mechanisms to protect
+   the SRH.
+
+   [RFC5095] deprecates the Type 0 Routing header due to a number of
+   significant attacks that are referenced in that document.  Such
+   attacks include bypassing filtering devices, reaching otherwise
+   unreachable Internet systems, network topology discovery, bandwidth
+   exhaustion, and defeating anycast.
+
+   Because this document specifies that the SRH is only for use within a
+   RPL routing domain, such attacks cannot be mounted from outside a RPL
+   routing domain.  As specified in this document, RPL routers MUST drop
+   datagrams entering or exiting a RPL routing domain that contain an
+   SRH in the IPv6 Extension headers.
+
+   Such attacks, however, can be mounted from within a RPL routing
+   domain.  To mitigate bandwidth exhaustion attacks, this specification
+   requires RPL routers to check for loops in the SRH and drop datagrams
+   that contain such loops.  Attacks that include bypassing filtering
+   devices and reaching otherwise unreachable Internet systems are not
+   as relevant in mesh networks since the topologies are, by their very
+   nature, highly dynamic.  The RPL routing protocol is designed to
+   provide reachability to all devices within a RPL routing domain and
+   may utilize routes that traverse any number of devices in any order.
+
+
+
+
+
+Hui, et al.                  Standards Track                   [Page 11]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+   Even so, these attacks and others (e.g., defeating anycast and
+   routing topology discovery) can occur within a RPL routing domain
+   when using this specification.
+
+5.2.  ICMPv6 Attacks
+
+   The generation of ICMPv6 error messages may be used to attempt
+   denial-of-service attacks by sending an error-causing SRH in back-to-
+   back datagrams.  An implementation that correctly follows Section 2.4
+   of [RFC4443] would be protected by the ICMPv6 rate-limiting
+   mechanism.
+
+6.  IANA Considerations
+
+   This document defines a new IPv6 Routing Type, the "RPL Source Route
+   Header", and has been assigned number 3 by IANA.
+
+   This document defines a new ICMPv6 Destination Unreachable Code,
+   "Error in Source Routing Header", and has been assigned number 7 by
+   IANA.
+
+7.  Acknowledgements
+
+   The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen
+   Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal
+   Thubert, Sean Turner, and Tim Winter for their comments and
+   suggestions that helped shape this document.
+
+8.  References
+
+8.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.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
+              Message Protocol (ICMPv6) for the Internet Protocol
+              Version 6 (IPv6) Specification", RFC 4443, March 2006.
+
+   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
+              of Type 0 Routing Headers in IPv6", RFC 5095,
+              December 2007.
+
+
+
+Hui, et al.                  Standards Track                   [Page 12]
+
+RFC 6554                 RPL Source Route Header              March 2012
+
+
+8.2.  Informative References
+
+   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
+              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
+              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
+              Low-Power and Lossy Networks", RFC 6550, March 2012.
+
+Authors' Addresses
+
+   Jonathan W. Hui
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, California  95134
+   USA
+
+   Phone: +408 424 1547
+   EMail: jonhui@cisco.com
+
+
+   JP. Vasseur
+   Cisco Systems
+   11, Rue Camille Desmoulins
+   Issy Les Moulineaux  92782
+   France
+
+   EMail: jpv@cisco.com
+
+
+   David E. Culler
+   UC Berkeley
+   465 Soda Hall
+   Berkeley, California  94720
+   USA
+
+   Phone: +510 643 7572
+   EMail: culler@cs.berkeley.edu
+
+
+   Vishwas Manral
+   Hewlett Packard Co.
+   19111 Pruneridge Ave.
+   Cupertino, California  95014
+   USA
+
+   EMail: vishwas.manral@hp.com
+
+
+
+
+
+
+Hui, et al.                  Standards Track                   [Page 13]
+