Re: [Autoconf] Updated ad hoc addressing model document

"Charles E. Perkins" <charles.perkins@earthlink.net> Fri, 05 February 2010 18:34 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2552A3A6D83 for <autoconf@core3.amsl.com>; Fri, 5 Feb 2010 10:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D8JTpRECY4T for <autoconf@core3.amsl.com>; Fri, 5 Feb 2010 10:34:47 -0800 (PST)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id D2C1A3A6C7E for <autoconf@ietf.org>; Fri, 5 Feb 2010 10:34:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=h5EGMVtuGyeZdASwxk1dkGupksYQknX+Jhl0ZiUgdMziHg33DnQ0CiCn8+Ck6u0n; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [12.204.153.98] (helo=[10.166.254.146]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1NdT1l-0000GB-6U; Fri, 05 Feb 2010 13:35:37 -0500
Message-ID: <4B6C64F6.9040807@earthlink.net>
Date: Fri, 05 Feb 2010 10:35:34 -0800
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
References: <be8c8d781001260409qd23d4era0eac47eaeb3dba2@mail.gmail.com> <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <C8A0698C-B04F-475B-B750-842C8786778F@thomasclausen.org> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <4B6B0E85.5050101@earthlink.net> <003e01caa63e$a8d190d0$fa74b270$@nl>
In-Reply-To: <003e01caa63e$a8d190d0$fa74b270$@nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ec7017f710d14f75517b1c14f56ce553350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Updated ad hoc addressing model document
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2010 18:34:48 -0000

Hello Teco,

On 2/5/2010 12:38 AM, Teco Boot wrote:


>
> ... existing IP addressing models don't depend on such clever
> thing. Here, we have the "assumption". Right?

First, I do not understand what the "assumption"
is that you mean here.

Second, existing IP addressing models that you
might be referring to, depend on a model of a
link == communication medium that does not pertain
to all ad hoc networks.

>>                I also do not
>> agree that we must avoid being clever.
>
> Agreed. That is why I use an addressing model that is better resistant
> against failures.

I didn't see which model you meant.



>>
>> I read this, and had to smile.  Of course there's no reason
>> to avoid link-locals for 1-hop traffic as long as you _know_
>> it's one hop.  In fact, blast away.
>
> OK, now we are there.
> MANET protocols that use RFC5498 can perfectly use link-locals.
> Same for L2 address resolving, as ND does.

You can be very mysterious at times.  I admit defeat,
unable to meet the challenge of understanding your meaning.

As you well know, ND works for nodes in range.
As specified now, it does not work for nodes that
are not in range, in case you wanted to tackle the
onerous project of creating a wireless link that
exceeds the transmission range of any node in the
link.


>> But for people who are running networks without such
>> comforts, assurance of availability for a L2 communication
>> channel is often necessary or at least highly desirable.
>> Then suddenly your link-local address is potentially
>> (a) invalid (b) unavailable or (c) ambiguous.  These
>> are normally considered poor indicators for IP-based
>> communications.
>
> What happens if your ULA or global is (a) invalid,
> (b) unavailable or (c) ambiguous?
> I don't see a difference with link-locals.
> Link-locals are used for protocols that require 1-hop
> communication or when no other addresses are available.
> In the latter, it is also 1-hop only.

Teco, whenever you ask this question, please first
revisit my explanation which I have offered perhaps
a dozen times in the past:
- determining link-local uniqueness should not require
   multi-hop protocol action
- with ad hoc networks, you may not know if a node
   with a link-local address on a particular link
   is actually adjacent/neighboring/in-range/...

On the positive side, you have asked the same
question so many times that I have the answer
instantly at the ready.


>> And that is the problem needing solution in the
>> general case, which has motivated the current form
>> of the addressing model document.
>
> With IPv6 in mind, the general case can easily include
> link-locals. Wouldn't it be nice to support IPv6 basics?

I have IPv6 in mind.  The general case does not
easily include link-locals over wireless media.

The particular specializations _may_ include
link-locals.

Wouldn't it be nicer to avoid requiring
particular specializations when the general
case is just waiting for us to quit delaying
and standardize an already-known solution?

Regards,
Charlie P.