Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8505

Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery

Pages: 47
Proposed Standard
Updates:  6775
Updated by:  892889299010
Part 3 of 3 – Pages 32 to 47
First   Prev   None

Top   ToC   RFC8505 - Page 32   prevText

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <>.
Top   ToC   RFC8505 - Page 33
   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,

   [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, DOI 10.17487/RFC4919, August 2007,

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

   [RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
              Statement and Requirements for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Routing",
              RFC 6606, DOI 10.17487/RFC6606, May 2012,

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400,
              November 2014, <>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
Top   ToC   RFC8505 - Page 34

10.2. Informative References

[Alternative-Ellip-Curve-Reps] Struik, R., "Alternative Elliptic Curve Representations", Work in Progress, draft-struik-lwip-curve- representations-00, October 2017. [AP-ND] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address Protected Neighbor Discovery for Low-power and Lossy Networks", Work in Progress, draft-ietf-6lo- ap-nd-08, October 2018. [Arch-for-6TiSCH] Thubert, P., Ed., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-17, November 2018. [Efficient-NPDAO] Jadhav, R., Ed., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Route Invalidation", Work in Progress, draft-ietf-roll-efficient-npdao-09, October 2018. [IEEE-802-15-4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, <>. [IPv6-Backbone-Router] Thubert, P., Ed. and C. Perkins, "IPv6 Backbone Router", Work in Progress, draft-ietf-6lo-backbone-router-08, October 2018. [IPv6-over-802.11ah] Del Carpio Vega, L., Robles, M., and R. Morabito, "IPv6 over 802.11ah", Work in Progress, draft-delcarpio-6lo- wlanah-01, October 2015. [IPv6-over-NFC] Choi, Y., Ed., Hong, Y-G., Youn, J-S., Kim, D-K., and J-H. Choi, "Transmission of IPv6 Packets over Near Field Communication", Work in Progress, draft-ietf-6lo-nfc-12, November 2018. [IPv6-over-PLC] Hou, J., Liu, B., Hong, Y-G., Tang, X., and C. Perkins, "Transmission of IPv6 Packets over PLC Networks", Work in Progress, draft-hou-6lo-plc-05, October 2018.
Top   ToC   RFC8505 - Page 35
              Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
              Zuniga, "Multicast Considerations over IEEE 802 Wireless
              Media", Work in Progress, draft-ietf-mboned-ieee802-mcast-
              problems-03, October 2018.

              Chakrabarti, S., Nordmark, E., Thubert, P., and M.
              Wasserman, "IPv6 Neighbor Discovery Optimizations for
              Wired and Wireless Networks", Work in Progress,
              February 2015.

              Perlman, R., "Fault-Tolerant Broadcast of Routing
              Information", North-Holland Computer Networks 7:
              pp. 395-405, DOI 10.1016/0376-5075(83)90034-X, 1983,

   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
              Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              DOI 10.17487/RFC1982, August 1996,

   [RFC3610]  Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610,
              September 2003, <>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,

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

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,
Top   ToC   RFC8505 - Page 36
   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,

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

   [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,
              DOI 10.17487/RFC6550, March 2012,

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,

   [RFC7428]  Brandt, A. and J. Buron, "Transmission of IPv6 Packets
              over ITU-T G.9959 Networks", RFC 7428,
              DOI 10.17487/RFC7428, February 2015,

   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,

   [RFC7934]  Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
              "Host Address Availability Recommendations", BCP 204,
              RFC 7934, DOI 10.17487/RFC7934, July 2016,

   [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              RFC 8064, DOI 10.17487/RFC8064, February 2017,

   [RFC8065]  Thaler, D., "Privacy Considerations for IPv6 Adaptation-
              Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
              February 2017, <>.
Top   ToC   RFC8505 - Page 37
   [RFC8105]  Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
              M., and D. Barthel, "Transmission of IPv6 Packets over
              Digital Enhanced Cordless Telecommunications (DECT) Ultra
              Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105,
              May 2017, <>.

   [RFC8163]  Lynn, K., Ed., Martocci, J., Neilson, C., and S.
              Donaldson, "Transmission of IPv6 over Master-Slave/Token-
              Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
              May 2017, <>.

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,

              Thubert, P., Ed., "Routing for RPL Leaves", Work in
              Progress, draft-thubert-roll-unaware-leaves-05, May 2018.
Top   ToC   RFC8505 - Page 38

Appendix A. Applicability and Fulfilled Requirements (Not Normative)

This specification extends 6LoWPAN ND to provide a sequence number to the registration and fulfills the requirements expressed in Appendix B.1 by enabling the mobility of devices from one LLN to the next. A full specification for enabling mobility based on the use of the EARO and the registration procedures defined in this document can be found in subsequent work [IPv6-Backbone-Router] ("IPv6 Backbone Router"). The 6BBR is an example of a Routing Registrar that acts as an IPv6 ND proxy over a Backbone Link that federates multiple LLNs as well as the Backbone Link itself into a single IPv6 subnet. The expected registration flow in that case is illustrated in Figure 6, noting that any combination of 6LR, 6LBR, and 6BBR may be collocated. 6LN 6LR 6LBR 6BBR | | | | | NS(EARO) | | | |--------------->| | | | | Extended DAR | | | |-------------->| | | | | | | | | proxy NS(EARO) | | | |--------------->| | | | | NS(DAD) | | | | ------> | | | | <wait> | | | | | | | proxy NA(EARO) | | | |<---------------| | | Extended DAC | | | |<--------------| | | NA(EARO) | | | |<---------------| | | | | | | Figure 6: (Re-)Registration Flow [Arch-for-6TiSCH] ("An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4") describes how a 6LoWPAN ND host using the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std. 802.15.4 [IEEE-802-15-4] can connect to the Internet via a RPL mesh network. Doing so requires additions to the 6LoWPAN ND protocol to support mobility and reachability in a secure and manageable network environment. This document specifies those new operations and fulfills the requirements listed in Appendix B.2.
Top   ToC   RFC8505 - Page 39
   The term "LLN" is used loosely in this document and is intended to
   cover multiple types of WLANs and WPANs, including Low-Power IEEE
   Std. 802.11 networking, Bluetooth low energy, IEEE Std. 802.11ah, and
   IEEE Std. 802.15.4 wireless meshes, so as to address the requirements
   discussed in Appendix B.3.

   This specification can be used by any wireless node to register its
   IPv6 Addresses with a Routing Registrar and to obtain routing
   services such as proxy ND operations over a Backbone Link.  This
   satisfies the requirements expressed in Appendix B.4.

   This specification is extended by [AP-ND] to provide a solution to
   some of the security-related requirements expressed in Appendix B.5.

   [ND-Optimizations] ("IPv6 Neighbor Discovery Optimizations for Wired
   and Wireless Networks") suggests that 6LoWPAN ND [RFC6775] can be
   extended to other types of links (beyond IEEE Std. 802.15.4) for
   which it was defined.  The registration technique is beneficial when
   the link-layer technique used to carry IPv6 multicast packets is not
   sufficiently efficient in terms of delivery ratio or energy
   consumption in the end devices -- in particular, to enable
   energy-constrained sleeping nodes.  The value of such an extension is
   especially apparent in the case of mobile wireless nodes, to reduce
   the multicast operations that are related to IPv6 ND [RFC4861]
   [RFC4862] and affect the operation of the wireless medium
   [Multicast-over-IEEE802-Wireless].  This fulfills the scalability
   requirements listed in Appendix B.6.

Appendix B. Requirements (Not Normative)

This appendix lists requirements that were discussed by the 6lo Working Group for an update to 6LoWPAN ND. How those requirements are matched with existing specifications at the time of this writing is shown in Appendix B.8.

B.1. Requirements Related to Mobility

Due to the unstable nature of LLN links, even in an LLN of immobile nodes, a 6LN may change its point of attachment from, say, 6LR-a to 6LR-b but may not be able to notify 6LR-a. Consequently, 6LR-a may still attract traffic that it cannot deliver any more. When links to a 6LR change state, there is thus a need to identify stale states in a 6LR and restore reachability in a timely fashion, e.g., by using some type of signaling upon detection of the movement or using a keep-alive mechanism with a period that is consistent with the needs of the application.
Top   ToC   RFC8505 - Page 40
   Req-1.1:  Upon a change of point of attachment, connectivity via a
             new 6LR MUST be restored in a timely fashion without the
             need to de-register from the previous 6LR.

   Req-1.2:  For that purpose, the protocol MUST enable differentiating
             between multiple registrations from one 6LN and
             registrations from different 6LNs claiming the same

   Req-1.3:  Stale states MUST be cleaned up in 6LRs.

   Req-1.4:  A 6LN SHOULD also be able to register its address
             concurrently to multiple 6LRs.

B.2. Requirements Related to Routing Protocols

The point of attachment of a 6LN may be a 6LR in an LLN mesh. IPv6 routing in an LLN can be based on RPL, which is the routing protocol that was defined by the IETF for this particular purpose. Other routing protocols are also considered by Standards Development Organizations (SDOs) on the basis of the expected network characteristics. It is required that a 6LN attached via ND to a 6LR indicate whether or not it (1) participates in the selected routing protocol to obtain reachability via the 6LR or (2) expects the 6LR to manage its reachability. The specified updates enable other specifications to define new services such as Source Address Validation Improvement (SAVI) (via [AP-ND]), participation as an unaware leaf to a routing protocol (such as the protocol described in [RFC6550] (RPL)) (via [Routing-for-RPL-Leaves]), and registration to Backbone Routers performing proxy ND in an LLN (via [IPv6-Backbone-Router]). Beyond the 6LBR unicast address registered by ND, other addresses, including multicast addresses, are needed as well. For example, a routing protocol often uses a multicast address to register changes to established paths. ND needs to register such a multicast address to enable routing concurrently with discovery. Multicast is needed for groups. Groups may be formed by device type (e.g., routers, street lamps), location (geography, RPL subtree), or both. The Bit Index Explicit Replication (BIER) architecture [RFC8279] proposes an optimized technique to enable multicast in an LLN with a very limited requirement for routing state in the nodes.
Top   ToC   RFC8505 - Page 41
   Related requirements are as follows:

   Req-2.1:  The ND registration method SHOULD be extended so that the
             6LR is instructed whether to advertise the address of a 6LN
             over the selected routing protocol and obtain reachability
             to that address using the selected routing protocol.

   Req-2.2:  Considering RPL, the ARO that is used in the ND
             registration SHOULD be extended to carry enough information
             to generate a DAO message as specified in Section 6.4 of
             [RFC6550] -- in particular, the capability to compute a
             Path Sequence and, as an option, a RPLInstanceID.

   Req-2.3:  Multicast operations SHOULD be supported and optimized --
             for instance, using BIER or the Multicast Protocol for
             Low-Power and Lossy Networks (MPL).  Whether ND is
             appropriate for the registration to the Routing Registrar
             is to be defined, considering the additional burden of
             supporting Multicast Listener Discovery Version 2 (MLDv2)
             for IPv6 [RFC3810].

B.3. Requirements Related to Various Low-Power Link Types

6LoWPAN ND [RFC6775] was defined with a focus on IEEE Std.802.15.4 and, in particular, the capability to derive a unique identifier from a globally unique EUI-64 address. At this point, the 6lo Working Group is extending the 6LoWPAN Header Compression (HC) technique [RFC6282] to other link types, including ITU-T G.9959 [RFC7428], Master-Slave/Token-Passing [RFC8163], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy [RFC8105], Near Field Communication [IPv6-over-NFC], and IEEE Std. 802.11ah [IPv6-over-802.11ah], as well as Bluetooth low energy [RFC7668] and Power Line Communication (PLC) Networks [IPv6-over-PLC]. Related requirements are as follows: Req-3.1: The support of the registration mechanism SHOULD be extended to more LLN links than IEEE Std.802.15.4, matching at least the LLN links for which an "IPv6 over foo" specification exists, as well as low-power Wi-Fi. Req-3.2: As part of this extension, a mechanism to compute a unique identifier should be provided, with the capability to form a Link-Local Address that SHOULD be unique at least within the LLN connected to a 6LBR discovered by ND in each node within the LLN.
Top   ToC   RFC8505 - Page 42
   Req-3.3:  The ARO used in the ND registration SHOULD be extended to
             carry the relevant forms of the unique identifier.

   Req-3.4:  ND should specify the formation of a site-local address
             that follows the security recommendations in [RFC7217].

B.4. Requirements Related to Proxy Operations

Duty-cycled devices may not be awake to answer a lookup from a node that uses IPv6 ND and may need a proxy. Additionally, the duty-cycled device may rely on the 6LBR to perform registration to the Routing Registrar. The ND registration method SHOULD defend the addresses of duty-cycled devices that are sleeping most of the time and incapable of defending their own addresses. Related requirements are as follows: Req-4.1: The registration mechanism SHOULD enable a third party to proxy-register an address on behalf of a 6LN that may be sleeping or located deeper in an LLN mesh. Req-4.2: The registration mechanism SHOULD be applicable to a duty-cycled device regardless of the link type and SHOULD enable a Routing Registrar to operate as a proxy to defend the Registered Addresses on its behalf. Req-4.3: The registration mechanism SHOULD enable long sleep durations, on the order of multiple days to a month.

B.5. Requirements Related to Security

In order to guarantee the operations of the 6LoWPAN ND flows, spoofing the roles of the 6LR, 6LBR, and Routing Registrar should be avoided. Once a node successfully registers an address, 6LoWPAN ND should provide energy-efficient means for the 6LBR to protect that ownership even when the node that registered the address is sleeping. In particular, the 6LR and the 6LBR should then be able to verify whether a subsequent registration for a given address comes from the original node. In an LLN, it makes sense to base security on Layer 2 security. During bootstrap of the LLN, nodes join the network after authorization by a Joining Assistant (JA) or a Commissioning Tool (CT). After joining, nodes communicate with each other via secured links. The keys for Layer 2 security are distributed by the JA/CT.
Top   ToC   RFC8505 - Page 43
   The JA/CT can be part of the LLN or be outside the LLN.  In both
   cases, the ability to route packets between the JA/CT and the joining
   node is needed.

   Related requirements are as follows:

   Req-5.1:  6LoWPAN ND security mechanisms SHOULD provide a mechanism
             for the 6LR, 6LBR, and Routing Registrar to authenticate
             and authorize one another for their respective roles, as
             well as with the 6LN for the role of 6LR.

   Req-5.2:  6LoWPAN ND security mechanisms SHOULD provide a mechanism
             for the 6LR and the 6LBR to validate new registrations of
             authorized nodes.  Joining of unauthorized nodes MUST be

   Req-5.3:  The use of 6LoWPAN ND security mechanisms SHOULD NOT result
             in large packet sizes.  In particular, the NS, NA, DAR, and
             DAC messages for a re-registration flow SHOULD NOT exceed
             80 octets so as to fit in a secured IEEE Std.802.15.4
             [IEEE-802-15-4] frame.

   Req-5.4:  Recurrent 6LoWPAN ND security operations MUST NOT be
             computationally intensive on the 6LN's CPU.  When
             calculation of a key hash is employed, a mechanism lighter
             than SHA-1 SHOULD be used.

   Req-5.5:  The number of keys that the 6LN needs to manipulate SHOULD
             be minimized.

   Req-5.6:  6LoWPAN ND security mechanisms SHOULD enable (1) the
             variation of CCM ("Counter with CBC-MAC") [RFC3610] called
             "CCM*" for use at both Layer 2 and Layer 3 and (2) the
             reuse of a security code that has to be present on the
             device for upper-layer security (e.g., TLS).  Algorithm
             agility and support for large keys (e.g., 256-bit key
             sizes) are also desirable.

   Req-5.7:  Public key and signature sizes SHOULD be minimized while
             maintaining adequate confidentiality and data origin
             authentication for multiple types of applications with
             various degrees of criticality.

   Req-5.8:  Routing of packets should continue when links pass from the
             unsecured state to the secured state.
Top   ToC   RFC8505 - Page 44
   Req-5.9:  6LoWPAN ND security mechanisms SHOULD provide a mechanism
             for the 6LR and the 6LBR to validate whether a new
             registration for a given address corresponds to the same
             6LN that registered it initially and, if not, determine the
             rightful owner and deny or clean up the registration if it
             is a duplicate.

B.6. Requirements Related to Scalability

Use cases from Automatic Meter Reading (AMR) (collection-tree operations) and Advanced Metering Infrastructure (AMI) (bidirectional communication to the meters) indicate the need for a large number of LLN nodes pertaining to a single RPL DODAG (e.g., 5000) and connected to the 6LBR over a large number of LLN hops (e.g., 15). Related requirements are as follows: Req-6.1: The registration mechanism SHOULD enable a single 6LBR to register multiple thousands of devices. Req-6.2: The timing of the registration operation should allow for long latency, such as that found in LLNs with ten or more hops.

B.7. Requirements Related to Operations and Management

Guideline 3.8 in Section 3 of [RFC1958] ("Architectural Principles of the Internet") recommends the following: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually." This is especially true in LLNs where the number of devices may be large and manual configuration is infeasible. Capabilities for dynamic configuration of LLN devices can also be constrained by network and power limitations. A network administrator should be able to validate that the network is operating within capacity and that, in particular, a 6LBR does not get overloaded with an excessive amount of registrations, so the administrator can take actions such as adding a Backbone Link with additional 6LBRs and Routing Registrars to the network.
Top   ToC   RFC8505 - Page 45
   Related requirements are as follows:

   Req-7.1:  A management model SHOULD be provided that enables access
             to the 6LBR, monitors its usage vs. capacity, and sends
             alerts in the case of congestion.  It is recommended that
             the 6LBR be reachable over a non-LLN link.

   Req-7.2:  A management model SHOULD be provided that enables access
             to the 6LR and its capacity to host additional NCEs.  This
             management model SHOULD avoid polling individual 6LRs in a
             way that could disrupt the operation of the LLN.

   Req-7.3:  Information on successful and failed registrations SHOULD
             be provided, including information such as the ROVR of the
             6LN, the Registered Address, the address of the 6LR, and
             the duration of the registration flow.

   Req-7.4:  In the case of a failed registration, information on the
             failure, including the identification of the node that
             rejected the registration and the status in the EARO,
             SHOULD be provided.

B.8. Matching Requirements with Specifications

+-------------+--------------------------------+ | Requirement | Document | +-------------+--------------------------------+ | Req-1.1 | [IPv6-Backbone-Router] | | | | | Req-1.2 | [RFC6775] | | | | | Req-1.3 | [RFC6775] | | | | | Req-1.4 | RFC 8505 | | | | | Req-2.1 | RFC 8505 | | | | | Req-2.2 | RFC 8505 | | | | | Req-2.3 | | | | | | Req-3.1 | Technology Dependent | | | | | Req-3.2 | Technology Dependent | | | | | Req-3.3 | Technology Dependent | | | | | Req-3.4 | Technology Dependent |
Top   ToC   RFC8505 - Page 46
             |             |                                |
             | Req-4.1     | RFC 8505                       |
             |             |                                |
             | Req-4.2     | RFC 8505                       |
             |             |                                |
             | Req-4.3     | [RFC6775]                      |
             |             |                                |
             | Req-5.1     |                                |
             |             |                                |
             | Req-5.2     | [AP-ND]                        |
             |             |                                |
             | Req-5.3     |                                |
             |             |                                |
             | Req-5.4     |                                |
             |             |                                |
             | Req-5.5     | [AP-ND]                        |
             |             |                                |
             | Req-5.6     | [Alternative-Ellip-Curve-Reps] |
             |             |                                |
             | Req-5.7     | [AP-ND]                        |
             |             |                                |
             | Req-5.8     |                                |
             |             |                                |
             | Req-5.9     | [AP-ND]                        |
             |             |                                |
             | Req-6.1     | RFC 8505                       |
             |             |                                |
             | Req-6.2     | RFC 8505                       |
             |             |                                |
             | Req-7.1     |                                |
             |             |                                |
             | Req-7.2     |                                |
             |             |                                |
             | Req-7.3     |                                |
             |             |                                |
             | Req-7.4     |                                |

               Table 8: Documents That Address Requirements
Top   ToC   RFC8505 - Page 47


Kudos to Eric Levy-Abegnoli, who designed the "First-Hop Security" infrastructure upon which the first Backbone Router was implemented. Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee, Warren Kumari, Benjamin Kaduk, Mirja Kuehlewind, Ben Campbell, Eric Rescorla, and Lorenzo Colitti for their various contributions and reviews. Also, many thanks to Thomas Watteyne for the world's first implementation of a 6LN that was instrumental to the early tests of the 6LR, 6LBR, and Backbone Router.

Authors' Addresses

Pascal Thubert (editor) Cisco Systems, Inc. Building D (Regus) 45 Allee des Ormes Mougins - Sophia Antipolis France Phone: +33 4 97 23 26 34 Email: Erik Nordmark Zededa Santa Clara, CA United States of America Email: Samita Chakrabarti Verizon San Jose, CA United States of America Email: Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America Email: