WO2016205673A1

WO2016205673A1 - Enhanced address registration in constrained networks

Info

Publication number: WO2016205673A1
Application number: PCT/US2016/038113
Authority: WO
Inventors: Chonggang Wang; Zhuo Chen; Shamim Akbar Rahman; Quang Ly; Vinod Kumar Choyi; Guang Lu; Xu Li; Rocco Di Girolamo; Lijun Dong
Original assignee: Convida Wireless, Llc
Priority date: 2015-06-19
Filing date: 2016-06-17
Publication date: 2016-12-22

Abstract

Existing IPv6 over Wireless Personal Area Networks (6LoWPANs) employ multi-hop Duplicate Address Detection (DAD). Overhead and/or hops can be reduced as compared to existing multi-hop DAD approaches.

Description

ENHANCED ADDRESS REGISTRATION IN CONSTRAINED NETWORKS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62/181,972 filed June 19, 2015, the disclosure of which is hereby incorporated by reference as if set forth in its entirety herein.

BACKGROUND

[0002] IPv6 over Wireless Personal Area Networks (6L0WPAN) refers to a network of constrained devices based on the IEEE 802.15.4 medium access control (MAC) protocol and the IPv6 protocol. A 6L0WPAN can work in a mesh-under mode or a route-over mode. Fig. 1 illustrates an example of a route-over 6L0WPAN network, which consists of a 6L0WPAN Border Router (6LBR), multiple 6L0WPAN Routers (6LRs), and multiple 6L0WPAN Nodes (6LNs). A 6LBR refers to a border router that is located at the junction of separate 6L0WPAN networks or between a 6L0WPAN network and another IP network. There may be one or more 6LBRs at a given 6L0WPAN network boundary. A 6LBR is the responsible authority for IPv6 prefix propagation for the 6L0WPAN network it is serving. An isolated 6L0WPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network. A 6LN refers to any host or router participating in a 6L0WPAN. A 6LN finds its default 6LR in order to join a given 6L0WPAN. A 6LR refers to an intermediate router in a given 6L0WPAN that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs), and forward and route IPv6 packets. 6L0WPAN routers are present in route-over topologies, such as the example shown in Fig. 1. Route-over refers to a topology in which hosts are connected to the 6LBR via the use of intermediate layer-3 (IP) routing. In such a topology, hosts are typically multiple IP hops from a 6LBR. As shown in Fig. 1, a route-over topology often consists of a 6LBR, a set of 6LRs, and hosts (e.g., 6LNs).

[0003] A 6L0WPAN can be deployed to support various applications, such as, for example, applications related to industrial monitoring, a connected home, healthcare, vehicle telematics, and agricultural monitoring. These applications may differ from each other in deployment method, network size, power source, connectivity, multi-hop communications, traffic pattern, mobility, security level, and/or quality of service. For example, a 6L0WPAN deployed in roads, vehicles, and traffic signals for vehicle telematics may be associated with various features, such as, pre-planned deployment, a hybrid power source, ad hoc and multi-hop communications, and high mobility for vehicles as compared to no mobility for roadside infrastructure.

[0004] A deployed 6L0WPAN can be an isolated network or a network integrated with the Internet. In an isolated 6L0WPAN, such as a wireless sensor network for a smart home for example, 6LRs and 6LNs can trust each other. In other 6LoWPANs, such as those deployed for environmental monitoring with remote control from the Internet for example, 6LRs and 6LNs may come and leave dynamically, and they might not trust each other.

[0005] The 6L0WPAN Neighbor Discovery Protocol (NDP) refers to a suite of protocols for formulating a 6L0WPAN. For example, referring to Figs. 2 and 3, the 6L0WPAN NDP defines router discovery (e.g., see Fig. 2) and address registration (e.g., see Fig. 3). After neighbor discovery is complete, routing protocols, such as the Routing Protocol for Low-Power and Lossy Networks (RPL) for example, can be used for data transmission. The 6L0WPAN NDP relates to packet adaptation, header compression, and neighbor discovery. The routing protocols are generally responsible for routing an IPv6 packet from/to a constrained device (e.g., 6LN or 6LR). Thus, a 6L0WPAN network generally needs to implement both a 6L0WPAN NDP and a routing protocol (e.g., RPL).

[0006] With respect to router discovery, Fig. 2 illustrates an existing router discovery process using Router Solicitation (RS) and Router Advertisement (RA) messages for a 6LN to discover its first-hop 6LR. The RS and RA are Internet Control Message Protocol (ICMP) messages with the ICMP Type set to 10 and 9, respectively. Referring to Fig. 2, at 1, a 6LN 202 (which may be a 6LR) may multicast an RS message to its neighboring routers. The 6LN 202 may unicast the RS message if it knows the address of a given 6LR 204 (which may be a 6LBR). The RS message carries the 6LN's link layer address in a Source Link Layer Address Option (SLLAO). At 2, the 6LR 204 receives the RS message and responds with a unicast RA message to the 6LN 202. The RA message may contain various options such as, for example, a Prefix Information Option (PIO) for IPv6 address prefix information, 6L0WPAN Context Option (6CO) for IPv6 header compression context information, a SLLAO for 6LR's link layer address, and an Authoritative Boarder Router Option (ABRO) for the 6LBR's IPv6 address. After receiving the RS message, the 6LR 204 can create a "Tentative" Neighbor Cache Entry (NCE) for the 6LN. In accordance with the illustrated example depicted in Fig. 2, the 6LR 204 previously performed a similar procedure (which is performed by the 6LN 202) to find a 6LBR. Thus, the 6LR 204 may have already received options such as, for example, the PIO, 6CO, and ABRO, from the 6LBR. Thus, 6LRs, for instance the 6LR 204, may use the procedure illustrated in Fig. 2 to first discover a 6LBR and connect themselves to the 6L0WPAN. After that, 6LRs, for instance the 6LR 204, can be discovered by 6LNs, for instance the 6LN 202, and thus connect 6LNs to the 6L0WPAN. At 3, optionally, the 6LR 204 may periodically broadcast the RA message, for instance to the 6LN 202.

[0007] Using the above-described router discovery process, a given 6LN can discover a plurality of 6LRs as its first-hop router candidates. The 6LN knows the IPv6 address prefix, which will be used to automatically formulate its own unique IPv6 address within the

6L0WPAN. The 6LN also knows 6L0WPAN header compression context information so that it can appropriately employ 6L0WPAN header compression for future communications with its first-hop routers. The 6LN may choose a 6LR as its first-hop default router based on information obtained in this process. As mentioned above, the process illustrated in Fig. 2 may also be used by a given 6LR to find a 6LBR and/or other 6LRs to establish a multi-hop 6L0WPAN.

[0008] Referring to Fig. 3, an example address registration process is shown, which may occur after the router discovery process illustrated in Fig. 2. As shown, the 6LN 202 registers its IPv6 address for a certain amount of time (a registration time), which removes the necessity of periodical RS/RA message exchanges between the 6LN 202 and its 6LR 204.

During the address registration, the 6LR 204 may need to perform a Duplicate Address Detection (DAD) with a 6LBR 206, via a Duplicate Address Request (DAR) message and a Duplicate Address Confirm (DAC) message, to guarantee that each 6LN within the 6L0WPAN has a unique and different IPv6 address. In the illustrated example, at 1, the 6LN 202 sends a Neighbor Solicitation (NS) message to its first-hop default router (6LR 204), which was discovered during the router discovery process. The NS message contains an Address

Registration Option (ARO), which carries a registration time and an Extended Unique Identifier (EUI-64) of the 6LN 202. The EUI-64 is defined by IEEE as a 64-bit identifier having various uses. For example, a 64-bit identifier may be used to address hardware interfaces within existing IEEE 802 or IEEE 802-like networking applications; a 64-bit identifier may be used to identify a specific hardware instance that is not necessarily a network address; or a 64-bit identifier may be used to identify a design instance, as opposed to a hardware instance (e.g., a model number).

[0009] With continuing reference to Fig. 3, at 2, the 6LR 204 sends the DAR message to the 6LBR 206, which could be multiple hops away from the 6LR 204. The DAR message may contain the IPv6 address of the 6LN 202, the registration time, and the EUI-64 address as carried in the ARO. A DAR message with the registration time set to zero indicates address de- registration. In accordance with the example, the 6LBR 206 maintains a centralized database of IPv6 addresses of all registered 6LNs. The 6LBR 206 checks the registering address of the 6LN 202 against the database to arbitrate if the new address is a duplicate one. At 3, the 6LBR 206 sends the DAC message back to the 6LR 204. The 6LBR 206 indicates the registration status in the DAC message. The status may be Success, Duplicate Address, Neighbor Cache Full, etc. At 4, the 6LR 204 sends a Neighbor Advertisement (NA) message to the 6LN 202 to inform the CLN 202 of its registration status from the DAC message. Thereafter, the 6LR 204 may create a "Registered" NCE for the 6LN 202, or change a previously created (during the router discovery) "Tentative" NCE to a "Registered" NCE. As illustrated, steps 2 and 3 may be performed using one or multiple hops as desired.

[0010] The registration may fail, for example, because the IPv6 address is already used by another 6LN with a different EUI-64, or the neighbor cache on the 6LR/6LBR is full. With respect to the IPv6 address already being used by another 6LN, this is related to support for using non-EUI-64-based addresses, such as temporary IPv6 addresses or addresses based on an Interface Identifier that is an IEEE 802.15.4 16-bit short address. As such, 6LNs may formulate the same IPv6 address as one another, and this is a reason that the IETF specifies the Duplicate Address Detection (DAD).

SUMMARY

[0011] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

[0012] In an example embodiment, a router comprises a processor, a memory, and communication circuitry. The router is connected to an IPv6 over Wireless Personal Area Network (6L0WPAN) via its communication circuitry. The router further comprising computer- executable instructions stored in the memory of the router which, when executed by the processor of the router, cause the router to receive a router advertisement message from a border router of the 6L0WPAN. The router advertisement message may include a security parameter associated with the border router. The security parameter may indicate a public key of the border router, and an algorithm for validating a registration certificate. The router may receive a neighbor solicitation message from a node within the 6L0WPAN. The neighbor solicitation message may include a registration requirement option. Based on the neighbor solicitation message, the router may generate a duplicate address request and send the duplicate address request to the border router. The duplicate address request may include an IP address associated with the node. In response to the duplicate address request, the router may receive the registration certificate from the border router. The registration certificate may indicate that the address request from the node is approved by the border router, and that the IP address associated with the node is registered with the border router. The router may send the registration certificate to the node for future use. For example, the registration certificate may be used to reduce duplicate address detection messages that need to be sent in the 6L0WPAN.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0014] Fig. 1 is an example diagram of a IPv6 over Wireless Personal Area Network (6L0WPAN) in route-over mode;

[0015] Fig. 2 is a call flow that shows an example of a router discovery process in a 6L0WPAN;

[0016] Fig. 3 is a call flow that shows an example of an address registration process in a 6L0WPAN;

[0017] Fig. 4 is a block diagram illustrating an example industrial control uses case for a 6L0WPAN;

[0018] Fig. 5 depicts an introduction of example embodiments described in detail herein;

[0019] Fig. 6 is a call flow that shows certificate generation and distribution during address registration in accordance with an example embodiment;

[0020] Fig. 7 is a call flow that shows an example of sequential address registration with multiple routers in accordance with an embodiment;

[0021] Fig. 8 is a call flow that shows an example of sequential address registration with multiple routers in accordance with another embodiment in which a new router can validate a registration certificate; [0022] Fig. 9 is a call flow that shows an example of sequential address registration with multiple routers in accordance with another embodiment in which routers trust each other;

[0023] Fig. 10 is a call flow that shows an example of sequential address registration with multiple routers in accordance with yet another embodiment in which routers trust the nodes in a 6L0WPAN;

[0024] Fig. 11 is a call flow that shows an example of concurrent address registration with multiple routers in an untrusted environment in accordance with an example embodiment;

[0025] Fig. 12 is a call flow that shows an example of concurrent address registration with multiple routers in a trusted environment in accordance with another example embodiment;

[0026] Fig. 13 is a call flow that shows an example of multiple nodes registering with the same router in accordance with an example embodiment;

[0027] Fig. 14 is a block diagram that shows an example user interface for configuring various parameters used in embodiments described herein;

[0028] Fig. 15 A is a system diagram of an example machine-to-machine (M2M) or Internet of Things (IoT) communication system in which one or more disclosed embodiments may be implemented;

[0029] Fig. 15B is a system diagram of an example architecture that may be used within the M2M / IoT communications system illustrated in Fig. 15 A;

[0030] Fig. 15C is a system diagram of an example M2M / IoT terminal or gateway device that may be used within the communications system illustrated in Fig. 15 A; and

[0031] Fig. 15D is a block diagram of an example computing system in which aspects of the communication system of Fig. 15A may be embodied.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0032] As used herein, an IPv6 over Wireless Personal Area Networks (6LoWPANs) refer to networks of constrained devices based on the IEEE 802.15.4 medium access control (MAC) protocol and the IPv6 protocol. 6LoWPANs can be implemented in various use cases. By way of example, Fig. 4 illustrates an industrial control use case in which a 6L0WPAN 400 is deployed at a factory floor 401. It will be understood that the illustrated example use case is presented by way of example, and embodiments described herein can be implemented in various other use cases as desired. As shown, the factory floor 401 is divided to four zones. The four zones, which include a first zone (zone 1), a second zone (zone 2), a third zone (zone 3), and a fourth zone (zone 4). Each zone includes at least one 6L0WPAN Node (6LN), for instance at least one sensor and/or actuator, and at least one router, for instance at least one 6L0WPAN Router (6LR). As used herein, a 6LN refers to any host or router participating in a given 6L0WPAN, such as the 6L0WPAN 400 for example. Similarly, as used herein, a 6LR refers to an intermediate router in a given 6L0WPAN, such as the 6L0WPAN 400 for example. A 6LR can send and receive Router Advertisements (RAs) and Router Solicitations (RSs), and forward and route IPv6 packets. The 6LNs and 6LRs installed at each node may be for connecting information and real-time process control. These nodes (e.g., sensors) and routers form the 6L0WPAN 400, which is a mesh network, and connect to the Internet via a backbone router, for instance a 6L0WPAN Border Router (6LBR) 406.

[0033] As used herein, a 6LBR refers to a border router that is located at the junction of separate 6L0WPAN networks or between a 6L0WPAN network and another IP network. There may be one or more 6LBRs at a given 6L0WPAN network boundary. A 6LBR is generally the responsible authority for IPv6 prefix propagation for the 6L0WPAN network it is serving. An isolated 6L0WPAN may also contain a 6LBR in the network, which may provide the prefix(es) for the isolated network.

[0034] Still referring to the example depicted in Fig. 4, the 6LNs (e.g., sensors) and routers may use IEEE 802.15.4 as the underlying technology and 16-bit short medium access control (MAC) addresses to reduce message size and communication overhead. As a result, the 6L0WPAN Neighbor Discovery Protocol (NDP) may employ multi-hop Duplicate Address Detection (DAD), for instance as illustrated in Fig. 3, to detect duplicate addresses. To improve reliability and robustness, for example, a 6LN (e.g., sensor or actuator) can connect to multiple routers. As shown, for example, a first node (6LN1) may connect to a first router (6LR1), a second router (6LR2), and a third router (6LR3). By way of further example, new sensors, which may be referred to generally as 6LNs, may be added to a given zone for collecting new sensory information or to replace old sensors. Such new sensors may connect to a given router and the network simultaneously with respect to each other. As shown, for example, a second node (6LN2), a third node (6LN3), and a fourth node (6LN4) are newly deployed sensors that connect to a second router (6LR2) at substantially the same time as each other. The illustrated routers may be main-powered, and may have connected resources in addition to the

sensors/actuators. In accordance with the example use case, a 6LN, for instance the first 6LN1, may connect to multiple 6LRs, and multiple 6LNs may connect to a single 6LR simultaneously. It is recognized herein that the existing 6L0WPAN NDP, in particular its DAD mechanism, has some shortcomings related to the illustrated use case, among others, which are addressed by embodiments described below. For example, it is recognized herein that when a given 6LN registers to multiple 6LR routers (either sequentially or simultaneously), the existing process performs multi-hop DAD multiple times (e.g, one time for each 6LR) even though the 6LN registers the same IP address. It is recognized herein that multi-hop DAD messages traverse multiple hops between a given 6LR and a given 6LBR, and such repeated multi-hop DAD operations may cause unnecessary overhead. Furthermore, when multiple 6LNs register to the same 6LR simultaneously, in accordance with existing approaches, the 6LR will repeat the multi-hop DAD process for each 6LN separately, which may result in excess overhead. Overall, it is recognized herein that the existing 6L0WPAN NDP treats a 6LN registering with a 6LR and corresponding multi-hop DAD separately, which causes extra overhead, for example, because each separate multi-hop DAD needs to be performed and repeated along multiple hops between the 6LR and the 6LBR.

[0035] Referring generally to Fig. 4, a given 6L0WPAN, for instance the 6L0WPAN 400, may consist of 6LNs, 6LRs, and a 6LBR, for instance the 6LBR 406. A 6L0WPAN may have an address prefix which is shared by all 6LNs and 6LRs associated therewith. In some cases, a given 6LN, such as a sensor node for example, first needs to discover its first-hop default 6LR to obtain address prefix and IPv6 header compression information. Then the 6LN may automatically formulate its IPv6 address based on the obtained address prefix and its lower layer identifiers, such as a MAC address for example. The formulated IPv6 addresses from different 6LNs may be duplicated, for instance, if the 6LNs use a 16-bit short MAC address to produce the IPv6 address. In order to ensure that IPv6 addresses are unique, the existing 6L0WPAN NDP defines the address registration procedure that includes multi-hop DAD, such that a given 6LN registers its IPv6 address to its default 6LR, and the default 6LR passes the 6LN's IPv6 address to the 6LBR so that the uniqueness of the IPv6 address can be checked. This multi-hop DAD may be considered a centralized approach because 6LBR makes all decisions related to DAD, and the approach introduces multi-hop interactions and message exchanges between the default 6LR and the 6LBR. It is recognized herein that when a 6LN needs to register to multiple first- hop 6LRs or when multiple 6LNs need to register with the same 6LR, existing multi-hop DAD causes high overhead, especially for large 6LoWPANs where the number of hops between the first-hop default 6LR and the 6LBR is comparably large. [0036] To overcome issues described above, among others, in existing 6L0WPAN multi-hop DAD, an embodiment described herein implements an enhanced address registration in which a given 6LR can determine whether a given IPv6 address is unique. This can reduce multi-hop DAD, for instance when a 6LN registers to multiple 6LRs, as compared to existing approaches. In an example embodiment, a given 6LR can buffer and aggregate address registration requests from different 6LNs, and as a result a one-time DAD message can be used to check multiple IPv6 addresses. This may also decrease the overhead as compared to the existing multi-hop DAD approach. Various embodiments are now described in further detail.

[0037] As described above, existing multi-hop DAD causes high overhead and may also cause long latency, in particular for scenarios in which a 6LN registers with multiple 6LRs, or when multiple 6LNs register to the same 6LR. Various embodiments described below reduce multi-hop DAD overhead. To this end, referring to Fig. 5, by way of introduction, the various embodiments described below include mechanisms that allow 1) security parameters of 6LBR's to be distributed during a router discovery; 2) a certificate for a given 6LN to be distributed when the 6LN registers its address with its first router during an address registration; 3) a sequential registration with multiple routers; 4) a concurrent registration with multiple routers; and/or 5) a multiple address registration.

[0038] Figs. 6-14 (described hereinafter) illustrate various embodiments of methods and apparatuses for address registration. In these figures, various steps or operations are shown being performed by one or more nodes, routers, and/or proxies. It is understood that the nodes, routers, and proxies illustrated in these figures may represent logical entities in a communication network and may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of, and executing on a processor of, a node of such network, which may comprise one of the general architectures illustrated in Figs. 15C or 15D described below. That is, the methods illustrated in Figs. 6-13 may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a network node, such as for example the node or computer system illustrated in Figs. 15C or 15D, which computer executable instructions, when executed by a processor of the node, perform the steps illustrated in the figures. It is also understood that any transmitting and receiving steps illustrated in these figures may be performed by communication circuitry (e.g., circuitry 34 or 97 of Figs. 15C and 15D, respectively) of the node under control of the processor of the node and the computer- executable instructions (e.g., software) that it executes. [0039] Turning now to an example embodiment in which a certificate is generated and distributed during an address registration, with reference to Fig. 6, an example network

6L0WPAN 600 includes a 6LN 602, a 6LR 604, and a 6LBR 606. For simplicity, the illustrated 6LR 604 is a one-hop link local neighbor of the 6LBR 606, and the 6LN 602 is a one-hop link local neighbor of the 6LR 604. It will be appreciated that the example network 600 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a network such as the network 600, and all such embodiments are contemplated as within the scope of the present disclosure.

[0040] Referring generally to Fig. 6, in accordance with the illustrated embodiment, the 6LBR 606 first broadcasts or unicasts certificate-related parameters in an RA message during the router discovery phase, such that 6LRs and 6LNs, for instance the 6LR 604 and the 6LN 602, know these parameters, which may include the 6LBR's public key and the algorithm used to generate the certificate. Then, during an address registration phase, the 6LBR 606 may calculate a registration certificate for each registering 6LN (e.g., 6LN 602) based on their respective IPv6 address, registration time, and other information (e.g., the first default 6LR's IPv6 address, the number of additional routers that the 6LN can register to in the future, the 6LN's capabilities, the 6LN's context information such as its geo-location and/or in-door location information for example, the 6LN's device type, etc). Thus, the registration certificate may represent the digital signing of the 6LN's IPv6 address, the 6LN's EUI-64 address, the IPv6 address of the 6LN's first default 6LR, the number of additional 6LRs to which the 6LN can register, and a registration time using the 6LBR's private key. As described further below, the registration certificate may be carried in a Duplicate Address Confirmation (DAC) message and a Neighbor Advertisement (NA) message, such that the registration certificate can be extracted the 6LR 604 and the 6LN 602, respectively. In addition, the 6LR 604 can indicate if it supports certificate validation and other mechanisms described herein when it sends RA messages.

[0041] Referring in particular to Fig. 6, at 1, in accordance with the illustrated embodiment, the 6LBR 606 broadcasts an RA message to its link-local one-hop neighbors. In accordance with the illustrated embodiment, the RA message includes a Security Parameter Option (SPO) in addition to existing options. The RA message may also contain a parameter that indicates the maximum number of Neighbor Solicitation (NS messages) that a 6LR is allowed to aggregate. Such a parameter may be used in an embodiment that implements multiple address registration, such as the embodiment described in detail below with reference to Fig. 13. When the 6LR 604 receives the SPO, it may determine that the 6LBR 606 supports using registration certificate. The 6LR 604 can then configure itself to support certificate-based sequential registration, as described in detail below with reference to Figs. 7-10, and the 6LR 604 can configure itself to support certificate-based concurrent registration, as described in detail below with reference to Figs. 1 1 and 12.

[0042] The SPO may contain various parameters such as, for example and without limitation, a public key of the 6LBR 606 and an algorithm for validating a registration certificate generated at 8 in accordance with the illustrated example. In some cases, at least one, for instance all, 6LRs in the network 600 will know the public key of the 6LBR 606, and may use it to validate the registration certificate generated by 6LBR. At 2, in accordance with the illustrated example, the 6LN 602 broadcasts an RS message to its link-local one-hop neighbors. In some cases, for example if the 6LN 602 knows the address of the 6LR 604, the 6LN 602 can unicast the RS message to 6LR. In accordance with the illustrated example, the RS message includes a new Registration Requirement Option (RRO), which may be in addition to existing RS message options.

[0043] The RRO may contain various information or parameters such as, for example and without limitation, a multiple router flag, a router feature flag, and a certificate flag. A multiple router flag may indicate whether the 6LN 602 needs to register with and maintain a registration relationship with multiple 6LRs. Thus, a given 6LR, such as the 6LR 604 for example, knows if the 6LN 602 will register its IPv6 address with multiple LRs or not. If the 6LN 602 only needs to register with one 6LR, for example, the 6LR 604 may accept the RS message and send back the RA message at 3. Alternatively, the 6LR 604 may reject the RS message and suppress sending an RA message, for example, because other 6LRs may have already responded to the broadcasted RS message. In some cases, for instance if the 6LN 602 only needs to maintain registration with one 6LR, the 6LR 604 may not need to maintain its registration certificate. In an example, the multiple router flag, which can also be referred to as the multiple router parameter, is optional and its absence in the message at 2 indicates that the 6LN 602 only needs to register with one 6LR. The router feature flag may indicate whether the 6LR for which the 6LN 602 is looking should support the enhanced address described herein. If the 6LN 602 is looking for a router that supports the enhanced address registration described herein, but a given 6LR does not support the enhanced address registration described herein, the 6LR does not respond to the RA message in accordance with an example. In an example embodiment, the router feature flag, which may also be referred to as the router feature parameter, is optional and its absence in the message at 2 indicates that the 6LN 602 requests regular 6LRs that support the existing neighbor discovery protocol. The certificate flag may indicate whether the 6LN 602 expects to receive a registration certificate from the 6LBR 606. In an example, if the certificate flag, which may also be referred to as the certificate parameter, is set to NO, then the 6LN 602 is requesting no certificate. Accordingly, continuing with the example, the 6LBR 606 will not generate the certificate (step 8). In an example, the certificate parameter is optional and its absence in the message at step 2 indicates that the 6LN 602 does not support, or does not need, the certificate to be generated by the 6LBR 606.

[0044] Still referring to Fig. 6, in accordance with the illustrated embodiment, at 3, the 6LR 604 may unicast an RA message to the 6LN 602 as a response to the RS message from 2. The 6LR 604 may indicate in the RA message whether it supports enhanced address registration as described herein. As shown, at 4, the 6LR 604 may periodically broadcast an RA message to its link-local one-hop neighbors. This RA message can contain the same information as the RA message that can be unicast (step 3). At 5, the 6LN 602 may send a Neighbor Solicitation (NS) message to the 6LR 604 in order to register its IPv6 address. In addition to existing options defined for NS messages, the NS message at 5 may contain the Registration Requirement Option (RRO). At 6, the 6LR 604 receives the NS message and generates a Duplicate Address Request (DAR) message. The 6LR 604 sends the DAR message to the 6LBR 606. The DAR message may contain the RRO. In an example, the 6LR 604 may change the RRO that it receives. For example, the 6LR 604 may the certificate flag from NO to YES to indicate that the 6LN 602 needs a registration certificate. Then the generated certificate can be used in the future by the 6LR 604 to help other 6LRs' Duplicate Address Detection (DAD). At 7, the 6LBR 606 may perform duplicate address detection by checking the 6LN's IPv6 address contained in the DAR message against its address database where all successfully registered IPv6 addresses are maintained. At 8, in accordance with the illustrated embodiment, the 6LBR 606 generates a Registration Certificate Option (RCO) for the 6LN 602. If the RRO indicates that a registration certificate is not needed, for example, the 6LBR 606 may skip this step and not produce any registration certificate. The generated registration certificate may contain various information, and may be encrypted by the 6LBR 606 using its private key. The registration certificate may include, for example and without limitation, the IPv6 address of the 6LN 602, the EUI-64 identifier of the 6LN 602, a granted registration time, and a validity time associated with the certificate. At 9, the 6LBR 606 may send a Duplicate Address Confirmation (DAC) message to the 6LR 604. In an example, the DAC message includes the RCO if the 6LBR generated the registration certificate at 8. At 10, the 6LR 604 may receive the DAC message and buffer the RCO if the RCO is in the received message. In an example, if the 6LN's registration is approved by the 6LBR 606, the 6LR 604 will add a new Neighbor Cache Entry (NCE) that is associated with the 6LN 602. At 11 , in accordance with the illustrated embodiment, the 6LR 604 sends a Neighbor Advertisement (NA) message to the 6LN 602 as a response to the message received at 5. The 6LR 604 may forward the RCO it may receive to the 6LN 602 via the NA message. The 6LN 602 may buffer the received registration certificate for future use.

[0045] Thus, a router, for instance the 6LR 604, may include a processor, a memory, and communication circuitry. The router may be connected to an IPv6 over Wireless Personal Area Network (6L0WPAN), for instance the 6L0WPAN 600, via its communication circuitry, The router may further include computer-executable instructions stored in the memory of the router which, when executed by the processor of the router, cause the router to receive a router advertisement message from a border router (e.g., the 6LBR 606) of the 6L0WPAN. As described above, the router advertisement message may include a security parameter associated with the border router, and an algorithm for validating a registration certificate. The security parameter may be indicative of a public key of the border router. As also described above, the router may receive a neighbor solicitation message from a node (e.g., the 6LN 602) within the 6L0WPAN. The neighbor solicitation message may include a registration requirement option. Based on the neighbor solicitation message, the router may generate a duplicate address request and send the duplicate address request to the border router. The duplicate address request may include an IP address associated with the node. In response to the duplicate address request, the router may receive the registration certificate from the border router. The registration certificate may indicate that the address request from the node is approved by the border router and that the IP address associated with the node is registered with the border router. In some cases, the router may send the registration certificate to the node for future use. In some cases, the router may update a neighbor cache entry associated with the node. In an example, the router 604 and the node 602 are one-hop neighbors in the 6L0WPAN 600. As described above, the router may validate the registration certificate using the public key and the algorithm. The registration certificate may be encrypted by a private key of the border router.

[0046] Turning now to sequential address registration with multiple routers, in an example scenario, a 6LN may first register with a default router 6LR (a first 6LR), for example, using the messaging described above with reference to Fig. 6. As a result, the 6LN may obtain a registration certificate from the 6LBR. By way of example, the 6LN may need to register with more 6LRs, for increased reliability and robustness for example, while maintaining its registration with the first 6LR. In an example, 6LRs within a given 6L0WPAN trust each other, and thus can interact and coordinate with each other to avoid multi-hop DAD with a given 6LBR.

[0047] When the 6LN registers itself with a new 6LR, the 6LN may send the registration certificate with its IPv6 address and registration time to the new 6LR. The new 6LR can validate the registration certificate using the 6LBR's public key. After validating the registration certificate, the new 6LR may be able to know the 6LN's IPv6 address, EUI-64 address, and the granted registration time. As a result, in some cases, there is no need for the new 6LR to perform multi-hop DAD with the 6LBR. New 6LRs may conduct local DAD based on the 6LN's registration certificate. But in a trusted environment (e.g., an isolated 6L0WPAN), the first 6LR and new 6LRs may be mutually trustable. As such, the new 6LR can directly check with the first 6LR concerning the existing registration of the 6LN without using the registration certificate. In absence of the embodiments described below, each 6LR may repeat the multi-hop DAD process with the 6LBR for the 6LN, which causes extra overhead.

[0048] Example uses cases are described in detail below with reference to Figs. 7-13. Referring generally to Figs. 7-12, an example 6L0WPAN 700 includes a 6LN 702, a first 6LR 704a, a second 6LR 704b, and a 6LBR 706. It will be appreciated that the example network 700 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a network such as the network 700, and all such embodiments are contemplated as within the scope of the present disclosure. Fig. 7 illustrates an example in which the second 6LR 704b, which can also be referred to as a new router 704b, cannot validate the received registration certificate. The new router 704b may choose the first router 704a or another router in the network 700 to validate the certificate. Fig. 8 illustrates an example in which the new router 6LR 704b is able to validate the received registration certificate. Fig. 9 illustrates an example in which no registration certificate is used. Instead, the new router 704b directly checks neighbor cache entries (NCEs) maintained at the first router 704a. Fig. 10 illustrates an example in which the routers (6LRs) trust the nodes (6LNs), and there is no need for the new router 704b to check with the first router 704a.

[0049] Referring now in particular to Fig. 7, at 1, in accordance with the illustrated example, the 6LN 702 sends an NS message to register with the second router 6LR 704b, while maintaining its registration relationship with the first router 6LR 704a. This NS message may contain, for example and without limitation, an RCO and a Router List Option (RLO). In some cases, the 6LN 702 received the RCO during its registration with the first router 6LR 704b. The RLO may contains a list of routers, for instance a list of IPv6 addresses of routers, that have already been registered. In accordance with the illustrated example, the RLO contains the IPv6 address associated with the first router 704a. After receiving this NS, the 6LR 704b may take various actions. For example, at 2, the 6LR 704b cannot validate the RCO because the 6LR 704b does not have the 6LBR's public key; the 6LR 704b does not support the algorithm for validating the RCO; the 6LR 704b has limited computation capability and decides not to validate the RCO; or a combination thereof. In the illustrated example, at 2, the 6LR 704b needs to send the RCO to the first router 704a or other neighboring routers so that the RCO can be validated. The 6LR 704b may obtain the IPv6 address, of the 6LR 704a, from the RLO. The 6LR 704b may send a Proxied NS (PNS) message to the 6LR 704a and/or other neighboring routers. The PNS message may contain the RCO of the 6LN 702.

[0050] At 3, in accordance with the illustrated embodiment, the 6LR 704a uses the public key of the 6LBR 706 to validate the RCO. The 6LR 704a may send a Proxied NA (PNA) message to the 6LR 704b that contains the validation result. At 4, in accordance with the illustrated example, the 6LR 704b receives the PNA message from the 6LR 704a and knows whether the RCO is valid. If the RCO is valid, the 6LR 704b can use it without employing multi-hop DAD with the 6LBR 706. As a result, the 6LR 70b may create a new NCE for the 6LN 702. In another example, if the RCO is invalid, the 6LR 704b may return a rejection (e.g., registration failure) to the 6LN 702 (at 8). In yet another example, if the 6LR 704a or other routers also cannot validate the RCO, the 6LR 704b may perform the existing multi-hop DAD with the 6LBR 706 at 5. At 5, in accordance with the illustrated example, the 6LR 704b optionally performs existing multi-hop DAD with the 6LBR. As a result, the 6LBR 796 may generate a new RCO and send it to the 6LR 704b. At 6, the 6LR 704b sends an NA message as a response to the 6LN 702. If the messaging illustrated at step 5 is performed, the NA message at 6 may contain the RCO if the new RCO was received from the 6LBR 706 during 5.

[0051] In some cases, the above-described PNS and PNA message can be implemented as two new ICMP messages. For example, each ICMP header has three fields: 8-bit Type, 8-bit Code, and Checksum, and the 8-bit "Type" field in an ICMP header can be used to indicate PNS and PNA. By way of example, according to a recent ICMP parameter allocation, values 102-126 and 159-199 of the "Type" field are unassigned. Two values from these ranges can be allocated for PNS and PNA, though it will be understood that other values may be allocated for PNS and PNA as desired. By way of further example, Type=l 10 may indicate a PNS message and Type=l 11 may indicate a PNA message. The 8-bit "Code" field can be leveraged to indicate the purpose of PNS and PNA. For example, setting the Code=32 may indicate that both PNS and PNA messages are used for a sequential registration with multiple routers.

[0052] Fig. 8 illustrates an example sequential address registration in which the new router 6LR 704b is able to validate the received registration certificate by itself. Referring to Fig. 8, in accordance with the illustrated embodiment, at 1, the 6LN 702 sends an NS message to register with the second router 6LR 704b while maintaining its registration relationship with the first router 6LR 704a. This NS message may contain a Registration Certificate Option (RCO) and a Router List Option (RLO). In some cases, the 6LN 702 received the RCO during its registration with the first router 6LR 704a. The RLO may contain a list of routers (e.g. their IPv6 addresses) that have already been registered. In the illustrated example, the RLO contains the IPv6 address of the 6LR 704a. After receiving this NS, the actions taken by the 6LR 704b may vary. At 2, in accordance with the illustrated example, the 6LR 704b validates the RCO. If the RCO is valid, the 6LR 704b creates a new NCE for the 6LN 702 and avoids the multi-hop DAD with the 6LBR 706. Illustrated steps 3 and 4 may optionally be performed. If the RCO is not valid, steps 3 and 4 may be skipped, and the 6LR 704b may perform the existing multi-hop DAD with the 6LBR 706 at 5. At 3, the 6LR 704b may send a PNS message to the 6LR 704a. The PNS message may include the RCO and RLO to inform the 6LR 704a that the 6LR 704b is another default router for the 6LN 720. The RCO in the message at 3, may be the same as the RCO received at 1, and the RLO at 3 may contain the IPv6 address of the 6LR 704b. At 4, the 6LR 704a may send a PNA message as a response to the 6LR 704b. At 5, in accordance with the illustrated example, the 6LR 704b performs existing multi-hop DAD with the 6LBR 706. As a result, the 6LBR 706 may generate a new RCO and send it to the 6LR 704b. At 6, in accordance with the illustrated example, the 6LR 704b sends an NA message as a response to the 6LN 702. This NA message may contain the RCO if the new RCO was received from the 6LBR 706.

[0053] In some cases, routers (6LRs) might not support certificate validation, but they might trust each other. As a result, referring to Fig. 9, new routers can check with the first router to check the existing the Neighbor Cache Entry (NCE), and to determine the registered address of the 6LN 702. Thus, sequential address registration with multiple routers can be optimized further as shown in Fig. 9.

[0054] Referring to Fig. 9, in accordance with the illustrated embodiment, at 1, the 6LN 702 sends a NS message to register with the second router 6LR 704b while maintaining its registration relationship with the first router 6LR 704a. This NS message may contain an RLO. The RLO may contain a list of routers (e.g., using their IPv6 addresses) that have already registered. In the illustrated example, the RLO includes the IPv6 address of the 6LR 704a. At 2, the 6LR 704b obtains the first 6LR's IPv6 address from the RLO, and sends a PNS message to the first 6LR 704a. The PNS message may contain the 6LN's IPv6 address and the second 6LR's IPv6 address. At 3, after receiving the PNS message, the 6LR 704a may check its NCEs to see if there is a "Registered" NCE corresponding to the IPv6 address of the 6LN 702. Then the 6LR 704a may send the result to the 6LR 704a via a PNA message. At 4, as shown, the 6LR 704b receives the PNA message from the 6LR 704a, and knows if the 6LN 702 has been registered with the 6LR 704a or not. If it has, illustrated step 5 may be skipped. Otherwise, the 6LR 704b may perform existing multi-hop DAD with the 6LBR 706 at 5. At 6, the 6LR 704b sends the NA message to the 6LN 702 as a response to the message received at 1.

[0055] Referring now to Fig. 10, in accordance with yet another example scenario, routers (e.g,. 6LRs) may trust 6LNs. Thus, a given 6LN, for instance the illustrated 6LN 702, may inform new routers that it has been successfully registered and that the registration is still active. An example of such a scenario is described further below with reference to Fig. 10.

[0056] At 1 , in accordance with the illustrated example, the 6LN 702 sends an NS message to register with the second router 6LR 704b while maintaining its registration relationship with the first router 6LR 704a. This NS message may contain a new

RegistrationFlag, which may be one bit, that informs the 6LR 704b that the registration has been previously approved by the 6LBR 706. In some cases, at 1, the 6LN 702 may also optionally send an RLO to inform the 6LR 704b of other routers (e.g., 6LR 704a) to which the 6LN 702 has registered. At 2, in accordance with the illustrated embodiment, because the 6LR 704b trusts the 6LN 702, the 6LR 704b may create a new NCE for the 6LN 702. At 3, the 6LR 704b may send an NA message to the 6LN 702, as a response to the message received at 1.

[0057] Thus, as described above with reference to Figs. 7-10, a router, for instance the 6LR 704b for example, may include a processor, a memory, and communication circuitry. The router may be connected to an IPv6 over Wireless Personal Area Network (6L0WPAN), for instance the 6L0WPAN 700 for example, via its communication circuitry. The router may further include computer-executable instructions stored in the memory of the router which, when executed by the processor of the router, cause the router to receive a neighbor solicitation message from a node (e.g., the node 702) within the 6L0WPAN. The network solicitation message may include an address associated with the node, a registration certificate, and a router list option indicative of one or more routers with which the node has already registered. As described above, for example with reference to Fig. 7, the router may send a proxied neighbor solicitation message to a selected one of the routers (e.g., router 704a) indicated in the router list option. The proxied neighbor solicitation message may include the registration certificate. The router may receive a validation result from the selected one router. The validation result may indicate whether the registration certificate is valid. In some cases, if the validation result indicates that the registration certificate is valid, the router may communicate with the node using the address associated with the node, thereby refraining from sending a duplicate address detection message to a border router of the 6L0WPAN.

[0058] Continuing with the example above, in other cases (e.g., see Fig. 8), the router may validate the registration certificate using a public key associated with a border router of the 6L0WPAN. The router may also generate a neighbor cache entry associated with the node, thereby avoiding a multi-hop duplicate address detection with the border router. The router may send a proxied neighbor solicitation message to at least one of the routers indicated in the router list option. The proxied neighbor solicitation message may inform the at least one router (e.g., 6LR 704a) indicated in the router list option that the router (e.g., 6LR 704b) is a default router for the node. In yet another example (e.g., see Fig. 9), the router may send a proxied neighbor solicitation message to a selected one of the routers indicated in the router list option, and the proxied neighbor solicitation message may include an address of the node and an address of the router. Furthermore, the router (e.g., 6LR 704b) may receive a proxied neighbor advertisement message that indicates that the selected one router (e.g., 6LR 704a) verified that the node (e.g,. 6LN 702) is a node registered with the selected one router, thereby avoiding a multi-hop duplicate address detection with a border router of the 6L0WPAN. In yet another example, as described above with reference to Fig. 10, the neighbor solicitation message may further include a flag indicating that a registration of the address associated with the node has been approved by a border router of the 6L0WPAN. Based on a trusted relationship that the router has with node, the router may generate a new neighbor cache entry associated with the node in response to the flag.

[0059] Turning now to concurrent address registration with multiple routers, in an example scenario, a 6LN discovers multiple 6LRs and decides to register its IPv6 address with a plurality of them. In an example embodiment, one of the 6LRs performs multi-hop DAD with the 6LBR to obtain a registration certificate. Then the one 6LR may share or distribute the obtained registration certificate to other 6LRs, such that local DAD can be performed by decrypting and validating the registration certificate. Thus, multi-hop DAD may not be required for the other 6LRs.

[0060] Fig. 11 illustrates an example of concurrent registration with multiple routers. Referring to Fig. 11 , the 6LN 702 needs to register itself with two first-hop routers, which are the first 6LR 704a and the second 6LR 704b. It will be understood that while the illustrated example only shows two routers, the described herein method is applicable to scenarios including any number of routers, for instances more than two routers, as desired. For example, the 6LR 704a may contact any number of routers as desired.

[0061] Still referring to Fig. 1 1, in accordance with the illustrated example, at 1 , the 6LN 702 sends a modified NS message to the 6LR 704a. This NS message may contain new options, for instance the RRO and the RLO. The RLO may contain IPv6 addresses of other routers besides the 6LR 704a. In accordance with the illustrated example, the RLO contains the IPv6 address of the 6LR 704b. As an alternative example, it will be understood that the 6LN 702 may choose the 6LR 704b as the first router, and send the NS message the 6LR 704b. At 2, in accordance with the illustrated example, the 6LR 704a performs multi-hop DAD by sending a modified DAR message to the 6LBR. This DAR message may include a new option (e.g., RRO), which is from the message at 1. The DAR message may also contain the RLO received from the message at 1. At 3, the 6LBR 706 may conduct duplicate address detection. At 4, if the RLO is contained in the message at 2 for example, the 6LBR 706 may determine other default routers from the list included in RLO. By way of example, the 6LN 702 may indicate in the message at 1 that it wants to register to multiple routers, but the 6LBR 706 may approve only one router, for example, which has the least number of registered 6LNs. At 5, the 6LBR 706 generates the registration certificate.

[0062] With continuing reference to Fig. 1 1 , at 6, in accordance with the illustrated example, the 6LBR 706 sends a modified DAC message to the 6LR 704a. This DAC message may contain options, such as the RCO and RLO for example. The RLO may contain the list of approved routers, in particular, for example, the IPv6 addresses of the approved routers. If the registration is approved by the 6LBR 706, for example, the 6LR 704a may create a new NCE for the 6LN 702. Optionally, in an example, the 6LBR 706 can include a flag in the message at 6 to indicate that the 6LBR 706 will inform all other approved routers in the list (e.g., if the flag=l) or that the 6LR 704a needs to contact each approved router (e.g., if the flag=0). At 7, if the 6LR 704b is in the list of the RLO received from the messages at 6 or from the message at 1 if no RLO is received at 6, the 6LR 704a may send a Proxied Neighbor Solicitation (PNS) message to the 6LR 704b. This PNS message may contain the RCO received from the message at 6. At 8, the 6LR 704b may validate the RCO by using the public key of the 6LBR 706. At 9, if the RCO is valid, the 6LR 704b may accept the registration and create a new NCE for the 6LN 702. At 10, the 6LR 704b sends a Proxied Neighbor Advertisement (PNA) message to the 6LR 704a. This PNA message may contain the result of the validation at 8. At 11, in accordance with the illustrated embodiment, the 6LR 704a sends a modified NA message to the 6LN 702. This NA message may contain new options, such as the RCO (received at 6) and RLO for example. The RLO may contain the IPv6 addresses of the routers that accept the 6LN's registration request. Thus, the RLO at 11 may have different values as compared to the RLO in the message at 1, for example, because the 6LBR 706 may reject at least one 6LR as indicated at 4.

[0063] In an alternative example, at 7, the 6LBR 706 can send a pseudo DAC message to the 6LR 704b, which may inform the 6LR 704b of the address registration details associated with the 6LN 702. This pseudo DAC message may contain the RCO. Then the 6LR 704b may still conduct the above-described steps 8 and 9, and send an NA message to the 6LN 702.

[0064] Thus, as described above, a border router (e.g., the 6LBR 706) may include a processor, a memory, and communication circuitry. The border router may be connected to an IPv6 over Wireless Personal Area Network (6L0WPAN) (e.g., 6L0WPAN 700) via its communication circuitry. The border router may further include computer-executable instructions stored in the memory of the border router which, when executed by the processor of the border router, cause the border router to receive a duplicate address request from a router within the 6L0WPAN. The duplicate address request may include a registration requirement option and a router list option indicative of one or more routers with which the node desires to be registered. The border router may conduct duplicate address detection, and approve at least one router from the router list option. Thus, the node is able to register to at least the approved router. The border router may send a duplicate address confirmation message to the router. The duplicate address confirmation message may indicate the at least one router that the border router approved.

[0065] Referring now to Fig. 12, when 6LRs can trust each other, such as in an isolated 6L0WPAN or when they have established a mutual trust relationship, there may be no need to use a registration certificate. Fig. 12 shows an example in which concurrent address registration is performed with multiple routers that trust each other.

[0066] At 1, in accordance with the illustrated example, the 6LN 702 sends a modified NS message to the first 6LR 704a. This NS message may contain new options, such as the RRO and RLO for example. In an example, the RLO contains IPv6 addresses of other routers besides the 6LR 704a, such as the 704b for example. At 2, the 6LR 704a performs multi-hop DAD by sending a modified DAR message to the 6LBR 706. This DAR message may contain the new RRO from 1. The DAR message may also contain the RLO received from the message at 1. At 3, the 6LBR 706 conducts duplicate address detection. At 4, if the RLO is contained in the message at 2, for example, the 6LBR 706 may determine other default routers from the list included in the RLO. By way of example, the 6LN 702 may indicate in the message at 1 that it wants to register to multiple routers, but the 6LBR 706 might approve only one router, for example, which has the least number of registered 6LNs. It will be understood that other criteria may be used to approve a given router as desired. At 5, in accordance with the illustrated example, the 6LBR 706 sends a modified DAC message to the 6LR 704a. This DAC message may contain the RLO. The RLO may contain a list of approved routers, for instance a list of IPv6 addresses associated with approved routers. If the registration is approved by the 6LBR 706, the 6LR 704a may create a new NCE for the 6LN 702. If the 6LR 704b is in the list of the RLO received from message at 6 or from the message at 1, the 6LR 704a may send a PNS message to the 6LR 704b. This PNS message may contain the RLO. At 7, the 6LR 704b may create a new NCE for the 6LN 702. At 8, the 6LR 704b may send a PNA message to the 6LR 704a. At 9, the 6LR 704a sends a modified NA message to the 6LN 702. This NA message may contain the RLO, which may contain the IPv6 address of each router that accepted the 6LN1 's registration request.

[0067] Turning now to an example use case in which multiple 6LNs need to register with the same 6LR, in accordance with an example embodiment, 6LR aggregate registration requests (e.g., NS messages) may be sent by the 6LNs, such that multi-hop DAD is performed only once. This one-time multi-hop DAD may register multiple IPv6 addresses, for instance instead of one IPv6 address, in contrast to the DAD in existing 6L0WPAN NDP. In order to reduce the length of DAR and DAC messages, the 6LR can choose a common registration time for all 6LNs. For example, a given 6LR may choose a minimum registration time among all 6LNs as the common registration time.

[0068] Referring to Fig. 13, an example of multiple address registration is illustrated in Fig. 13. Fig. 13 shows an example 6L0WPAN 700a that includes a first 6LN 702a (6LN1), a second 6LN 702b (6LN2), a 6LR 704a, and a 6LBR 706. It will be appreciated that the example network 700 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a network such as the network 700, and all such embodiments are contemplated as within the scope of the present disclosure. In the example illustrated in Fig. 13, the first 6LN 702a and the second 6LN 702b need to register with the 6LR 704a. It will be understood that while Fig. 13 only shows two 6LNs for convenience, any number of nodes can implement the illustrated method as desired.

[0069] At 1, in accordance with the illustrated embodiment, the second 6LN 702b sends a modified NS message to the 6LR 704a. This NS message may contain an RRO. The RRO may indicate how long this NS can be buffered. Accordingly, the 6LR 704a can buffer this message to potentially aggregate it with other NS messages. In some cases, the message at 1 may be a re-registration from the second 6LN 702b to renew its previous registration before the registration time expires. At 2, the second 6LN 702b sends a modified NS message to the 6LR 704a. This NS message may contain an RRO. The RRO may indicate how long this NS can be buffered. In some cases, the message at 2 may be a re-registration from the second 6LN 702b to renew its previous registration before the registration time becomes expired. At 3, the 6LR 704a may aggregate the NS messages from 1 and 2. The 6LR 704a may generate a DAR message based on the NS message. In some cases, the respective registration times from the NS messages may be different, so the 6LR 704a may choose the earliest one as the common registration time for the 6LN 702a and the 6LN 702b. The common registration time may be contained in the DAR message at 4. Alternatively, the DAR message may carry multiple registration time values (e.g., original registration times from 1 and 2) but the length of DAR message may become longer as compared to the DAR message that only carries a common registration time.

[0070] Still referring to Fig. 13, at 4, in accordance with the illustrated example, the 6LR 704a sends a modified DAR message to the 6LBR 706. This DAR message may contain various options, such as the RRO and a Multi-Address Registration Option (MARO) for example. The MARO may contain IPv6 addresses of the 6LNs whose NS messages are aggregated by the 6LR 704a. Thus, in accordance with the illustrated example, the MARO contains the IPv6 addresses of the first 6LN 702a and the second 6LN 702b. Multiple RROs may be contained in the DAR message. In particular, each RRO may correspond to a different 6LN. Alternatively, multiple RROs may be compressed into fewer RROs, for example, if 6LNs have similar or the same requirements. For example, RROs may be reduced if the 6LNs each need a certificate to be generated by the 6LBR 706. At 5, the 6LBR 706 may conduct duplicate address detection for each IPv6 address contained in the MARO. At 6, in accordance with the illustrated example, the 6LBR 706 generates a registration certificate for each approved IPv6 address from the message at 5. At 7, the 6LBR 706 sends a modified DAC message to the 6LR 704a. This DAC message may contain the RCO and the MARO. For example, if more than one address is approved by the 6LBR 706, multiple RCOs may be contained in this DAC message. The MARO may contain the list of approved IPv6 addresses, based on which the 6LR 704a can determine the status of each address (e.g., approved or rejected). The 6LR 704a may distribute address registration results and the corresponding RCOs to the approved 6LNs. At 8, in accordance with the illustrated example, the 6LR 704a sends a modified NA message to the second 6LN 702b. This NA message may contain the RCO that was generated by the 6LBR 706 for the 6LN 702b. At 9, as shown, the 6LR 704b sends a modified NA message to the 6LN 702a. This NA message may contain the RCO that was generated by the 6LBR 706 for the 6LN 702a.

[0071] In another example, there are multiple 6LNs (e.g., a third 6LN3 and a fourth 6LN4) that have been successfully registered with the 6LR 704a separately from each other. By way of example, the 6LN3 may have a smaller registration time as compared to the other 6LNs, and before it becomes expired, the 6LN3 may send a NS message to the 6LR 704a to renew its registration time. After receiving the 6LN3's NS message, the 6LRs 704a may realize that the 6LN4 will expire soon, and therefore the 6LR 704a may decide to renew the registration time of both the 6LN3 and 6LN4. As a result, the 6LR 704a may send one DAR message to the 6LBR 706 (similar to the message at 4 depicted in Fig. 13). This DAR message may include the MARO, and it may indicate the respective IPv6 address and new registration time of the 6LN3 and the 6LN4. Thus, in summary, in accordance with various example embodiments, a given 6LR can aggregate NS messages from various 6LNs and use one-time DAD (e.g., one DAR and one DAC message) for 6LNs, for example and without limitation: when all 6LNs are registering themselves to the 6LR as new devices; when all 6LNs are re-registering themselves to the 6LR for registration renewal; or when some 6LNs are registering themselves as new devices, but others are renewing their previous registration.

[0072] Various message options are disclosed above. Table 1 below summarizes example usages of the proposed message options introduced above. Each proposed option can be implemented as a new ICMP option, and Tables 2 to 6 illustrate an example format for each option. Table 1. Example Usages of Options Described Herein

Table 2. Example SPO Format

Table 5. Example RLO Format

[0073] Referring now to Fig. 14, an example user interface 1400 is depicted. The user interface 1400 may be used to configure parameters that can be maintained at a 6LBR. The user interface 1400 may be implemented as an application running on a 6LBR that has a display screen and/or a keyboard associated therewith, which may provide users a mechanism to change the value of various parameters. Example parameters include, presented without limitation: a maximum number of routers to which a 6LN can connect (MAX_Num_Rtr_Per_Nd 1402); a maximum number of 6LNs that a given 6LR can accommodate (MAX_Num_Nd_Per_Rtr 1404); a maximum number of NS messages that a 6LR can aggregate at one time

(MAX_Num_NS_Agg 1406); key generation parameters (Key_Gen_Param 1408); and certification generation parameters (Certification_Gen_Param 1410). With respect to the parameter indicative of the maximum number of NS messages that a 6LR can aggregate at one time (MAX_Num_NS_Agg 1406), by way of example, if MAX_Num_NS_Agg = 1, it may indicate that multiple address registration should be disabled. This parameter may be distributed to 6LRs via RA messages. By way of further example, key generation parameters

(Key Gen Param 1408), may be set in various ways. For example, a cryptography algorithm, which is used by a built-in software to generate the pair of private and public keys of the 6LBR, may be selected/configured. The address of a key generating entity, which can generate the keys and provide them to a given 6LBR, may be configured. By way of yet another example, predetermined values for the Private and Public Keys (Public Key, Private Key) may be provided using the example user interface 1400. Certificate generation parameters

(Certificate_Gen_Param 1410), may also be set several ways using the user interface 1400. For example, the address of a certificate authority, through which a 6LBR can get certificates instead of generating them by itself, can be provided using the user interface 1400. By way of another example, an algorithm for generating registration certificate can be configured via the user interface 1400. When the parameters are selected, a user may acuate an Enable New

Configuration option 1412 to initiate the selected parameters. It will be understood that the user interface 1400 can be used to monitor and control alternative or additional parameters as desired. It will further be understood that user interfaces can provide a user with various information in which the user is interested via a variety of charts or alternative visual depictions.

[0074] In some cases, so that a network application can access and change the above- described parameters remotely (e.g., from a remote network management station or from an application installed on a smart phone), a given 6LBR may provide a RESTful interface in accordance with an example embodiment. In particular, in accordance with one example, each parameter described above may be regarded as a resource and assigned with a Uniform Resource Identifier (URI). An example of such assignments is illustrated in Table 7 below. Existing RESTful protocols, such as Hypert ext Transfer Protocol (HTTP) and Constrained Application Protocol (CoAP) for example, can access these parameters using RESTful methods. Referring to the example illustrated in Table 7, "/root" refers to the root URI of all resources maintained by the 6LBR, and "/root/ND" stands for the path for storing resources/parameters related to

6L0WPAN neighbor discovery.

Table 7. Example 6LBR Parameters and Example URIs associated

Parameter Name Corresponding URI Applicable RESTful Methods

MAX_Num_Rtr_Per_Nd /root/N D/M AXN u m RtrPe rNd CREATE, RETRIEVE, UPDATE,

DELETE

MAX_Num_Nd_Per_Rtr /root/N D/M AXN u m N d Pe rRt r CREATE, RETRIEVE, UPDATE,

DELETE

MAX_Num_NS_Agg /root/ND/MAXNumNSAgg CREATE, RETRIEVE, UPDATE,

DELETE

Key_Gen_Param /root/ND/KeyGenParam CREATE, RETRIEVE, UPDATE,

DELETE

Certificate_Gen_Param /root/ND/CertificateGenParam CREATE, RETRIEVE, UPDATE,

DELETE [0075] Thus, as described above, for a given 6LN to register with multiple 6LRs, a given 6LBR may assign a certificate for the 6LN when it registers with the first 6LR. The certificate may indicate that the IPv6 address of the 6LN has been approved to be used for a certain finite amount of time. The certificate may be digitally signed by the 6LBR using its private key, and can only be verified using the 6LBR's public key in accordance with one example. Other 6LRs, provided they have the 6LBR's public key, can verify the authenticity of the 6LN's certificate and determine whether respective addresses have been successfully registered. In other words, other 6LRs can leverage the certificate and make a conclusion about the uniqueness of the 6LN's IPv6 address. Using this approach, DAD functionality for other routers can be offloaded from the 6LBR to 6LRs by using the certificate assigned by the 6LBR.

[0076] In one example, the 6LBR distributes its public key to 6LRs in an RA message during the router discovery phase. Then, during address registration phase, the 6LBR may assign a certificate using its private key for each new and successful address registration. In other words, when a 6LN registers its IPv6 address at the first time, the existing multi-hop DAD may be performed between the default 6LR and the 6LBR, but the 6LBR may send a certificate to the 6LN. The assigned certificate may indicate that the IPv6 address of the 6LN is validated and can be used for a period of time as approved by the 6LBR.

[0077] In another embodiment described above, a given 6LN can register with multiple 6LRs sequentially. For example, the 6LN may use the assigned certificate to register itself with other 6LRs. Because the certificate is assigned by the 6LBR, other 6LRs can leverage it to determine whether the 6LN's IPv6 address is unique, and thus other 6LRs do not need to conduct existing multi-hop DAD. Therefore, multi-hop DAD with the 6LBR may be eliminated, which may reduce the overhead and expedites the address registration process with other 6LRs.

[0078] In another example embodiment described above, a 6LN may need to register multiple 6LRs simultaneously (which can be referred to as concurrent address registration). In some cases, only one 6LR needs to employ multi-hop DAD with the 6LBR to retrieve the certificate. After that, other 6LRs may determine whether the 6LN's IPv6 address is unique, based on the assigned certificate, without checking with the 6LBR. In other words, if other 6LRs receive a valid certificate, they know it is assigned by the 6LBR for a 6LN's IPv6 address, which in turn implies the corresponding IPv6 address has been successfully registered. Likewise, the overhead associated with DAD is decreased and the speed of address registration is increased. [0079] In another example embodiment described above, multiple 6LNs may register their IPv6 addresses to the same 6LR (which can be referred to as multiple address registration). In some cases, when multiple 6LNs register with the same 6LR, the 6LR combines their registration requests and performs multi-hop DAD only once for all the 6LNs. In other words, instead of using multi-hop DAD for each 6LN, the 6LR may aggregate address registration requests and use one-time multi-hop DAD for all 6LNs, which may improve the overall address registration performance.

[0080] It is recognized herein that public-key cryptosystems use asymmetric cryptographic algorithms which rely on one key for encryption and another different, but related, key for decryption. These two keys (e.g., private key and public key) have the property that it is computationally challenging and nearly impossible to derive the private key from the public key. Public-key cryptography can be used for certificate generation and certificate validation described herein. During certificate generation, content of the certificate may be digitally signed using the private key and the signature may be incorporated within the certificate. In some cases, the signature within the certificate can only be verified using the corresponding public key. In other words, if the contents within the certificate and the corresponding digital signature are verified, it implies that the certificate and the associated signature must have been generated by an entity that has the appropriate private key, which is referred to as certificate validation. As described above, the 6LBR may use its private key to digitally sign the information concerning a 6LN's IPv6 address and its registration status in order to generate the registration certificate. As described herein, this registration certificate may be distributed to the 6LN, and can be passed to other 6LRs. The other 6LRs may use the 6LBR's public key to verify the received 6LN's registration certificate, and in the meantime for example, validate its previous registration. As such, multi-hop DAD may be avoided for these 6LRs. To this end, a 6LBR may need to generate or be configured with a pair of keys (e.g., public key and private key). In some cases, a 6LR, which may have resource constraints for example, may offload the certification validation by requesting the validation process to be performed by another 6LR or any other entity which has more computing resources and a trust relationship with the requesting 6LR.

[0081] As described above, the various techniques described herein may be

implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effect the methods described herein. As used herein, the terms "apparatus," "router," "network apparatus," "node," "device," and "network node" may be used interchangeably.

[0082] Fig. 15 A is a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IoTAVoT, and any M2M device, M2M gateway or M2M service platform may be a component of the IoTAVoT as well as an IoTAVoT service layer, etc. Any of the client or router devices illustrated in any of Figs. 6-13 may comprise a node of a communication system such as the one illustrated in Figs. 15A-D.

[0083] As shown in Fig. 15 A, the M2M/IoT/WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network 12 may comprise multiple access networks that provides content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network 12 may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[0084] As shown in Fig. 15 A, the M2M/ IoTAVoT communication system 10 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, devices, of the network. For example, the Field Domain may include M2M gateways 14 and terminal devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M/ IoTAVoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M terminal devices 18 are configured to transmit and receive signals via the communication network 12 or direct radio link. A M2M gateway device 14 allows wireless M2M devices (e.g. cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M service layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example. Exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[0085] The term "service layer" refers to a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT, and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport/access layer. The service layer supports multiple categories of (service) capabilities or functionalities including service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies (e.g., oneM2M) have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home networks. An M2M service layer can provide applications and/or various devices with access to a collection of, or a set of, the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs that make use of message formats, resource structures, and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or functionalities exposed to various applications and/or devices (e.g., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities. [0086] Referring to Fig. 15B, the illustrated M2M service layer 22 in the field domain provides services for the M2M application 20, M2M gateway devices 14, and M2M terminal devices 18 and the communication network 12. It will be understood that the M2M service layer 22 may communicate with any number of M2M applications, M2M gateway devices 14, M2M terminal devices 18, and communication networks 12 as desired. The M2M service layer 22 may be implemented by one or more servers, computers, or the like. The M2M service layer 22 provides service capabilities that apply to M2M terminal devices 18, M2M gateway devices 14 and M2M applications 20. The functions of the M2M service layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[0087] Similar to the illustrated M2M service layer 22, there is the M2M service layer 22' in the Infrastructure Domain. M2M service layer 22' provides services for the M2M application 20' and the underlying communication network 12' in the infrastructure domain. M2M service layer 22' also provides services for the M2M gateway devices 14 and M2M terminal devices 18 in the field domain. It will be understood that the M2M service layer 22' may communicate with any number of M2M applications, M2M gateway devices and M2M terminal devices. The M2M service layer 22' may interact with a service layer by a different service provider. The M2M service layer 22' may be implemented by one or more servers, computers, virtual machines (e.g., cloud/compute/storage farms, etc.) or the like.

[0088] Still referring to Fig. 15B, the M2M service layer 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The service layer 22 and 22' also enables M2M applications 20 and 20' to communicate through various networks 12 and 12' in connection with the services that the service layer 22 and 22' provide.

[0089] The M2M applications 20 and 20' may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20'.

[0090] Generally, a service layer (SL), such as the service layers 22 and 22' illustrated in Figs. 15A and 15B, defines a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the service layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE), which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the service layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the service layer may be implemented in a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a service layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device, or the like) having the general architecture illustrated in Fig. 15C or 15D described below.

[0091] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a resource- oriented architecture (ROA) to access services, such as the above-described Network and Application Management Service for example.

[0092] Fig. 15C is a block diagram of an example hardware/software architecture of a node or apparatus of a network, such as one of the clients or routers illustrated in Figs. 6-14 which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in Figs. 15A and 15B. As shown in Fig. 15C, the node or apparatus 30 may include a processor 32, a transceiver 34, a transmit/receive element 36, a speaker/microphone 38, a keypad 40, a display/touchpad 42, non-removable memory 44, removable memory 46, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit/receive element 36. It will be appreciated that the node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the duplicate address detection and methods related thereto described herein.

[0093] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the node 30 to operate in a wireless environment. The processor 32 may be coupled to the transceiver 34, which may be coupled to the transmit/receive element 36. While Fig. 15C depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip. The processor 32 may perform application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or communications. The processor 32 may perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

[0094] As shown in Fig. 15C, the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit/receive element 36). The processor 32, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node 30 to communicate with other nodes via the network to which it is connected. In particular, the processor 32 may control the communication circuitry in order to perform the transmitting and receiving steps described herein (e.g., in Figs. 6-13) and in the claims. While Fig. 15C depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip. [0095] The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, devices, and the like. For example, in an embodiment, the transmit/receive element 36 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit and/or receive any combination of wireless or wired signals.

[0096] In addition, although the transmit/receive element 36 is depicted in Fig. 15C as a single element, the node 30 may include any number of transmit/receive elements 36. More specifically, the node 30 may employ MIMO technology. Thus, in an embodiment, the node 30 may include two or more transmit/receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0097] The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.1 1, for example.

[0098] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. The non-removable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30, such as on a server or a home computer. The processor 32 may be configured to control lighting pattems, images, or colors on the display or indicators 42 to reflect the status a UE (e.g., see GUI 1400), and in particular underlying networks, applications, or other services in communication with the UE. The processor 32 may receive power from the power source 48, and may be configured to distribute and/or control the power to the other components in the node 30. The power source 48 may be any suitable device for powering the node 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0099] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node 30. It will be appreciated that the node 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[00100] The processor 32 may further be coupled to other peripherals 52, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 52 may include an accelerometer, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[00101] The apparatus or node 30 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The apparatus 30 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52.

[00102] Fig. 15D is a block diagram of an exemplary computing system 90 which may also be used to implement one or more nodes of a network, such as clients or routers illustrated in Figs. 6-14, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in Figs. 15A and 15B. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within central processing unit (CPU) 91 to cause computing system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91 , which performs additional functions or assists CPU 91. CPU 91 and/or coprocessor 81 may receive, generate, and process data related to address registration.

[00103] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[00104] Memory devices coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92.

Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

[00105] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[00106] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[00107] Further, computing system 90 may contain communication circuitry, such as for example a network adaptor 97 that may be used to connect computing system 90 to an external communications network, such as network 12 of Fig. 15A and Fig. 15B, to enable the computing system 90 to communicate with other nodes of the network. The communication circuitry, alone or in combination with the CPU 91, may be used to perform the transmitting and receiving steps described herein (e.g., in Figs. 6-13) and in the claims.

[00108] It will be understood that any of the methods and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above may be implemented in the form of such computer executable instructions. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, but such computer readable storage media do not include signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium which can be used to store the desired information and which can be accessed by a computer.

[00109] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[00110] The following is a list of acronyms relating to service level technologies that may appear in the above description. Unless otherwise specified, the acronyms used herein refer to the corresponding term listed below.

6CO 6L0WPAN Context Option

6LBR 6L0WPAN Border Router

6LN 6L0WPAN Node

6LO IPv6 over Networks of Resource-constrained Nodes

6L0WPAN IPv6 over Wireless Personal Area Networks

6LR 6L0WAN Router

6MAN IPv6 Maintenance

ABRO Authoritative Boarder Router Option

ARO Address Registration Option CoAP Constrained Application Protocol

DAC Duplicate Address Confirmation

DAD Duplicate Address Detection

DAR Duplicate Address Request

EUI Extended Unique Identifier

HTTP HyperText Transfer Protocol

ICMP Internet Control Message Protocol

IETF Internet Engineering Task Force

MAC Medium Access Control

MARO Multi-Address Registration Option

NA Neighbor Advertisement

NCE Neighbor Cache Entry

ND Neighbor Discovery

NDP Neighbor Discovery Protocol

NS Neighbor Solicitation

PIO Prefix Information Option

PNA Proxied Neighbor Advertisement

PNS Proxied Neighbor Solicitation

RA Router Advertisement

RCO Registration Certificate Option

RLO Router List Option

RFC Request For Comments

RPL IPv6 Routing Protocol for Low-Power and Lossy Networks

RRO Registration Requirement Option

RS Router Solicitation

SLLAO Source Link Layer Address Option

SPO Security Parameter Option

URI Uniform Resource Identifier

[00111] This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.

Claims

What is Claimed:

1. A router comprising a processor, a memory, and communication circuitry, the router being connected to an IPv6 over Wireless Personal Area Network (6L0WPAN) via its communication circuitry, the router further comprising computer-executable instructions stored in the memory of the router which, when executed by the processor of the router, cause the router to perform operations comprising:

receiving a router advertisement message from a border router of the 6L0WPAN, the router advertisement message including a security parameter associated with the border router, the security parameter indicative of a public key of the border router, and an algorithm for validating a registration certificate.

2. The router as recited in claim 1 , wherein the router further comprises computer- executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

receiving a neighbor solicitation message from a node within the 6L0WPAN, the neighbor solicitation message including a registration requirement option;

based on the neighbor solicitation message, generating a duplicate address request and send the duplicate address request to the border router, the duplicate address request including an IP address associated with the node; and

in response to the duplicate address request, receiving the registration certificate from the border router, the registration certificate indicating that the address request from the node is approved by the border router and that the IP address associated with the node is registered with the border router.

3. The router as recited in any one of the preceding claims, wherein the router further comprises computer-executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

sending the registration certificate to the node for future use.

4. The router as recited in any one of the preceding claims, wherein the router further comprises computer-executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising: updating a neighbor cache entry associated with the node.

5. The router as recited in any one of the preceding claims, wherein the router and the node are one-hop neighbors in the 6L0WPAN.

6. The router as recited in any one of the preceding claims, wherein the router further comprises computer-executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

validating the registration certificate using the public key and the algorithm.

7. The router as recited in any of one of the preceding claims, wherein the registration certificate is encrypted by a private key of the border router.

8. A router comprising a processor, a memory, and communication circuitry, the router being connected to an IPv6 over Wireless Personal Area Network (6L0WPAN) via its communication circuitry, the router further comprising computer-executable instructions stored in the memory of the router which, when executed by the processor of the router, cause the router to perform operations comprising:

receiving a neighbor solicitation message from a node within the 6L0WPAN, the network solicitation message including an address associated with the node, a registration certificate, and a router list option indicative of one or more routers with which the node has already registered.

9. The router as recited in claim 8, wherein the router further comprises computer- executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

sending a proxied neighbor solicitation message to a selected one of the routers indicated in the router list option, the proxied neighbor solicitation message including the registration certificate;

receiving a validation result from the selected one router, the validation result indicating whether the registration certificate is valid; and

if the validation result indicates that the registration certificate is valid, communicating with the node using the address associated with the node, thereby refraining from sending a duplicate address detection message to a border router of the 6L0WPAN.

10. The router as recited in claim 8, wherein the router further comprises computer- executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

validating the registration certificate using a public key associated with a border router of the 6L0WPAN; and

generating a neighbor cache entry associated with the node, thereby avoiding a multi-hop duplicate address detection with the border router.

1 1. The router as recited in claim 10, wherein the router further comprises computer- executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

sending a proxied neighbor solicitation message to at least one of the routers indicated in the router list option, the proxied neighbor solicitation message informing the at least one router indicated in the router list option that the router is a default router for the node.

12. The router as recited in claim 8, wherein the router further comprises computer- executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

sending a proxied neighbor solicitation message to a selected one of the routers indicated in the router list option, the proxied neighbor solicitation message including an address of the node and an address of the router; and

receiving a proxied neighbor advertisement message that indicates that the selected one router verified that the node is a node registered with the selected one router, thereby avoiding a multi-hop duplicate address detection with a border router of the 6L0WPAN.

13. The router as recited in claim 8, wherein the neighbor solicitation message further includes a flag indicating that a registration of the address associated with the node has been approved by a border router of the 6L0WPAN, and wherein the router further comprises computer-executable instructions which, when executed by the processor of the router, cause the router to perform further operations comprising:

based on a trusted relationship that the router has with the node, generating a new neighbor cache entry associated with the node in response to the flag.

14. A border router comprising a processor, a memory, and communication circuitry, the border router being connected to an IPv6 over Wireless Personal Area Network (6L0WPAN) via its communication circuitry, the border router further comprising computer-executable instructions stored in the memory of the border router which, when executed by the processor of the border router, cause the border router to perform operations comprising:

receiving a duplicate address request from a router within the 6L0WPAN, the duplicate address request including a registration requirement option and a router list option indicative of one or more routers with which the node desires to be registered;

conducting duplicate address detection;

approving at least one router from the router list option, the node being able to register to the approved at least router; and

sending a duplicate address confirmation message to the router, the duplicate address confirmation message indicating the at least one router that the border router approved.