9.  Protocol Constants

   This section defines the relevant protocol constants used in this
   document based on a subset of [RFC4861] constants.  "*" indicates
   constants modified from [RFC4861], and "+" indicates new constants.

   Additional protocol constants are defined in Section 4.

   6LBR Constants:

   MIN_CONTEXT_CHANGE_DELAY+               300 seconds

   6LR Constants:

   MAX_RTR_ADVERTISEMENTS                  3 transmissions

   MIN_DELAY_BETWEEN_RAS*                  10 seconds

   MAX_RA_DELAY_TIME*                      2 seconds

   TENTATIVE_NCE_LIFETIME+                 20 seconds

   Router Constants:

   MULTIHOP_HOPLIMIT+                      64

   Host Constants:

   RTR_SOLICITATION_INTERVAL*              10 seconds

   MAX_RTR_SOLICITATIONS                   3 transmissions

   MAX_RTR_SOLICITATION_INTERVAL+          60 seconds

10.  Examples

10.1.  Message Examples

   STEP

      6LN                                                        6LR

       |                                                          |

   1.  |       ---------- Router Solicitation -------->           |

       |                       [SLLAO]                            |

       |                                                          |

   2.  |       <-------- Router Advertisement ---------           |

       |              [PIO + 6CO + ABRO + SLLAO]                  |


     Figure 2: Basic Router Solicitation/Router Advertisement Exchange
                     between a Node and a 6LR or 6LBR


      6LN                                                        6LR

       |                                                          |

   1.  |       ------- NS with Address Registration ------>       |

       |                     [ARO + SLLAO]                        |

       |                                                          |

   2.  |       <----- NA with Address Registration --------       |

       |                   [ARO with Status]                      |


             Figure 3: Neighbor Discovery Address Registration

      6LN                           6LR                          6LBR

       |                             |                             |

   1.  | --- NS with Address Reg --> |                             |

       |      [ARO + SLLAO]          |                             |

       |                             |                             |

   2.  |                             | ----------- DAR ----------> |

       |                             |                             |

   3.  |                             | <---------- DAC ----------- |

       |                             |                             |

   4.  | <-- NA with Address Reg --- |                             |

       |      [ARO with Status]      |


    Figure 4: Neighbor Discovery Address Registration with Multihop DAD

10.2.  Host Bootstrapping Example

   The following example describes the address bootstrapping scenarios
   using the improved ND mechanisms specified in this document.  It is
   assumed that the 6LN first performs a sequence of operations in order
   to get secure access at the link layer of the LoWPAN and obtain a key
   for link-layer security.  The methods of how to establish link-layer
   security are out of scope of this document.  In this example, an IEEE
   802.15.4 6LN forms a 16-bit short IPv6 address without using DHCPv6
   (i.e., the M flag is not set in the RAs).

   1.  After obtaining link-layer security, a 6LN assigns a link-local
       IPv6 address to itself.  A link-local IPv6 address is configured
       based on the 6LN's EUI-64 link-layer address formed as per
       [RFC4944].

   2.  Next, the 6LN determines one or more default routers in the
       network by sending an RS to the all-routers multicast address
       with the SLLAO set to its EUI-64 link-local address.  If the 6LN
       was able to obtain the link-layer address of a router through its
       link-layer operations, then the 6LN may form a link-local
       destination IPv6 address for the router and send it a unicast RS.

       The 6LR responds with a unicast RA to the IP source address using
       the SLLAO from the RS (it may have created a Tentative NCE).  See
       Figure 2.

   3.  In order to communicate more than one IP hop away, the 6LN
       configures a global IPv6 address.  In order to save overhead,
       this 6LN wishes to configure its IPv6 address based on a 16-bit
       short address as per [RFC4944].  As the network is unmanaged
       (M flag not set in the RA), the 6LN randomly chooses a 16-bit
       link-layer address and forms a Tentative IPv6 address from it.

   4.  Next, the 6LN registers that address with one or more of its
       default routers by sending a unicast NS message with an ARO
       containing its Tentative global IPv6 address to register, the
       Registration Lifetime, and its EUI-64.  An SLLAO is also included
       with the link-layer address corresponding to the address being
       registered.  If a successful (Status 0) NA message is received,
       the address can then be used, and the 6LN assumes that it has
       been successfully checked for duplicates.  If a duplicate address
       (Status 1) NA message is received, the 6LN then removes the
       temporary IPv6 address and 16-bit link-layer address and goes
       back to step 3.  If a Neighbor Cache Full (Status 2) message is
       received, the 6LN attempts to register with another default
       router or, if none, goes back to step 2.  See Figure 3.  Note
       that an NA message returning an error would be sent back to the
       link-local EUI-64-based IPv6 address of the 6LN instead of the
       16-bit (duplicate) address.

   5.  The 6LN now performs maintenance by sending a new NS address
       registration before the lifetime expires.

   If multihop DAD and multihop prefix and context distribution are
   used, the effect of the 6LRs and hosts following the above
   bootstrapping process is a "wavefront" of 6LRs and hosts being
   configured, spreading outward from the 6LBRs: First, the hosts and
   6LRs that can directly reach a 6LBR would receive one or more RAs and
   then configure and register their IPv6 addresses.  Once that is done,
   they would enable the routing protocol and start sending out RAs.
   That would result in a new set of 6LRs and hosts to receive responses
   to their RSs, form and register their addresses, etc.  That repeats
   until all of the 6LRs and hosts have been configured.

10.2.1.  Host Bootstrapping Messages

   This section provides specific message examples related to the
   bootstrapping process described above.  When discussing messages, the
   following notation is used:

   LL64:  Link-local address based on the EUI-64, which is also the
      802.15.4 long address.

   GP16:  Global address based on the 802.15.4 short address.  This
      address may not be unique.

   GP64:  Global addresses derived from the EUI-64 address as specified
      in [RFC4944].

   MAC64:  EUI-64 address used as the link-layer address.

   MAC16:  IEEE 802.15.4 16-bit short address.

   Note that some implementations may use LL64 and GP16 style addresses
   instead of LL64 and GP64.  In the following, we will show an example
   message flow as to how a node uses LL64 to register a GP16 address
   for multihop DAD verification.

    6LN-----RS-------->6LR
     Src= LL64 (6LN)
     Dst= all-router-link-scope-multicast
     SLLAO= MAC64 (6LN)

    6LR------RA--------->6LN
     Src= LL64 (6LR)
     Dst= LL64 (6LN)

   Note: Source address of RA must be a link-local
   address (Section 4.2 of RFC 4861).

    6LN-------NS Reg------>6LR
     Src= GP16 (6LN)
     Dst= LL64 (6LR)
     ARO
     SLLAO= MAC16 (6LN)

    6LR---------DAR----->6LBR
     Src= GP64 or GP16 (6LR)
     Dst= GP64 or GP16 (6LBR)
     Registered Address= GP16 (6LN) and EUI-64 (6LN)

    6LBR-------DAC--------->6LR
     Src= GP64 or GP16 (6LBR)
     Dst= GP64 or GP16 (6LR)
     Copy of information from DAR

    If Status is a success:

    6LR ---------NA-Reg------->6LN
     Src= LL64 (6LR)
     Dst= GP16 (6LN)
     ARO with Status = 0

    If Status is not a success:

    6LR ---------NA-Reg-------->6LN
     Src= LL64 (6LR)
     Dst= LL64 (6LN) --> Derived from the EUI-64 of ARO
     ARO with Status > 0


                Figure 5: Detailed Message Address Examples

10.3.  Router Interaction Example

   In the route-over topology, when a routing protocol is run across
   6LRs, the bootstrapping and Neighbor Cache management are handled a
   little differently.  The description in this paragraph provides only
   a guideline for an implementation.

   At the initialization of a 6LR, it may choose to bootstrap as a host
   with the help of a parent 6LR if the substitutable multihop DAD is
   performed with the 6LBR.  The Neighbor Cache management of a router
   and address resolution among the neighboring routers are described in
   Sections 6.5.3 and 6.5.5, respectively.  In this example, we assume
   that the neighboring 6LoWPAN link is secure.

10.3.1.  Bootstrapping a Router

   In this scenario, the bootstrapping 6LR, 'R1', is multiple hops away
   from the 6LBR and surrounded by other 6LR neighbors.  Initially, R1
   behaves as a host.  It sends a multicast RS and receives an RA from
   one or more neighboring 6LRs.  R1 picks one 6LR as its temporary
   default router and performs address resolution via this default
   router.  Note that if multihop DAD is not required (e.g., in a
   managed network or using EUI-64-based addresses), then it does not
   need to pick a temporary default router; however, it may still want
   to send the initial RS message if it wants to autoconfigure its
   address with the global prefix disseminated by the 6LBR.

   Based on the information received in the RAs, R1 updates its cache
   with entries for all the neighboring 6LRs.  Upon completion of the
   address registration, the bootstrapping router deletes the temporary
   entry of the default router, and the routing protocol is started.

   Also note that R1 may refresh its multihop DAD registration directly
   with the 6LBR (using the next-hop neighboring 6LR determined by the
   routing protocol for reaching the 6LBR).

10.3.2.  Updating the Neighbor Cache

   In this example, there are three 6LRs: R1, R2, and R3.  Initially,
   when R2 boots, it sees only R1, and accordingly R2 creates an NCE for
   R1.  Now assume that R2 receives a valid routing update from router
   R3.  R2 does not have any NCE for R3.  If the implementation of R2
   supports detecting link-layer addresses from the routing information
   packets, then it directly updates its Neighbor Cache using that
   link-layer information.  If this is not possible, then R2 should
   perform multicast NS with the source set with its link-local or
   global address, depending on the scope of the source IP address
   received in the routing update packet.  The target address of the NS
   message is the source IPv6 address of the received routing update
   packet.  The format of the NS message is as described in Section 4.3
   of [RFC4861].

   More generally, any 6LR that receives a valid route update from a
   neighboring router for which it does not have any NCE is required to
   update its Neighbor Cache as described above.

   The router (6LR and 6LBR) IP addresses learned via ND are not
   redistributed to the routing protocol.

11.  Security Considerations

   The security considerations of IPv6 ND [RFC4861] and address
   autoconfiguration [RFC4862] apply.  Additional considerations can be
   found in [RFC3756].

   There is a slight modification to those considerations, due to the
   fact that in this specification the M flag in the RAs disables the
   use of stateless address autoconfiguration for addresses not derived
   from EUI-64.  Thus, a rogue router on the link can force the use of
   only DHCP for short addresses, whereas in [RFC4861] and [RFC4862] the
   rogue router could only cause the addition of DHCP and not disable
   stateless address autoconfiguration for short addresses.

   This specification assumes that the link layer is sufficiently
   protected -- for instance, by using MAC-sublayer cryptography.  Thus,
   its threat model is no different from that of IPv6 ND [RFC4861].  The
   first trust model listed in Section 3 of [RFC3756] applies here.
   However, any future 6LoWPAN security protocol that applies to ND for
   the 6LoWPAN protocol is out of scope of this document.

   The multihop DAD mechanisms rely on DAR and DAC messages that are
   forwarded by 6LRs, and as a result the hop_limit=255 check on the
   receiver does not apply to those messages.  This implies that any
   node on the Internet could successfully send such messages.  We avoid
   any additional security issues due to this by requiring that the
   routers never modify the NCE due to such messages, and that they
   discard them unless they are received on an interface that has been
   explicitly configured to use these optimizations.

   In some future deployments, one might want to use SEcure Neighbor
   Discovery (SEND) [RFC3971] [RFC3972].  This is possible with the ARO
   as sent between hosts and routers, since the address that is being
   registered is the IPv6 source address of the NS and SEND verifies the
   IPv6 source address of the packet.  Applying SEND to the router-to-
   router communication in this document is out of scope.

12.  IANA Considerations

   This document registers three new ND option types under the
   subregistry "IPv6 Neighbor Discovery Option Formats":

   o  Address Registration Option (33)
   o  6LoWPAN Context Option (34)
   o  Authoritative Border Router Option (35)

   The document registers two new ICMPv6 "type" numbers under the
   subregistry "ICMPv6 "type" Numbers":

   o  Duplicate Address Request (157)
   o  Duplicate Address Confirmation (158)

   IANA has also created a new subregistry for the Status values of the
   Address Registration Option, under the ICMPv6 parameters registry.

   Address Registration Option Status Values registry:

   o  Possible values are 8-bit unsigned integers (0..255).
   o  Registration procedure is "Standards Action" [RFC5226].
   o  Initial allocation is as indicated in Table 2:

          +--------+--------------------------------------------+
          | Status |                 Description                |
          +--------+--------------------------------------------+
          |    0   |                   Success                  |
          |    1   |              Duplicate Address             |
          |    2   |             Neighbor Cache Full            |
          |  3-255 | Allocated using Standards Action [RFC5226] |
          +--------+--------------------------------------------+

                                  Table 2

13.  Interaction with Other Neighbor Discovery Extensions

   There are two classes of ND extensions that interact with this
   specification in different ways.

   One class encompasses extensions to the DAD mechanisms in [RFC4861]
   and [RFC4862].  An example of this is Optimistic DAD [RFC4429].  Such
   extensions do not apply when this specification is being used, since
   it uses ARO for DAD (which is neither optimistic nor pessimistic --
   always one round trip to the router to check DAD).

   All other (non-DAD) ND extensions, be they path selection types like
   default router preferences [RFC4191], configuration types like DNS
   configuration [RFC6106], or other types like Detecting Network
   Attachment [RFC6059], are completely orthogonal to this specification
   and will work as is.

14.  Guidelines for New Features

   This section discusses guidelines of new protocol features defined in
   this document.  It also sets some expectations for implementation and
   deployment of these features.  This section is informative in nature:
   it does not override the detailed specifications of the previous
   sections but summarizes them and presents them in a compact form, to
   be used as checklists.  The checklists act as guidelines to indicate
   the possible importance of a feature in terms of a deployment as per
   information available as of the writing of the document.  Note that
   in some cases the deployment is 'SHOULD' where the implementation is

   a 'MUST'.  This is due to the presence of substitutable features; the
   deployment may use alternative methods for those.  Therefore,
   implementing a configuration knob is recommended for the
   substitutable features.  The lists emphasize conciseness over
   completeness.

   +----------+-----------------------------------+--------+-----------+
   | Section  | Description                       | Deploy | Implement |
   +----------+-----------------------------------+--------+-----------+
   | 3.1      | Host-initiated RA                 | MUST   | MUST      |
   | 3.2      | EUI-64-based IPv6 address         | MUST   | MUST      |
   |          | 16-bit MAC-based address          | MAY    | SHOULD    |
   |          | Other non-unique addresses        | MAY    | MAY       |
   | 3.3      | Host-initiated RS                 | MUST   | MUST      |
   |          | ABRO processing                   | SHOULD | MUST      |
   | 4.1      | Registration with ARO             | MUST   | MUST      |
   | 4.2, 5.4 | 6CO                               | SHOULD | SHOULD    |
   | 5.2      | Joining solicited-node multicast  | N/A    | N/A       |
   |          | Joining all-nodes multicast       | MUST   | MUST      |
   |          | Using link-layer indication for   | MAY    | MAY       |
   |          | NUD                               |        |           |
   | 5.5      | 6LoWPAN-ND NUD                    | MUST   | MUST      |
   | 5.8.2    | Behavior on wakeup                | SHOULD | SHOULD    |
   +----------+-----------------------------------+--------+-----------+

           Table 3: Guideline for 6LoWPAN-ND Features for Hosts

   +---------------+-------------------------+------------+------------+
   | Section       | Description             | Deploy     | Implement  |
   +---------------+-------------------------+------------+------------+
   | 3.1           | Periodic RA             | SHOULD NOT | SHOULD NOT |
   | 3.2           | Address assignment      | SHOULD     | MUST       |
   |               | during startup          |            |            |
   | 3.3           | Supporting EUI-64-based | MUST       | MUST       |
   |               | MAC hosts               |            |            |
   |               | Supporting 16-bit MAC   | MAY        | SHOULD     |
   |               | hosts                   |            |            |
   | 3.4, 4.3,     | ABRO processing/sending | SHOULD     | MUST       |
   | 8.1.3, 8.1.4  |                         |            |            |
   | 8.1           | Multihop prefix storing | SHOULD     | MUST       |
   |               | and redistribution      |            |            |
   | 3.5           | Tentative NCE           | MUST       | MUST       |
   | 8.2           | Multihop DAD            | SHOULD     | MUST       |
   | 4.1, 6.5,     | ARO support             | MUST       | MUST       |
   | 6.5.1 - 6.5.5 |                         |            |            |
   | 4.2           | 6CO                     | SHOULD     | SHOULD     |
   | 6.3           | Process RS/ABRO         | MUST       | MUST       |
   +---------------+-------------------------+------------+------------+

             Table 4: Guideline for 6LR Features in 6LoWPAN-ND

   +--------------+--------------------------+------------+------------+
   | Section      | Description              | Deploy     | Implement  |
   +--------------+--------------------------+------------+------------+
   | 3.1          | Periodic RA              | SHOULD NOT | SHOULD NOT |
   | 3.2          | Address autoconf on      | MUST NOT   | MUST NOT   |
   |              | router interface         |            |            |
   | 3.3          | EUI-64 MAC support on    | MUST       | MUST       |
   |              | 6LoWPAN interface        |            |            |
   | 8.1 - 8.1.1, | Multihop prefix          | SHOULD     | MUST       |
   | 8.1.5        | distribution             |            |            |
   | 8.2          | Multihop DAD             | SHOULD     | MUST       |
   +--------------+--------------------------+------------+------------+

            Table 5: Guideline for 6LBR Features in 6LoWPAN-ND

15.  Acknowledgments

   The authors thank Pascal Thubert, Jonathan Hui, Richard Kelsey, Geoff
   Mulligan, Julien Abeille, Alexandru Petrescu, Peter Siklosi, Pieter
   De Mil, Fred Baker, Anthony Schoofs, Phil Roberts, Daniel Gavelle,
   Joseph Reddy, Robert Cragie, Mathilde Durvy, Colin O'Flynn, Dario
   Tedeschi, Esko Dijk, and Joakim Eriksson for useful discussions and
   comments that have helped shape and improve this document.

   Additionally, the authors would like to recognize Pascal Thubert for
   contributing the original registration idea and for extensive
   contributions to earlier versions of the document, Jonathan Hui for
   original ideas on prefix/context distribution and extensive
   contributions to earlier versions of the document, Colin O'Flynn for
   useful "Error-to" suggestions (Section 6.5.2) and for contributions
   to the Examples section, Geoff Mulligan for suggesting the use of
   address registration as part of existing IPv6 ND messages, and
   Mathilde Durvy for helping to clarify router interaction.

16.  References

16.1.  Normative References

   [ETHERNET]
              "IEEE Standard for Information technology -
              Telecommunications and information exchange between
              systems - Local and metropolitan area networks - Specific
              requirements - Part 3: Carrier Sense Multiple Access with
              Collision Detection (CSMA/CD) Access Method and Physical
              Layer Specifications", IEEE Std 802.3-2008, December 2008,
              <http://standards.ieee.org/getieee802/download/
              802.3-2008_section1.pdf>.

   [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.

   [RFC2491]  Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
              over Non-Broadcast Multiple Access (NBMA) networks",
              RFC 2491, January 1999.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

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

   [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.

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

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

16.2.  Informative References

   [EUI64]    IEEE, "Guidelines for 64-bit Global Identifier
              (EUI-64(TM)) Registration Authority", <http://
              standards.ieee.org/regauth/oui/tutorials/EUI64.html>.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 2006.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, August 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5889]  Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
              Hoc Networks", RFC 5889, September 2010.

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

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, November 2010.

Authors' Addresses

   Zach Shelby (editor)
   Sensinode
   Konekuja 2
   Oulu  90620
   Finland

   Phone: +358407796297
   EMail: zach@sensinode.com


   Samita Chakrabarti
   Ericsson

   EMail: samita.chakrabarti@ericsson.com


   Erik Nordmark
   Cisco Systems

   EMail: nordmark@cisco.com


   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   EMail: cabo@tzi.org