Subject: [Autoconf] Global Connectivity: Doubts

From: Alicia Triviño <[email-masked]>
Date: Wed, 07 Mar 2007 08:53:00 +0100

Hello:

I have several doubts related to the "Global 
connectivity for IPv6 Mobile Ad Hoc Networks" 
(draft-wakikawa-manet-globalv6-05.txt)  that 
integrates mobile ad hoc networks into the Internet.

- The validity of entries in the Internet Gateway 
list and in the Internet Gateway Prefix List is 
derived from the IGWADV-N. Which field is used 
for this purpose? The “Reachable Time”?  (I think 
that the “Router Lifetime” could not be used as 
it is set to 0 when NDP extensions are employed).

- Should not the "Router Lifetime" include 
information about the validity of the routing 
information in both cases:IGWADV-N or IGWADV-M ?

- In the IGWADV-N format, the M (Managed Address 
Autoconfiguration) bit is suppressed although it 
is present in the RA messages (NDP specifications). Why is this bit suppressed?

Any help?

Thanks in advance,

Alicia Triviño                               / Tl. +34-95.213.71.91
Dpto. Tecnologia Electronica
E.T.S. Ing. Telecomunicacion
Universidad de Malaga
Campus Universitario de Teatinos
29071 Malaga, Spain

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

---

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

---

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
>
>manet mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/manet
>

---

From: Alicia Triviño <[email-masked]>
Date: Fri, 09 Mar 2007 11:19:59 +0100

Hi all,

I think that there is one issue that has not been 
considered in the draft. Analyzing the proposed 
mechanisms for integrating MANET into the 
Internet, there are two possible implementations for the Internet Gateway:

- previously installed in those scenarii where 
MANET are expected to be connected to the Internet [1] [2].

- non-dedicated gateways. In those scenarii where 
only a ISP Edge Router is installed, a MANET node 
can autoconfigure itself to act as the Internet Gateway [3].

Maybe it will be interesting to include this point.

Best Regards,

Alicia Triviño

[1] R. Wakikawa, J. T. Malinen, C. E. Perkins, A. 
Nilsson, A. J. Tuominen, “Global Connectivity for 
IPv6 Mobile Ad Hoc Networks”, 
draft-wakikawa-manet-globalv6-05.txt, Internet 
Draft, Internet Engineering Task Force, March, 2006

[2] C. Jelger, T. Noel, A. Frey, "Gateway and 
address autoconfiguration for IPv6 adhoc 
networks", 
draft-jelger-manet-gateway-autoconf-v6-02.txt, 
Internet Draft, Internet Engineering Task Force, April 2004.

[3]  S. Singh, J.H. Kim, Y.G. Choi, Y.S. Roh, " 
Mobile multi-gateway support for IPv6 mobile ad 
hoc networks",  draft-singh-manet-mmg-00.txt, 
Internet Draft, Internet Engineering Task Force, June 2004.

At 14:20 07/03/2007, you wrote:
>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: Jean Lorchat <[email-masked]>
Date: Fri, 09 Mar 2007 21:56:35 +0900

Hi Alex,

> 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 ?

> 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.
You even don't have to solicit the prefix information).

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

At least OLSRv2 does. OLSR(v1) has support for "Host Network Attachment"
but I think they only accomodate IPv4 prefixes.

Hope this helps,
Jean

---

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.
> 

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).
> 
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:15:44 +0100

Alicia,

the problem statement makes the difference between 2 categorie of 
scenarii: (i) connected MANET and (ii) standalone MANET. Conceptually, 
the difference made is whether or not you may have access (possibly 
through several hops) to a "traditional" server. So the sub-scenarii you 
are pointing out are covered, since they address adding more hops to 
reach the Edge Router.

Emmanuel

Alicia Triviño a écrit :
> Hi all,
> 
> I think that there is one issue that has not been considered in the 
> draft. Analyzing the proposed mechanisms for integrating MANET into the 
> - previously installed in those scenarii where MANET are expected to be 
> connected to the Internet [1] [2].
> 
> - non-dedicated gateways. In those scenarii where only a ISP Edge Router 
> is installed, a MANET node can autoconfigure itself to act as the 
> Internet Gateway [3].
> 
> [1] R. Wakikawa, J. T. Malinen, C. E. Perkins, A. Nilsson, A. J. 
> Tuominen, “Global Connectivity for IPv6 Mobile Ad Hoc Networks”, 
> draft-wakikawa-manet-globalv6-05.txt, Internet Draft, Internet 
> Engineering Task Force, March, 2006
> 
> [2] C. Jelger, T. Noel, A. Frey, "Gateway and address autoconfiguration 
> for IPv6 adhoc networks", draft-jelger-manet-gateway-autoconf-v6-02.txt, 
> [3]  S. Singh, J.H. Kim, Y.G. Choi, Y.S. Roh, " Mobile multi-gateway 
> support for IPv6 mobile ad hoc networks",  draft-singh-manet-mmg-00.txt,

---

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: Jean Lorchat <[email-masked]>
Date: Sat, 10 Mar 2007 13:17:28 +0900

Hi Alex,

> address?  A unicast address?

The destination address is called ALL-MANET-NEIGHBORS and is "a
well-known link local multicast address" to be assigned (see NHDP draft,
section 13.1)

> in this multicast group before receiving a TC from another router, no?

Since it is the multicast address for all MANET neighbors, if the router
is participating in the MANET, it has already subscribed to this group.

> needs a quick response and the sender's timer is too long.

I can see your point. But since we are talking about OLSRv2 here, and
given it is a proactive protocol, I don't know if there is such a
mechanism as solicitation for TCs. Maybe an OLSRv2 author could provide
more insight ?

> a form of unreachability detection or test or similar mechanism?

OLSR's Proactive nature warrants that if another MR is reachable, then
the information is available locally (in a set of received information).
Of course this information has a validity time associated that is taking
care of the unreachability detection. In any case, MRs must advertise
their prefix (even if no one is interested).

This said, I highly recommend reading OLSRv2 and related drafts (i.e.
packetbb, nhdp, olsrv2) ;-)

Happy reading,

Jean

---

From: Alicia Triviño <[email-masked]>
Date: Sat, 10 Mar 2007 10:57:28 +0100

Hi all,

I did not explain myself clearly in my previous 
mail. I think that in the scenarii represented in 
Fig.1 (multihop connected MANETs), there could be 
two different types of gateways:

* Dedicated gateway: A specific device that is 
previously installed in those scenarii where 
MANETs are expected to be integrated into the Internet [1] [2].

* Non-dedicated Gateway: A Mobile Router in the 
MANET temporally and dynamically configures 
itself in order to behave as the Internet Gateway [3].

Best Regards,

                                                        ----- MR1...MR3
                                                       /      .
               +-------------+         +------------+ /       .
               |             |   p2p   |            |/        .
               |  ISP Edge   |   Link  | Internet   |         .
               |   Router    +---------+  gateway   |\        .
               |             |         |            | \       .
               +-------------+         +------------+  \----- MR2

                        Fig. 1. Connected MANET router topology

At 15:15 09/03/2007, you wrote:
>Alicia,
>
>the problem statement makes the difference 
>between 2 categorie of scenarii: (i) connected 
>MANET and (ii) standalone MANET. Conceptually, 
>the difference made is whether or not you may 
>have access (possibly through several hops) to a 
>"traditional" server. So the sub-scenarii you 
>are pointing out are covered, since they address 
>adding more hops to reach the Edge Router.
>
>Emmanuel
>
>Alicia Triviño a écrit :
>>Hi all,
>>I think that there is one issue that has not 
>>been considered in the draft. Analyzing the 
>>proposed mechanisms for integrating MANET into 
>>the Internet, there are two possible implementations for the Internet Gateway:
>>- non-dedicated gateways. In those scenarii 
>>where only a ISP Edge Router is installed, a 
>>MANET node can autoconfigure itself to act as the Internet Gateway [3].
>>[1] R. Wakikawa, J. T. Malinen, C. E. Perkins, 
>>A. Nilsson, A. J. Tuominen, “Global 
>>Connectivity for IPv6 Mobile Ad Hoc Networks”, 
>>>Autoconf mailing list to prepare the 
>>>forthcoming working group meeting in Prague.
>>>
>>>Cheers
>>>Emmanuel
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Mar 2007 16:29:49 +0100

> well-known link local multicast address" to be assigned (see NHDP draft,

Makes sense.

> is participating in the MANET, it has already subscribed to this group.

Right, but a router has two ways of joining a group, either with MLD or 
with a multicast routing protocol.  I have to figure out which OLSRv2 uses.

> packetbb, nhdp, olsrv2) ;-)

Thanks, I'll have to read that.  I understand OLSRv2 has a proactive 
nature.  If this nature forbids it to solicit TC then makes sense.

I think (after looking at AUTOCONF WG Charter) that discussing OLSRv2 
shouldn't happen here so I'll post OSLRv2 questions in the MANET WG later.

Alex

---

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

If  are saying that the draft needs to point to the types of gateways 
(mobile, fixed, single/multiple) and any related issues due to that then 
I agree. As for example if the gateways are mobile/multiple then the default
gateway, routing header (as used in ref [3] that you mentioned) and the 
advertised prefix may get invalidated with time. However, a dedicated gateway 
would provide a more stable route to the destination on the Internet. I think 
those points which relates to the Autoconf has been addressed in section 
"Gateway Related Issues". Perhaps the draft could provide a bit more detail ?

- Shubhranshu
  ----- Original Message ----- 
  From: Alicia Triviño 
  To: [email-masked] 
  Sent: Saturday, March 10, 2007 3:27 PM
  Subject: Re: [Autoconf] Autoconf Problem Statement

  Hi all,

  I did not explain myself clearly in my previous mail. I think that in the scenarii represented in Fig.1 (multihop connected MANETs), there could be two different types of gateways:

  * Dedicated gateway: A specific device that is previously installed in those scenarii where MANETs are expected to be integrated into the Internet [1] [2]. 

  * Non-dedicated Gateway: A Mobile Router in the MANET temporally and dynamically configures itself in order to behave as the Internet Gateway [3]. 

  Best Regards,

----- MR1...MR3
                                                     
/      .
             
+-------------+        
+------------+ /       .
             
|            
|   p2p  
|           
|/        .
             
|  ISP Edge   |   Link  |
Internet   |         .
             
|   Router    +---------+ 
gateway   |\        .
             
|            
|        
|            |
\       .
             
+-------------+        
+------------+  \----- MR2

    the problem statement makes the difference between 2 categorie of scenarii: (i) connected MANET and (ii) standalone MANET. Conceptually, the difference made is whether or not you may have access (possibly through several hops) to a "traditional" server. So the sub-scenarii you are pointing out are covered, since they address adding more hops to reach the Edge Router.

    Emmanuel

    Alicia Triviño a écrit :

      Hi all,
      I think that there is one issue that has not been considered in the draft. Analyzing the proposed mechanisms for integrating MANET into the Internet, there are two possible implementations for the Internet Gateway:
      - previously installed in those scenarii where MANET are expected to be connected to the Internet [1] [2].
      - non-dedicated gateways. In those scenarii where only a ISP Edge Router is installed, a MANET node can autoconfigure itself to act as the Internet Gateway [3].
      Maybe it will be interesting to include this point.
      Best Regards,
      Alicia Triviño

      [1] R. Wakikawa, J. T. Malinen, C. E. Perkins, A. Nilsson, A. J. Tuominen, "Global Connectivity for IPv6 Mobile Ad Hoc Networks", draft-wakikawa-manet-globalv6-05.txt, Internet Draft, Internet Engineering Task Force, March, 2006
      [2] C. Jelger, T. Noel, A. Frey, "Gateway and address autoconfiguration for IPv6 adhoc networks", draft-jelger-manet-gateway-autoconf-v6-02.txt, Internet Draft, Internet Engineering Task Force, April 2004.
      [3]  S. Singh, J.H. Kim, Y.G. Choi, Y.S. Roh, " Mobile multi-gateway support for IPv6 mobile ad hoc networks",  draft-singh-manet-mmg-00.txt, Internet Draft, Internet Engineering Task Force, June 2004.

        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: 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

---

From: "Simone Ruffino" <[email-masked]>
Date: Mon, 12 Mar 2007 18:24:19 +0100

Hi Alicia,

I think we included some statements for what I call "opportunistic 
gateways" (for example, MANET routers that become gateways after they 
activates a non-MANET interface to connect with an "outside" network) in 
one of the first versions of the PS draft.

We subsequently decided not to describe all the possible Gateway 
variants, but, instead, to describe the two states a MANET can find 
itself into: non-connected and connected. From the point of view of 
autoconf, i.e. from the point of view of address assignment and prefix 
delegation, it makes no difference, if the MANET is connected to the 
Internet via a temporary highly-dynamic gateway or via a fixed managed 
gateway.
The requirements are in fact the same: the configuration process must 
complete in a small amount of time and it must react to topological 
changes as quickly as possible.

Regs,
Simone
p.s.
<sponsor_mode>You could maybe find useful to also have a look at 
draft-ruffino-manet-autoconf-multigw-03, which was designed with very 
dynamic scenarios in mind, where gateways are mostly opportunistic. 
Unfortunately, it still assumes a multi-link subnet model...:-( 
</sponsor_mode>

Alicia Triviño wrote:
> Hi all,
>
> I did not explain myself clearly in my previous mail. I think that in 
> the scenarii represented in Fig.1 (multihop connected MANETs), there 
> could be two different types of gateways:
>
> * Dedicated gateway: A specific device that is previously installed in 
> those scenarii where MANETs are expected to be integrated into the 
> Internet [1] [2].
>
> * Non-dedicated Gateway: A Mobile Router in the MANET temporally and 
> dynamically configures itself in order to behave as the Internet 
> Gateway [3].
>
> Best Regards,
>
>                                                       
> ----- MR1...MR3
>                                                      
> /      .
>              
> +-------------+        
> +------------+ /       .
>              
> |            
> |   p2p  
> |           
> |/        .
>              
> |  ISP Edge   |   Link  |
> Internet   |         .
>              
> |   Router    +---------+ 
> gateway   |\        .
>              
> |            
> |        
> |            |
> \       .
>              
> +-------------+        
>> scenarii: (i) connected MANET and (ii) standalone MANET. 
>> Conceptually, the difference made is whether or not you may have 
>> access (possibly through several hops) to a "traditional" server. So 
>> the sub-scenarii you are pointing out are covered, since they address 
>>> draft. Analyzing the proposed mechanisms for integrating MANET into 
>>> - non-dedicated gateways. In those scenarii where only a ISP Edge 
>>> Router is installed, a MANET node can autoconfigure itself to act as 
>>> the Internet Gateway [3].
>>> [2] C. Jelger, T. Noel, A. Frey, "Gateway and address 
>>> autoconfiguration for IPv6 adhoc networks", 
>>> draft-jelger-manet-gateway-autoconf-v6-02.txt, Internet Draft, 
>>> Internet Engineering Task Force, April 2004.
>>> support for IPv6 mobile ad hoc networks", 
>>> draft-singh-manet-mmg-00.txt, Internet Draft, Internet Engineering 
>>> Task Force, June 2004.
>>>
> ------------------------------------------------------------------------
>
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------