in Index   Prev   Next

RFC 6775

Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Pages: 55
Proposed Standard
Updates:  4944
Updated by:  850589299010
Part 3 of 3 – Pages 41 to 55
First   Prev   None

Top   ToC   RFC6775 - Page 41   prevText

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
Top   ToC   RFC6775 - Page 42

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
Top   ToC   RFC6775 - Page 43
      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.
Top   ToC   RFC6775 - Page 44
       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.
Top   ToC   RFC6775 - Page 45

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)
Top   ToC   RFC6775 - Page 46
     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.
Top   ToC   RFC6775 - Page 47
   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.
Top   ToC   RFC6775 - Page 48
   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)
Top   ToC   RFC6775 - Page 49
   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
Top   ToC   RFC6775 - Page 50
   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

   | 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
Top   ToC   RFC6775 - Page 51
   | 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
Top   ToC   RFC6775 - Page 52

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, < 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.
Top   ToC   RFC6775 - Page 53
   [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://>. [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.
Top   ToC   RFC6775 - Page 54
   [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.
Top   ToC   RFC6775 - Page 55

Authors' Addresses

Zach Shelby (editor) Sensinode Konekuja 2 Oulu 90620 Finland Phone: +358407796297 EMail: Samita Chakrabarti Ericsson EMail: Erik Nordmark Cisco Systems EMail: Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 EMail: