Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt

[Emmanuel Baccelli <[e-mail]>]

Hi Alex,

I also read the draft, and I did not see any fundamental difference in with
the draft the working group has been working on for months, i.e.
draft-ietf-autoconf-adhoc-addr-model. This is quite reassuring: apparently
the working group did not totally waste its time until now ;) More comments
below.


On Wed, Oct 21, 2009 at 11:42 PM, Alexandru Petrescu <
[e-mail]> wrote:

> AUTOCONFers,
>
> I just noticed this draft just announced:
>
> [e-mail] a écrit :
>
>> A URL for this Internet-Draft is:
>>
>> http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-model-00.txt
>>
>
> This draft says, among others:
>
>    MANET interfaces MUST also be configured with IPv6 Link-local
>>   addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]).
>>   Two main concerns may arise when considering the use of IPv6 Link-
>>   local addresses:
>>
>>   o  Address uniqueness: the event of having two duplicate addresses in
>>      the same link has proved to be very low (EUI64 derived interface
>>      identifiers very rarely collide, since MAC addresses are expected
>>      to be globally unique), and even some mechanisms have been
>>      proposed to reduce the collision probability
>>      [I-D.soto-mobileip-random-iids].  Therefore, in most scenarios it
>>      is safe to assume that the probability of having two or more
>>      duplicated link-local addresses in a MANET is negiglible.  For
>>      those scenarios, in which this cannot be safely assumed, we refer
>>      to the DAD considerations of Section 3.3.
>>
>>   o  Reachability: connectivity among neighbours in wireless links may
>>      be intermittent and/or short-lived.  Therefore, the use of link-
>>      local addresses may lead to reachability issues, since two nodes
>>      that were in direct coverage range at one moment, might not be
>>      anymore shortly after.  These problems might also arise in wired
>>      networks (nodes going up/down), but it is not the common case.
>>
>>   Having brought to attention these concerns, it is further left to the
>>   designers of MANET routing protocols (and other protocols) to
>>   determine whether link-local addresses can be used in an effective
>>   way.
>>
>
> I must say I fully agree with the above text, because it says link-locals
> are "MUST".  It is more positive towards link-locals, I agree with it.
>


draft-ietf-autoconf-adhoc-addr-model-00 says no different, in section 6.2:
"an IPv6 link-local address is assigned to each interface as per [RFC4291]".
Similarly, in the same section, the draft also mentions concerns with the
use of link local addresses.

The difference is that draft-ietf-autoconf-adhoc-addr-model-00 also
concludes on the matter (a model should offer such conclusion in my mind, if
not, it is not a model). The conclusion is, in section 6.2, that it "should
be encouraged to primarily focus on configuring IP addresses that are not
link-local". So in effect, link-locals are not forbidden, but their use is
discouraged. Note that implicitely, the same conclusion is in
draft-bernardos-autoconf-addressing-model-00.txt.




>
> I agree with it more than I agree with this text in
> draft-ietf-autoconf-adhoc-addr-model-00.txt:
>
>>   Note that while link-local addresses are assumed to be "on link", the
>>   utility of link-local addresses is limited as described in Section 6.
>>
>
> ... which has a negative co-notation in that use of the "limited" word.
>


If you think the term "limitations" is too negative compared to the term
"concerns" (used instead in
draft-bernardos-autoconf-addressing-model-00.txt), swapping such words would
be an easy fix. Personally, I do not have any issues with this.

If anybody has practical suggestions as to how to modify
draft-ietf-autoconf-adhoc-addr-model-00, please let it be  known at this
point.

Appart from word-tweaking here and there, it seems that we essentially all
agree on the model. So let's move on to actually designing solutions...

Regards,

Emmanuel