## 3 Related Work
Assuming each node possesses the same set of interfaces, in order for this to work, each node may possess at most one interface of a given type. Hence, when receiving a message from a given neighbor, it can uniquely identify the neighbor's originating interface. Furthermore, we assume that each node keeps a single neighbor cache, a single default router list, and a single routing table and that each node (conceptually) tracks a single candidate neighbor set and parent set, respectively. Nodes presumably advertise the same rank across all interfaces. Conveniently, with one link-layer address per node and a single neighbor cache, the PO solution can work with 6 LoWPAN ND (Pay, 2018; Pay, 2018), as-is. In addition, both storing and non-storing mode (Section 2.3) would work since nodes are the addressable entities and the default router list and routing table are node-scope as well. 3. The IO proposal views each interface as an independent entity. To this extent, a node keeps track of candidate neighbor tuples (nodeID, interfaceID) and, for each physical neighbor, considers only the tuple with the best link quality for addition to the parent set (based on DODAG version and advertised rank) and subsequent rank computation (1). Rank computation remains largely identical, only now, \(\Delta R_{c}\) is defined as the link metric of the selected tuple. From the parent set, the neighbor tuple with the lowest computed rank becomes preferred. Note that, contrary to the PO solution, there is no stability mechanism preventing erratic preferred parent changes upon link failures. The absence of any sort of stability mechanism, combined with the fact that every interface is a separate neighbor, is shown to lead to DODAG instability. [PERSON] et al. (2018) proposed a dual-radio RPL solution similar to the PO approach (Pay, 2018; Pay, 2018). Firstly, it also builds a single DODAG. Second, each physical neighbor can be addressed through both interfaces with the same IPv6 address(es). Third, a physical node advertises the same rank across both interfaces. The parent set is formed based on the DODAG version and advertised rank of candidate neighbors. However, in this case, two parent sets are formed, one for each interface. Unfortunately, the authors did not specify how the OF subsequently performs rank computation and selects the preferred parent, nor how preferred interfaces are selected. They did, however, describe useful guidelines for RPL management traffic, which we adapted slightly (see Section 4.1). [PERSON] et al. (2018) described a multi-interface RPL extension wherein every interface is an RPL neighbor and a separate addressable entity, maintaining its own neighbor cache. To our understanding, each physical node keeps a single routing table and advertises the same rank across all interfaces. Furthermore, each interface has a unique link-layer address and, from it, derives a link-local unicast address. Each physical node is presumably assigned one routable address, through which it may be reached across all interfaces. If so, that would require it to verify the uniqueness of its routable address on all interfaces before it may be used on any of them. If the routable address is not unique by definition, verifying uniqueness through Duplicate Address Detection (DAD) would only work with basic ND (Pay, 2018; Pay, 2018), and not with its 6 LoWPAN-optimized form (Pay, 2018). What is more, while (for downward traffic) this solution would work well in storing mode (see Section 2.3.2) if each physical node exclusively unicasts DAOs to its preferred parent (which is a neighboring interface), there is likely no standard-compliant method to support non-storing mode (see Section 2.3.1). In addition, [PERSON] et al. 's (2018) proposal suffers a similar problem to [PERSON] et al. 's (Pay, 2018; Pay, 2018) IO solution, i.e., changing the preferred interface to a neighboring node automatically requires a parent change. More recently, [PERSON] et al.