Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Feb 2006 14:03:54 -0800

I don't know if this is the correct forum, but below are
some comments on this draft:

Fred
[email-masked]

1) In introduction, add DYMO to list of IETF routing protocols.

2) Second to last paragraph of P.4, change: "whether they are
   reactive and proactive." to: "... reactive or proactive."

3) Final paragraph of P.4, this text seems to assume that
   internet-gateways maintain a roster of the addresses of
   nodes that reside within the MANET, e.g., so that packets
   destined to MANET nodes don't leak out into the Internet
   and so that ICMP redirects can be issued. This assumption
   needs to be made explicit somehow - both in this section
   and elsewhere throughout the document.

4) Top of P.6, the sentence: "The node therefore needs to obtain
   a global prefix owned and distributed by an internet-gateway."
   Is the intention here that a prefix must be owned by one
   and only one internet-gateway? Or, could the same prefix
   potentially be advertised by multiple gateways?

5) Bottom of P.6, change "two messages such as" to "two messages:".

6) Section 4.3, add a third message type "internet gateway
   confirmation". The purpose of this message is to provide
   a 3-way handshake between manet nodes and internet gateways
   under the following procedure:

    1. manet node sends "internet gateway solicitation" to
       multicast address
    2. Internet gateway(s) sends "internet gateway advertisement"
       to unicast address of manet node
    3. manet node sends "internet gateway confirmation" to
       unicast address of internet gateway(s)

   The "internet gateway confirm" message is needed to allow the
   internet gateway to construct a roster of the MANET nodes it
   serves. The roster is needed in order for the gateway to
   determine when redirects should be sent for intra-MANET
   communications.

7) P.11, second sentence beginning with: "Since the manet node is
   assumed to already have done Duplicate Address Detection (DAD),
   as defined in [11], for the link-local address", this does not
   seem to be a valid assumption since there is no way for the node
   to inquire throughout the entire MANET as to whether its link-local
   address is unique within the MANET. Suggest dropping the entire
   discussion on DAD and simply say "DAD is not in scope".

8) Section 5.5, change: "But it just stop sending..." to: "But it
   SHOULD stop sending...". Also, the rest of this first paragraph
   of section 5.5 seems poorly-worded and imprecise. Suggest either
   a re-write or just remove the text.

9) Section 6.1, second paragraph. Change: "When an internet-gateway..."
   to: "When a manet node...".

10) Section 7.3, the verification: "- If the hop limit field of the
    message is less than or equal to zero...", how is the "less than"
    check to be one (i.e., the hop-limit field is just an 8-bit
    unsigned integer). Suggest changing: "less than or equal to zero"
    to simply "equal to zero".

11) Section 7.3, final sentence (and section 7.4) the "global manet
    node list" spoken of here can only be unidirectional. If an
    "internet gateway confirm" message type is added (as per
    comment 6), the global manet node list can be made bi-directional.

12) Section 7.5, this entire section seems to assume that internet-
    gateways are assigned prefixes in 1x1 correspondence. As asked
    earlier, can more than one internet-gateway advertise the *same*
    prefix, i.e., can a prefix be co-owned by more than one gateway?
    If yes, then this section would require rewrites. If no, then
    why not?

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

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 02 Feb 2006 12:39:20 +0900

Hello Fred

Thanks for detailed comments.
Please find my reply in-line.

At Wed, 1 Feb 2006 14:03:54 -0800,
>    and elsewhere throughout the document.

Right. However, there are several scenarios.
1. MN has only a topology correct address from IGW.
2. MN has a topology correct address and an own address such as HoA.
Only in the case 2, we need such assumption.
IGW can filter the packets easily with prefix comparison for the case-1.

We may drop this assumption.  When the destination node is in the same
MANET, but the packet need to go through HA, this roster based
filtering breaks this scenario.

This feature is just an optimization to directly route the packet
meant for a MN located in the same MANET.

BTW, roster is good word:-) I didn't come up with this word. thanks.

>    potentially be advertised by multiple gateways?

We don't think such limitation. Multiple IGW can advertise the same
prefix.

>    determine when redirects should be sent for intra-MANET

agree with the third message for the roster management.

>    discussion on DAD and simply say "DAD is not in scope".

agree for the link-local address DAD. However, the IGW may help DAD
operation because it has a roster of the MANET nodes. IGW easily
detects the duplication.

>     to simply "equal to zero".

OK. I'll fix these in the next revision.

>     comment 6), the global manet node list can be made bi-directional.

right.

I want to ask you whether we should keep the roster management in the spec.
Roster brings several optimization such as filtering packets and
helping DAD, but, on the other hand, it cause certain burden to MN and
IGW.
In addition, if we consider multiple IGW serving a same prefix, we
need some the roster sync between gateways.

>     If yes, then this section would require rewrites. If no, then

Right. We don't need the assumption.  To support multiple IGWs, we
need to drop the roster management or put the roster sync between IGWs.

thanks,
ryuji

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Feb 2006 13:14:32 +0200

>    If yes, then this section would require rewrites. If no, then
Good question. If we look at this from an IP perspective,
having the same prefix on two gateways is possible, but
it requires those gateways to share a common link
where, e.g., neighbor discovery can occur.

But the main question is whether the MANET-specific
parts can use multiple gateways or not. I guess the
answer to that depends at least on whether the gateways
can stay in sync. For instance, if the MANET hosts behind
a gateway look exactly like other hosts connected
to the gateways, then the usual RFC 2461-2463
mechanisms appear to be sufficient for hosts to
talk to each other even if they are on another
gateway, verify address uniqueness, etc.

--Jari

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 02 Feb 2006 21:03:49 +0900

In addition, current draft is still missing of how DNS Server can be
configured on the manet node from the global connectivity point of
view. Perhaps, Ryuji remembers what I am indicating because I did
raise this concern before. Obtaining DNS Server address is an 
essential part of manet global connectivity, so one option SHOULD
be attached to the RA option along with Prefix option. You can refer
to the related work below; 
http://www.watersprings.org/pub/id/draft-daniel-manet-dns-discovery-globalv6-00.txt
http://www.watersprings.org/pub/id/draft-jeong-dnsop-ipv6-dns-discovery-08.txt

Thanks, 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 02, 2006 7:03 AM
Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt

Fred

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Feb 2006 16:11:41 +0200

Yes, DNS server is needed too, assuming we have
global connectivity. But we may also need other
information, such as NTP servers, local SIP servers
etc. I wonder if there is a way to somehow use DHCP
in this context so that we wouldn't need to invent
all those options again.

--Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 02 Feb 2006 09:42:43 -0800

Hello folks,

I've not read all of the emails, but this one
caught my eye.

> in this context so that we wouldn't need to invent

Wouldn't it make sense to run the gateway as a
sort of DHCP relay?

But I would think that would be a separate draft.
The functions are separable.  Plus, such a scheme
has to avoid conflicting with the useful possibility that
DNS and SIP are present in the manet.  Presumably,
the local services would be preferred over the
infrastructure services in many or most cases.

Regards,
Charlie P.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 02 Feb 2006 12:59:10 -0500

Jari - you could either run a DHCP server providing configuration
information (as in RFC 3736) on the network element issuing the RAs or a
DHCP relay forwarding to a server on another host.  Either way, use of DHCP
would leverage re-use of all the existing configuration options...

- Ralph

>> http://www.watersprings.org/pub/id/draft-daniel-manet-dns-discovery-globalv6-
http://www.watersprings.org/pub/id/draft-jeong-dnsop-ipv6-dns-discovery-08.tx>>
t

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 03 Feb 2006 09:13:10 +0900

I was saying that DNS option should be included into the 
manet RA message while modifying it to be adopted to the
at least *mobile* adhoc environment. NTP, SIP and others 
can be also considered simuntaneously, but I believe DNS 
is most preferable information from the autoconf point of view. 
Others can be deliveried using DHCP whenever necessary.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Feb 2006 15:49:43 +0200

> Wouldn't it make sense to run the gateway as a

Sounds reasonable to me.

> The functions are separable. 

I like separation. Perhaps what we are after here is
making a model for the Manet - Internet connection
that enables such separation. That is, just make the
smallest possible function that can provide communication
capability from the manet nodes to the gateway, and
then use that capability to build things like the
DHCP relay.

> Plus, such a scheme
> DNS and SIP are present in the manet.  

Ack.

--Jari

---

From: "Joe Macker" <[email-masked]>
Date: Fri, 3 Feb 2006 12:12:45 -0500

Can someone help me with recent background on this thread?
We have been running DHCP relay type functionality for years in manet.
I gave a few high level briefing in older manet minutes.
In many scenario (connected ones) this approach works fine.  There are
remaining engineering questions of how relay agents can and should operate
in a MANET.

What documents presently discuss related work for stateful or hybrid
stateless/stateful. Say using the DHCP only to configure stateful things
other than address.  Also there are some engineering discussions that could
take place when considering unicast vs. multicast support of the signaling.

-joe

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Jari Arkko
>Sent: Friday, February 03, 2006 8:50 AM
>To: Charles E. Perkins
>Cc: [email-masked]
>> Wouldn't it make sense to run the gateway as a sort of DHCP relay?
>
>Sounds reasonable to me.
>
>I like separation. Perhaps what we are after here is making a 
>model for the Manet - Internet connection that enables such 
>separation. That is, just make the smallest possible function 
>that can provide communication capability from the manet nodes 
>to the gateway, and then use that capability to build things 
>like the DHCP relay.
>
>> Plus, such a scheme

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Feb 2006 09:18:29 -0800

Hello Joe,

>I gave a few high level briefing in older manet minutes.
For those of us with short memories, could you provide URLs
into the pages the IETF proceedings?

>In many scenario (connected ones) this approach works fine.
>
Of this, I have no doubt.  Using a gateway as a DHCP relay, or configuring
a well connected manet node as a DHCP server, seems pretty workable.

But, what about scenarios where there isn't any preconfigured DHCP
server or gateway?  Do you have solutions for that?  If the solutions
were in your previous presentations, oops sorry I missed that.

Regards,
Charlie P.

---

From: "Joe Macker" <[email-masked]>
Date: Fri, 3 Feb 2006 12:31:14 -0500

It was discussed publicly twice. There was a short presentation at the
Vienna IETF.
If it isnt in the proceedings I can forward it.

It is also discussed breif;y as a testing example in the following mobile
emulator paper.
We used the emulator to test multiple hop MANET configuration with DHCP
relay agent functionality.  This work strived to be independent from a
particular unicast routing protocol.
Once its only applicable for a connected scenario.  In doing this work we
realized future things that we would like to improve. So I am interested in
having more discussion with other parties that may be working in this area.

Macker J.P., J. Weston, W. Chao. " A Low Cost IP-based Mobile Network
Emulator", IEEE Milcom 2003 Proceedings, Oct 2003.

>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Friday, February 03, 2006 12:18 PM
>To: Joe Macker
>Cc: [email-masked]
>Of this, I have no doubt.  Using a gateway as a DHCP relay, or 
>configuring a well connected manet node as a DHCP server, 
>seems pretty workable.
>
>But, what about scenarios where there isn't any preconfigured 
>DHCP server or gateway?  Do you have solutions for that?  If 
>the solutions were in your previous presentations, oops sorry 
>I missed that.
>
>Regards,
>Charlie P.
>
>

---

From: "Joe Macker" <[email-masked]>
Date: Fri, 3 Feb 2006 12:45:17 -0500

>the solutions were in your previous presentations, oops sorry 
Charlie/All:

Sent a separate note on previous work reference. Some of this was IPv4 work
and some limited IPv6 work was done as well.  The approach does do some
limited gatway discovery (if that is what you mean by preconfigured?) but I
believe the larger answer with distributed, fragmented, or self-election
involves taking advantage of anycast or SMF/SMURF multicast work to enable
more distributed/efficent adaptation and service discovery.  of course, this
goes beyond DHCP.. Hopefully that is one way to provide some separation in
technique specification that is more general yet practical.  

For a single server type scenarios the unicast type relay agent approach may
be more efficient. I think more examples and scenarios need to be looked at
here.

-Joe

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 6 Feb 2006 08:53:09 +0900

Hi  all

I basically agree on using existing approaches as many as possible  
for connected-manet.
However, manet is multi-hop networks and some of signaling may be  
multi-hopped.
If a node is capable of being both a manet node and IPv6 node, it  
must operate the protocol carefully.
If a node attaches to a legacy IPv6 link and starts sending  a DHCP  
server solicitation,
a NS, and a RS over multihop, it will be messed up.

We needs certain modifications to these protocols for manet and
an DNA!? mechanism to detect whether the attached link is manet or not.

regards,
ryuji

On 2006/02/03, at 2:59, Ralph Droms wrote:

>>> http://www.watersprings.org/pub/id/draft-daniel-manet-dns- 
>>> discovery-globalv6-
>>> 00.txt
>>>

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 08 Feb 2006 12:40:08 +0100

Hi Ryuji,

See some comments and self-publicity below.

Regards,
Christophe

Ryuji Wakikawa wrote:
> Hi  all
> 
> I basically agree on using existing approaches as many as possible  for 
> connected-manet.
> If a node is capable of being both a manet node and IPv6 node, it  must 
> operate the protocol carefully.

Well such messages can be "captured" and handled in a clever way. For 
example the underlay nature of LUNARng (see http://core.it.uu.se/adhoc/) 
allows a node to perform a "MANET-specific handling" of such messages. 
For example, DHCP/RS requests are captured, autoconf is performed and 
faked DHCP/RA replies are generated back to the application (dhcp 
client) or IP layer (IPv6 SAA).

Interested readers can have a look at our paper describing this "Model 
Based Protocol Fusion for MANET-Internet Integration" here:

    http://cn.cs.unibas.ch/pub/doc/2006-Wons.pdf

> an DNA!? mechanism to detect whether the attached link is manet or not.

We have alrady had some debate about this (threads around 02/25/05) and 
I remember a clear issue was "how" and "who" should perform such a 
"detection". I agree there is quite some room here to enable some sort 
of a "MANET-aware" node behavior.