Subject: [manet] Autoconf Problem Statement

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 07 Mar 2007 14:20:54 +0100

Hi all,

the MANET autoconf problem statement has been updated.

http://manetautoconf.online.fr/Blog/wp-content/draft-baccelli-autoconf-problem-statement-02.txt

Thourough reviewing from you is now needed in order to
identify:

   - what is missing, and needs to be included?
   - what is in excess, and needs to be removed?
   - what is in the document, but is not entirely in the desired shape?
   - what is well addressed in the document?

Such points must be discussed now on the Autoconf mailing list to 
prepare the forthcoming working group meeting in Prague.

Cheers
Emmanuel

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

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 7 Mar 2007 11:03:50 -0500

Still reviewing but wanted to comment on improvement.
Good job removing state diagrams and DAD references based on feedback from
last two meetings. 
-Joe
>-----Original Message-----
>From: Emmanuel Baccelli [mailto:[email-masked]] 
>Sent: Wednesday, March 07, 2007 8:21 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [manet] Autoconf Problem Statement
>
>Hi all,
>
>Such points must be discussed now on the Autoconf mailing list 
>to prepare the forthcoming working group meeting in Prague.
>
>Cheers
>Emmanuel
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Mar 2007 11:49:29 +0100

Emmanuel Baccelli wrote:
> Thourough reviewing from you is now needed in order to identify:
> 
> - what is missing, and needs to be included? - what is in excess, and
>  needs to be removed? - what is in the document, but is not entirely 
> in the desired shape? - what is well addressed in the document?

Hi Emmanuel,

This is a very generous question and please let me take advantage of its
opportunities.

I was wondering whether draft misses some aspects.

This draft:
> Standard automatic IPv6 address/prefix assignment solutions [5], [3]
>  [4] do not work "as-is" on MANETs due to ad hoc networks' unique 
> characteristics [2], and new mechanisms are therefore needed.

While I agree the widespread address assignment solutions rfc2462
stateless, rfc3315 DHCP and rfc2461 ND are not suited for MANET
environments, I think that only some existing _address_ assignment
mechanisms are listed while existing _prefix_ assignment mechanisms are
not listed.

DHCPv6 Prefix Delegation is such a mechanism RFC3633.

There exist other prefix assignment mechanisms that are currently in
draft shape, that could be relevant:
-Prefix Delegation for NEMOv6 Mobile Routers (based on Mobile IPv6
  allocation or on DHCPv6 Prefix Delegation: 2 drafts).
-ICMPv6 Redirect is not quite a prefix assignment, but its effects are
  the inclusion in the routing table of a /128 next-hop.
-two personal proposal as extension to ND to assign prefixes. drafts, no
  WG no BoF - see [email-masked].
-there may be others if one looks harder.

Address (not prefix) assignment is a much wider landscape with more
drafts/rfcs that are less widespread use and that are not DHCP nor SLAAC
(Stateless Address Auto Config), see Fast Mobile IPv6 EXPERIMENTAL RFC
and Fast Mobile IPv4 WG item in MIP4 WG.  Auto-generation of addresses
(from EUI64 IEEE-802, or from  other link's ID, or from other secret
material - CGA, HBA) exist as well, in various RFC or draft form.

That said, I will post separately on other aspects.

Thanks,

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Mar 2007 13:23:14 +0100

> in the desired shape? - what is well addressed in the document?

Do you think autoconf prefix autoconfiguration problem could accommodate
a problem whereby two Mobile Routers serving Local Fixed Nodes need to
exchange routing table entries?

The scenario is a scene where two vehicles arrives and stay put for a
while.  In each vehicle there's a fixed Mobile Router.  EAch additional
computer is fixed in each vehicle and is called a Local Fixed Node (eg a
laptop, or car engine control, or pda - all fixed in each vehicle).

Each Mobile Router has an egress interface, whose radio is  receivable
from outside the vehicle.  The radio in the vehicle is not visible
outside, especially when all doors are shut close.

There's no Internet connectivity at this scene, no WMAN infrastructure,
all communication is built locally.

With this setting, although one LFN in one vehicle could talk to the
other LFN in another vehicle (via the external inter-vehicular radio),
the two MRs currently have no means to exchange routing information
(other than OSPF or DHCP, which require pre-configuration of the other
peer prior to arriving at the scene).

What do you think about this problem?  Could it be accommodated
somewhere in the AUTOCONF Problem Statement draft?

The solutions that _may_ be pertinent to this problem are Neighbour
Discovery extensions, specifically putting prefixes in RA or in NA.
There are about two drafts in this space, I can refer them if interest is.

Is an AUTOCONF or MANET existing solution draft addressing this problem
already?

Thanks in advance,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Mar 2007 14:11:22 +0100

Hi Jean, thanks for message, please allow me to ask a few details that
would save me documented reading.

Jean Lorchat wrote:
> Hi Alex,
> 
>> Each Mobile Router has an egress interface, whose radio is 
>> receivable from outside the vehicle.  The radio in the vehicle is 
>> not visible outside, especially when all doors are shut close.
> 
> Why do you mention this in-vehicle radio ? Can it get involved in the
>  scenario ? or did you want to describe the ingress interface ?

Right, I just wanted to describe the ingress interface.  The fact that
the in-vehicle interface is wireless does not mean (in this scenario)
that any device is moving out/in the vehicle.  Not for this scenario.

>> There's no Internet connectivity at this scene, no WMAN 
>> infrastructure, all communication is built locally.
>> 
>> With this setting, although one LFN in one vehicle could talk to 
>> the other LFN in another vehicle (via the external inter-vehicular 
>> radio), the two MRs currently have no means to exchange routing 
>> information (other than OSPF or DHCP, which require 
>> pre-configuration of the other peer prior to arriving at the 
>> scene).
> 
> If MANET is running on the (egress) radio interface, then OLSRv2 can
>  solve the problem (by using the "Local Attached Network Set", and 
> putting information about these prefixes in the periodic TC messages.
> 
> 
What's the dst address of periodic TC messages?  Is that a multicast
address?  A unicast address?

If unicast - then somehow the router should be pre-configured with the
address of the destination, no?

If multicast - then somehow the receiving router must express interest
in this multicast group before receiving a TC from another router, no?

> You even don't have to solicit the prefix information).

I think sometimes it's useful to solicit for a TC, especially when one
needs a quick response and the sender's timer is too long.

>>  Discovery extensions, specifically putting prefixes in RA or in 
>> NA. There are about two drafts in this space, I can refer them if 
>> interest is.
>> 
>> Is an AUTOCONF or MANET existing solution draft addressing this 
>> problem already?
> 
> At least OLSRv2 does. OLSR(v1) has support for "Host Network 
> Attachment" but I think they only accomodate IPv4 prefixes.

Can OLSRv2 on one MR realize somehow that all other Mobile Routers have
left the scene and no longer send TC messages when it's alone?  Is there
a form of unreachability detection or test or similar mechanism?

Thanks,

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 09 Mar 2007 15:20:51 +0100

Alex,

> exchange routing table entries?

As of yet, Autoconf is focussing on IPv6 address and prefix 
configuration. So other types of configuration is out of scope for now.

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Mar 2007 15:39:55 +0100

> configuration. So other types of configuration is out of scope for now.

I see, thanks for the info.

When you say 'configuration', you mean the means by which a node assigns 
an address (or a prefix) for itself?  For example DHCP and SLAAC would 
be address configuration mechanisms.  Is this kind of address assignment 
that you refer to when you say AUTOCONF is focusing on IPv6 address and 
prefix configuration?

And is it that prefixes exchanged by a protocol (and to be installed in 
one's routing table), thus not _assigned_ to a node, like OSPF would do, 
are out of scope in AUTOCONF?

Thanks,

Alex
PS:  Regardless of my problem proposal where prefixes are exchanged
      between routers (and not assigned to a router), I think
      self-derivation of an address (like IPv6 EUI64 or other link-layers
      and CGA/HBA) and DHCP prefix delegation should be mentioned in the
      problement statement draft because they're all means of assigning
      addresses and prefixes to nodes.

---

From: Shubhranshu <[email-masked]>
Date: Mon, 12 Mar 2007 16:45:06 +0530

Alex, 

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
> -there may be others if one looks harder.

Section 4.2 of the draft provides a brief text on prefix delegation, rfc 3633 although 
without specifically pointing to the RFC. Since you missed the point, it seems the
text needs further elaboration.
Other related drafts that you mentioned can be included as informative references 
but I think the Autoconf PS ID need not analyze them in its problem statement section.  

- Shubhranshu

---

From: Shubhranshu <[email-masked]>
Date: Mon, 12 Mar 2007 18:16:05 +0530

Please see inline comment.

----- Original Message ----- 
> Is an AUTOCONF or MANET existing solution draft addressing this problem

Yes, it would help to better understand if you could list those two drafts. 

Since in your scenario the two seperate car networks are connected via external 
inter-vehicular radio, it can be considered as a single MANET. Since it is a standalone MANET, 
I think It would be fine to allow these nodes to talk to each other using MANET local address
or ULA. Nodes can then run routing protocols such as OLSRv2, draft-ietf-manet-olsrv2 or
DYMO draft-ietf-manet-dymo.

- Shubhranshu