Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: 6LO

RFC 8505

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

Pages: 47
Proposed STD
Updates:  6775
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

              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.

              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.

              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, "IEEE Standard for Low-Rate Wireless Networks",
              IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875,

              Thubert, P., Ed. and C. Perkins, "IPv6 Backbone Router",
              Work in Progress, draft-ietf-6lo-backbone-router-08,
              October 2018.

              Del Carpio Vega, L., Robles, M., and R. Morabito, "IPv6
              over 802.11ah", Work in Progress, draft-delcarpio-6lo-
              wlanah-01, October 2015.

              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.

              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

   Phone: +33 4 97 23 26 34

   Erik Nordmark
   Santa Clara, CA
   United States of America


   Samita Chakrabarti
   San Jose, CA
   United States of America


   Charles E. Perkins
   2330 Central Expressway
   Santa Clara, CA  95050
   United States of America