RFC 8505
Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
Pages: 47
Proposed Standard
→ Errata
Updates: 6775
Updated by: 8928 8929 9010 9685
Proposed Standard
→ Errata
Updates: 6775
Updated by: 8928 8929 9010 9685
Part 3 of 3 – Pages 32 to 47
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: pthubert@cisco.com Erik Nordmark Zededa Santa Clara, CA United States of America Email: nordmark@sonic.net Samita Chakrabarti Verizon San Jose, CA United States of America Email: samitac.ietf@gmail.com Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America Email: charliep@computer.org