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, <https://www.rfc-editor.org/info/rfc2119>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>. [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, <https://www.rfc-editor.org/info/rfc4443>. [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, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>. [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, <https://www.rfc-editor.org/info/rfc4919>. [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, <https://www.rfc-editor.org/info/rfc6282>. [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, <https://www.rfc-editor.org/info/rfc6606>. [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, <https://www.rfc-editor.org/info/rfc6775>. [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, <https://www.rfc-editor.org/info/rfc7400>. [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, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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, <https://ieeexplore.ieee.org/document/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.
[Multicast-over-IEEE802-Wireless] 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. [ND-Optimizations] Chakrabarti, S., Nordmark, E., Thubert, P., and M. Wasserman, "IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks", Work in Progress, draft-chakrabarti-nordmark-6man-efficient-nd-07, February 2015. [Perlman83] 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, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/ readings/p83.pdf>. [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>. [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <https://www.rfc-editor.org/info/rfc3610>. [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, <https://www.rfc-editor.org/info/rfc4429>. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>. [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, <https://www.rfc-editor.org/info/rfc6550>. [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, <https://www.rfc-editor.org/info/rfc7217>. [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <https://www.rfc-editor.org/info/rfc7428>. [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, <https://www.rfc-editor.org/info/rfc7668>. [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>. [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>. [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[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, <https://www.rfc-editor.org/info/rfc8105>. [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, <https://www.rfc-editor.org/info/rfc8163>. [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, <https://www.rfc-editor.org/info/rfc8279>. [Routing-for-RPL-Leaves] Thubert, P., Ed., "Routing for RPL Leaves", Work in Progress, draft-thubert-roll-unaware-leaves-05, May 2018.
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.
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.
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 address. 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.
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.
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.
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 prevented. 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.
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.
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 |
| | | | 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
Acknowledgments 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: email@example.com Erik Nordmark Zededa Santa Clara, CA United States of America Email: firstname.lastname@example.org Samita Chakrabarti Verizon San Jose, CA United States of America Email: email@example.com Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America Email: firstname.lastname@example.org