Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00

["Teco Boot" <[e-mail]>]

Carlos Jesús Bernardos Cano wrote:

>	- Section 3: "The configuration proposed by this model is
>applicable to
>any router's IP interface" --> I wonder if this should be changed to
>"The configuration proposed by this model is applicable to any router's
>IP MANET interface" or something like that. By saying "any router's IP
>interface" it may seem that the configuration of "non-MANET" interfaces
>would also follow the guidelines provided by the document (i.e., /128,
>no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state
>that the model is for MANET interfaces.

Somewhat agreed. The problem is wording: what is MANET interface?
I say: interface with MANET protocol running. Then your suggestion
is also not completely correct. Interface to Wireless Link? Also
not completely correct, as there are many wireless links that do not 
have problems with on-link prefixes.


>	- Section 4: "no two such interfaces in the network should be
>configured with the same subnet prefix" --> this at least conflicts with
>LLs. (I'm not bringing up __here__ again the LL issue, just pointing out
>that the document should be revised to avoid this kind of contradictory
>statements: "Note that while an IPv6 link-local address is assigned to
>each interface as per [RFC4291]" and "no two such interfaces in the
>network should be configured with the same subnet prefix".

Agreed.


>	- Section 6.1: "These limitations are further exacerbated by the
>smaller pool of IPv4 link-local addresses to choose from and thus
>increased reliance on DAD" --> if link-locals are not considered and
>"normal" DAD is not considered suitable for MANETs, I think this
>sentence makes no sense and should just simply be removed.

Yes, we should remove all references to DAD. It is to controversial.


>	- Section 6.2: "Routers cannot forward any packet with link-local
>source or destination address to other links..." --> this is rather
>obvious and not particular of MANETs, why is this described in the
>document?

See my other posting. This is an important argument, as in the normal
case the link is expected to be somewhat stable, and there is an
interface down trigger to signal the link down. On xxx interfaces,
there is no such a trigger. And when nodes get out of range,
connections using LLs are affected while connections with non-LLs
are not.


>	- Section 6.2: "There is no mechanism to ensure that IPv6 link-
>local
>addresses are unique across multiple links, hence they can not be used
>to reliably identify routers." --> this is not particular of MANETs
>either, why is in the document?

We should remove this argument.


>	- Appendix A: "MANET Link Model" --> I don't believe in the
>existence
>of a "MANET Link", and I don't see its relevance in an __address
>autoconfiguration__ document. Repeating myself here... I think this
>document and some discussions in the ML deviate from the charter goal:
>we need to come up with a practical ____addressing____ architecture.
>IMHO, we have been discussing instead about "IP over MANET", which to me
>is a rather different thing (well, to me it doesn't even exist, if we
>consider L3 MANETs).

With having the draft-baccelli-autoconf-adhoc-addr-model, we can close
this issue.


>	- Appendix A: "it remains to be determined whether or not the
>scope of
>AUTOCONF includes applications other than routing protocols running on
>the router" --> this is a very important question that we have brought
>in the meeting. I have my personal opinion, but this is irrelevant,
>since there seem to be a consensus (I wasn't aware of it, but Thomas
>stated otherwise). I'd like to ask the chairs to bring this to the ML to
>close this issue.

I think the consensus is that there are applications in a MANET. The MANET 
is not solely for running MANET protocols... .
It is also in the charter:
  It is required that such models do not cause problems for ad
  hoc-unaware parts of the system, such as standard applications running
  on an ad hoc node or regular Internet nodes attached to the ad hoc
  nodes.


Teco.