Subject: [manet] Answer to a question in Ad Hoc IP Address Autoconfiguration

From: "Jaehoon Jeong" <[email-masked]>
Date: Fri, 18 Jul 2003 10:11:27 +0900

Dear Charles Perkins,

In my talk of this IETF meeting, you asked how AERR message is delivered 
from one mobile node to another which have duplicate addresses during weak DAD. 
For example, look at the Fig 1, where MANET partition consist of four nodes.

       MN-1 <-----> MN-2 <-----> MN-3 <-----> MN-4
 (A.B.C.D, key-1)                                         (A.B.C.D, key-4)
         
  Fig 1. Address Duplication during ad hoc routing (or Weak DAD)
 
How does MN-4 inform MN-1 of address duplication through AERR message
while MN-1 performs the route discovery(RREQ) of a destination 
with its source address "A.B.C.D"?
RREQ contains its source address and key.
MN-4 receives an RREQ from MN-1 and finds out address duplication,
because the source address of RREQ is the same as MN-4's but the keys are different.

In Weak DAD, the forwarding is based on the pair of IP address and key. 
MN-3 has two host routes of address "A.B.C.D" in the moment that MN-3 forwards
MN-4's AERR message toward MN-1 like Table 1.

  Table 1. Routing Table of MN-3

   -----------------------------------------------
  |      Dest       | Dest Key | Next Hop | Distance |
   -----------------------------------------------
  |   A.B.C.D   |    key-4    |   MN-4    |      1      |
  |   A.B.C.D   |    key-1    |   MN-2    |      2      | -> precursor for forwarding RREP message
       ....

Through the forwarding based on IP address and key, the AERR from MN-4 will be delivered to MN-1.
This is my answer :-)
Is there any more question and comments?

Regards,
Jaehoon Paul
&jw™¨¥Šx%ŠËfjw‰ë_¢¸!¶Úlÿü0ÃXžµú+ƒùšŠYšŸùb²Ø§~æjw

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 18 Jul 2003 01:37:08 -0700

Hello Jaehoon Paul,

Thanks for your explanation, now I understand.

The solution places a requirement for a new field in the
routing table -- namely, the inclusion of a "key" field.

I guess there isn't any protection against accidental
cases where the two contenders for  A.B.C.D  happen
to select the same value for "key".  That should be O.K.
as long as (i) the key is _long_ (in bits),  and (ii) the
nodes are quite capable of producing truly random
numbers.  Also, I notice that the intermediate routing
points also have to maintain the "key" value for the
two endpoints, at least during address discovery.

Regards,
Charlie P.

Jaehoon Jeong wrote:

>fjw-(%
x%
Kfjw-~'-?z+m&O0Wx5h.fj)fj?e
Kbz?)^

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Christophe Jelger" <[email-masked]>
Date: Fri, 18 Jul 2003 11:52:16 +0200

Hi,

I'm sorry I have not really followed all discussions around DAD in Adhoc
networks and I've also not attended the IETF in Vienna, but I have a few
questions about DAD in adhoc networks ...

1. Keeping in mind that IPv6 address collisions for stateless configurations
are extremely rare (from a probalistic point of you), I wonder what are the
motivations for doing DAD in adhoc networks ... (actually the same question
could apply to wired networks, but I don't want to start a discussion on
that) ;-)

2. DAD was designed to work on a link, it does not prevent nodes on
different links to have the same address ... does it therefore make sense to
use DAD in a adhoc network, which is by essence a multi-hop network ?

3. If one wants to dissemate global prefix information in an adhoc network,
the usual RA technique cannot be used because nodes should forward packets
sent to a link local address ... the point is : if we don't do it the normal
way and thus don't strictly follow IPv6 rules, can't we also consider to
bypass DAD ?

4. By including complex mechanisms to perform DAD in adhoc networks, would
it not prevent routing protocols from being developed in a large scale and
thus used ?

Please do not misunderstand my point : I'm not saying DAD should not be
used, I'm just trying to understand the pros and cons of using it in an
adhoc environment. Comments on my thoughts are very welcome.

Thanks,

Christophe

---------------------------------------------------------------
Christophe Jelger - LSIIT           [email-masked]
Université Louis Pasteur
Strasbourg - France                   Tel: +33 (0)3 90 24 45 90

http://www-r2.u-strasbg.fr/~jelger
---------------------------------------------------------------

---

From: "Jihoon Lee" <[email-masked]>
Date: Sat, 19 Jul 2003 14:11:50 +0900

Hi. Jelger and manet members.

My commes are in line.

> use DAD in a adhoc network, which is by essence a multi-hop network ?

IPv6 DAD scheme has on-link range. As you said, there is, in essence, a difference between normal IPv6 DAD and DAD in Ad hoc. DAD in Ad hoc means a scheme that can detect address duplication in one ad hoc network. One ad hoc network is similar to IPv6 on-link subnet. Especially in ad hoc networks, there is a chance in network merging (ad hoc A + ad hoc B). In merged network, there is a big chance in the existence of some nodes with the same address, each other randomly generated. A collision among some nodes is inevitable.

In summary, I think DAD in ad hoc is needed to escape packet misroutings to wrong node. 

In addition, I think that for efficient DAD shceme, network clustering/partitioning scheme must be together considered 

	šëfj)bž	b²Ùšëbz×è®m¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ùšë

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 23 Jul 2003 11:51:39 +0900

SGkgQ2hhcmxpZSBQLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsaWUgUGVya2lucyIgPGNoYXJsaWVwQElQUkcubm9raWEuY29tPg0KVG86ICJKYWVob29uIEplb25nIiA8cGF1bEBldHJpLnJlLmtyPg0KQ2M6ICJNQU5FVCBXRyIgPG1hbmV0QGlldGYub3JnPg0KU2VudDogRnJpZGF5LCBKdWx5IDE4LCAyMDAzIDU6MzcgUE0NClN1YmplY3Q6IFJlOiBbbWFuZXRdIEFuc3dlciB0byBhIHF1ZXN0aW9uIGluIEFkIEhvYyBJUCBBZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uDQoNCg0KPiANCj4gDQo+IEhlbGxvIEphZWhvb24gUGF1bCwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBleHBsYW5hdGlvbiwgbm93IEkgdW5kZXJzdGFuZC4NCj4gDQo+IFRoZSBzb2x1dGlvbiBwbGFjZXMgYSByZXF1aXJlbWVudCBmb3IgYSBuZXcgZmllbGQgaW4gdGhlDQo+IHJvdXRpbmcgdGFibGUgLS0gbmFtZWx5LCB0aGUgaW5jbHVzaW9uIG9mIGEgImtleSIgZmllbGQuDQo+IA0KUmlnaHQuDQoNCj4gSSBndWVzcyB0aGVyZSBpc24ndCBhbnkgcHJvdGVjdGlvbiBhZ2FpbnN0IGFjY2lkZW50YWwNCj4gY2FzZXMgd2hlcmUgdGhlIHR3byBjb250ZW5kZXJzIGZvciAgQS5CLkMuRCAgaGFwcGVuDQo+IHRvIHNlbGVjdCB0aGUgc2FtZSB2YWx1ZSBmb3IgImtleSIuICBUaGF0IHNob3VsZCBiZSBPLksuDQo+IGFzIGxvbmcgYXMgKGkpIHRoZSBrZXkgaXMgX2xvbmdfIChpbiBiaXRzKSwgIGFuZCAoaWkpIHRoZQ0KPiBub2RlcyBhcmUgcXVpdGUgY2FwYWJsZSBvZiBwcm9kdWNpbmcgdHJ1bHkgcmFuZG9tDQo+IG51bWJlcnMuICANCkN1cnJlbnRseSwgdGhlcmUgaXMgbm8gcHJvdGVjdGlvbiBhZ2FpbnQgdGhlIHNpbXVsdGFuZW91cyBjb25mbGljdCBvZiBhZGRyZXNzIGFuZCBrZXkuDQpJIGFzc3VtZWQgdGhlIHBvc3NpYmlsaXR5IG9mIHRoYXQgY2FzZSBpcyB2ZXJ5IGxvdyBhcyB5b3Ugc3VnZ2VzdGVkLg0KDQo+IEFsc28sIEkgbm90aWNlIHRoYXQgdGhlIGludGVybWVkaWF0ZSByb3V0aW5nDQo+IHBvaW50cyBhbHNvIGhhdmUgdG8gbWFpbnRhaW4gdGhlICJrZXkiIHZhbHVlIGZvciB0aGUNCj4gdHdvIGVuZHBvaW50cywgYXQgbGVhc3QgZHVyaW5nIGFkZHJlc3MgZGlzY292ZXJ5Lg0KPiANClllcy4gDQpJIGFtIHRoaW5raW5nIG92ZXIgYW5vdGhlciB3YXkgdG8gcmVwbGFjZSBXZWFrIERBRCwgd2hpY2ggZG9lcyBub3QgdXNlIGFkZGl0aW9uYWwga2V5IA0KZm9yIGFkZHJlc3MgZHVwbGljYXRpb24gZGV0ZWN0aW9uLiANCkkgYW0gaW52ZXN0aWdhdGluZyB3aGV0aGVyICJPcmlnaW5hdG9yIFNlcXVlbmNlIE51bWJlciIgb2YgUlJFUSBjYW4gYmUgdXNlZCBpbnN0ZWFkIG9mIGtleSBvciBub3QuDQpIb3cgYWJvdXQ/DQoNCi9KYWVob29uIFBhdWwNCg0KPiBSZWdhcmRzLA0KPiBDaGFybGllIFAuDQo+IA0KPiANCj4gSmFlaG9vbiBKZW9uZyB3cm90ZToNCj4gDQo+ID5EZWFyIENoYXJsZXMgUGVya2lucywNCj4gPg0KPiA+SW4gbXkgdGFsayBvZiB0aGlzIElFVEYgbWVldGluZywgeW91IGFza2VkIGhvdyBBRVJSIG1lc3NhZ2UgaXMgZGVsaXZlcmVkIA0KPiA+ZnJvbSBvbmUgbW9iaWxlIG5vZGUgdG8gYW5vdGhlciB3aGljaCBoYXZlIGR1cGxpY2F0ZSBhZGRyZXNzZXMgZHVyaW5nIHdlYWsgREFELiANCj4gPkZvciBleGFtcGxlLCBsb29rIGF0IHRoZSBGaWcgMSwgd2hlcmUgTUFORVQgcGFydGl0aW9uIGNvbnNpc3Qgb2YgZm91ciBub2Rlcy4NCj4gPg0KPiA+ICAgICAgIE1OLTEgPC0tLS0tPiBNTi0yIDwtLS0tLT4gTU4tMyA8LS0tLS0+IE1OLTQNCj4gPiAoQS5CLkMuRCwga2V5LTEpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoQS5CLkMuRCwga2V5LTQpDQo+ID4gICAgICAgICANCj4gPiAgRmlnIDEuIEFkZHJlc3MgRHVwbGljYXRpb24gZHVyaW5nIGFkIGhvYyByb3V0aW5nIChvciBXZWFrIERBRCkNCj4gPiANCj4gPkhvdyBkb2VzIE1OLTQgaW5mb3JtIE1OLTEgb2YgYWRkcmVzcyBkdXBsaWNhdGlvbiB0aHJvdWdoIEFFUlIgbWVzc2FnZQ0KPiA+d2hpbGUgTU4tMSBwZXJmb3JtcyB0aGUgcm91dGUgZGlzY292ZXJ5KFJSRVEpIG9mIGEgZGVzdGluYXRpb24gDQo+ID53aXRoIGl0cyBzb3VyY2UgYWRkcmVzcyAiQS5CLkMuRCI/DQo+ID5SUkVRIGNvbnRhaW5zIGl0cyBzb3VyY2UgYWRkcmVzcyBhbmQga2V5Lg0KPiA+TU4tNCByZWNlaXZlcyBhbiBSUkVRIGZyb20gTU4tMSBhbmQgZmluZHMgb3V0IGFkZHJlc3MgZHVwbGljYXRpb24sDQo+ID5iZWNhdXNlIHRoZSBzb3VyY2UgYWRkcmVzcyBvZiBSUkVRIGlzIHRoZSBzYW1lIGFzIE1OLTQncyBidXQgdGhlIGtleXMgYXJlIGRpZmZlcmVudC4NCj4gPg0KPiA+SW4gV2VhayBEQUQsIHRoZSBmb3J3YXJkaW5nIGlzIGJhc2VkIG9uIHRoZSBwYWlyIG9mIElQIGFkZHJlc3MgYW5kIGtleS4gDQo+ID5NTi0zIGhhcyB0d28gaG9zdCByb3V0ZXMgb2YgYWRkcmVzcyAiQS5CLkMuRCIgaW4gdGhlIG1vbWVudCB0aGF0IE1OLTMgZm9yd2FyZHMNCj4gPk1OLTQncyBBRVJSIG1lc3NhZ2UgdG93YXJkIE1OLTEgbGlrZSBUYWJsZSAxLg0KPiA+DQo+ID4gIFRhYmxlIDEuIFJvdXRpbmcgVGFibGUgb2YgTU4tMw0KPiA+DQo+ID4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICB8ICAgICAgRGVzdCAgICAgICB8IERlc3QgS2V5IHwgTmV4dCBIb3AgfCBEaXN0YW5jZSB8DQo+ID4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICB8ICAgQS5CLkMuRCAgIHwgICAga2V5LTQgICAgfCAgIE1OLTQgICAgfCAgICAgIDEgICAgICB8DQo+ID4gIHwgICBBLkIuQy5EICAgfCAgICBrZXktMSAgICB8ICAgTU4tMiAgICB8ICAgICAgMiAgICAgIHwgLT4gcHJlY3Vyc29yIGZvciBmb3J3YXJkaW5nIFJSRVAgbWVzc2FnZQ0KPiA+ICAgICAgIC4uLi4NCj4gPg0KPiA+VGhyb3VnaCB0aGUgZm9yd2FyZGluZyBiYXNlZCBvbiBJUCBhZGRyZXNzIGFuZCBrZXksIHRoZSBBRVJSIGZyb20gTU4tNCB3aWxsIGJlIGRlbGl2ZXJlZCB0byBNTi0xLg0KPiA+VGhpcyBpcyBteSBhbnN3ZXIgOi0pDQo+ID5JcyB0aGVyZSBhbnkgbW9yZSBxdWVzdGlvbiBhbmQgY29tbWVudHM/DQo+ID4NCj4gPlJlZ2FyZHMsDQo+ID5KYWVob29uIFBhdWwNCj4gPn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/Zmp3LRkoJQ0KPiB4JQ0KPiBLZmp3LX4nLT96KwIbbSZPf38gMFd4HjV/aC4PZmopZmo/ZQ0KPiBLYh16PxkpXg0KPiA+ICANCj4gPg0KPiANCj4g_______________________________________________manet mailing [email-masked]://www1.ietf.org/mailman/listinfo/manet