Subject: Re: Address Allocation

From: Fred Baker <[email-masked]>
Date: Thu, 24 Jan 2002 11:55:44 -0800

At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote:
>is anyone know the manner used by an Ad Hoc host to get an IP address ? is 
>there a differences betwwen a local area and a large nnetwork for the 
>allocation ?

I don't see any draft that specifically addresses that.

It seems to me that there are three possible ways:
  - static configuration
  - DHCP or something like it
  - autoconfiguration

frankly, in an IPv6 world, I would hope that some form of autoconfiguration 
would be useful. There are some issues; if one picks a random number and 
asks one's immediate neighbors whether it's a good choice, they may not 
know what would be a good choice after the device moves. However, basing it 
on a serial number printed in a ROM (as is done with Ethernet addresses) 
has a good chance of avoiding ambiguities in the procedure.

In IPv4 or IPv6, static configuration can be used in networks of moderate 
scale.

DHCP etc has issues, though, at least as it stands. What we do today is 
configure address proxies which can forward DHCP messages to more central 
DHCP servers, or configure DHCP servers in the routers themselves. In a 
manet, this seems problematic - some systems in the network might have 
difficulty obtaining addresses during times of instability.

---

From: Joe Macker <[email-masked]>
Date: Thu, 24 Jan 2002 19:13:57 -0500

At 11:55 AM 1/24/2002 -0800, Fred Baker wrote:
>>is anyone know the manner used by an Ad Hoc host to get an IP address ? is there a differences betwwen a local area and a large nnetwork for the allocation ?
>
>frankly, in an IPv6 world, I would hope that some form of autoconfiguration would be useful. There are some issues; if one picks a random number and asks one's immediate neighbors whether it's a good choice, they may not know what would be a good choice after the device moves. However, basing it on a serial number printed in a ROM (as is done with Ethernet addresses) has a good chance of avoiding ambiguities in the procedure.

I think v6 version implementations hold some promise for easing autoconfiguration here as Fred indicates (by using addresses partially based on MAC addresses,etc). 

>In IPv4 or IPv6, static configuration can be used in networks of moderate scale.

Yes, has been done so in practice within a manet domain of 20-30 nodes with little pain.  Would quickly become more painful as things grew and dispersed?  Used dhcp at edges for handling wired hosts carried along with manet routers (advertised mask so no brainer there).

>DHCP etc has issues, though, at least as it stands. What we do today is configure address proxies which can forward DHCP messages to more central DHCP servers, or configure DHCP servers in the routers themselves. In a manet, this seems problematic - some systems in the network might have difficulty obtaining addresses during times of instability.

Some of you may have missed the zeroconf relationship discussions we had in London. Interesting discussions and along the lines of outlining some problem spaces...at least the discussion should have been covered in the minutes. I believe there is future interesting work to be done here.  There have been early draft IDs and ideas being kicked around in this space. The distributed, multi-hop nature and potential dynamics are obvious issues.

---

From: "Elizabeth M. Belding-Royer" <[email-masked]>
Date: Thu, 24 Jan 2002 17:29:41 -0800 (PST)

> I don't see any draft that specifically addresses that.

Our revised Internet Draft on address autoconfiguration 
(revised for the last IETF) addresses this issue for both
IPv4 and IPv6 networks.  The basic mechanism is that 
a mobile node selects an address from some address space,
and then it must perform duplicate address detection to
ensure that address is not already claimed within the network.

The draft name is draft-perkins-manet-autoconf-01.txt.
Its in the Internet Draft repository.

Elizabeth

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Fri, 25 Jan 2002 09:52:28 +0200

If we have a network that is splited in two parts that have no network
connectivity between them (the two groups might be far away from each
other) and then they get merged (because nodes actually move, and the
two groups might get closer), it is possible that two nodes (one on
each part) have the same address because when they used this
'duplicate address detection' they didn't detect each other and they
thought that nobody else was using the same address than themselves.

So, if nodes move, your solution just doesn't work.

BR/Manel Guerrero

---

From: Joe Macker <[email-masked]>
Date: Fri, 25 Jan 2002 11:15:27 -0500

Manel:

These same issues were raised by many during the London meeting and in years past.  Along these lines, I remember looking through related work in distributed multicast address allocation (at the application layer to setup dynamic unique endpoint identifiers) attempting to address issues of "collision detection and resolution" as dynamics and topology fragmentation occur. Not an easy problem, especially at the routing protocol layer. So I don't think we have a good robust solution at the present time for surviving and recovering robustly from duplicate address collision for dynamic, multi-hop networks with fragmentation,etc occurring.  As another (less distributed option) a fixed arbitration authority (manet stubs may often connect to a fixed infrastructure),etc can perhaps solve this in an easier fashion that handles the fragmentation case.  Multicast or anycast services might be useful regardless of how its solved.

-Joe

---

From: Sanket Nesargi <[email-masked]>
Date: Fri, 25 Jan 2002 11:23:05 -0600 (CST)

On the topic of address allocation, we have a paper titled -
"MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network", due to
appear in the proceedings of Infocom 2002.
We have presented a comparison of the exitsing approaches to address
allocation, and developed a distributed alogirithm to dynamically allocate
addresses. Issues related to partitioning and the merger of partitions
(leading to address conflicts) have been addressed as well.

This paper can be accessed at:
www.utdallas.edu/~ravip/papers/infocom2002.pdf

We hope that our paper addresses some of the more pertinent issues in
address allocation. Any feedback is very welcome.

Thanks,
- Sanket

---------------------------------------------------------------------
        Standing on a hill in my mountain of dreams,
        telling myself its not as hard as it seems
                                                - Led Zeppelin

Sanket S. Nesargi
Distributed Systems Lab
University of Texas at Dallas,        http://www.utdallas.edu/~sanket
Richardson TX 75082                             <[email-masked]>
---------------------------------------------------------------------

---

From: Joe Macker <[email-masked]>
Date: Fri, 25 Jan 2002 14:00:44 -0500

At 11:22 AM 1/25/2002 -0600, Saad Biaz wrote:
>I am following this thread of address allocation and wonder about the
>necessity or the meaning of an address at the network layer.
>
>Let us consider an IP address. This IP address is useful at the network
>layer ONLY to bring a packet to the right subnet. When a packet reaches the 
>subnet, it is the MAC address that is used to find out the node.
>
>Now, consider the adhoc networks. There are no subnets. Nodes moving from
>place to place, sometimes in the range of some set of nodes, later in te
>range of another set. If the network layer does not refer to some
>"grouping", then why need one. It is useless.
>
>Therefore, why not just use the MAC address that is normally unique?

You may have missed in the thread we talked about this option.  Using a potentially unique ROM-burned number as a segment of the address space was covered in the discussion and its a good option.  We are however dealing with IP routing, since this is an IETF WG, and heterogeneity,etc is important.  There may indeed be large sets of fixed subnets attached to mobile manet routers in some cases or we may route across multiple wireless media.  We have discussed this before.

-Joe