The shadow network architecture

Interesting link reveals the possible use of hidden botnets in networks.

Link

Review: RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6

RFC 4941 reveals privacy issues related to IPv6 stateless auto configuration.

The IPv6 stateless auto configuration allows hosts to generate IP addresses without the need of a central node to coordinate and distribute unique addresses. The mechanism allows to generate a unique IP address by using the IEEE interface identifier. Actually the interface identifier is generated based on address identifier such as a MAC address which is supposed to be unique, a characteristic guaranteed by the constructor/manufacturer of the network card.
Using a unique interface identifier allows nodes to generate unique IPv6 addresses. The Node adds the network prefix to the interface identifier in order to obtain a 128 bit unique (local or global) address.
Consequently, when a node moves to another network the prefix is the only changing part in the IPv6 address since the interface identifier is always the same and unique.
This unchanging part of the IP address allows for tracking and user localization which violates privacy. ( An employee is at home?, active?, with whom he is communicating? etc).
This privacy problem occurred in the IPv6 and did not exist in the IPv4 which assigned IP addresses independently from the interface identifier.

Any possible Approaches?

• Use DHCPv6 to assign and manage addresses. Those addresses are also temporary and never changed. RFC 4941 claims to propose a similar DHCPv6 approach when using temporary addresses.
• Change the interface identifier portion of the address over time and generate new addresses from the interface identifier.
• Caller ID approach: Many machines function as clients and servers. When acting as a server the machine would need a DNS name. The privacy issue appears when the machine is acting like a client and its identity is revealed. (The similarity with the caller ID approach is when a user lists his telephone numbers publicly but disable the display of its number when initiating calls.)
  

RFC 4941 proposal:
Their approach proposes the generation of Temporary addresses, a pseudo-random sequence of interface identifiers using the MD5 hash. These addresses would be used for a short period of time. New temporary addresses will be generated to replace the expired ones. Nodes concerned about privacy may use different interface identifiers on different prefixes.

Generation of Randomized Interface Identifiers:
They propose to use 2 approaches in order to generate randomized interface identifiers.

• The first requires a 64 bit stable storage for generated temporary addresses, so the new generated address is based on the previous one. This technique prevents two nodes of generating the same random number.
• The non stable storage technique will use configuration parameters like user ID, serial numbers with a randomized data and an MD5 algorithm is order to generate random numbers.
• Alternate approaches can be used like CGA (Cryptographically Generated Addresses) to generate a random interface ID based on the node's public key. The purpose is to prove ownership of an IPv6 address and prevents stealing and spoofing of addresses. However this technique requires that a node holds a public key. The node can still be identified by its key (transactions etc). The process is intensive and discourages frequent regeneration. (Especially on low cost machines).
  

However, every time a node generates a value it should checks that the address in not reserved for particular usage or already assigned. If so, the node should repeat the process of generating random interface identifiers. The node also generates temporary addresses of every public address created. New Temporary addresses should be generated to replace expired ones.

The use of temporary addresses is an approach proposed to resolve privacy issues, however this solution have the following impacts on the Internet:

• The widespread use of temporary addresses complicating the flexibility of generating global unique addresses from interface identifiers since for each generated address DAD should be applied.
• Clients having their addresses changing over time will make packet tracking more difficult and so debugging when unknown behaviors occurs. Hence the packet's source cannot be determined if it is from one machine or multiple ones.
• Some servers refuses access to clients for which no DNS names exists. Temporary addresses are not registered.
• How to distinguish in a large network with a high rate of changing temporary addresses between the new generated addresses and spoofed addresses.

We can see clearly that stateless auto configuration generates addresses without the need of a central node and no need to apply DAD. However this unchanging part is causing privacy issue and permits identification and node tacking across the Internet due to the prefix modification when entering another network.
This prefix modification is the result of the hierarchical nature of the Internet addresses to facilitate routing and delegate address management between organizations. An unstructured architecture will hide the topology of the network but will add more burden on routers in order to transfer and deliver packets.
A new naming and addressing approach should make a good balance between simplicity and flexibility in generating global unique addresses in a distributed, self manner and providing privacy hence not exposing identity and node's location.

Link to the RFC

Review: RFC 4862 - IPv6 Stateless Address Autoconfiguration

RFC 4862 specifies the steps for a host (except routers) to apply in order to auto configure its interface and generate an IPv6 address.

Why Stateless auto configuration?

• Assign a unique address to an interface.
• Hosts in small networks would not require a DHCP server or a router to obtain a unique address. Such hosts should be able to generate unique addresses in the network.
• Large networks will not require DHCP servers for address auto configuration. Hosts should be able to generate global unique addresses.
• Facilitate address renumbering on a site or subnet. A site renumber it's nodes when it switches to a new network service provider (IP prefix modification). When renumbering, old IP address will coexist with the new IP address during a period until the old IP becomes invalid.
  

How stateless auto configuration works?
We can divide the process of auto configuration into the following phases:

1. A node generate a link-local address when its interface becomes enabled. (Reboot, start time, attachment to another link etc). This link-local address is formed by concatenating the interface identifier (generated from the interface MAC address for example) to the well-know link-local prefix 0xFE80::0.
2. The node checks if the address is unique by using Duplication Address Detection (DAD) techniques. If the address is unique then it will be assigned to the interface, if not another interface identifier is required to generate a unique link-local address. Administrators can supply an alternate interface identifier. If not a manual configuration is required. In this phase, the node generates a link-local unique address.
   
3. Nodes will listen to routers advertisements holding information to generate global addresses. Solicitation messages can also be sent by nodes to routers to avoid waiting for advertisement messages. If some specific flags are set then the node can use a prefix carried in the advertisement and apply it to the generated address. (Prefix concatenated with Interface ID). Actually this prefix is usually the subnet's prefix.
4. Duplication Address Detection is required before assigning the global unique address to the interface. Some implementations applies DAD only to link local addresses and assumes it is globally unique if it passes the local test. However new techniques have been developed for privacy protection issues. An interface identifier can be generated randomly for example, then a clash with another global address might occurs [RFC 4941 - Privacy extensions for stateless address autoconfiguration].

Nodes still listens to routers advertisements mainly to reset/increase the prefix lifetime or valid time. When the prefix advertised is different from the one generated, then it is a renumbering case, the node will form a new address (new prefix, Interface ID) and adds it to the list of addresses assigned to the interface.


According to this RFC, the Duplication Address Detection is not fully reliable, it will generate a large overhead when testing a global unique IP address.
Other mechanisms to detect address collision should be pushed further.
Site renumbering is another argument to be added to the list in order to separate a host's name from its identity.
Generating the same suffix every time can expose the identity and location of a node which in some cases can be unwanted.

Link to RFC 4862

Review: 6LowPAN

Why IPv6 can’t be applied directly on LowPANs?
6LoWPAN defines IPv6 protocol over Low power Wireless Personal Area Networks.
LowPAN devices uses IEEE 802.15.4 radios. In order to understand why we
can’t use IPv6 directly on top of LowPAN devices let’s list the characteristics of such
devices [2]:

• Small packet size. 81 bytes for data packets in the networking layer. (The maximum physical layer packet is 127 bytes, consequently the maximum frame size at the media access control layer is 102 octets. 21 bytes at maximum are usedfor securing link-layer communications).
• Support for both 16-bit short or IEEE 64-bit MAC addresses.
• Low cost devices: low bandwidth with data rates of (250 kbps, 40 kbps, 20 kbps) for (2.4 GHz, 915 MHz, 868 MHz). Low power typically battery dependent. Low processing and storage capabilities (8KB RAM, limited buffering, etc).
• Topologies include star and mesh operation.
  
• Large number of devices expected to be deployed.

The main problems with IP for LowPANs are the following:
The term Maximum Transmission Unit (MTU) refers to the size (in bytes) of the largest PDU that a given layer of a communications protocol can pass to other layers. A higher MTU brings greater efficiency because each packet carries more user data than protocol overheads. Large packets can occupy a slow link for some time, causing greater delays to following packets and increasing lag and minimum latency.
IPv6 protocol uses 128 bits IP address and a header of 40 bytes long. The MTU is at least 1280 bytes in order to maximize the efficiency of the transmission ((useful data)/(overhead data)).
LowPAN devices supports small packets with 81 bytes available for the networking layer and above. Using IPv6 on IEEE 802.15.4 leaves only 41 bytes for transport and applications layers. This is obviously not enough for data exchange, packet fragmentation and reassembly is needed but will use even more bytes. An IP header compression is needed.
Since large number of devices will be deployed, address auto configuration is attractive because it will reduce the overhead between devices. There is a need for a method to generate and assign an Identifier from the EUI-64 bits to a LowPAN device.
Routing protocols in mesh and star networks must be adapted to a small overhead. LowPAN devices have limited resources (memory, bandwidth, CPU, energy), processing 128 bits addresses and large headers will decrease the system’s efficiency and increase data treatment latency.

Why use IP based protocol in LowPANs?
The benefits of using IP based networks are the following [1][2]:

• The hierarchy of naming and addressing in IP networks which simplify the connectivity model.
• IP-based technologies already exist, are well-known, and proven to be working.
  
• IP networking technology is specified in open and freely available specifications.
  
• Use existing tools for diagnostics, management, and debugging of IP networks instead of designing and developing new ones.
• IP-based devices can be connected easily to other IP-based networks, without the need for intermediate entities like translation gateways or proxies.
  

Addressing Modes
IEEE 802.15.4 uses IEEE 64 bit and 16 bit addresses. Short addresses are assigned by a PAN coordinator during an event which means that validity and uniqueness of such addresses are limited by the lifetime of the association, failure of the coordinator, etc [3].
For short addresses (16 bits), a pseudo 48 bit address is formed by concatenating 16 zero bits to the 16 bit PAN ID (Personal Area Network). If no PAN ID assigned then 16 bits of zeros are used and the resulting concatenation is a 32 bits address. These 32 bits are concatenated with the short address in order to obtain a 48 bit address.
From a 48 bit address, a 64 bit interface identifier is formed as in [5] and [6] by adding 0xFFFE in the middle of the 48 bits (24 bits,0xFFFE,24bits). IPv6 local addresses are formed using the 64 interface identifier by appending the prefix FE80::/64. (0xFE80::EUI-64) or global addresses based on information advertised by routers [7].
Routers are the link between IP and LowPAN networks, those routers will handle address transition.

Header types
6LowPAN proposes specific header encoding and compression mechanisms to adapt IPv6 into IEEE 802.15.4 frames. Separating headers will reduce overhead. If a device is sending short packets directly to another node it does not pay for extra fields such as Mesh networking or fragmentation. The overhead reduction is an energy saving.
The header types are the following:

• The Dispatch Header (1 byte), define the type of header to follow. The dispatchheader is identified by the first two bits set to either 00 (non-6LowPAN frames)or 01. The remaining 6 bits indicate if the following field is an uncompressedIPv6 header or an HC1 header (IPv6 compressed header). To accomplish compression[1] the protocol uses a combination of the following facts: the low order64 bits of an IPv6 address (the link local address) can be the device’s MAC address,the 802.15.4 frame carries these MAC addresses, a number of the fields inthe IPv6 header are static.Combining all of these features allows the protocol to compress the standard 40 byte IPv6 header down to just 2 bytes (including the HC1 Header byte) for most intra-PAN unicast communication where source and destination addresses are deleted and generated from Link level frames (IEEE 802.15.4). All of the rest of the fields can be reconstituted without any state information at any of the receiving or intermediate nodes. Additionally by assigning the link local address to the device’s MAC address 6lowpan can use Stateless Address Auto configuration(Zero-conf) and eliminates the need to infrastructure servers like DHCP servers.
• The Mesh Header (4 bytes) is used to encode the hop limit and the source and destination of the packet. It includes two single bit fields to indicate if the originating
  or final address is a short or long address. The “hops left” field is a 4 bit
  field used to limit the number of intermediate hops between the source and destination.
  The value of 0xF was reserved to indicate that an extra byte is included
  allowing for network depths of up to 255 hops.
• The Fragmentation Header (4 bytes for the first fragment and 5 bytes for subsequent
  fragments) supports the fragmentation and reassembly of frames larger
  than the size of the 802.15.4 frame.

Today there is at least 6 implementations of 6LowPAN on multiple 802.15.4 radio platforms. The working group is still continuing to investigate the areas of neighbor discovery: IPv6 network prefix, local routers and other network configurations parameters.
The area of service discovery to locate other sensors and controllers and higher layer services.
Is it a good choice to push further IP based protocols to other areas such as LowPAN while efforts increases to redesign the Internet?
Should we inherit the limitation of IP which merges between naming and addressing to LowPANs?
What about cross-layering violation while compressing Ipv6 headers and regenerating source and destination address for Link level frames? According to the OSI scheme, Layers should be independent and unable to understand other layer’s data.
Even though in some cases header compression is efficient (with layer violation) other compressions remains unoptimized in LowPAN. Additional work should push routing protocols and reduce overhead of such protocols.

References:
1. The 6LoWPAN Architecture, Geoff Mulligan and 6LoWPAN Working Group, EmNets '07: Proceedings of the 4th workshop on Embedded networked sensors
2. RFC 4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals.
3. RFC4944 - Transmission of IPv6 Packets over IEEE 802.15.4 Networks
4. 6LoWPAN: Incorporating IEEE 802.15.4 into the IP architecture Internet Protocol
for Smart Objects (IPSO) alliance.
5. RFC 2464: Transmission of IPv6 Packets over Ethernet Networks
6. http://technet.microsoft.com/en-us/library/cc736439(WS.10).aspx
7. RFC 4862: IPv6 Stateless Address Auto configuration

Review: The SATIN Component System—A Metamodel for Engineering Adaptable Mobile Systems

Readers might be wondering why is he writing about components now, well I am interested in the meta models. Such models can be useful when designing a naming and addressing system, the meta-data associated to each component will help to find a specific component.

This article suggests a component model in order to deal with mobile adaptation.
Applications are more often monolithic (one code block), which means hard to update and maintain when an event or change of context occurs.
Their model allows logical mobility defined as the migration of a partial or complete application or process from one host to another.

Component based development divide the system into interacting components with well defined interfaces. Traditional approaches do not support code migration and execution at runtime. They apply this mobility to components.

The SATIN component model allows to send and receive components dynamically at runtime. Instead of relying on the invocation of remote services, SATIN components are remotely cloned and instantiated locally.
This solution provides autonomy when networks are disconnected. Applications can introspect which components are available locally for a task, and dynamically change the system configuration by adding or removing components.

Component metadata is essential in order to best describe component's properties which are a set of its attributes (ID, version, dependencies with other components, hardware etc). The SATIN component system use attributes similar to the Debian packaging system. This allows applications running on heterogeneous hardware/framework to decide whether on not to deploy a component.
The central component of a SATIN system is the container component which acts as a registry, holds a reference to each component installed on the system. A registrar component is used for loading, removing components, managing dependencies etc.

They consider four aspects of Logical Mobility: components, classes, Instances and data types which is a bit stream. A Logical Mobility Entity (LME) is an abstract generalization of a class, instance or data types. Logical Mobility Unit (LMU) is an encapsulation of LMEs. LMU provides operations that permit inspection of the content, a handler class to deploy and manipulate it contents. Properties (set of attributes) of LMU are used to express dependencies, target environment etc. These LMUs and its contents are serialized/deserialized for transfer and deployment between physical hosts. LMU is always deployed in a reflective component which is able to adapt on runtime by receiving LMU from other hosts.
When a change in the context/environment appears (user/component triggered), the system asks the deployer for a component satisfying a set of attributes. The local deployer contacts a remote deployer and asks for a component. The container packs an LMU and sends it back to the host.
Component discovery and advertising is general. It can uses Jini, UPnP, etc.
In their implementation they used IP Multicast advertising group and a simple centralized publish/subscribe protocol.

So far my knowledge on mobile adaptively component systems is limited, comments on this topic will be added further.
However classic issues deserves to be explored such as:
How much time is needed to transfer a component in a mobile system?
Can we and how to guarantee such time in a dynamic and mobile system. Mobile nodes appears and disappears, the transfer of LMU will be interrupted due to node departure (this is MANET similar issues).
How to advertise for services and new nodes with a minimum overhead, message exchange between nodes?
How to manage resources allocated for every component in a limited resource environment/platforms?

Link to the article

Review: Infrastructure for Pervasive Computing: Challenges

This paper enumerates the challenges faced today to design an infrastructure for pervasive computing.
Their conceptual model is based on four components: devices, users, software components and users interface.
In the following paragraph a summary of the challenges related to the naming and addressing issues of devices and software components.

Devices:

• Heterogeneity is expected to increase in the future, devices will include sensors and everyday objects such as watches, shoes etc. Those devices will require to interact despite differences in resources (hardware and software capabilities). An infrastructure is needed to manage the integration of those devices in the system.
  

• Mobility is faced to problems related to maintaining connectivity while devices move between networks (See IP mobile section). Disconnected networks can be handled by replicated data.

Software Components:

• Mobility and distribution: since users are mobile they can access several devices simultaneously. Mechanisms should enable the mobility and distribution of software. The support for distribution need to be extended to address mobility, synchronization and coordination between software components. Platforms like CORBA offers only transparency of distributed communication.

• Context awareness: applications will rely more on context knowledge than information based on user's input.

• Adaptation: The infrastructure should be able to facilitate adaptation such as reconfiguring software components, binding, adding, removing components.

• Interoperability: applications will be required to respond to new tasks and situations. Applications would be dynamically assembled from existing and available components. Those components should acquire knowledge of each other's interfaces and behavior to interact with other unknown heterogeneous components.

• Component discovery has been addressed in many research areas. Resource discovery is supported by a type management repository which maintains descriptions of service interface types. Another solution is addressed by network directory protocols such as LDAP. As resource discovery tried to solve the problem differently, the main challenge would be to integrate the different approaches into a scalable resource discovery by mapping requests between resource discovery domains.

• Scalability: the increasing number of devices and softwares requires a powerful scalable software platform on which distributed components will be built on.

The following paragraph presents existing approaches in the domain of service platforms:
Service platforms allow the rapid creation and deployment of services, as well dynamic service discovery.
JINI based on Java and RMI. Services can be added and removed dynamically.
JINI proposes among others a look up service used by clients to locate services.

MOCA aims to satisfy requirements of mobile environments. It provides dynamic service discovery, limited forms of adaptation to changes due to mobility, support for device heterogeneity.
JINI and MOCA provides solution to small scale environments.

The NINJA service framework addresses large scale services. Service discovery is supported by hierarchical arrangement of service discovery services.



Link to the article

Review: LHA -Logical Hierarchical Addressing Protocol For Mobile Ad-hoc Networks

The LHA allocation scheme uses the private block (192.168.0.0 - 192.168.255.255) to assign addresses to hosts in a MANET. The Host address is divided to 2 parts:

• Extended MANET ID, (ExMaID) 6 bits.
• Host ID, 16 bits.

They also use a NetID based on MAC address to identify a network.

An AA node is an Address Agent which assigns new free addresses to requesters. A requester node chooses its AA node from its neighbors.
The AA node which provides an address to the requester is his predecessor, and the requester is the successor of the AA node.

Network initialization:
The node starts a network when no messages are received for address assignment request. To choose the first address, the node selects a random number in the range of [1-30] as Host ID then another number from 6 bits as ExMaID. The NetID is defined by using the node's MAC address.

Joining of a node:
When a node joins a network it requests a free address from its neighbors. It then chooses its AA node based on its address and the available free addresses at this node.
AA node uses the following equation to assign a new free address:
New_Ad = Root_Ad + k*(Agent_Ad - (Root_Ad - 1)) - Afa +1.
Afa is the number of the available free addresses at this node.
K is the number of direct successor a node can have.

If an AA node don't have any addresses left, it broadcasts a request to its neighbors asking for a free address, the new node will be a successor to the node who provided the free address.

If no addresses are available, the new node is a root node for a new network.

Departure of a node:
When leaving a network, the node broadcasts informing his departure. The predecessor nodes updates their informations.

Network Partitioning:
When an AA node fails to assign a free address it checks it ALN (the number of lost nodes), if ALN > Threshold then there is network partition.
One of the partitions with the root node will increment its ExMaID while the other partition decreases its ExMaID and assigns the address of the root node to the new joining node. NetID is also updated in this partition.
All nodes free their missed addresses of their successors.

Network Merging:
There is 2 types of network merging:

• Soft merging: when the ExMaID are different then there is no address duplicated addresses. One of the partitions updates it NetID and save the ExMaID
• Hard merging: when ExMaID are identical then there is a high probability of address conflict. One of the networks increment its ExMaID by 2 and save the NetID of the other network.
  

Results shows that this method reduces latency to obtain IP address by 50 % comparing to the Token-based address assignment.

This work claim to reduce latency by 50% comparing to another address assignment protocol.
However it leaves many unresolved or unexplained points such as:

• How to determine how much successors a node can have, the value of K in the equation of address assignment. This value will definitely impact the number of free address allocations because every node is an AA node.
• When the root node leaves the network, the NetID should be changed and another node should be the new root node. What if a root node left the network then decides to join but because it is out of the transmission range, this node will not receive further messages from other nodes in the network. This node can initiate a new network with the same NetID, ExMaID and assign addresses to new nodes. When the node goes back into the transmission range of the initial network there is a high probability of address conflict which can go undetected because the NetID, ExMaID are identical.
• In the network partitioning if (ALN > Threshold) this is not necessarily a network partition. It can be simply nodes left the network after crash, empty battery etc, though too much unnecessary effort is done by changing ExMaID and broadcasting it.
• Since the NetID and not the ExMaID is used to identify a network then all the routing is based on the NetID and not IP address. This method will have impact on routing.
• When Hard merging, ExMaID is incremented by 2, what if there was a partition before, this means that one of the partion will increase its ExMaID by 1 what if the same partition was partitioned its ExMaID will be incremented by 1 which means the sum of increments is 2, equal to incrementing ExMaID when hard merging. This will lead to more conflict when partitions merge with a network who just had a Hard merging.
  

link to the article

Review: Prophet address allocation for large scale MANETs

The Prophet address allocation scheme uses an arithmetic function F based on an IP address and a state value of F. This function seems to generate a sequence of numbers with a low probability of redundancy. The minimal interval between two occurrences is very large and depends on the IP address range.
Every host holds F and can assign a unique IP to other nodes.
When joining a network, a node A requests a unique IP address. If his request was ignored then A can start configuring a MANET. It proceeds by choosing a random private IP address and a random state value. When a new node B joins the network, A allocates a free IP address to B using F. Then A transmit to B, its new IP address and its state of F. A updates its state of F.
B is now capable to assign free IP addresses to new nodes.
As for partitioning and merging, since the IP addresses are "unique" no changing is required.
When dealing with scenario#3, a host configuring a MANET chooses a Network ID and sends it to new nodes with the free IP address.
When merging two alternative mechanisms have been proposed one of the MANET group should drop its IP addresses and request new free addresses. This method will break on-going communication and routing in the changing MANET.
The second mechanism requires only nodes with conflicting addresses to obtain new addresses. This mechanism requires high overheads to detect conflict addresses and does not provide an answer regarding what function to use for future allocations.
Node A chooses the seed for the whole network and the sequences may be computed locally which means it knows in advance which addresses are going to be allocated.

This scheme is able to reduce communication overheads in scenarios #1 and #2 since every node is able to generate a unique IP address with a low probability of conflict. However the low probability is based on a large range of IP address which is not the case with the private addresses. As for the Scenario #3, it will be handled in their future work.
Their approach is not suitable for large scale MANETs where the probability of assigning the same IP address is high.

link to the article

Review: Hosts Address Auto Configuration for Mobile Ad Hoc Networks.

This article propose a method for MANET nodes to assign a unique IP address.
Their approach is based on defining a MANET ID and a HOST ID from a private IP address block, (172.16.0.0 - 172.31.255.255) for exemple.
The MANET ID is a randomly 8 bits number while the HOST ID is a 16 bits number. the IP address will have the following form 172.MANET_ID.HOST_ID.

A Node creates the first network if no answers are received from hosts in an Ad Hoc network. it has a node number "0". it selects a randomly MANET ID between [0x16 and 0x32] and takes the first address in the host ID space [0x00.0x00]. The node "0" can allocate the addresses using the following equation:
Sum(i=0,i=Base_Value-1, n*Base_value+1).
Where base value= 2,3, ...
Host number n=0,1,2 ..
i = 0,1,2 ..(Base value-1)

The new node willl be add the generated value to the node "0" IP address. It will obtain a unique IP address in the Network.
The higher the value, the wider the tree and the higher the number of leaves with free addresses to allocate.
With base value=2, node 0 allocates values 0 and 1. Node 4 allocates values 8 and 9....
When a host joins a network, it broadcasts asking for a unique IP address. Nodes with available addresses will answer it. The new host should gives priority to the address allocating host with the lowest address.
This approach defines also use cases to reallocate addresses of hosts departing the network. ex when node 8 leaves, node 4 can reassign only value 8.
When network partition occurs nodes should free allocated addresses of non reachable hosts. The non reachable hosts are identified when routing packets and route discovery.
As for the network merging they propose to use the highest MANET ID between the 2 networks. The addresses with the lowest MANET ID will be reassigned.

Even though this approach seems interesting however when reallocating addresses there is high traffic of information to parent nodes to restrict the generation of certain IDs. It can be done when the Base value is low but when it increases, the restrictions exchange will be harder to maintain.
As for the merging, I think it would be more convenient to use the MANET ID of the network with the highest number of nodes. This approach will reassign new addresses to fewer nodes.
The solution don't provide a solution when 2 networks with same randdom selected MANET ID merges.

link to the article

Mobile Ad Hoc NETwork (MANET)

A Mobile Ad Hoc Network is formed by the association of mobile devices, usually wireless and capable of multi-hop communication among themselves even if there is no networking infrastructure available. [MANET Auto configuration Internet-Draft].

Node's mobility (arrival and departure of nodes in the network) makes it difficult to rely on a central trusted node whose role will be to allocate free unique IP addresses. The failure or departure of such central node will prevent further IP allocation.
Since there is no central networking infrastructure, MANET nodes should request from other nodes (or auto-assign) a unique identifier in order to communicate with other MANET nodes.

When building an address allocation system, the following 3 scenarios should be handled:
[Prophet allocation ...]

1. Join and leave: A mobile node joins a network and leaves forever with/without acknowledgment of departure. How to detect unacknowledged departure and reuse allocated IP address. How to allocate a unique IP address for 2 nodes joining at the same time.
2. Partition and Merge: a node or more of the MANET moves outside other's transmission range. When they move back within the transmission range, they should merge again with the MANET. What if other nodes joined and same IP addresses where allocated to them.
3. Two separated MANETs with different IP configuration merging.
   

Existing solutions can be divided into the following three categories:

1. Conflict-detection allocation: A new node selects an address from the private address space and requests approval from all nodes in the MANET. If it receives a conflict message from a node in the network, then it selects another address until the address is free, it becomes the new node's address. (Duplicate Address Detection method). These methods can handle easily scenario#1.
   
2. Conflict-free allocation: Free IP addresses are assigned to new nodes. Dynamic Configuration and Distribution Protocol is an example of conflict-free allocation algorithms which is based on dividing the address pool in two halves every time a new node joins the MANET. This insures the uniqueness of the allocated addresses. These methods can handle scenario #1 and #2 since the addresses are already different. However when it comes to dealing with scenario #3 conflicts are unavoidable. The pool addresses are taken from the private addresses range.
3. Best effort allocation: the nodes responsible for allocating new addresses attempt to provide a conflict free address to the best of their knowledge, but conflicts may still occur, say due to the same address being allocated to two joining nodes before there is time for updating the table of existing addresses. An example of best-effort allocation is MANETConf Protocol.
   

The next section describes a summary of an auto address assignment methods to MANET nodes.