• pledge
• joined node
• Join Proxy (JP)
• Join Registrar/Coordinator (JRC)
• Enhanced Beacon (EB)
• join protocol
• join process

• 6LoWPAN Border Router (6LBR)
• 6LoWPAN Node (6LN)

pledge identifier:

The pledge identifier identifies the (6LBR) pledge.The pledge identifier MUST be unique in the set of all pledge identifiers managed by a JRC.The pledge identifier uniqueness is an important security requirement, as discussed in Section 9.The pledge identifier is typically the globally unique 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 802.15.4 device, in which case it is provisioned by the hardware manufacturer. The pledge identifier is used to generate the IPv6 addresses of the (6LBR) pledge and to identify it during the execution of the join protocol.Depending on the configuration, the pledge identifier may also be used after the join process to identify the joined node.For privacy reasons (see Section 10), it is possible to use a pledge identifier different from the EUI-64.For example, a pledge identifier may be a random byte string, but care needs to be taken that such a string meets the uniqueness requirement.

Pre-Shared Key (PSK):

A symmetric cryptographic key shared between the (6LBR) pledge and the JRC.To look up the PSK for a given pledge, the JRC additionally needs to store the corresponding pledge identifier.Each (6LBR) pledge MUST be provisioned with a unique PSK.The PSK MUST be a cryptographically strong key, with at least 128 bits of entropy, indistinguishable by feasible computation from a random uniform string of the same length.How the PSK is generated and/or provisioned is out of scope of this specification.This could be done during a provisioning step, or companion documents can specify the use of a key-agreement protocol.Common pitfalls when generating PSKs are discussed in Section 9.In the case of recommissioning a device to a new owner, the PSK MUST be changed.Note that the PSK is different from the link-layer keys K1 and K2 specified in [RFC 8180].The PSK is a long-term secret used to protect the execution of the secure join protocol specified in this document; the link-layer keys are transported as part of the secure join protocol.

Optionally, a network identifier:

The network identifier identifies the 6TiSCH network.The network identifier MUST be carried within Enhanced Beacon (EB) frames.Typically, the 16-bit Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4] is used as the network identifier.However, PAN ID is not considered a stable network identifier as it may change during network lifetime if a collision with another network is detected.Companion documents can specify the use of a different network identifier for join purposes, but this is out of scope of this specification.Provisioning the network identifier to a pledge is RECOMMENDED.However, due to operational constraints, the network identifier may not be known at the time of provisioning.If this parameter is not provisioned to the pledge, the pledge will attempt to join one advertised network at a time, which significantly prolongs the join process.This parameter MUST be provisioned to the 6LBR pledge.

Optionally, any non-default algorithms:

The default algorithms are specified in Section 7.3.3.When algorithm identifiers are not provisioned, the use of these default algorithms is implied.

Global IPv6 address of the JRC:

This address is used by the 6LBR pledge to address the JRC during the join process.The 6LBR pledge may also obtain the IPv6 address of the JRC through other available mechanisms, such as DHCPv6 [RFC 8415], Generic Autonomic Signaling Protocol (GRASP) [RFC 8990], or Multicast DNS (mDNS) [RFC 6762]; the use of these mechanisms is out of scope of this document.Pledges do not need to be provisioned with this address as they discover it dynamically through CoJP.

1. The pledge listens for an Enhanced Beacon (EB) frame [IEEE802.15.4]. This frame provides network synchronization information, telling the device when it can send a frame to the node sending the beacons, which acts as a Join Proxy (JP) for the pledge, and when it can expect to receive a frame. The EB provides the link-layer address of the JP, and it may also provide its link-local IPv6 address.
2. The pledge configures its link-local IPv6 address and advertises it to the JP using Neighbor Discovery. The advertisement step may be omitted if the link-local address has been derived from a known unique interface identifier, such as an EUI-64 address.
3. The pledge sends a Join Request to the JP in order to securely identify itself to the network. The Join Request is forwarded to the JRC.
4. In the case of successful processing of the request, the pledge receives a Join Response from the JRC (via the JP). The Join Response contains configuration parameters necessary for the pledge to join the network.

+--------+                 +-------+                 +--------+
| pledge |                 |  JP   |                 |  JRC   |
|        |                 |       |                 |        |
+--------+                 +-------+                 +--------+
   |                          |                          |
   |<---Enhanced Beacon (1)---|                          |
   |                          |                          |
   |<-Neighbor Discovery (2)->|                          |
   |                          |                          |
   |-----Join Request (3a)----|----Join Request (3a)---->| \
   |                          |                          | | CoJP
   |<----Join Response (3b)---|----Join Response (3b)----| /
   |                          |                          |

• The Master Secret MUST be the PSK.
• The Master Salt MUST be the empty byte string.
• The ID Context MUST be set to the pledge identifier.
• The ID of the pledge MUST be set to the empty byte string. This identifier is used as the OSCORE Sender ID of the pledge in the security context derivation, since the pledge initially acts as a CoAP client.
• The ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" in ASCII). This identifier is used as the OSCORE Recipient ID of the pledge in the security context derivation, as the JRC initially acts as a CoAP server.
• The Algorithm MUST be set to the value from [RFC 8152], agreed to out-of-band by the same mechanism used to provision the PSK. The default is AES-CCM-16-64-128.
• The key derivation function MUST be agreed out-of-band by the same mechanism used to provision the PSK. Default is HKDF SHA-256 [RFC 5869].

+-----------------------------------+
|  Constrained Join Protocol (CoJP) |
+-----------------------------------+
+-----------------------------------+  \
|         Requests / Responses      |  |
|-----------------------------------|  |
|               OSCORE              |  | CoAP
|-----------------------------------|  |
|           Messaging Layer         |  |
+-----------------------------------+  /
+-----------------------------------+
|                UDP                |
+-----------------------------------+

• The Join Request message, sent by the (6LBR) pledge to the JRC, potentially proxied by the JP. The Join Request message and its mapping to CoAP is specified in Section 8.1.1.
• The Join Response message, sent by the JRC to the (6LBR) pledge, if the JRC successfully processes the Join Request using OSCORE and it determines through a mechanism that is out of scope of this specification that the (6LBR) pledge is authorized to join the network. The Join Response message is potentially proxied by the JP. The Join Response message and its mapping to CoAP is specified in Section 8.1.2.

• The Parameter Update message, sent by the JRC to the joined node that formerly acted as a (6LBR) pledge. The Parameter Update message and its mapping to CoAP is specified in Section 8.2.1.

• The request method is POST.
• The type is Confirmable (CON).
• The Proxy-Scheme option is set to "coap".
• The Uri-Host option is set to "6tisch.arpa". This is an anycast type of identifier of the JRC that is resolved to its IPv6 address by the JP or the 6LBR pledge.
• The Uri-Path option is set to "j".
• The OSCORE option SHALL be set according to [RFC 8613]. The OSCORE security context used is the one derived in Section 7.3. The OSCORE 'kid context' allows the JRC to retrieve the security context for a given pledge.
• The payload is a Join_Request CBOR object, as defined in Section 8.4.1.

• The Response Code is 2.04 (Changed).
• The payload is a Configuration CBOR object, as defined in Section 8.4.2.

• The request method is POST.
• The type is Confirmable (CON).
• The Uri-Host option is set to "6tisch.arpa".
• The Uri-Path option is set to "j".
• The OSCORE option SHALL be set according to [RFC 8613]. The OSCORE security context used is the one derived in Section 7.3. When a joined node receives a request with the Sender ID set to 0x4a5243 (ID of the JRC), it is able to correctly retrieve the security context with the JRC.
• The payload is a Configuration CBOR object, as defined in Section 8.4.2.

• The Response Code is 4.00 (Bad Request).
• The payload is an Unsupported Configuration CBOR object, as defined in Section 8.4.5, containing more information about the parameter that triggered the sending of this message.

role:

The identifier of the role that the pledge requests to play in the network once it joins, encoded as an unsigned integer.Possible values are specified in Table 3.This parameter MAY be included.If the parameter is omitted, the default value of 0, i.e., the role "6TiSCH Node", MUST be assumed.

network identifier:

The identifier of the network, as discussed in Section 3, encoded as a CBOR byte string.When present in the Join_Request, it hints to the JRC which network the pledge is requesting to join, enabling the JRC to manage multiple networks.The pledge obtains the value of the network identifier from the received EB frames.This parameter MUST be included in a Join_Request object regardless of the role parameter value.

unsupported configuration:

The identifier of the parameters that are not supported by the implementation, encoded as an Unsupported_Configuration object described in Section 8.4.5.This parameter MAY be included.If a (6LBR) pledge previously attempted to join and received a valid Join Response message over OSCORE but failed to act on its payload (Configuration object), it SHOULD include this parameter to facilitate the recovery and debugging.

Join_Request = {
    ? 1 : uint,                       ; role
      5 : bstr,                       ; network identifier
    ? 8 : Unsupported_Configuration   ; unsupported configuration
}

link-layer key set:

An array encompassing a set of cryptographic keys and their identifiers that are currently in use in the network or that are scheduled to be used in the future.The encoding of individual keys is described in Section 8.4.3.The link-layer key set parameter MAY be included in a Configuration object.When present, the link-layer key set parameter MUST contain at least one key.This parameter is also used to implement rekeying in the network.The installation and use of keys differs for the 6LBR and other (regular) nodes, and this is explained in Sections [8.4.3.1] and [8.4.3.2].

short identifier:

A compact identifier assigned to the pledge.The short identifier structure is described in Section 8.4.4.The short identifier parameter MAY be included in a Configuration object.

JRC address:

The IPv6 address of the JRC, encoded as a byte string, with the length of 16 bytes.If the length of the byte string is different from 16, the parameter MUST be discarded.If the JRC is not co-located with the 6LBR and has a different IPv6 address than the 6LBR, this parameter MUST be included.In the special case where the JRC is co-located with the 6LBR and has the same IPv6 address as the 6LBR, this parameter MAY be included.If the JRC address parameter is not present in the Configuration object, this indicates that the JRC has the same IPv6 address as the 6LBR.The joined node can then discover the IPv6 address of the JRC through network control traffic.See Section 6.

blacklist:

An array encompassing a list of pledge identifiers that are blacklisted by the JRC, with each pledge identifier encoded as a byte string.The blacklist parameter MAY be included in a Configuration object.When present, the array MUST contain zero or more byte strings encoding pledge identifiers.The joined node MUST silently drop any link-layer frames originating from the pledge identifiers enclosed in the blacklist parameter.When this parameter is received, its value MUST overwrite any previously set values.This parameter allows the JRC to configure the node acting as a JP to filter out traffic from misconfigured or malicious pledges before their traffic is forwarded into the network.If the JRC decides to remove a given pledge identifier from a blacklist, it omits the pledge identifier in the blacklist parameter value it sends next.Since the blacklist parameter carries the pledge identifiers, privacy considerations apply.See Section 10.

join rate:

The average data rate (in units of bytes/second) of join traffic forwarded into the network that should not be exceeded when a joined node operates as a JP, encoded as an unsigned integer.The join rate parameter MAY be included in a Configuration object.This parameter allows the JRC to configure different nodes in the network to operate as JP and to act in case of an attack by throttling the rate at which JP forwards unauthenticated traffic into the network.When this parameter is present in a Configuration object, the value MUST be used to set the PROBING_RATE of CoAP at the joined node for communication with the JRC.If this parameter is set to zero, a joined node MUST silently drop any join traffic coming from unauthenticated pledges.If this parameter is omitted, the value of positive infinity SHOULD be assumed.A node operating as a JP MAY use another mechanism that is out of scope of this specification to configure the PROBING_RATE of CoAP in the absence of a join rate parameter from the Configuration object.

Configuration = {
    ? 2 : [ +Link_Layer_Key ],   ; link-layer key set
    ? 3 : Short_Identifier,      ; short identifier
    ? 4 : bstr,                  ; JRC address
    ? 6 : [ *bstr ],             ; blacklist
    ? 7 : uint                   ; join rate
}

key_id:

The identifier of the key, encoded as a CBOR unsigned integer.This parameter MUST be included.If the decoded CBOR unsigned integer value is larger than the maximum link-layer key identifier, the key is considered invalid.If the key is considered invalid, the key MUST be discarded,and the implementation MUST signal the error as specified in Section 8.3.1.

key_usage:

The identifier of the link-layer algorithm, security level, and link-layer frame types that can be used with the key, encoded as an integer.This parameter MAY be included.Possible values and the corresponding link-layer settings are specified in theIANA "Constrained Join Protocol (CoJP) Key Usage" registry (Section 11.2).If the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-MIC32) from Table 6 MUST be assumed.This default value has been chosen because it results in byte savings in the most constrained settings; its selection does not imply a recommendation for its general usage.

key_value:

The value of the cryptographic key, encoded as a byte string.This parameter MUST be included.If the length of the byte string is different than the corresponding key length for a given algorithm specified by the key_usage parameter, the key MUST be discarded, and the implementation MUST signal the error as specified in Section 8.3.1.

key_addinfo:

Additional information needed to configure the link-layer key, encoded as a byte string.This parameter MAY be included.The processing of this parameter is dependent on the link-layer technology in use and a particular keying mode.

Link_Layer_Key = (
      key_id             : uint,
    ? key_usage          : int,
      key_value          : bstr,
    ? key_addinfo        : bstr,
)

Key ID Mode 0x00 (Implicit, pairwise):

The key_id parameter MUST be set to 0.The key_addinfo parameter MUST be present.The key_addinfo parameter MUST be set to the link-layer address(es) of a single peer with whom the key should be used.Depending on the configuration of the network, key_addinfo may carry the peer's long link-layer address (i.e., pledge identifier), short link-layer address, or their concatenation with the long address being encoded first.Which address type(s) is carried is determined from the length of the byte string.

Key ID Mode 0x01 (Key Index):

The key_id parameter MUST be set to a value different from 0.The key_addinfo parameter MUST NOT be present.

Key ID Mode 0x02 (4-byte Explicit Key Source):

The key_id parameter MUST be set to a value different from 0.The key_addinfo parameter MUST be present.The key_addinfo parameter MUST be set to a byte string, exactly 4 bytes long.The key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4].

Key ID Mode 0x03 (8-byte Explicit Key Source):

The key_id parameter MUST be set to a value different from 0.The key_addinfo parameter MUST be present.The key_addinfo parameter MUST be set to a byte string, exactly 8 bytes long.The key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4].

identifier:

The short identifier assigned to the pledge, encoded as a byte string.This parameter MUST be included.The identifier MUST be unique in the set of all identifiers assigned in a network that is managed by a JRC.If the identifier is invalid, the decoder MUST silently ignore the Short_Identifier object.

lease_time:

The validity of the identifier in hours after the reception of the CBOR object, encoded as a CBOR unsigned integer.This parameter MAY be included.The node MUST stop using the assigned short identifier after the expiry of the lease_time interval.It is up to the JRC to renew the lease before the expiry of the previous interval.The JRC updates the lease by executing the parameter update exchange with the node and including the Short_Identifier in the Configuration object, as described in Section 8.2.If the lease expires, then the node SHOULD initiate a new join exchange, as described in Section 8.1.If this parameter is omitted, then the value of positive infinity MUST be assumed, meaning that the identifier is valid for as long as the node participates in the network.

Short_Identifier = [
      identifier        : bstr,
    ? lease_time        : uint
]

code:

Indicates the capability of acting on the parameter signaled by parameter_label, encoded as an integer.This parameter MUST be included.Possible values of this parameter are specified in the IANA "Constrained Join Protocol (CoJP) Unsupported Configuration Codes" registry (Section 11.3).

parameter_label:

Indicates the parameter. This parameter MUST be included. Possible values of this parameter are specified in the label column of the IANA "Constrained Join Protocol (CoJP) Parameters" registry" (Section 11.1).

parameter_addinfo:

Additional information about the parameter that cannot be acted upon.This parameter MUST be included.If the code is set to "Unsupported", parameter_addinfo gives additional information to the JRC.If the parameter indicated by parameter_label cannot be acted upon regardless of its value, parameter_addinfo MUST be set to null, signaling to the JRC that it SHOULD NOT attempt to configure the parameter again.If the pledge can act on the parameter, but cannot configure the setting indicated by the parameter value, the pledge can hint this to the JRC.In this case, parameter_addinfo MUST be set to the value of the parameter that cannot be acted upon following the normative parameter structure specified in this document.For example, it is possible to include the link-layer key set object, signaling that either a subset or the entire key set that was received cannot be acted upon. In that case, the value of parameter_addinfo follows the link-layer key set structure defined in Section 8.4.2.If the code is set to "Malformed", parameter_addinfo MUST be set to null, signaling to the JRC that it SHOULD NOT attempt to configure the parameter again.

Unsupported_Configuration = [
       + parameter           : Unsupported_Parameter
]

Unsupported_Parameter = (
         code                : int,
         parameter_label     : int,
         parameter_addinfo   : nil / any
)

Name:

This is a descriptive name that enables an easier reference to the item.It is not used in the encoding. The name MUST be unique.

Label:

The value to be used to identify this parameter.The label is an integer. The label MUST be unique.

CBOR Type:

This field contains the CBOR type for the field.

Description:

This field contains a brief description for the field. The description MUST be unique.

Reference:

This field contains a pointer to the public specification for the field, if one exists.

Name:

This is a descriptive name that enables easier reference to the item.It is not used in the encoding. The name MUST be unique.

Value:

This is the value used to identify the key usage setting.These values MUST be unique. The value is an integer.

Algorithm:

This is a descriptive name of the link-layer algorithm in use and uniquely determines the key length.The name is not used in the encoding. The algorithm MUST be unique.

Description:

This field contains a description of the key usage setting.The field should describe in enough detail how the key is to be used with different frame types, specific for the link-layer technology in question. The description MUST be unique.

Reference:

This contains a pointer to the public specification for the field, if one exists.

Name:

This is a descriptive name that enables easier reference to the item.It is not used in the encoding.The name MUST be unique.

Value:

This is the value used to identify the diagnostic code.These values MUST be unique.The value is an integer.

Description:

This is a descriptive human-readable name.The description MUST be unique.It is not used in the encoding.

Reference:

This contains a pointer to the public specification for the field, if one exists.

[IEEE802.15.4]

IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, April 2016,
<https://ieeexplore.ieee.org/document/7460875>.

[RFC2119]

S. Bradner, "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>.

[RFC2597]

J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>.

[RFC3172]

G. Huston, "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001,
<https://www.rfc-editor.org/info/rfc3172>.

[RFC5869]

H. Krawczyk, and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.

[RFC6761]

S. Cheshire, and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013,
<https://www.rfc-editor.org/info/rfc6761>.

[RFC7252]

Z. Shelby, K. Hartke, and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.

[RFC7554]

T. Watteyne, M. Palattella, and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.

[RFC8085]

L. Eggert, G. Fairhurst, and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017,
<https://www.rfc-editor.org/info/rfc8085>.

[RFC8126]

M. Cotton, B. Leiba, 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>.

[RFC8152]

J. Schaad, "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.

[RFC8174]

B. Leiba, "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>.

[RFC8180]

X. Vilajosana, K. Pister, and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017,
<https://www.rfc-editor.org/info/rfc8180>.

[RFC8505]

P. Thubert, E. Nordmark, S. Chakrabarti, and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.

[RFC8613]

G. Selander, J. Mattsson, F. Palombini, and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.

[RFC8820]

M. Nottingham, "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020,
<https://www.rfc-editor.org/info/rfc8820>.

[RFC8949]

C. Bormann, and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.

[RFC8974]

K. Hartke, and M. Richardson, "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
<https://www.rfc-editor.org/info/rfc8974>.

[RFC9030]

P Thubert, "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.

[NIST800-90A]

National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", DOI 10.6028/NIST.SP.800-90Ar1, June 2015,
<https://doi.org/10.6028/NIST.SP.800-90Ar1>.

[RFC4231]

M. Nystrom, "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005,
<https://www.rfc-editor.org/info/rfc4231>.

[RFC4944]

G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.

[RFC6550]

T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, 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>.

[RFC6762]

S. Cheshire, and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.

[RFC7721]

A. Cooper, F. Gont, and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.

[RFC8415]

T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.

[RFC8480]

Q. Wang, X. Vilajosana, and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>.

[RFC8610]

H. Birkholz, C. Vigano, and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019,
<https://www.rfc-editor.org/info/rfc8610>.

[RFC8615]

M. Nottingham, "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.

[RFC8742]

C. Bormann, "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>.

[RFC8990]

C. Bormann, B. Carpenter, and B. Liu, "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021,
<https://www.rfc-editor.org/info/rfc8990>.

Mališa Vučinić

Jonathan Simon

Kris Pister

Michael Richardson