Join Proxy for Bootstrapping of Constrained Network Elements

3.1. Problem Statement

As depicted in Figure 1, the Pledge (P), in a network such as a 6LoWPAN [RFC4944] mesh network
can be more than one hop away from the Registrar (R) and it is not yet authenticated to the network. Also, the Pledge does not possess any key material to encrypt or decrypt link-layer data transmissions.¶

In this situation, the Pledge can only communicate one-hop to its neighbors, such as the constrained Join Proxy (J), using link-local IPv6 addresses and using no link-layer encryption. However, the Pledge needs to communicate with end-to-end security with a Registrar to authenticate and obtain its domain identity/credentials. In the case of cBRSKI, the domain identity is an X.509 certificate. Domain credentials may include key material for network access.¶

So one problem is that there is no IP routability between the Pledge and the Registrar, via intermediate nodes such as 6LoWPAN Routers (6LRs), despite the need for an end-to-end secured session between both.¶

Furthermore, the Pledge is not be able to discover the IP address of the Registrar because it is not yet allowed onto the network.¶

3.2. Solution

To overcome these problems, the constrained Join Proxy is introduced. This is specific functionality that all, or a specific subset of, authenticated nodes in an IP network can implement. When the Join Proxy functionality is enabled in a node, it can help a neighboring Pledge securely onboard the network.¶

The Join Proxy performs relaying of UDP packets from the Pledge to the intended Registrar, and relaying of the subsequent return packets. An authenticated Join Proxy can discover the routable IP address of the Registrar, as specified in this document. Future methods of Registrar discovery can also be easily added.¶

The Join Proxy acts as a packet-by-packet proxy for UDP packets between Pledge and Registrar. The cBRSKI protocol between Pledge and Registrar [cBRSKI] which this Join Proxy supports uses UDP messages with DTLS-encrypted CoAP payloads, but the Join Proxy as described here is unaware of these payloads. The Join Proxy solution can therefore be easily extended to work for other UDP-based protocols, as long as these protocols are agnostic to (or can be made to work with) the change of the IP and UDP headers
performed by the Join Proxy.¶

In summary, the following steps are typically taken for the onboarding process of a Pledge:¶

1. Join Proxies in the network learn the IP address and UDP port of the Registrar.¶

2. A new Pledge arrives: it discovers one or more Join Proxies and selects one.¶

3. The Pledge sends a link-local UDP message to the selected Join Proxy.¶

4. The Join Proxy relays the message to the Registrar (and port) discovered in step 1.¶

5. The Registrar sends a response UDP message back to the Join Proxy.¶

6. The Join Proxy relays the message back to the Pledge.¶

7. Step 3 to 6 repeat as needed, for multiple messages, to complete the onboarding protocol.¶

8. The Pledge uses its obtained domain identity/credentials to join the domain network.¶

To reach the Registrar in step 4, the Join Proxy needs to be either configured with a Registrar address or needs to dynamically discover a Registrar as detailed in Section 5.1. This configuration/discovery is specified here as step 1. Alternatively, in case of automated discovery it can also happen on-demand in step 4, at the moment that the Join Proxy has data to send to the Registrar. For step 1, it is out of scope how a Join Proxy selects a Registrar when it discovers two or more. That is the subject of future work.¶

3.3. Forming 6LoWPAN Mesh Networks with cBRSKI

The Join Proxy has been specifically designed to set up an entire 6LoWPAN mesh network using cBRSKI onboarding. This section outlines how this process works and highlights the role that the Join Proxy plays in forming the mesh network.¶

Typically, the first node to be set up is a 6LoWPAN Border Router (6LBR) which will form the new mesh network and decide on the network's configuration. The 6LBR may be configured using for example one of the below methods. Note that multiple methods may be used within the scope of a single installation.¶

1. Manual administrative configuration¶

2. Use non-constrained BRSKI [RFC8995] to automatically onboard over its high-speed network interface when it gets powered on.¶

3. Use cBRSKI [cBRSKI] to automatically onboard over its high-speed network interface when it gets powered on.¶

Once the 6LBR is enabled, it requires an active Registrar reachable via IP communication to onboard any Pledges. Once cBRSKI onboarding is enabled (either administratively, or automatically) on the 6BLR, it can support
the onboarding of 6LoWPAN-enabled Pledges, via its 6LoWPAN network interface. This 6LBR may host the cBRSKI Registrar itself, but the Registrar may also be hosted elsewhere on the installation network.¶

At the time the Registrar and the 6LBR are enabled, there may be zero Pledges, or there may be already one or more installed and powered Pledges waiting - periodically attempting to discover a Join Proxy over their 6LoWPAN network interface.¶

A Registrar hosted on the 6LBR will, per [cBRSKI], make itself discoverable as a Join Proxy so that Pledges can use it for cBRSKI onboarding over a 6LoWPAN link (one hop). Note that only some of Pledges waiting to onboard may be direct neighbors of the Registrar/6LBR. Other Pledges would need their traffic to be relayed by Join Proxies across one or more enrolled mesh devices (6LR, see Figure 1) in order to reach the Registrar/6LBR. For this purpose, all or a subset of the enrolled Pledges start to act as Join Proxies themselves. Which subset is selected, and when the Join Proxy function is enabled by a node, is out of scope of this document.¶

The desired end state of the installation includes a network with a Registrar and all Pledges successfully enrolled in the network domain and connected to one of the 6LoWPAN mesh networks that are part of the installation. New Pledges may also be added by future network maintenance work on the installation.¶

Pledges employ link-local communication until they are enrolled, at which point they stop being a "Pledge". A Pledge will periodically try to discover a Join Proxy using for example link-local discovery requests, as defined in [cBRSKI]. Pledges that are neighbors of the Registrar will discover the Registrar itself (which is posing as a Join Proxy) and will be enrolled first, using cBRSKI. The Pledges that are not a neighbor of the Registrar will at first fail to find a Join Proxy. Later on, they will eventually discover a Join Proxy so that they can be enrolled with cBRSKI too. While this continues, more and more Join Proxies with a larger hop distance to the Registrar will emerge. The mesh network auto-configures in this way, such that at the end of the onboarding process, all Pledges are enrolled into the network domain and connected to the mesh network.¶

4.1. Mode Implementation and Configuration Requirements

For a Join Proxy implementation on a node, there are three possible scenarios:¶

1. Both stateful and stateless modes are implemented. The Join Proxy can switch between these modes, depending on configuration.¶

2. Only stateful mode is implemented.¶

3. Only stateless mode is implemented.¶

An application profile or ecosystem standard that integrates the Join Proxy functionality as defined in this document MAY define any of these three options. In particular, option 2 or 3 has the advantage of reducing code size and testing efforts, when all devices under the application profile/standard adhere to the same choice.¶

A generic Join Proxy that is not adhering to such an application profile/standard MUST implement both modes.¶

A cBRSKI Registrar by design necessarily implements the stateful mode, and it SHOULD implement support for Join Proxies operating in the stateless mode. The exception case here is a cBRSKI Registrar that is implemented for a particular dedicated application profile/standard which specifies only the stateful mode.¶

If a Join Proxy implements both modes, then it MUST use only the mode that is currently configured for the network (by a method or profile outside the scope of this document) or the mode individually configured for the device. If the mode is not configured, the device MUST NOT operate as a Join Proxy.¶

For a Join Proxy to be operational, the node on which it is running has to be able to talk to a Registrar (exchange UDP messages with it). Establishing this connectivity can happen fully automatically if the Join Proxy node first enrolls itself as a Pledge, and then discovers the Registrar IP address/port and if applicable its desired mode of operation (stateful or stateless), through a discovery mechanism (see Section 5). Other methods, such as provisioning the Join Proxy are out of scope for this document but equally feasible.¶

Independent of the mode of the Join Proxy, the Pledge first discovers (see Section 5.2) and selects the most appropriate Join Proxy. From the discovery result, the Pledge learns a Join Proxy's link-local IP address and UDP join-port. Details of this discovery are defined by the onboarding protocol and are not in scope of this document. For cBRSKI, this is defined in Section 10 of [cBRSKI].¶

4.2. Notation

The following notation is used in this section in both text and figures:¶

• The colon (:) separates IP address and port number (<IP>:<port>).¶

• IP_P denotes the link-local IP address of the Pledge. For simplicity, it is assumed here that the Pledge only has one network interface.¶

• IP_R denotes the routable IP address of the Registrar.¶

• IP_Jl denotes the link-local IP address of the Join Proxy on the interface that connects it to the Pledge.¶

• IP_Jr denotes the routable IP address of the Join Proxy.¶

• p_P denotes the UDP port used by the Pledge for its onboarding/joining protocol, which may be cBRSKI. The Pledge acts in a UDP client role, specifically as a DTLS client for the case of cBRSKI.¶

• p_Jl denotes the join-port of the Join Proxy.¶

• p_Jr denotes the client port of the Join Proxy that it uses to forward packets to the Registrar.¶

• p_R denotes the server port of the Registrar on which it serves the onboarding protocol, such as cBRSKI.¶

• p_Rj denotes the server port of the Registrar on which it serves the JPY protocol.¶

• JPY[H( ),C( )] denotes a JPY message, as defined by the JPY protocol, with header H and content C indicated in between the parentheses.¶

4.3. Stateful Join Proxy

In stateful mode, the Join Proxy acts as a UDP circuit proxy that does not change the UDP payload (called "data octets" in [RFC768]) but only rewrites the IP and UDP headers of each UDP packet it forwards between a Pledge and a Registrar.¶

The UDP flow mapping state maintained by the Join Proxy can be represented as a list of tuples, one for each active Pledge, as follows:¶

In case a Join Proxy has multiple network interfaces that accept Pledges, an interface identifier needs to be added on the leftmost tuple component. If a Join Proxy has multiple network interfaces to connect to (one or more) Registrars, an interface identifier needs to be added to the rightmost tuple component. Both of these are not shown further in this section, for better readability.¶

The establishment of the UDP connection state on the Join Proxy is solely triggered by receipt of a UDP packet from a Pledge with an IP_P:p_P link-local source and IP_Jl:p_Jl link-local destination for which no mapping state exists, and that is terminated by a connection expiry timer.¶

Figure 2 depicts an example DTLS session via the Join Proxy, to show how this state is used in practice. In this case the Join Proxy knows the IP address of the Registrar (IP_R) and the default CoAPS port (P_R = 5684) on the Registrar is used to access cBRSKI resources.¶

The Join Proxy MUST allocate a unique IP_Jr:p_Jr for every unique Pledge that it serves. This is typically done by selecting a unique available port P_Jr for each Pledge. Doing so enables the Join Proxy to correctly map the UDP packets received from the Registrar back to the corresponding Pledges. Also, it enables the Registrar to correctly distinguish multiple DTLS clients by means of IP address/port tuples.¶

The default timeout for clearing the state for a Pledge MUST be 30 seconds after the last relayed packet was sent on a UDP connection associated to that Pledge, in either direction. The default timeout MAY be overridden by another value that is either configured, or discovered in some way out of scope of this document.¶

When a Join Proxy receives an ICMP [RFC792] / ICMPv6 [RFC4443] error from the Registrar, this may signal a permanent change of the Registrar's IP address and/or port, or it may signal a temporary disruption of the network. In such case, the Join Proxy SHOULD send an equivalent ICMP error message (with same Type and Code) to the Pledge. The specific Pledge can be determined from the IP/UDP header information that is contained in the ICMP error message body, if included. In case the ICMP message body is empty, or insufficient information is included there, the Join Proxy does not send the ICMP error message to the Pledge because the intended recipient cannot be determined.¶

To protect itself and the Registrar against malfunctioning Pledges and/or denial of service (DoS) attacks, the Join Proxy SHOULD limit the number of simultaneous state tuples for a given IP_p to at most 2, and it SHOULD limit the number of simultaneous state tuples per network interface to at most 10.¶

When a new Pledge connection is received and the Join Proxy is unable to build new mapping state for it, for example due to the above limits, the Join Proxy SHOULD return an ICMP Type 1 "Destination Unreachable" error message with Code 1, "Communication with destination administratively prohibited".¶

4.4. Stateless Join Proxy

Stateless Join Proxy operation eliminates the need and complexity to maintain per-Pledge UDP connection mapping state on the proxy and the machinery to build, maintain and remove this mapping state. It also removes the need to protect this mapping state against DoS attacks and may also reduce memory and CPU requirements on the proxy.¶

Stateless Join Proxy operations work by introducing a new JPY message used in communication between Proxy and Registrar. This message will store the state "in the network". It consists of two parts:¶

• Header (H) field: contains state information about the Pledge (P) such as the link-local IP address and UDP port.¶

• Contents (C) field: the original UDP payload (data octets according to [RFC768]) received from the Pledge, or destined to the Pledge.¶

When the join proxy receives a UDP message from a Pledge, it encodes the Pledge's link-local IP address, interface ID and UDP (source) port of the UDP packet into the Header field and the UDP payload into the Contents field and sends the packet to the Registrar from a fixed source UDP port. When the Registrar sends packets for the Pledge, it MUST return the Header field unchanged, so that the join proxy can decode the Header to reconstruct the Pledge's link-local IP address, interace and UDP (destination) port for the return UDP packet. Figure 3 shows this per-packet mapping on the join proxy for a DTLS session.¶

The Registrar transiently stores the Header field information. The Registrar uses the Contents field to execute the Registrar functionality. When the Registrar replies, it wraps its DTLS message in a JPY message and sends it back to the Join Proxy. The Registrar SHOULD NOT assume that it can decode the Header Field of a received JPY message, it MUST simply replicate it when responding. The Header of a reply JPY message contains the original source link-local address and port of the Pledge from the transient state stored earlier and the Contents field contains the DTLS payload created by the Registrar.¶

On receiving the JPY message, the Join Proxy retrieves the two parts. It uses the Header field information to send a link-local UDP message containing the (DTLS) payload retrieved from the Contents field to a particular Pledge.¶

When the Registrar receives such a JPY message, it MUST treat the Header H as a single additional opaque identifier of all packets associated to a UDP connection with a Pledge. Whereas in the stateful proxy case, all packets with the same 4-tuple (IP_Jr:p_Jr, IP_R:p_R) belong to a single Pledge's UDP connection, in the stateless proxy case only the packets with the same 5-tuple (IP_Jr:p_Jr, IP_R:p_Rj, H) belong to a single Pledge's UDP connection. The JPY message Contents field contains the UDP payload of the packet for that Pledge's UDP connection. Packets with different header H belong to different Pledge's UDP connections.¶

In the stateless mode, the Registrar MUST offer the JPY protocol on a discoverable UDP port (p_Rj). There is no default port number available for the JPY protocol, unlike in the stateful mode where the Registrar can host all its services on the CoAPS default port.¶

When a Join Proxy receives an ICMP [RFC792] / ICMPv6 [RFC4443] error from the Registrar, this may signal a permanent change of the Registrar's IP address and/or port, or it may signal a temporary disruption of the network.¶

Unlike a stateful Join Proxy, the stateless Join Proxy cannot determine the Pledge to which this ICMP error should be mapped, because the JPY header containing this information is not included in the ICMP error message. Therefore, it cannot inform the Pledge of the specific error that occurred.¶

4.5. JPY Protocol and Messages

JPY messages are used by a stateless Join Proxy to carry required state information in the relayed UDP messages, such that it does not need to store this state in memory. JPY messages are carried directly over the UDP layer. So, there is no CoAP or DTLS layer used between the JPY messages and the UDP layer.¶

A Registrar that supports the JPY protocol also uses JPY message to return relayed UDP messages to the stateless Join Proxy, including the state information that it needs.¶

    jpy_message =
    [
       jpy_header  : bstr,
       jpy_content : bstr,
    ]

    jpy_header_plaintext = [
      family:  uint .bits 1,
      ifindex: uint .bits 8,
      srcport: uint .bits 16,
      iid:     bstr .bits 64,
    ]

5.1. Join Proxy Discovers Registrar

In order to accommodate automatic configuration of the Join Proxy, it MUST discover the location and capabilities of the Registrar, in case this information is not configured already.¶

In BRSKI [RFC8995] the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] protocol is supported for discovery of a BRSKI Registrar in an Autonomic Control Plane (ACP). However, this document does not target the ACP context of use. Therefore, the definition of how to use GRASP for discovering a cBRSKI Registrar is left to future work such as [I-D.ietf-anima-brski-discovery].¶

Although multiple discovery methods can be supported in principle by a single Join Proxy, this document only defines one default method for a Join Proxy to discover a Registrar: using CoAP resource discovery queries [RFC6690] [RFC7252].¶

The CoAP discovery query to use depends on the intended mode of operation of the Join Proxy, stateless or stateful. A stateless Join Proxy needs to discover a UDP endpoint (address and port) that can accept JPY messages. On the other hand, a stateful Join Proxy needs to discover a single CoAPS endpoint that offers the full set of cBRSKI Registrar resources.¶

  REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp

  RES: 2.05 Content
    Content-Format: 40
    Payload:
      <coaps+jpy://[ipv6_address]:port>;rt=brski.rjp

  REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski

  RES: 2.05 Content
    Content-Format: 40
    Payload:
      <coaps://[ipv6_address]:port/uri_path>;rt=brski

  REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski

  RES: 2.05 Content
    Content-Format: 40
    Payload:
        <coaps://[2001:db8:0:abcd::52]/b>;rt=brski

  REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp

  RES: 2.05 Content
    Content-Format: 40
    Payload:
        <coaps+jpy://[2001:db8:0:abcd::52]:7634>;rt=brski.rjp

5.2. Pledge Discovers Join Proxy

Regardless of whether the Join Proxy operates in stateful or stateless mode, it is discovered by the Pledge identically. Section 10 of [cBRSKI] defines the details of the CoAP discovery request sent by the Pledge.¶

A Join Proxy implementation by default MUST support this discovery method. If there is another method configured, by some means outside of the scope of this document, the default method MAY be deactivated.¶

The join-port of the Join Proxy is discovered by sending a multicast GET request to "/.well-known/core" including a resource type (rt) parameter with the value "brski.jp". This value is defined in Section 8.1. Upon success, the return payload will contain the join-port.¶

The example below shows the discovery of the join-port (field join_port) of the Join Proxy:¶

  REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

  RES: 2.05 Content
    Content-Format: 40
    Payload:
      <coaps://[IP_address]:join_port>;rt=brski.jp

Note that the join_port field and preceding colon MAY be absent in the discovery response: this indicates that the join-port is the default CoAPS port 5684.¶

In the returned CoRE link format document, discoverable port numbers are usually returned for the Join Proxy resource in the <URI-Reference> of the link (see Section 5.1 of [RFC6690] for details).¶

8.1. Resource Type Attributes Registry

This specification registers two new Resource Type (rt=) Link Target Attributes in the "Resource Type (rt=) Link Target Attribute Values" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group, per the [RFC6690] procedure.¶

Attribute Value: brski.jp
Description: Constrained Join Proxy for cBRSKI onboarding protocol.
Reference:   [This RFC]

Attribute Value: brski.rjp
Description: cBRSKI Registrar Join Proxy endpoint that supports the
             JPY protocol.
Reference:   [This RFC]

8.2. coaps+jpy Scheme Registration

This specification registers a new URI scheme per [RFC7595] under the IANA "Uniform Resource Identifier (URI) Schemes" registry.¶

Scheme name: coaps+jpy
Status:      permanent
Applications/protocols that use this scheme name:
             cBRSKI, constrained Join Proxy
Contact:     ANIMA WG
Change controller: IESG
References:  [This RFC]

The scheme specification is provided below.¶

• Scheme syntax: identical to the "coaps" scheme defined in [RFC7252].¶

• Scheme semantics: identical to the "coaps" scheme, except that the JPY message encapsulation mechanism described in Section 4.5 of [This RFC] is used to transport each CoAPS UDP datagram.¶

• Encoding considerations: identical to the "coaps" scheme.¶

• Interoperability considerations: identical to the "coaps" scheme.¶

• Security considerations: all of the security considerations of the "coaps" scheme apply. Users of this scheme should be aware that as part of the intended use, a UDP message that was formed using the "coaps" scheme is modified by a Join Proxy as defined by [This RFC] into a UDP message conforming to the "coaps+jpy" scheme without the Join Proxy being able to parse/decode which CoAPS URI was originally used by the sender. Depending on the CoAP Options used in the original CoAPS message, this operation may modify elements of the original CoAPS URI (as will be reconstructed by the receiving coaps+jpy server) in a way that is unknown to the Join Proxy.¶

8.3. Service Name and Transport Protocol Port Number Registry

This specification registers two service names under the IANA "Service Name and Transport Protocol Port Number" registry.¶

Service Name: brski-jp
Transport Protocol(s): udp
Assignee:  IESG <iesg@ietf.org>
Contact:  IESG <iesg@ietf.org>
Description: Bootstrapping Remote Secure Key Infrastructure
             constrained Join Proxy
Reference:   [This RFC]

Service Name: brski-rjp
Transport Protocol(s): udp
Assignee:  IESG <iesg@ietf.org>
Contact:  IESG <iesg@ietf.org>
Description: Bootstrapping Remote Secure Key Infrastructure
             Registrar join-port used by stateless constrained
             Join Proxy
Reference:   [This RFC]

12.1. Normative References

[cBRSKI]

Richardson, M., Van der Stok, P., Kampanakis, P., and E. Dijk, "Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-constrained-voucher-26, 8 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-26>.

[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/rfc/rfc2119>.

[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/rfc/rfc4443>.

[RFC768]

Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/rfc/rfc768>.

[RFC792]

Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/rfc/rfc792>.

[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/rfc/rfc8174>.

[RFC8366bis]

Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T., and Q. Ma, "A Voucher Artifact for Bootstrapping Protocols", Work in Progress, Internet-Draft, draft-ietf-anima-rfc8366bis-12, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-rfc8366bis-12>.

[RFC8949]

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

[RFC8995]

Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

[RFC9147]

Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/rfc/rfc9147>.

[RFC9148]

van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol", RFC 9148, DOI 10.17487/RFC9148, April 2022, <https://www.rfc-editor.org/rfc/rfc9148>.

12.2. Informative References

[I-D.ietf-anima-brski-discovery]

Eckert, T. T. and E. Dijk, "BRSKI discovery and variations", Work in Progress, Internet-Draft, draft-ietf-anima-brski-discovery-05, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-discovery-05>.

[I-D.kumar-dice-dtls-relay]

Kumar, S. S., Keoh, S. L., and O. Garcia-Morchon, "DTLS Relay for Constrained Environments", Work in Progress, Internet-Draft, draft-kumar-dice-dtls-relay-02, 20 October 2014, <https://datatracker.ietf.org/doc/html/draft-kumar-dice-dtls-relay-02>.

[I-D.richardson-anima-state-for-joinrouter]

Richardson, M., "Considerations for stateful vs stateless join router in ANIMA bootstrap", Work in Progress, Internet-Draft, draft-richardson-anima-state-for-joinrouter-03, 22 September 2020, <https://datatracker.ietf.org/doc/html/draft-richardson-anima-state-for-joinrouter-03>.

[ieee802-1AR]

"IEEE 802.1AR Secure Device Identity", IEEE Standards Association, 2018, <https://standards.ieee.org/ieee/802.1AR/6995/>.

[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/rfc/rfc3610>.

[RFC3927]

Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/rfc/rfc3927>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4944]

Montenegro, G., Kushalnagar, N., Hui, J., 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/rfc/rfc4944>.

[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/rfc/rfc6550>.

[RFC6690]

Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/rfc/rfc6690>.

[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/rfc/rfc6775>.

[RFC7030]

Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/rfc/rfc7030>.

[RFC7102]

Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <https://www.rfc-editor.org/rfc/rfc7102>.

[RFC7228]

Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/rfc/rfc7228>.

[RFC7252]

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

[RFC7595]

Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/rfc/rfc7595>.

[RFC7959]

Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/rfc/rfc7959>.

[RFC8610]

Birkholz, H., Vigano, C., 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/rfc/rfc8610>.

[RFC8974]

Hartke, K. 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/rfc/rfc8974>.

[RFC8990]

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

[RFC9031]

Vučinić, M., Ed., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", RFC 9031, DOI 10.17487/RFC9031, May 2021, <https://www.rfc-editor.org/rfc/rfc9031>.