Subject: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt

From: [email-masked]
Date: Mon, 19 Nov 2007 06:10:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF.

	Title           : Address Autoconfiguration for MANET: Terminology and Problem Statement
	Author(s)       : E. Baccelli, et al.
	Filename        : draft-ietf-autoconf-statement-02.txt
	Pages           : 19
	Date            : 2007-11-19

Traditional dynamic IPv6 address assignment solutions are not adapted
to mobile ad hoc networks.  This document elaborates on this problem,
states the need for new solutions, and requirements to these
solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statement-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-autoconf-statement-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-autoconf-statement-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Nov 2007 15:33:31 +0100

Thanks to the authors for this new draft.

I have the following comments.

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. This draft is a work item of the Ad-Hoc Network 
> Autoconfiguration Working Group of the IETF.
> 
> 
> Title           : Address Autoconfiguration for MANET: Terminology 
> and Problem Statement Author(s)       : E. Baccelli, et al. Filename
>  : draft-ietf-autoconf-statement-02.txt Pages           : 19 Date : 
> 2007-11-19
> 
>  to mobile ad hoc networks.  This document elaborates on this 
> problem, states the need for new solutions, and requirements to these
>  solutions.
> 
[...]
>  Standard automatic IPv6 address assignment and prefix delegation 
> solutions [5][RFC4862 stateless autoconf], [3][RFC4861 ND] 
> [4][RFC3315 DHCPv6] do not work "as-is" on MANETs

Thanks for mentioning these RFCs. Please also refer to the reference
[18] (RFC3633 IPv6 Prefix Options for DHCPv6) that you already added,
thanks.

> Global prefix  - An IP prefix delegated to a MANET router, consisting
>  in chunks of IP addresses valid for communications reaching outside 
> the MANET (as well as communications within the MANET). [...] Prefix
> delegation  - The process of providing a router with a set of 
> contiguous addresses it may manage for the purpose of configuring 
> interfaces or other routers.

These two paragraphs being defining paragraphs: I think they should
mention their relationship to DHCPv6 Prefix Delegation (RFC3633 and
RFC3769) because they use precisely the same term "prefix delegation"
but with a slightly different meaning.

 From reading this autoconf-statement-02 draft I mainly understand that
you mean "prefix delegation" as some generic mechanisms to assign a
prefix to a router, maybe some administrative out-of-band means too. Or,
RFC3633 and RFC3769 and a bunch of other mobility-related drafts use
"prefix delegation" to mean DHCPv6-PD.

If would personally avoid the use of "prefix delegation" as the generic
means, because it's easily confusable with DHCPv6-PD. But your reading
may be different. If so, it would be clearer to clarify the relationship
with DHCPv6-PD.

For example, what does this mean:
> Automatic configuration of IP addresses on MANET interfaces and 
> prefix delegation to MANET routers are necessary in a number of 
> deployment scenarios.

Does it mean that some generic mechanism to assign prefixes to routers
is needed? Or does it mean that DHCPv6-PD is needed? That's why the
definitions above would benefit from clarifying.

> Traditional solutions assume that a broadcast directly reaches every 
> router or host on the subnetwork, whereas this generally is not the 
> case in MANETs (see [2]).

If you want to define 'MANETs' to be such that broadcast don't directly
reaches every router or host on the subnetwork then you have a problem
defining MANET. Please redefine MANET such link-layer broadcast reaches
all hosts and routers on that link.

Most wireless link-layers have a very well defined broadcast property.
If in some MANET cases that broadcast property is not maintained then
the MANET should be redefined such that the broadcast property is respected.

For example, if in WiFi host A sees B, B sees C but C doesn't see A then
please don't configure A, B and C in the IP same subnet. Please
configure them as two different subnets one for A and B and the other
for B and C and B as a router.

> Some routers in the MANET will typically assume multihop broadcast, 
> and expect to receive through several intermediate relayings by peer
>  MANET routers.

What's the scenario and requirements for multihop broadcast? Would IP
multicast work ok instead of multihop broadcast?

> While stateless protocols such as [5] and [3] could provide IP 
> address configuration (for MANET interfaces, loopback interfaces), 
> these solutions do not provide any mechanism for allocating "unique 
> prefix(es)" to routers in order to enable the configuration of host 
> interfaces.

YEs, but stateful DHCP Prefix Delegation does provide a mechanism for
allocating unique prefixes to routers in order to enable configuration
of hosts interfaces. I think it makes sense to actually use reference
[18] that you inserted. Maybe use it here.

> A MANET router needs to configure IP addresses and prefixes as usual,
>  on its non-MANET interfaces as well as its attached hosts and 
> routers, if any.

I'm not sure I understand this statement ok. I understand MANET router
needing to configure IP addresses for itself (and we already have a
problem here because other than DHCPv6-PD and NEMO MRs other routers
don't know how to auto-configure addresses).

Do you mean that the MANET router needs to configure addresses to the
attached hosts too? Or that the hosts need also to configure IP addresses?

I'm afraid that saying that the router configures an address on the host
it may be very different than existing stateless and stateful
autoconfig. Because in stateless the router puts a prefix in the RA but
the host configures the address and in stateful the router may send an
address but the host configures it.

If I think DHCPv6-PD then I can say that the text should say:

"The MANET Router should help and assist the host to auto-configure its
(host's) address."

Or similar, but I don't know what you really meant to say with that?

> For example, in Fig.
>    1, the MANET router MR3 cannot communicate directly with a DHCP
>    server [4] that would be available through a MANET border router,
>    since the server and the MANET router are not located on the same
>    logical link.  While DHCP can to some extent overcome this issue in a
>    static network, it is not the case in a dynamic topology, as
>    explained below.
>                                                        ----- MR1...MR3
>                                                       /      .
>               +-------------+         +------------+ /       .
>               |             |   p2p   |  MANET     |/        .
>               |  ISP Edge   |   Link  |  Border    |         .
>               |   Router    +---------+  Router    |\        .
>               |             |         |            | \       .
>               +-------------+         +------------+  \----- MR2
> 
>                        Fig. 1. Connected MANET router topology.

I think there may be some confusions here.

You're saying the MR3 can not communicate directly with the DHCP Server
(the "ISP Edge Router" presumably). If they're not on the same subnet
then they don't need to communicate directly. The last-hop MANET Router
(presumably the non-illustrated MR2) would play the role of a Relay and
the Relay would unicast the messaging to the DHCP Server (presumably the
ISP Edge Router).

Then you're saying that this may work in the static case but not in a
dynamic topology. For one thing I'd like to say that there are many
MANET-like situations where the hosts and routers are stable. Rescue
scene is one of them. Are these ruled out from the AUTOCONF WG?

Then, if we accept that the above network is dynamic (and we rule out
the class of fixed scenes) then one wonders - what moves more precisely?
Are the DHCP Server and the Border ROuter fixed entities and only the
MRs move? Can we specify this?

Then, if we accept that only the MANET MRs move then the DHCP problem
turns into a problem of MR2 (the DHCP Relay) disappearing and maybe
another MR (another DHCP Relay) take its place. Which DHCP Relay is
active? How can the MR3 discover the Relay? Can it simply multicast a
DHCPv6 Solicit message taking advantage of the underlying well-defined
multicast behaviour? I think it can.

If not all these issues I described above - then what DHCP issues do you
see?

Alex

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

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 20 Nov 2007 15:28:44 +0100

Hi Alex,
thanks for your feedback,

Alexandru Petrescu a écrit :
>> Automatic configuration of IP addresses on MANET interfaces and prefix 
>> delegation to MANET routers are necessary in a number of deployment 
>> scenarios.
> 

What would you suggest we use to replace the generic terms "prefix 
delegation". I didn't know it was such DHCP tainted. I though it was 
just a generic term, at the base of Internet addressing schemes.

> all hosts and routers on that link.

I think you sould read the architecture document ;) We are not defining 
MANETs in the PS, we are mentioning their properties in reality, and why 
you get new issues due to these specific properties.

>> While stateless protocols such as [5] and [3] could provide IP address 
>> configuration (for MANET interfaces, loopback interfaces), these 
>> solutions do not provide any mechanism for allocating "unique 

OK

> Or similar, but I don't know what you really meant to say with that?

Again, I suggest you take another look at the architecture document. 
Hosts and routers attached to the MANET router via a non-MANET interface 
behave like "classical IP" with usual protocols. What we are discussing 
is what happens on MANET interfaces, between MANET routers.

> scene is one of them. Are these ruled out from the AUTOCONF WG?

No this is not ruled out. But neither is the case where MANET routers 
move around.

> MRs move? Can we specify this?

Potentially every entity can move relatively to another. I think this is 
clearly stated in many places in the draft.

> multicast behaviour? I think it can.

Once again, there is no such "underlying well-defined multicast 
behaviour". Read the architecture draft.

Cheers
Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 15:55:03 +0100

Hi Emmanuel, thanks for the mail.

> just a generic term, at the base of Internet addressing schemes.

I was thinking maybe something like 'admninistratively assigned by a 
human network planner' or maybe 'statically and manually configured' 
depending on context.  Other people may use different?

> you get new issues due to these specific properties.

I've read it, commented on it in the MANET WG and didn't get anybody to 
share that view.

> is what happens on MANET interfaces, between MANET routers.

So it's been decided that a MANET router will configure an address for 
the MANET host?  This is what I understand when I read "A MANET router 
needs to configure IP addresses and prefixes as usual, on its non-MANET 
interfaces as well as its attached hosts and routers, if any."

I thought maybe a MANET router can just deliver a prefix in the RA and 
the MANET host will configure its address.  Or via some DAD-like mechanism.

Is it already decided that the MANET router configures an address and 
gives it to the MANET host somehow?  Sorry if I miss something.

> No this is not ruled out.

Ok.

> But neither is the case where MANET routers move around.

Ok.  But how do the MANET routers move around?

Also, in Figure1 above the ISP Edge Router and MANET Border Router don't 
move?  Or does the MANET Border Router move?

> clearly stated in many places in the draft.

Yes, it is.  But if we don't know _how_ do they move around and _how_ do 
they move with respect to their wireless link layer capabilities then it 
is completely uncapable to be dealt with.

For example, if we knew that each MR will never get out of the 
link-layer's wifi range, or that when it gets out of the wifi range it 
must auto-configure an address...  Or similar things.

If we just say that they 'move' then it is no indication for a problem 
or protocol.  Routers can move and there's simply to problem to be solved.

> behaviour". Read the architecture draft.

I think you're right.  The autoconf-manetarch does seem to take into 
account the underlying well-defined multicast behaviour I'm talking about:
>    Link-local Multicast/Broadcast Scope
>       On a MANET interface, a packet sent to a link-local multicast or
>       all-ones broadcast address reaches the MANET interfaces of
>       neighboring MANET routers, regardless of their configured
>       addresses.

That is what I meant ^.  In the Fig.1 scenario above the MR3 will send 
an IP message to network-layer multicast address which will have a 
link-layer header link-local multicast destination address, the 
MR2-Relay will IP-unicast it to the Server.

I think this scheme can accommodate the Figure1 above.  But if you're 
just saying that things will move around then it will not work - no 
other thing will work either, risking maybe in the worst the case that 
even the new protocol one is about to design for AUTOCONF WG will 
probably not work when routers move around.

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 20 Nov 2007 18:59:02 +0100

> depending on context.  Other people may use different?

Well, it may be done automatically too right? So I'm afraid what you 
propose is not approriate...

>> I think you sould read the architecture document ;) We are not 
>> defining MANETs in the PS, we are mentioning their properties in 
>> reality, and why you get new issues due to these specific properties.
> 

Sorry that you feel so alone ;)

>> Hosts and routers attached to the MANET router via a non-MANET 
>> interface behave like "classical IP" with usual protocols. What we are 
>> discussing is what happens on MANET interfaces, between MANET routers.
> 

For now there is no such thing as a "MANET host" defined anywhere... 
Look again.

> move?  Or does the MANET Border Router move?

Can you tell me the difference from the point of view of the MANET? 
There is relative mobility, that's enough to have some unsolved issues 
here. But it is true that in general MANET routers are more likely to be 
mobile than ISP edge routers ;)

>> Potentially every entity can move relatively to another. I think this 
>> is clearly stated in many places in the draft.
> 

As to how they move, well I don't know. Do you want to describe every 
mobility model? Good luck ;) But one thing is sure: they are not assumed 
to be limited by the same wifi range.

> MR2-Relay will IP-unicast it to the Server.

I think there is a misunderstanding here. Maybe there will be at some 
point a protocol that will relay some messages in order to reach the 
server. But there is none for now. So you do not have the behaviour that 
you describe, and among other things this is why there is a problem!

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 20:34:28 +0100

Emmanuel Baccelli wrote:

>>> What would you suggest we use to replace the generic terms 
>>> "prefix delegation". I didn't know it was such DHCP tainted. I 
>>> though it was just a generic term, at the base of Internet 
>>> addressing schemes.
>> 
>> I was thinking maybe something like 'admninistratively assigned by 
>> a human network planner' or maybe 'statically and manually 
>> configured' depending on context.  Other people may use different?
>> 

I don't think there's no means to automatically administratively assign
prefixes to a machine remotely (other than DHCPv6-PD and some use of
Router Renumbering).

If you think there's a method for automatically administratively
assigning of prefixes please say so, thanks, I don't know what is intended.

[large snip]

>> I think you're right.  The autoconf-manetarch does seem to take 
>> into account the underlying well-defined multicast behaviour I'm 
>> talking about:
>>> Link-local Multicast/Broadcast Scope On a MANET interface, a 
>>> packet sent to a link-local multicast or all-ones broadcast 
>>> address reaches the MANET interfaces of neighboring MANET 
>>> routers, regardless of their configured addresses.
>> 
>> That is what I meant ^.  In the Fig.1 scenario above the MR3 will 
>> send an IP message to network-layer multicast address which will 
>> have a link-layer header link-local multicast destination address, 
>> the MR2-Relay will IP-unicast it to the Server.
> 
>  server. But there is none for now. So you do not have the behaviour 
> that you describe, and among other things this is why there is a 
> problem!

Emmanuel, already a DHCP Relay (a new MR2 between MR1 and MR3 in the 
figure above) relays messages as I described in the paragraph above - 
it's DHCP terminology and implementation.

Can we agree on this.

If you want I can make a separate thread.

IF we run this and find some problems with DHCP because something moves 
somehow then I'm all years.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 20:42:27 +0100

> I don't think there's no means to automatically administratively assign
---------------------   ^strike 'no', I meant 'any'.
> assigning of prefixes please say so, thanks, I don't know what is intended.

Do you think there's any means to automatically administratively assign 
prefixes?

Alex
>>>> Link-local Multicast/Broadcast Scope On a MANET interface, a packet 
>>>> sent to a link-local multicast or all-ones broadcast address reaches 
>>>> the MANET interfaces of neighboring MANET routers, regardless of 
>>>> their configured addresses.
>>>
>>> send an IP message to network-layer multicast address which will have 
>>> a link-layer header link-local multicast destination address, the 
>> that you describe, and among other things this is why there is a problem!
>