Subject: [Autoconf] Problem Statement Draft: Comments on the Security Consideration Section

From: "Hasnaa Moustafa" <[email-masked]>
Date: Wed, 4 Apr 2007 22:13:01 +0200

Hi,

As settled during the last Autoconf session in Prague, here are my comments
concerning the security consideration section in the autoconfiguration
problem statement draft (draft-baccelli-autoconf-statement-02).

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

Address Autoconfiguration for MANET: Terminology and Problem Statement

(draft-baccelli-autoconf-statement-02)

*Comments on Section (5. Security Consideration) *

**

**

*I. Some unclear issues: *

- In the statement: Analysis includes trust model and threats for a specific
ad hoc network scenario, where all the routers share a common link ( i.e.
they are one hop away from each other, full-meshed connectivity is
available).

* Firstly: What do you mean by "routers share a common link"? One could
understand that bus connectivity exists between routers, which is not the
case as far as I understand and regarding the description given between
brackets. I suggest revising this phrase or re-formulating it.

* Secondly: Concerning the "mesh connectivity" that is mentioned between
brackets, is this a requirement for security? I wonder if the mesh
connectivity is related to RFC 3756 (IPv6 ND Trust Models and Threats) or it
is a proposition that you are proposing. I checked RFC 3756 and I did not
find something specific concerning mesh connectivity. Otherwise, if you are
proposing this requirement, would not this lead to a mismatch with the
deployment scenarios discussed in your draft (Section 3).

- Last statement in the first paragraph: you are mentioning as attack
example "DoS attacks on DAD procedures". Actually, DoS could take place
during the whole autoconfiguration process and is not limited to the DAD
process.

*II. Trust models in RFC 3756 versus address autoconfiguration security: *

**

**

- I noticed that you focus on the third trust model given in RFC 3756, which
reflects classical ad hoc networks scenarios. However, I think that the
second trust model in RFC 3756 is also related to the autoconfiguration
problem statement (the model representing a public network run by an
operator, where the clients do not trust each other but they rather trust
the operator " RFC 3756 Page 4 -> Section 3 -> point 2"). This trust model
fits well in the case of connected MANET which you mention in section 3.2 in
the problem statement draft. IMO, both trust models "classical ad hoc" and
"public network" should be considered.

I wonder if you have already considered both trust models or not in the
security consideration section, as I find between the lines that you are
mentioning the case when MANET is connected to the Internet! But no explicit
citation to the related trust model is given.

**

**

**

*III. Suggestion of some re-phrasing and minor re-wording:   *

**

**

- In the statement (in particular, analysis includes trust model and threats
for a specific ad hoc network scenario…). IMHO, the word analysis does not
match well with trust models. Also, mentioning "specific ad hoc network
scenario" lets one thinks of a precise scenario of deployment, however the
RFC 3756 gives a trust model for classical ad hoc networks scenarios however
not explicitly mentioning threats related to multi-hop communication. Thus,
I suggest modifying this statement as follows (trust models are derived and
threats analysis are given considering ad hoc networks scenarios, where
nodes do not directly trust. However, threats related to multi-hop
communication are not clearly presented in [6]).

- In the second part of the first statement (as in other type of IPv6
networks) -> I suggest putting "types" instead of "type"

- In the statement "Although the document does not explicitly address
MANETs, where routers can be multiple hop …."-> I suggest putting "multiple
hops" instead of "multiple hop".

**

*IV. Multi-hop Communication:*

- The second paragraph gives some guidelines for securing the
autoconfiguration process while taking into consideration multi-hop
communication. It is mentioned that the security analysis has to be extended
to include threats specific to multi-hop communication, and that routing
security is out of the scope. I totally agree, but I would like to add a
couple of points:

  * There is a need to develop a trust model taking care of multi-hop
communication (may be this point should be mentioned before the point of
security analysis and threats)

  * Attacks such as Man-in-the-middle and non cooperation in messages
forwarding worth consideration.

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

Regards,

Hassnaa Moustafa

France Telecom R&D (Orange Labs)
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 05 Apr 2007 16:55:55 +0200

Hi all,

The problem statement has been updated subsequent to the last WG meeting 
in Prague. Minor clarifications since -02, including:

- Interpretation Issue: Section 4.3.2. (Address Uniqueness Requirements) 
was rephrased not to be wrongly interpreted, as pointed out by C. Perkins.

- Terminology Issue: the term "Internet Gateway" leading to some 
confusions, as pointed out by R. Wakikawa. It is not used anymore, and 
now the document only mentions MANET Border Routers (MBR), a term 
already defined in the Architecture draft.

Your review and your feedback is requested now. There was already some 
feedback today about the security section. Anything else? Check this link:

http://tools.ietf.org/id/draft-baccelli-autoconf-statement-03.txt

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Apr 2007 21:22:46 +0200

> already defined in the Architecture draft.

Emmanuel, let me give again some feedback, some I already sent publicly 
but I don't see it reflected.

-Do you consider CGA/HBA, privacy extensions for stateless autoconf and
  rfc2464 to be autoconfiguration mechanisms?  How about teredo and 6to4.
  Should those be mentioned?
-in addition to the problem of assigning addresses, should the problem
  statement describe the fine distinction between assigning a prefix (by
  eg dhcp-pd, or 6to4 derivation) and distributing a prefix (like OSPF
  LSA, or rfc4191).
-should the document mention the problem of subscribing to some
  mandatory IPv6 multicast groups?
-should the document state that DHCP (Relay) _can_ manage multi-hop
  networks?
-should the document allow for wired networks as well (not only
  wireless).  Consider that what some people may qualify as MANET nodes
  are accessed by human controllers via usb (IPv6 over USBnet is btw
  unspecified but has a nice way of working).
-should the document point to existing means of existing 'MANET'-related
  link-layers for auto-configuring addresses.

This is just things that strike me at a first view.

Thanks,

Alex

> http://tools.ietf.org/id/draft-baccelli-autoconf-statement-03.txt

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

---

From: Teco Boot <[email-masked]>
Date: Thu, 05 Apr 2007 23:39:11 +0200

Hi Emmanuel,

Here some comments.

RFC4291 defines the interface ID length: 64 bits. Reading 4.1, I could
conclude other interface ID lengths are introduced. Is this proposed?

On DAD, RFC4429 discusses probability of collisions. At time of writing,
there was a discussion on wireless interfaces and DAD, the interface has no
state change when moving and thus the DAD is not triggered. A reason
accepting a risk on collisions is that interface IDs should be unique if
burned in L2 addresses are used and collisions are extremely rare if truly
random interface IDs are generated. What is the reason for a new mechanism?
It could be DAD for manual configured addresses, but why use these on a
MANET interface? Or support for IPv4 Link Local addresses?

Teco

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 17 Apr 2007 16:59:01 +0200

Hi Teco,
see inline:

> conclude other interface ID lengths are introduced. Is this proposed?

No. Section 4.1 does not address interface ID length. It just states 
that an IPv6 address (128 bits long) must be configured.

> MANET interface? Or support for IPv4 Link Local addresses?

As far as I understand, aside from the address generation aspect, RFC 
4429 does not address multihop detection, and does not deal with the 
standalone (no connection to the infrastructure) case. So in this 
regard, new DAD mechanisms are needed, if the scenario needs DAD.

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 17 Apr 2007 17:13:48 +0200

Hi Alex,
see inline

>  Should those be mentioned?

As far as I know, these can be considered as solutions for address 
generation schemes. However, they cannot provide any multihopDAD 
services, another aspect of the problem we are addressing.

>  eg dhcp-pd, or 6to4 derivation) and distributing a prefix (like OSPF

The distinction between routing tasks and configuration tasks should 
indeed be clear. In my opinion it is already clear enough in the draft?

>  mandatory IPv6 multicast groups?

This is out of scope. We are initially focusing on issues concerning 
address configuration/assignment. No unicast routing, no multicast routing.

> -should the document state that DHCP (Relay) _can_ manage multi-hop

The draft already mentions DHCP and hierarchies as existing solutions. 
It also evokes their shortcommings regarding node mobility, paritioning, 
merging, multihopDAD etc.

>  unspecified but has a nice way of working).

For wired networks, I guess standard solutions are fine  ;)  so there is 
no additional problem to be mentionned here.

>  link-layers for auto-configuring addresses.

I don't understand your question. We are dealing with layers addressed 
by the IETF, i.e. not lower layers?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Apr 2007 08:35:22 -0700

> regard, new DAD mechanisms are needed, if the scenario needs DAD.

Because of partitions/merges/node movements, as far as I
can tell the only way RFC4429 can absolutely assure address
uniqueness in MANETs is if the optimistic nodes were to keep
their addresses in the optimistic state indefinitely (e.g.,
by setting 'DupAddrDetectTransmits' to some value representing
infinity). That would entail 1) having the optimistic node
proactively sending NS every RetransTimer msec, and 2)
sending initial packets through a default router and only
taking direct paths to neighbors after receiving a Redirect.
This might not be optimal for all node types and networks.

RFC4429 does make the case that by the Birthday Paradox the
odds of collision when using random self-generated addresses
like CGAs is "vanishingly small", but unless a node remains
"permanently optimistic" an unrecoverable collision is possible.
(Of course, the odds of collision for manually-configured or
administratively-assigned addresses is *much* higher.)

Fred
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Apr 2007 18:41:00 +0200

Emmanuel Baccelli wrote:
> Hi Alex, see inline

Hi Emmanuel,

>> Emmanuel, let me give again some feedback, some I already sent 
>> publicly but I don't see it reflected.
>> 
>> -Do you consider CGA/HBA, privacy extensions for stateless autoconf
>>  and rfc2464 to be autoconfiguration mechanisms?  How about teredo
>>  and 6to4. Should those be mentioned?
> 
> generation schemes.

Ok, I can call these methods 'address generation' schemes instead of
'address auto-configuration'.

It's still true that two nodes using any one of those schemes can
communicate ok.  The node generates an address locally and can use that
address to communicate to other nodes.

> However, they cannot provide any multihopDAD services, another aspect
>  of the problem we are addressing.

I'm not sure I understand 'multihopDAD service'.  It reads to me that
the requirement is to have address auto-configuration that delivers
unique addresses across a network, uniqueness that resists merging of
subnets.

This is too generic and corresponds to absolutely no real need.  There
is no real need of multi-hop sub-networks that merge together at the
will of an unknown event, and across which addresses must be and stay
unique.

I am insisting very much on this.

If some two subnetworks merge, we most certainly know why.  And we
should state that why.

>> -in addition to the problem of assigning addresses, should the 
>> problem statement describe the fine distinction between assigning a
>>  prefix (by eg dhcp-pd, or 6to4 derivation) and distributing a 
>> prefix (like OSPF LSA, or rfc4191).
> 

It's not to my reading.  The draft doesn't cite neither RFC4191 nor OSPF
nor any other routing protocol.  I suggest it does, it's very simple to
cite RFCs.

In your oppinion, in which part of the draft is there explicit that
there's a difference between a mechanism for assigning a prefix
(DHCP-Prefix Delegation) and a mechanism for distributing a prefix (OSPF
LSA, RFC4191)?

>  address configuration/assignment. No unicast routing, no multicast 

I see, I didn't mean multicast routing.

For IPv6 Neighbour Discovery on a simple link to work ok it needs to be
able to subscribe to link-local multicast groups; not multicast routing.

For IPv6 Stateless Address autoconfiguration to work, for DAD, and for
DHCPv6 to work, there is an absolute need for the host to be able to
subscribe to multicast groups.

This is true for any initial phase of any new address autoconfiguration
mechanism (usually discovery of something).  Hence any new method of
address auto-configuration that involves communicating with somebody
else in IPv6 will have this need of subscribing to IPv6 multicast groups.

> The draft already mentions DHCP and hierarchies as existing 
> solutions. It also evokes their shortcommings regarding node 
> mobility, paritioning, merging, multihopDAD etc.

Ok.

>> wireless).  Consider that what some people may qualify as MANET 
>> nodes are accessed by human controllers via usb (IPv6 over USBnet 
>> is btw unspecified but has a nice way of working).
> 
> For wired networks, I guess standard solutions are fine  ;)  so there
>  is no additional problem to be mentionned here.

Well, an example of MANET network has a number of mobile phones
communicating with WiFi.  However, for controlling each phone, one needs
to connect a laptop to the phone.  That connection is with wired USB.
There's no IPv6-over-USB specification, so I'm not sure which standard
solution you mean :-)

I think the problem this draft has is that it assumes that MANET
networks are exclusively wireless.  I think wired segments can very well
appear in a MANET network, at least USB.

>> -should the document point to existing means of existing 
>> 'MANET'-related link-layers for auto-configuring addresses.
> 
> I don't understand your question. We are dealing with layers 
> addressed by the IETF, i.e. not lower layers?

I think all MANET networks are very much dependent to a large extent to
the nature of below link-layer.  That dictates lots of things about the
nature of the MANET network.

A number of link-layers addressed at IETF as 'foo', are wireless and can
be good MANET constituents.  For example IPv6-over-802.15.4 in 6LowPAN
WG, very much MANET like.  A document in that WG defines alternative
means to generate an IPv6 address for such nodes, different than
rfc2464.  These 802.15.4 nodes are clearly candidates for being MANET nodes.

Alex

---

From: Shubhranshu <[email-masked]>
Date: Thu, 19 Apr 2007 20:31:59 +0530

Hello Alex,

Please see inline.

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
>>> mandatory IPv6 multicast groups?

I do not see any problem here of subscribing to the multicast groups e.g. for
DAD purpose. It would help if you could elaborate on the particular problem 
you are referring to. 

> else in IPv6 will have this need of subscribing to IPv6 multicast groups.

Any MANET node can simply join, say, solicited-node multicast address, and send
NS message for DAD, just like in any IPv6 network. In the absence of MLD support, these 
can be statically assigned and would work fine. If there is MLD support, there still seems
to be no issue. Do you mean there is need for a new way to achieve this in MANET 
environment?

- Shubhranshu

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Apr 2007 19:12:18 +0200

Hi Shubranshu,

Shubhranshu wrote:
> Hello Alex,
> 
> Please see inline.
> 
> ----- Original Message ----- From: "Alexandru Petrescu" 
> <[email-masked]>
>> 
> I do not see any problem here of subscribing to the multicast groups
>  e.g. for DAD purpose. It would help if you could elaborate on the 
> particular problem you are referring to.

I might have over-state it as a 'problem'.  I think the problem
statement draft should (1) list the multicast groups to which a MANET
node should subscribe prior to AUTOCONFiguring a unicast IPv6 address.

>>> This is out of scope. We are initially focusing on issues 
>>> concerning address configuration/assignment. No unicast routing,
>>>  no multicast routing.
>> 
>> For IPv6 Neighbour Discovery on a simple link to work ok it needs 
>> to be able to subscribe to link-local multicast groups; not 
>> multicast routing.
>> 
>> For IPv6 Stateless Address autoconfiguration to work, for DAD, and
>>  for DHCPv6 to work, there is an absolute need for the host to be 
>> able to subscribe to multicast groups.
>> 
>> This is true for any initial phase of any new address 
>> autoconfiguration mechanism (usually discovery of something). Hence
>>  any new method of address auto-configuration that involves 
>> communicating with somebody else in IPv6 will have this need of 
>> subscribing to IPv6 multicast groups.
> 
> 
> Any MANET node can simply join, say, solicited-node multicast 
> address, and send NS message for DAD, just like in any IPv6 network.

Right, this should be stated, IMHO.  But formulated more in AUTOCONF
terms, not just DAD terms.

Also, any DHCPv6 server must join a all-servers group in order for
DHCPv6 to work.

I think the document should (2) state that AUTOCONF address 
autoconfiguration may involve an initial 'discovery' phase and that 
phase should happen with a multicast method, otherwise it will not 
scale. (the 'problem' could be that if multicast is not used for 
discovery then discovery is not scaleable).

> In the absence of MLD support, these can be statically assigned and 
> would work fine.

I'm not sure what you mean by 'statically assigning' an IPv6 multicast
address.  Can you elaborate.  Do you mean setting up local filters in a
driver?  Or you mean 'ifconfig add _a_multicast_address'?  I think the 
latter can't scale, while the former doesn't work on some link-layers.

In absence of link-layer multicast support (and not of MLD) then
discovery phase of any AUTOCONF mechanism doesn't scale, and that's a
problem.

> If there is MLD support, there still seems to be no issue. Do you 
> mean there is need for a new way to achieve this in MANET 
> environment?

No, I didn't mean anything special for a MANET environment.

For MANET environment: I've suggested to add _wired_ links to definition
of MANET.

If there's no MLD support, and no link-layer multicast support, then any
address autoconfiguration mechanism can not scale well (the number of 
dropped discovery messages grows with the number of nodes - should only 
depend on number of discovered entities).  And this is a problem that I 
meant.

Alex

---

From: Shubhranshu <[email-masked]>
Date: Fri, 20 Apr 2007 18:14:21 +0530

Hello Alex,

Please see inline.

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Shubhranshu" <[email-masked]>
Cc: <[email-masked]>

> node should subscribe prior to AUTOCONFiguring a unicast IPv6 address.

Ok. Let me first see if there is any MANET-Autoconf specific issue here or not
and then list or not this in the Autoconf problem statement draft. Please see below comments.

> discovery then discovery is not scaleable).

Right, seems we are in agreement here.

> latter can't scale, while the former doesn't work on some link-layers.

I meant setting up local filters in the driver. True, the later cannot scale
and filter approach does not work well on all link-layers. Those link types
would demand something different such as IPv6-over-foo, just like in any IPv6
network with such link characteristics.  

> discovery phase of any AUTOCONF mechanism doesn't scale, and that's a

Again, I see this as general problem and not specific to MANET environment
or am I missing your point here ? 

> For MANET environment: I've suggested to add _wired_ links to definition

I think yes, we need to consider wired links as well in the MANET definition. 
 
> depend on number of discovered entities).  And this is a problem that I 

Agree, thanks for bringing this to the list.

- Shubhranshu

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Apr 2007 17:32:03 +0200

Shubhranshu wrote:
> <[email-masked]> To: "Shubhranshu" 
> <[email-masked]> Cc: <[email-masked]>
> 
>>>>>> -should the document mention the problem of subscribing to 
>>>>>> some mandatory IPv6 multicast groups?
>>>>> 
>>> 
>>> I do not see any problem here of subscribing to the multicast 
>>> groups e.g. for DAD purpose. It would help if you could elaborate
>>>  on the particular problem you are referring to.
>> 
>> statement draft should (1) list the multicast groups to which a 
>> MANET node should subscribe prior to AUTOCONFiguring a unicast IPv6
>>  address.
>> 
> 
> Ok. Let me first see if there is any MANET-Autoconf specific issue 
> here or not and then list or not this in the Autoconf problem 
> statement draft. Please see below comments.

Yes.

>> Right, this should be stated, IMHO.  But formulated more in 
>> AUTOCONF terms, not just DAD terms.
>> 

Ok, so can we go as far  to say that _if_ there's a discovery method
using multicast addresses then a MANET multicast address should be used?
  Or should we say that an existing (non-MANET) multicast address should
be used?

>>> In the absence of MLD support, these can be statically assigned 
>>> and would work fine.
>> 
>> I'm not sure what you mean by 'statically assigning' an IPv6 
>> multicast address.  Can you elaborate.  Do you mean setting up 
>> local filters in a driver?  Or you mean 'ifconfig add 
>> _a_multicast_address'?  I think the latter can't scale, while the 
>> former doesn't work on some link-layers.
> 
> I meant setting up local filters in the driver.

Ok, I think this is not the same as doing an 'ifconfig add a
IPv6_group_address' on a interface, ie statically assigning.

> True, the later cannot scale and filter approach does not work well 
> on all link-layers. Those link types would demand something different
>  such as IPv6-over-foo, just like in any IPv6 network with such link 
> characteristics.

So I think until we have references to those IPv6-over-foo behaviours
with respect to multicast we can't eliminate the use of MLD, and we
should solely rely on MLD in the textual description.

>> discovery phase of any AUTOCONF mechanism doesn't scale, and that's
>>  a problem.
> 
> Again, I see this as general problem and not specific to MANET 
> environment or am I missing your point here ?

What link-layers does the MANET environment use?  If one knows that then
one can say whether there's something specific for a MANET environment
or not.

>> For MANET environment: I've suggested to add _wired_ links to 
>> definition of MANET.
> 

But both this document and the MANET-arch document
draft-ietf-autoconf-manetarch-01.txt only talk 'wireless' not 'wired'.
So both should be updated?

>> If there's no MLD support, and no link-layer multicast support, 
>> then any address autoconfiguration mechanism can not scale well 
>> (the number of dropped discovery messages grows with the number of 
>> nodes - should only depend on number of discovered entities).  And 
>> this is a problem that I meant.
> 

Thanks for acknowledging it.  Can we have the scalability issue, its
multicast solution and the eventual necessity of multicast address for
AUTOCONF purposes in the problem statement draft?

Alex

---

From: Shubhranshu <[email-masked]>
Date: Mon, 23 Apr 2007 17:54:30 +0530

Please see inline

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Shubhranshu" <[email-masked]>
>  Or should we say that an existing (non-MANET) multicast address should

I see related points that needs to be considered here. Discovery of
which nodes are you referring to? If you mean only those nodes that 
are on the same link then existing  addresses could be used. If you are
referring to discovery of all nodes in a particular MANET then you 
might need to use a MANET multicast address.

If we are assigning an unique prefix to each Ad-hoc node then we need not 
discover every other node for address-autoconf purposes. 

> IPv6_group_address' on a interface, ie statically assigning.

Right. had used the term to convey approach if nodes are not subscribing to the 
multicast group. 

Yes.

> one can say whether there's something specific for a MANET environment

OK, could have started with this question then. 
As you would expect, MANET specifications are applicable to all link types. 
However, AFAIK, MANET implementations & related documents mostly
assume WiFi like link characteristics. 

Yes.

> AUTOCONF purposes in the problem statement draft?

Agree that if there is no MLD and link-layer multicast support then there could
be scalability issues. But here we can consider the case where MLD is supported. 

- Shubhranshu

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Apr 2007 16:23:32 +0200

Shubhranshu wrote:
> <[email-masked]>
>>>> 
>>>> autoconfiguration may involve an initial 'discovery' phase and
>>>> that phase should happen with a multicast method, otherwise it
>>>> will not scale. (the 'problem' could be that if multicast is
>>>> not used for discovery then discovery is not scaleable).
>>> 
>> Ok, so can we go as far  to say that _if_ there's a discovery
>> method using multicast addresses then a MANET multicast address
>> should be used? Or should we say that an existing (non-MANET)
>> multicast address should be used?
>> 
> 
> are on the same link then existing  addresses could be used. If you
> are referring to discovery of all nodes in a particular MANET then
> you might need to use a MANET multicast address.

I mean multicast addresses that may be specific to AUTOCONF address
auto-configuration.  It may indeed be that MANET multicast addresses
(those proposed in draft-ietf-manet-iana) are all that's needed.

> If we are assigning an unique prefix to each Ad-hoc node then we need
>  not discover every other node for address-autoconf purposes.

This is something I consider open to question in the MANET Architecture
document (draft-ietf-autoconf-manetarch-01).  I don't think it's neither
useful nor necessary to assign _a_ unique prefix (shorter than /128) per
node in a MANET network.  We can discuss that separately.  I think the
prefixes are assigned to subnets, not necessarily to routers.  I mean
both should be possible (assign a prefix per node, and per subnets).

>>> True, the later cannot scale and filter approach does not work
>>> well on all link-layers. Those link types would demand something
>>> different such as IPv6-over-foo, just like in any IPv6 network
>>> with such link characteristics.
>> 
>> So I think until we have references to those IPv6-over-foo
>> behaviours with respect to multicast we can't eliminate the use of
>> MLD, and we should solely rely on MLD in the textual description.
>> 
> 
> Yes.
> 
>>>> In absence of link-layer multicast support (and not of MLD)
>>>> then discovery phase of any AUTOCONF mechanism doesn't scale,
>>>> and that's a problem.
>>> 
>> What link-layers does the MANET environment use?  If one knows that
>> then one can say whether there's something specific for a MANET
>> environment or not.
> 
> OK, could have started with this question then. As you would expect,
>  MANET specifications are applicable to all link types. However,
> AFAIK, MANET implementations & related documents mostly assume WiFi
> like link characteristics.

Three things here: (1) necessity to clarify which link-layers have been
experimented with MANET protocols, (2) necessity to clarify which
link-layer triggers have been used and (3) necessity to that a
MANET protocol is actually run at link-layer (no IP addressing).

WiFi-like interfaces may cover a wide range of interfaces.  802.11a, b,
g, n have different bandwidths and latencies, ranging from simple to
almost two orders of magnitude in difference (2Mb up to 250Mb); and
uplink/downlink assymmetry characteristics.  This should give large
differences in terms of IP protocol behaviour, at least in corner
extreme cases.

Wireless-PAN may also be a very good candidate link-layer.

802.11s is another way of looking at MANET protocols.

In this context, would you consider that MANET networks are only for
802.11b 11Mb/s? (where it was experimented presumably the most).

The second thing (link-layer triggers) seems to be mentioned in the
MANETarch document, section 7 cross-layering; but not enough precise
IMHO, simply because it doesn't say which trigger.

The third thing is that it _appears_ to me that some forms of MANET
protocols specified at IETF may have been used as link-layer protocols,
for _some_ link layers.  By abuse of language IMHO then people say that
a certain IETF MANET protocol is actually in widespread use.  But such a
IETF MANET protocol run at link layer is completely differently
implemented from what's specified at IETF, at least because there are no
IP addresses, no port numbers.

This relationship between MANET protocols and link-layers (link-layer
message encapsulating eg a DYMO-like  message) should clarified IMHO.
Or I should be directed to a place where that's clarified.

>> 
>>>>> If there is MLD support, there still seems to be no issue. Do
>>>>> you mean there is need for a new way to achieve this in MANET
>>>>>  environment?
>>>> 
>> draft-ietf-autoconf-manetarch-01.txt only talk 'wireless' not
>> 'wired'. So both should be updated?
> 
> Yes.

Ok.

>>>> (the number of dropped discovery messages grows with the number
>>>> of nodes - should only depend on number of discovered
>>>> entities).  And this is a problem that I meant.
>>> 
>> Thanks for acknowledging it.  Can we have the scalability issue,
>> its multicast solution and the eventual necessity of multicast
>> address for AUTOCONF purposes in the problem statement draft?
>> 
> 
> Agree that if there is no MLD and link-layer multicast support then 
> there could be scalability issues. But here we can consider the case
> where MLD is supported.

Ok, I agree to consider only AUTOCONF cases where MLD is supported.

Alex